“It is Testing that is really slowing the Project down”

“Why are we finding all these bugs, so late in the Project”

“Testers must be testing edge cases to death”

I dont know of many experienced Testers who haven’t heard  some or all of the above statements before .

I heard it again yesterday and that set off a bomb of creative rage that has inspired me to write this post.

This post collates my experiences on what typically ,the root cause turns out to be (when Business/PMO folks perceive that Testing is slowing down things)  and tactics that I have advocated/employed to change the narrative

What it could actually be – 

• That the Project estimates did not take cognizance of Testing risks when planning the Project schedule
• That the Project plan trivialized the Integration work with 3rd party components
• That some of the risks are actually materializing and the schedule needs to be inspected and adapted
• That Testers and Dev Team dont work in a cross-functional structure
• That even in a cross-functional structure , Developers dont help with Testing bottlenecks ( and rather pick the next Dev item from the backlog)
• That your code base is reeling from tech debt
• That you dont measure tech debt (and mistake tech debt related bugs/constraints as “slow” Testing)
• That you dont have automated tests to detect timely regression
• That you compromise automated testing coverage over stability
• That you have dependencies on IT Ops to complete your Definition of Done
• That your Developers only take ownership of the Dev part of Definition of Done
• That Testers are not allowed to directly talk to SMEs/end-users
• That Testers can not articulate their Test approach ( to non-tech folks in the Project)

How could this be changed ?

The narrative needs to move from “blame” to “invovlement”

Have the Testers’ skin in the game in activities that they usually are not involved in ,listen to their feedback and support them to achieve their ideas

Involve Testers (more) in –

• Discussions on choosing a vendor
• Discussions on choosing a solution
• Discussions on designing the solution architecture
• Managing Test environments
• Testing in Production ( yeah, this is actually a useful thing depending on the context)
• Scoping a Project schedule
• Talking directly to end-users
• Challenging responsibilities for Test Automation in the Team
• Determining code standards for the Team
• Technical design reviews

Engage with Testers (more) on –

• Designing Tests
• Eliciting their Test approach and coverage
• Reviewing Automated Test code
• Observing their Test approach
• Eliciting how could Testing could be made better
• Taking joint ownership of quality
• Supporting them to uphold quality standards of the Test process