Variations and different implementations of Agile

As more organizations shift to an 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, verifies and gives feedback directly to the developers.

SHIFT ASIA is one of the leading software quality assurance companies, specialized in these 2 core businesses, but not limited to: quality assurance (software testing) and software development.

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 the 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 challenges, 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 a waterfall manner as you can imagine.

Q2: What are critical 3Ss and 4Cs in Agile?

In contrast to how development happens in a waterfall manner, what is important in the new normal “Agile” is said to be the three S’s – Sprints, Standups, and Stories.

Agile testing works 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 user feedback, managing in sprints, having regular standups, and understanding user stories (journey) is crucial.

Also, commonly referred 4Cs are: which is 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 documentation. Therefore, it is flexible and highly responsive to changes based on the feedback coming from users but it could get messy and we think test cases are a must even in agile.

So yes, in agile we do need test cases. Based on the 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 evidence to prove what we were set to do has been completed. If your team lacks test cases and a 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 other 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 sometimes participate 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 a full-functioning agile team to keep up with the development pace.

Our head of development always reminds 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 the 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 at https://medium.com/@shiftasia