It seems that I know Alan for ages through his Tooth of the Weasel posts that I monitor using the Ministry Of Testing blog feed. In his lecture, Alan presents his summary of some of the Modern testing principles. I know about those through his blog posts, we even had a five-minute talk at our last Testival Conference.
Alan and Brent made a list of seven modern testing principles as a result of their discussions about software testing on AB Testing Podcast. A and B are the first letters of their names. Alan first introduced his dog Tera and promised that she would not interrupt his talk (I have never heard of dog interested in testing).
At that time, Alan was Test Architect at Microsoft (now with Unity), and he wanted to share testing topics with other software testers (got advice from his Microsoft coworker Michael Hunter). That is how the AB Testing podcast started.
We predicted inevitable, a tester/developer conflict.
Book alert, How We Test Software At Microsoft. Alan was a co-author of this book. The book was published in 2009, and Alan revealed that at that time, Microsoft had a developer/tester ratio of 1:1. Around that time, Agile evolution started, and Alan found Agile very promising. He read Agile Testing by Janet And Lisa, which also helped him to shape modern testing principles. At Microsoft, developers become testers, but the path was also in the opposite direction, testers become developers. Some with success and some failed.
Testing needs to happen, and not just by testers.
Modern testing just documented what was going on in testing at that time. It was contrasted to traditional testing, but what was traditional testing according to Alan:
In traditional testing, the feedback loop is too long.
The primary reference for modern testing principles was the book:
Business first, the customer owns the quality, and everybody can test were controversial principles. Reactions from the community were positive and negative. Negative ones were triggered by the fear of losing the testing role. If everybody could test what I would do?
And DevOps term was coined.
- System thinking where we consider the performance of the whole system, with a focus on business value
- Amplify and shorten the feedback loops from right to left, where left is a developer with his code.
- Culture of continual experimentation and learning
We need to accelerate the development team. Team velocity could be slow or fast. What could causes slow velocity:
- code review
- dependency on another team
- what should we code?
Doing team retrospectives is very useful in identifying reasons for slow velocity. And here is why you should get rid of the scrum testing column. First, this column makes developers throw their code over the wall to testers.
Without the testing column, developer knows that part of the definition of done is testing.
For testing, it will get help from the test team.
Only customers truly evaluate quality.
Book Alert. The Five Dysfunctions of a Team by Patrick Lencioni.
Who owns the quality? Everybody. Traditional testers think that mixing quality and business value is dangerous. Alan asks, which product has higher quality:
- No bugs and no users?
- 50 bugs with workarounds and 100 000 users?
In the end, we need to have a balance between engineering quality and fail to deliver. Tera was sleeping during the presentation so this could confirm my heuristic that dogs do not have an interest in software testing.