I remember the days of the waterfall approach, when we were towards the end of a release, scrambling to prioritize the test cases to execute (of course, not all test cases were automated and we only had a few weeks to complete the process). It’s very common for Testers to find new issues after the deadline is past (was the unit/integration testing complete?), and possibly UI issues that we don’t even get a chance to report. When this occurs, there are three approaches management can take for the release. 1) Move forward with the release and follow-up with a patch release at a later date 2) Delay the release date 3. Completely cancel the release.
Is this the way we want to keep releasing products? From a QA perspective, the defect count in the backlog would increase without any control, leaving very little time to refine our test cases. The management of test cases would become an effort on its own leaving very little, if any time to even think of automation or process efficiencies in handling customer defects. This seemingly never ending flow of events becomes very difficult to handle. It can lead to long hours and a sense of a black hole not knowing what will happen towards the end of a testing cycle. Is this your story as well?
Let’s now step into the world of agile, scrum and process efficiencies. This has initiated a sweeping change. But does anyone like change? We were so used to a structured QA process and always believed that there was no better way of doing things. The agile mindset advocated breaking down walls of inefficiency between Development and QA teams and instead viewing both as one team, where everyone works together during the entire process. Developers would test just as would the QA folks. This was a very alien and unusual approach for a typical waterfall QA role to embrace.
Resistance to change was the first hurdle to overcome in this new environment. Acceptance came gradually as communication flows were much clearer and more efficient than before and people learned to work together. Collaboration and team work now was here to stay. All team members had to work on the scope of each sprint and set controls as to the expected outcome and deliverables. This set the stage for a faster release cycle and greatly increased the chances for customer satisfaction. Amidst all this positive energy now induced into an organization, a few questions still lingered in the minds of some team members. Would the agile approach mean the end of the intrinsic value of the QA role? Would there be any testing that QA would still call its own? These questions were natural as all of a sudden test cases became documents that anyone could access and edit/question. There was also a mistaken perception that when a sprint starts, QA personnel would just record test cases waiting for the development team to complete the stories.
The answers to these questions turned out to be quite positive as the true value of the QA role has actually been enhanced to a whole new level in the agile world. It’s just not about writing test cases anymore (based on the Acceptance Criteria) and making sure the basic functionality works. The developer has to do that early on. The QA role has become more specifically geared towards executing test scripts that we could hardly get to before. Routine test cases are now handled even before we step in, and our role is to execute the more rigorous and all-encompassing end to end systems testing scenarios that are honed with a specific purpose of attempting to break the system. The ability to focus the QA effort to the vital few versus the trivial many, leads to catching issues way before the product to the hands of the customer. So the ultimate goal of enhanced customer satisfaction is reached in a whole new way. We give the features they want with quality built in way earlier.
If there are customer issues, how great would it be to actually automate those and run them as part of our regression tests? Of course, not all the defects QA finds will necessarily need be fixed, however, just knowing about these defects allows us to learn about our product’s limitations, (what it can or cannot do) and what features can be added in subsequent releases. If there is more than one team working on different features of the product, QA becomes more mindful about the possible duplication of test cases and the potential to reuse any, thereby ensuring that any individual effort is more streamlined with the intent ultimately being to bring it all together to a single high quality result.
In the agile world there is no more waiting around, instead every minute spent on each sprint is geared towards avoiding the risk of repetitive effort and adding value. This comes to the forefront during sprint review and planning meetings where it’s not just about identifying testing tasks. Unlike the waterfall approach, QA involvement begins as early as the design meetings, in order to infuse the perspective of a customer into the discussion. This sets the stage for a better chance of customer acceptance from the outset. With a more in depth understanding of the features through each sprint, we are better able to identify the gaps in development tasks, ensure completeness of the Acceptance Criteria and reduce the impact of any dependency blocking the story from being tested. When it comes to stories addressing system wide and architecture related changes, QA can continue testing the backend and the data flow without needing to wait for the UI component to be available. Thus functional testing fits like a hand in a glove with the unit and integration testing.
It can indeed be very challenging to work in a QA role in a scrum/agile environment. But with this challenge comes the opportunity to enhance one’s contribution and collaboration for a successful team effort. Effective communication and better time management are skills gained by every team member. Not only does one need to have an open mind to trying something new but also to take on a non-traditional approach to getting a product across the finish line. It is clear that the value gained by the QA Role with an Agile mindset far outweigh what it used to be in the waterfall model. The future for agile QA is bright and exciting.
Connect with Praveena at: firstname.lastname@example.org