This is a dangerous conceptualization. Testing must be thought of as part-and-parcel of the development activity. We must fight against the temptations to think of an 'integration testing period' or an 'acceptance testing period'.
Here is a list of testing types that I think possibly could be decoupled from the activity of coding, but they are the exception, not the rule.
- Load
- Security
- E2E
- User Acceptance
I know that this is a generally non-controversial position to take, but I am alarmed at how frequently people around me take the 'test as support' view.
What are your thoughts?
I like it. Interestingly, in my current company, there are no dedicated QA personnel. When I started here as the QA strategist my first communication to the company was that everyone has a role to play in quality. Devs write automated tests (unit, integration and soon E2E), do code reviews and feature testing of other dev's work and must verify each story in the integration environment after all automated tests have run... only then does it go to the product team for user acceptance testing. Product does much of what a traditional manual qa testing role does and they are great at it cause they know the product so well and also know the business and customers. Particularly in an agile environment this is the only way that QA actually works well. You don't have time during a sprint to segregate the testing activities.
ReplyDeleteI really like that model. A few questions: What is the size of the company? (10, 50, hundreds?) And how has this impacted your speed?
ReplyDelete