Developing applications has come a long way from the days when everyone basically did their own thing and met up at some point to compare notes. DevOps has brought about a change in the mindset that comes naturally to most people, that mindset being “let me finish what I am doing first and then give me your input.” The truth is that nobody really likes being told what to do, and that’s probably why the quality assurance teams are always so “popular” in their organizations.
If DevOps is all about continuous code delivery, where exactly does the QA come into the picture then? A lot of the time there is a common misconception that DevOps is a mad dash to the finish line. Getting code out on time is important, but reducing defects is as important a part of DevOps as anything else.
The whole theory behind automation is that it reduces human error because it runs with a minimum amount of human interference. It’s when things get boring and repetitive that humans tend to make mistakes, and that’s where an automated workflow takes care of the monotonous stuff while the humans are free to use the more creative side of their brains.
Breaking the mold
DevOps has basically changed the role of a QA team in a big way, and it’s only those who are willing to get down and dirty right through the production cycle that are actually going to be successful here. There was a time when quality analysts would walk into a room, do their inspections with an air of superiority, and walk out like they were better than everyone else. With regard to mobile applications in particular, those days are gone, and it just doesn’t make sense to have an external “siloed” QA team anymore.
The more traditional way of thinking is, of course, to always have a third-party QA team to maintain integrity as well as quality control. The new way of thinking, however, is to make QA a part of everyone’s job to a point where QA is ever present throughout the production cycle. Not everyone welcomes change, and there are obviously those who feel like if they keep doing what they’ve been doing all along everything will be fine. But production bottlenecks caused by QA being an afterthought will soon turn them toward integrating QA into their production pipelines.
New default settings
DevOps is all about a direct approach, and thinking out of the box. We’ve been taught to approach application development a certain way, and DevOps looks to break that mindset. Everyone who’s ever taken a written examination of some sort knows that the common practice is to finish writing and then hand your paper over for assessment. That is in essence what the traditional waterfall approach was like for the QA team, except they have to make the assessments and pass it back to the other teams to start over.
A much better practice would obviously be to have the teacher stand by your side and correct you as you make your mistakes in real time. Not only will you save time, you’ll also get outstanding results. Yes, if we were in school it would probably be called cheating, but this is the enterprise and such behavior is applauded, admired, and adopted.
The advantage of having your QA team on the “inside” is that you get their opinion before anyone has even begun making mistakes or errors. A QA team’s input on what features will be feasible, what kind of testing would be required for each feature, and what problems may be encountered is something invaluable, to say the least. Involving the QA team from the get-go also means you have their opinion on time estimation as well as the chance to automate testing at different stages of the software delivery pipeline.
Not to mention that this practice would quickly change the popular opinion that quality analysts are outsiders, it also adds to a company’s foundation. Quality needs to be something that lives and breathes throughout the organization rather than an outside entity that is frowned upon. If DevOps means continuous code deployment, it also means continuous testing. A test-driven development approach would mean developers test their own functions for errors and don’t proceed further till they’ve been fixed, or “nipped in the bud.”
DevOps, QA, and mobile apps
With regards to mobile applications in particular, the majority of enterprises are moving towards DevOps practices. QA teams are in a unique position where they need to move from their original position between Dev and Ops to both sides, becoming an “all-encompassing” entity. The change from providing a reactive service like doing a quality test to actually helping developers proactively write better code is what needs to happen for successful QA integration into the DevOps workflow.
At the end of the day, it’s all about focusing on what you’re good at. The cloud and DevOps definitely champion this cause as well. While developers may be great at writing code, they’re not looking at things in the same mindset a QA person would, so QA will always be required as an integral part of the production system, albeit in more of a teacher’s role rather than in that of a supervisor.
Apart from evolving into this force that is constantly making quality a part of everyone’s business, QA teams of the future are going to have seriously developed automation skills. Automated testing is the future of QA in DevOps and it’s going to be major part of what QA teams in the enterprise do. Again, with regards to mobile applications, that’s another level of testing, and to be specific, about three levels of testing. Mobile applications first go through automated testing on emulators, then automated testing on real mobile devices in the cloud, and finally functional / UI testing on real mobile devices in-house.
One popular open source automated testing suite goes by the name of Selenium. In fact it is so popular that testing done using these tools is often referred to as “Selenium Testing.” This testing framework works with multiple devices or emulators simultaneously and also supports “hot-swaps.” There are a number of interesting testing tools like Sauce Labs, which has an extensive suite of testing tools based on Selenium and its mobile counterpart, Appium. Sauce even offers real device testing in the cloud, so you don’t need to build your own device lab in-house. Another simple, yet interesting alternative is TestingWhiz’s Enterprise edition that offers over 290 inbuilt testing commands, letting you record and playback tests in a codeless way. HPE Unified Functional Testing, more popularly known by its former name HP Quick Test, is also among the more popular automated testing tools. Some of its features are an integration with Mercury Business Process Training, advanced error-handling mechanisms, and automated documentation.
The future of QA
It would be great if quality was a part of everyone’s job and we didn’t need an additional QA team to perform checks and tests. The future will not be without quality analysts. Rather, we’ll see a dynamic shift in roles and a deeper integration of the QA team in the system, and probably even a new breed of QA that focuses heavily on fully automated testing.
Photo credit: Pixabay