Working in an Agile environment does not guarantee a “shift left. When you take on the role of Software Tester on a team, you get into a routine after a while. You respond to tickets in the ‘Ready for Test’ column, hope the Acceptance Criteria are clear enough so you can adjust your Test Cases accordingly, plan exploratory tests, think about what features should be added to your Test Automation script… So basically, you work on the “right side” of the scrum board.

Maybe it’s time to adopt “shift left” practices.

Take time to think about the process. Are there steps that can be taken to make the development process more efficient? What can QA do to accelerate the process, provide monitoring, version control, documentation agreements, optimize cross-team communication? A good starting point could be Team Retrospective – how about taking ownership of one of the action items that emerge as a result, or even seemingly minor but recurring issues on post-it bills? Are there frustrations within the team that QA can solve (or at least try to solve)?

Try to convince developers of the importance of actually testing their code. Can they see the compiled result before sending the code? Suggest using tools that analyze Unit Tests, support the code review process, pair programming sessions… This ensures higher quality code before the ticket comes into Test.

Boehm’s Curve essentially states that it is more expensive to fix bugs later in the process. Preventing bugs is one of the results of “shift left. The new feature is analyzed by the UX or analysts, designers provide the design prototypes. At this point, QA can already begin abstract exploratory testing and ask critical questions such as “does this feature deliver the expected value to the user?”, “does this feature solve an existing problem?”, “does the feature add to the complexity of the entire system?” …

The important step is to move from “reactive” to “proactive. Talk to team members, other QA colleagues, team leaders about current challenges. Participating in meetings earlier in the process, where requirements, design, refinements are discussed, is good practice. It is not enough just to attend these meetings, but also to participate in discussions. This is probably easier for experienced Software Testers, but still worth putting into practice.

Blog: Darko Grabovac, M2Q