A sprint world without the testing column

The waterfall model, a classic approach to software development, is characterised by its linear and sequential nature. This methodology involves breaking down the development process into distinct phases, each of which must be completed before moving on to the next.

In many organisations, waterfall has been replaced by the agile methodology, which breaks down projects into smaller, iterative cycles called sprints. Agile promotes flexibility, collaboration and continuous improvement, fostering a culture of innovation, customer satisfaction and a faster time-to-market.

By adopting the agile methodology, we gained the use of “sprint boards.” These are visual tools that help us monitor the advancement of work within each sprint. While the goal is to accelerate development and improve feedback cycles, many teams continue to isolate testing as a separate phase, as evidenced by the “testing” column on their boards. Below, we've listed all of the phases of a sprint:

• Backlog: items that need refinement gathering and analysis.

• To do: tasks that are ready to be started but haven't yet.

• In progress: tasks that are currently being worked on.

• Code review: tasks with development completed and awaiting review by a peer.

• Testing: tasks that are being tested to ensure quality.

• Done: tasks that have been completed and are ready for deployment or release.

This promotes a culture where testing is seen as a final step, executed after the completion of development and reviews, causing any problems to be labelled as bugs and deferred to future sprints. However, the adoption of the “shift left” approach means it may no longer make sense to give testing a designated phase. This is because it's happening throughout the various phases of a sprint.

While the traditional boundaries of testing have blurred, the need for high-quality software remains constant. The primary objective should not be the identification and enumeration of defects. Instead, the focus should be on establishing a robust and error-free development process with clearly delineated steps and exacting requirements.

By adopting a shift left approach, meaning incorporating quality assurance and testing activities earlier in the development lifecycle, quality assurance (QA) engineers and developers are actively involved in these activities from the inception of the development process. This leads to an improvement in product quality and a faster time-to-market.

The QA role has expanded beyond traditional testing to encompass a more strategic and technical approach to ensuring software quality.

Below we list and explain three necessary components for making quality assurance a crucial part of your development team.

1. Refinement: Quality assurance should begin early in the development process, starting from requirement definition or refinement. By considering business logic, action flows, edge cases and potential scenarios, we can minimise surprises during project implementation. And by using a Definition of Ready, teams can ensure that they are working on the right things at the right time, and that they are delivering high-quality results.

2. Development: By leveraging test automation while developing/coding, we can significantly enhance software quality. Unit tests provide granular verification of code logic, while end-to-end tests guarantee a seamless user journey. Early adoption of test automation accelerates development cycles and minimises the risk of critical issues, ultimately delivering superior software products.

3. Code review: Employ exploratory testing with a focus on both technical implementation and user experience. This approach enables the rapid discovery of issues without rigid test scripts or plans. Developers can also conduct informal demos to share their work in progress. This allows for early visibility, early feedback on requirements, and early defect identification. This approach helps us shift left and improve code quality by addressing issues before they progress to the next environment — an important point because bugs become more expensive to fix the further in the process they are found. Defects are communicated directly to the developer, who then rectifies them and presents the revised code in another informal demo.

By fixing problems early, we can significantly reduce costs and eliminate the need for costly rework, when issues are often surfaced at the end of the process.

Is it time to remove the testing column from our sprint board?

By removing the testing column and keeping it in code review, we're removing the natural separation between development work and quality reviews. Using a simple board or a straightforward approach would encourage more conversation and collaboration, leading the team to consider quality throughout the entire SDLC, rather than as a single, isolated phase.

While not all teams have invisible barriers, it's worth considering how visual representations of workflows can impact collaboration. When teams have a strong sense of ownership and continuous feedback, even seemingly fragmented workflows can function effectively. However, if visual cues suggest siloed handoffs, it might hinder their ability to collaborate seamlessly.