Manual QA in AGILE

It was a priority feature which was supposed to be rolled out Live. All the stakeholders were ‘watchers’ for that ticket be it Engineering, Product, Marketing etc. All the Scrum teams were pulled up and aligned with the release schedule as well.

The core team which owned the actual module had successfully developed and tested in QA environments. Unit tests were passed, system tests were done, and automation was a ‘green’ as well.

The team was confident on their module and the core feature they developed.

Finally the code was moved to ‘Staging’ environment, an environment lower to PRODUCTION but a replica of it. Testing was done in staging environment to Integrate the code/ feature with PROD like testing environment and making sure it still works seamlessly.

The Tester executed the tests on core feature and it looked good. He ran the automation for their module and it passed as well. Before moving it to PROD, the tester just decided to do some adhoc test on areas out of scope of their feature. To his surprise he found that one of the important search area was broken and results were Not rendering correctly. He checked in PRODUCTION and it was working fine there, that implies their team has broken that area. The tester alarmed the team and discussed that this was not the part of QA scope as they did not touch that code at all. However being a critical search feature, it would impact a lot of their customers had it gone Live. They later came to know it was due to some other team changes that merged earlier which caused the issue, but since it was not related to their team work, it was Not tested earlier.

Well above is a real time scenario that might happen to any Scrum team which is practicing AGILE.

We typically have different scrum teams which owns their module and team is focused to work on their changes mostly. Since AGILE is timeboxed, it is sprit goal oriented, so the entire team wants to get the feature out as soon as possible, and sometimes not considering the unknown impact of their changes.

‘That’s not my teams work, I don’t know nothing about their module, I didn’t touch their code, it should be the other team’s responsibility’, you might have often heard this if you ever worked in an Scrum team.

So who is responsible for it? Well it could be anyone, be it a bad impact analysis from the team, be it the other team who actually owns it, or it could be a environmental/ configuration issue as well.

However the important thing to understand it that the business should Not be impacted, important is that the customers should not have a bad experience, important is that the brand should not be affected.

So who is the gatekeeper between the entire Organization and the customer world out there?

It is the QA. The Tester who must make sure that only that goes out to the Live world, which is supposed to be, and not a defect or a bad customer experience. A QA is the one who should ensure Quality is still intact no matter how many releases we do in a day, a week, or a month. It is the core job of the QA to make sure that before a customer reports an issue, it should be caught and fixed within the Organization.

With that being said, in the above scenario, the QA did a good job by catching the issue at right time before it was pushed Live.

But why was it not caught before?

The debugging discovered that the code was working fine, the integration was perfect, the API’s were doing what they were supposed to do, all automation tests were passed, so everything in their MVC framework seemed to be working fine.

A deeper analysis revealed that it was the css issue which was introduced as a part of their Front end technology upgrade. The UI was upgraded to use a latest framework. Since it belonged to a different scrum team so the core team did not test that area where the issue was. Since it was a UI issue, this was not caught by Automation as well. Hence it is important to understand a skilled Manual QA’s role as well.

In AGILE we often work on our areas or teams and not touching other pages, areas assuming it belongs to the other team and should work fine. Due to this, we are limited to our own module and functionality but hardly do we know about how the other areas of the application works.

This is opposite to the traditional Waterfall model where testers were doing end to end testing, touching all areas of the application once the feature was developed. The only advantage that I see there is getting the business domain Knowledge and touching every critical part of the application.

However AGILE has several advantages over a traditional approach, but at times the scrum teams miss to do a proper impact analysis or testing coverage owning to pressure from the Product to ship out the stuff sooner which leads to potential defects.

Luckily if you have a strong QA team which can go a step beyond their scope and test the feature thoroughly using his skills and expertise, you may still save a disaster.

With the rapid changing technologies now a days, it is also important for a QA to upgrade itself and be on top of the things. A QA is not a manual QA anymore, he should understand the business requirement right from the initial discussions to final delivery, he should be flexible and communicative as well. He should be well versed with all the technologies their application is consuming. A QA should understand how the components are integrated and working together be it Front end or backend.

So again, even if we use the best technology, the best development team, the best management, when it comes to a a Live feature, it is the QA who stands as a guard before letting your business out to the world. It is imperative to understand the QA role in a scrum team which can save worth millions for an Organization. No matter which technology an Organization may use, we can not rule out a human eye which has the potential to catch the issues which may be missed by an automated system.