Instead of shifting testing to the left – move it there completely!

A lot of articles and discussions are happening with regards to shifting testing to the left. From an agile perspective, this means to move more of the testing effort to the left on the board into earlier swim lanes such as DISCOVERY, BACKLOG, NEXT UP, ANALYSIS, DEVELOPMENT, etc. The ability to get testing involved from the onset is a great thing.

While I wholeheartedly agree with this approach, I’m also of the mindset that this is where testing should reside full-time, and that in most cases, they do not need to be involved on the ‘right side’ of the board.

I’ve always questioned the value of having testers acting as “gate keepers”, “double checkers” or “QA’ers” to execute the same tests that their teammates who are building software can do themselves. This is quite often a wasteful exercise with minimal value.  In the olden days of waterfall, this was necessary, as developers were often isolated from testing and weren’t even aware of how their issues were going to be tested. With agile, comes the ability to have testers work with developers to design the test strategy, what and how it will be manually tested, what will be automated, document the tests, identify edge/corner cases and explore and learn about the product. If testers are sharing and documenting all the testing needs on the ‘left’ of the board, is there really a need for them to test on the ‘right’? These types of constrained tests can be done by anyone on the team.

I would argue that the need for testers to “QA” issues is not required.  This is not to say that they could never do so. There can be times where an issue is very complex, tightly integrated and risky where having a second set of eyes to review near the end is beneficial.  But these should be identified as part of the test strategy on the ‘left’ and planned for accordingly.

Today’s modern tester should be focused more on identifying the what and how to test, test coaching, test design/approach, documenting tests, identifying risks, domain/persona research and doing regular exploratory/adhoc testing.

As a tester, think of the value you should be providing your team(s). If you feel the effort of double checking or QA’ing is offering little value, then change the process. Identifying the what and how to test is often far more important than the testing itself. Focus more of your time and energy on testing activities that others will not be doing or thinking of doing!

Work on sharing that knowledge with your team and make quality a team thing.