What is Agile Testing? | 3Ss and 4Cs in Agile Model
Variations and different implementations of Agile
As more organizations shift to agile delivery model, it raises questions among developers and QA leaders. When does the testing happen exactly? The answer is: All the time. With Agile, the test plan is in place throughout. Every time a new update is made to the code, the test team gets their hands on it, verify and feedback directly to the developers.
SHIFT ASIA has two core businesses – quality assurance (software testing) and software development, and we can certainly relate to friction and confusions that are often seen as we encountered the same challenge as we transitioned to agile testing. In this article, we will address common questions we hear from developers and correct interpretation of agile supporting the delivery of successful projects.
Q1: What is the goal of Agile Testing?
Agile testing is continuous, which goes hand in hand with development work and provides an ongoing feedback loop into the development process.
The goal of a collaboration model between agile development and testing team is to sustainably deliver new features fast with quality. Teams that move to agile from waterfall often wrestle with how to incorporate testing time at the speed of agile. Some other teams hustle because there isn’t an agile testing team to efficiently support the developers and move things up the pipeline. These are legitimate challenge, and our company had gone through the same because traditional testing methodologies simply don't fit into an agile context and most of our Japanese customers functioned in waterfall manner as you can imagine.
Q2: What are critical 3Ss and 4Cs in Agile?
In contrast to how development happed in waterfall manner, what is important in the new normal "Agile" is said to be the three S's - Sprints, Standups, and Stories.
Agile testing work around regular feedback from the end user, it also addresses a common problem many software teams have, which is building the wrong solution because the team misinterprets a feature relying on their engineering instincts, rather than what the requirement says or what the end users may want. In order to take action based on those user feedbacks, managing in sprints, having regular standups and understanding user stories (journey) is crucial.
Also, commonly referred 4Cs are: which is to say everything happens continuously where features can evolve in response to changing customer requirements.
• Continuous Build;
• Continuous Integration (CI);
• Continuous Delivery (CD); and
• Continuous Deployment.
Q3: Do we need test cases in agile?
As we know, Agile testing reduces documentation – quick response over process or neat documentations. Therefore, it is flexible and highly responsive to changes based on feedbacks coming from users but it could get messy and we think test cases are must even in agile.
So yes, in agile we do need test cases. Based on stories we mentioned earlier, we create test scenarios, and based on test scenarios, we create test cases. Because at the end of the sprint, developers and testers are required to perform per-sprint closure activities, which we want to use as an evidence to prove what we were set to do has been completed. If your team lacks test cases and track record of bugs, that raises a red flag.
Q4: Does it require change in team structure?
Many would agree in saying that another evolution in agile testing is that testers are no longer a separate unit and no more hatred between the Dev and QA departments. In another words, testers are officially part of the agile development team and though they play different roles, everyone on the integral team is responsible for testing. Yet, 40% of our client teams have semi-independent testing teams - they are test specialists, but they work closely with developers throughout the software development cycle in which our test experts sometime participate in to lend extra hands.
Q5: How do we keep up?
It depends on the skillsets of developers on the team, but agile test cycles can also feature automation and a small fraction of testing involving end users. This way, it saves us time and money, allowing full-functioning agile team to keep up with the development pace.
Our head of development always remind us, “to treat bugs in new features and regressions in existing features differently”. If a bug surfaces during development, take the time to understand the mistake, take user scenario into consideration, fix it, and move items out of the debugging pipeline. If a regression that something worked before but doesn't anymore, then it's likely to reappear, in this write scripts (automate it) to protect against that recurring regression in the future.
Please read on...
Please come back and read our second chapter of Agile Testing and Real Life Interpretations.
And don't forget to follow us on https://medium.com/@shiftasia