SHARE THIS POST

There’s been some buzz in recent years within software development circles. A methodology has been thrown around and while some praise it, others sometimes cringe. Maybe you’ve heard the term once or twice, maybe you’ve formed an opinion, and maybe you still have questions. Of course we’re talking about DevOps. In particular, we’re talking about how DevOps may affect Quality Assurance.

The manner in which the DevOps methodology is frequently misused has led to some unintended negative consequences. Done correctly, DevOps can have a staggering positive change in a company’s software development lifecycle. But done incorrectly, as it often is, it can have the opposite effect. Misused DevOps methodology can lead to developer burn out, undue stress on QA professionals, and shoddy customer-facing products. The scariest part for those of us in QA is the misguided notion that the DevOps methodology will eliminate the need for dedicated QA.

What is DevOps

First, a quick primer on our subject matter. Ask ten software professionals what DevOps is and you’re likely to get ten different answers, and this is where the problem starts. At its simplest definition, using a DevOps method means that previously isolated teams such as development, QA, Business, and Operations communicate more frequently, more in depth, and work together in a collaborative manner and share responsibility for the end product.  This isn’t unlike other methodologies out there, such as Agile. And like similar methodologies, DevOps aims to help teams put software and services into production faster and with higher quality.

With a stress on communication, integration, automation, and collaboration, teams use tools and policies to facilitate faster delivery with increased quality. Many teams aim for continuous improvement via extremely fast release cycles with smaller, incremental changes that pose less risk due to affecting such small parts of the system. There’s certainly nothing wrong with that at all, isn’t that what we all want? The split between good DevOps and bad DevOps seems to happen when teams decide just how to achieve the speedy delivery they want.

Misuse #1 – The Jack-of-all-trades approach

Some teams misconstrue DevOps to mean that each member of the team plays multiple roles. The developer is also the DBA and the build manager, for instance; the BA is also the QA person, so on and so forth. This kind of ‘jack-of-all-trades’ approach is necessary for small startups who don’t have the capital to hire larger teams. But it means that corners are cut, individuals are stressed to the max, and each different task that a person branches out to perform is done with decreasing quality. People specialize for a reason – one person cannot know and do everything well for an indefinite period of time. Continuing this kind of process as the company grows and the demand increases will only rapidly burn out team members. Not to mention that continual task switching actually slows people down and costs both time and money.

Choose the right person for a specific job. It’s to any team member’s advantage to have multiple skillsets – it makes them more employable as an individual and more indispensable as a team member. It’s also great for the team and business to have team members who can perform multiple roles when the need arises, but it should not be the preferred state.

Misuse #2 – The release-too-fast approach

Some teams release multiple times a day and such a rapid release schedule inevitably means cutting corners. As those of us who have been in QA for a while know, QA is often a big target for such cuts. It seems as though we’ve only just gotten to the point of full acceptance of how valuable effective QA is for a team, and now those managers who never really bought into it are using DevOps as an excuse to cut QA again. It’s not overt since they do claim that they desire quality, but they just don’t allow for the time to actually achieve it. The time constraints DevOps methods can put on teams means that the meticulous manual testing just isn’t viable.

This speed at the cost of testing and quality assurance does not result in a quality end product. And, releasing poor quality software – no matter how quickly – is not beneficial for any business. While DevOps methods can aid in speeding up releases, it needs to be tempered with equally efficient quality assurance.

Misuse #3 – The automate-everything-approach

The major push now is to automate, automate, automate. Unit tests, functional tests, even delivery. Again, in theory there’s nothing wrong with automation, but in practice every single aspect of development and QA cannot be automated. Doing so leads to removal of the human element of actually using and exploring a system the way a human is apt to do. Removing that aspect can lead to glaring defects that end users will ultimately find.

Automated tools can merely check code, they can’t actually test. They can’t problem solve, they can’t explore and find different paths, and neither can they determine aesthetics or usability. While testing should always be supported by tools, it still requires a human element. Testers need tools and should know how to use them and use them well, but these tools can never replace the tester despite how badly a manager may want them to. Meaningful exploratory, human testing will always be necessary. But there will continue to be managers who misconstrue DevOps to mean replacing the testers with an automated tool that simply checks code.

Final Notes

The deeply collaborative, quicker released, and higher quality products that DevOps aims for simply cannot be done without adequate testing. Properly used, DevOps requires more testing, not less, but the testing itself needs to be more efficient. Without a doubt automation is necessary and testers need to adapt their skills to a faster paced world.

While all testers really should have some level of coding skills, we can’t and shouldn’t assume that the future of all quality assurances lies in testers becoming programmers. Developers aren’t the only one expected to multi-task, testers need to as well. It would help to learn some architecture, some coding skills, and the business aspect. The more that a QA professional can do, the more beneficial they are to any team, but they’re still needed as testers, not developers.

QA professionals should always keep their skills up to date and keep an eye to future needs in this ever-changing world of technology. But should they be worried their jobs disappearing? No. They should learn to automate, keep their skills fresh, maintain the ability to adapt, and understand that a human tester will always be needed. At least until SkyNet is created.

Note: This article was recently published in October-November edition of Tea-time with Testers magazine –>http://media.wix.com/ugd/c47e45_c0ea1fa2e85a4605960efe03b822f4ae.pdf

About the Author

The author, Ruslan Desyatnikov, is the CEO & Founder of QA Mentor. He created QA Mentor to fill the gap he has witnessed in QA service providers during his near 20 years in QA. With Ruslan’s guidance, unique services and methodologies were developed at QA Mentor to aid clients in their QA difficulties while still offering a high ROI. Ruslan offers monthly seminars aimed at imparting his extensive testing knowledge that can be applied to start-ups as well as large companies. To learn more about QA Mentor and testing services please visit www.qamentor.com or contact Ruslan directly by sending email to rdesyatnikov@qamentor.com