Testing in Agile: The End of QA as We Know It

Testing in Agile: The End of QA as We Know It

What do you mean, who owns quality? Quality Assurance, of course. The kings and queens of quality, the masters of the tests, the lords of the sign-off. Also, people often looked down on as less technical, last to get their hands on the code, first to be blamed when things go wrong. The invisible knights of the manual testing, the unsung heroes of the death march.

Of course, switching to Agile has changed the industry. These days the cross-functional teams all over the world are having stand-up meetings, demos and retrospectives, but what about quality? Who owns quality in Agile?

Unfortunately, the answer is still the same. Quality Assurance seems to continue being the Cinderella of Software Engineering, the poor little sister by the fireplace, unloved and underappreciated, in charge of the most important aspect of software development: quality.

And here's the main problem with traditional QA: testing at the end of the cycle is wrong, regardless of the cycle's length. It is simply too late. For the end result to be of high quality, each step along the way has to be of high quality. Every member of the development team should own and be responsible for quality throughout the entire development cycle.

The introduction of test automation and TDD shifted the balance of the traditional functional roles. These days testers are much more technical than they used to be. They write test automation scripts, incorporate those scripts into automated build and CI/CD process, write SQL queries, and even code. Developers, on the other hand, became much more involved in testing through automated unit test and TDD.

Their roles are merging, creating a much bigger functional and skill-related overlap than ever before, but we still call them "developers" and "testers", as if they are different alien species.

How about we get rid of the traditional titles? Instead of "developers" and "QA", let's call everybody a "Software Engineer". There will be engineers who mostly code and those who mostly test. There will be UI specialists, Database specialists, Testing specialists and DevOps specialists, but at the end of the day, the entire team will work together towards one goal - flexible, robust, user-friendly solution of excellent quality.

How can this be achieved? In three simple steps:

1. Create together

Everything the team creates has to be linked together through interdependence and collaboration. The user stories should drive test and code design. Acceptance criteria should be incorporated into test cases and code changes. They, in turn, will fire up the automated test scripts and unit test.

2. Strive for quality

Everything the team creates should have the overall goal of excellency. Great user stories are thought-through and meaningful. They describe features that create business value. Great software design is simple, innovative, long-lasting and adaptable. Great code is bug-free, robust, testable, easy to understand and maintain. Great applications are user friendly, easy to use, customize, and integrate with other components across the system.

3. Check yourself and check your buddies

And when each piece is created, it has to be tested, which means it has to be checked, then double checked and then explored.

Let every team member check their own work and then switch places and check on everybody else's progress. Ask questions. Suggest improvements. Let the coders review testing scenarios and build scripts. Let the testers do code reviews and analyze deploy procedures. Take holistic approach to the solution and make sure all of its aspects are reviewed by multiple people from different angles. Uncover problems early, and reduce or eliminate the cost of fixing.

QA transformation

OK, so everybody is in charge of quality, does it mean we don't need QA anymore? No, we need them. We need them more then ever.

They've shared some of their responsibilities with their teammates, and by doing this turned into the true Quality Masters. They preside over all processes, share their passion for quality, represent the end user, ensure the system integrity in all shapes and forms: usability, data integrity, consistency, security. Their unique point of view and expertise goes across all knowledge domains: Business, Technical and Operational. They are the bridge that connects different parts of the organization, the glue that holds the team together.

So, forget QA, forget the death marches. Never again should anyone look down upon a Testing Software Engineer. Everybody on the team owns quality, but Testing Specialists are passionate about it, lead others and set the highest standards for one thing that matters most - QUALITY.

Did you like my post? Please like or share with your network. Follow me to read my posts and send me your questions about practical Agile. 

Chris Fischer

Data Analytics | Utilities | Grid Modernization | Enterprise Cloud Architecture | TOGAF | Azure | GCP

7 年

Testing? Who needs testing? That's what customers are for.

Prabir K Bandyopadhyay ? PMP?? PRINCE2 Agile? Practitioner

Senior Vice President and Head of Banking Practice at AQM Technologies

8 年

Good read , Thank you for sharing.

回复
Samarth Joshi

Product Owner Financial Markets Compliance at NICE Actimize

8 年

Probably a decade ago "Independent QA" was the new trend. I am guessing it became a necessity because the whole idea of developers doing the testing did not clearly work out. Why after 10 years are we going back to where we came from? Agile is great because the team keeps delivering something and the stakeholders can see their ideas taking shape but it also brings less quality checks. If you compare the quality gates of a waterfall model with agile there is a huge difference. The entry exit criteria is clearly defined and ownership is not ambiguous. The only problem waterfall had was QA happening much later but that could have been solved by mini waterfall where you have a monthly release and still maintain the quality checks and documentation at every stage. If the tester does coding and developer does testing none of them could be effective in my opinion. Every industry has a separate QA and so should the software industry. I may be wrong but that's my opinion.

Brijesh S.

Consulting Services | MBA, CISA, PMP, CRISC, CDPSE

8 年

Excellent article!!

回复

要查看或添加评论,请登录

Katy Sherman的更多文章

社区洞察

其他会员也浏览了