Software Testing

Gone are those days where the team use to work on a project for a long time and the customer would get their required project delivered after a very long time in one go. These were the days where water fall model was predominantly used where fixed phases of software development like Planning, Requirement elicitation, Design, coding and unit testing, Integration testing, System testing and Customer acceptance testing were followed very rigidly. In these kind of software development model, testing team used to have dedicate phase to test the software and any major issues found in the system under test would have huge impact on the project or product quality and on the timeline. Pressure on the entire team would be high to make change and retest the system and deliver on time with good quality. Even handling changes in requirements used to have huge impact on the system to be developed. These are the few reasons which lead to the evolution of agile development model. 

Agile model encourages continuous integration and continuous deployment of the software and the team develops the system in multiple sprints and generally there is no dedicated testing phase at the end of the project. Now the question arises how will the testers contributes in this kind of software development model and ensure they are adding value to the team.

Unlike in water fall model, here the testers have to be involved or engaged throughout the project development from the inception till the delivery of the project. Let’s see how the testers can contribute in agile world.

Sprint planning Session

A member of testing team should always attend planning sessions. This ensures QA is in sync with the development team from the start, and allows QA to identify possible problem areas and risks early on. Just like developers estimate the effort it will take for them to write code, QA should estimate their effort required for testing the code during the planning session. When QA is left out of the planning session, testing effort / time is often overlooked and not included in the sprint’s overall estimates.

Daily stand ups.

A member of testing team should attend daily stand ups. This promotes a collaborative team environment, making QA feel involved and a part of the team. Additionally, by QA being involved in stand ups, they’re able to stay up to date with how the sprint is going and allows them to plan their workload. If a tester has a blocker, they can bring this up during the stand up. QA’s presence in stand ups also gives them a chance to give an update on known issues, which in turn allows developers to keep up to speed on testing progress and plan their own workload

Testing throughout the sprints

In order to deliver high quality software in a short amount of time, testing team need to work efficiently. With testing happening throughout the entire duration of the sprint, the workload for QA is spread out and allows for issues to be found earlier instead of only at the end of the sprint. If you find all the bugs at the end of the sprint, it’s too late. By integrating testing and development, it allows the two teams to work together and resolve issues faster, leading to higher quality results.

Short demo of the system developed so far

It’s hard to argue the value of in-person communication. Assuming QA and development work in the same location, schedule a quick face-to-face meeting to get the demo of each feature developed so far. This allows QA to see exactly how the new feature works and is a good time for them to ask the developer any questions. These hand-offs can also bring to light issues the developer may not have thought of yet. These interactions also help shorten the feedback loop between development and QA.

Sprint Retrospective

Ensure testing team members are part of Sprint retrospectives and help in identifying weaknesses in the system and contribute in determining solutions. QA needs to be involved in these discussions to ensure any concerns they have are addressed before the start of the next sprint. For example, maybe a lot of the work was delivered to QA late in the sprint, leading to a rushed testing effort. QA might raise this concern to avoid it happening again in the next sprint.

Document test cases.

Never skip documentation since the agile manifesto / principles says so. Always have the minimum required testing documentation in place.

Team have to embrace the above discussed points to be successful in agile development world.