Bloggo back to the blog
I was really enthusiastic about the theme for this year’s conference, as I am passionate about sharing my views and experiences. However, I wasn’t selected as a speaker this time. With this post, I do want to share the abstract that I submitted under the title “Contagious Testing”.
I stated my key points as follows:
1. Prove your value to the team, and people will listen to you.
2. Learn the tools and language of developers & analysts. Give feedback, become involved in their work.
3. Do some causal analysis beyond reporting a defect. This earns you respect and saves the team time.
Only once someone has proven their value to the team, will people listen to what a tester has to say. I am a person who believes in learning by doing, leading by example, and thinking outside of the box. I will give examples of those three, and how my cross-functional approach of testing is contagious towards the people around me.
Being able to deliver value to a team is a matter of attitude. Try to keep defects from being introduced, or duplicated, rather than trying to find as many defects as you can. Actively help to improve the requirements before they are implemented.
Secondly on providing value, give fast feedback by testing small parts of the product as they are being developed. Don’t accept a big bang delivery. Even in a traditional setting, early testing is desirable, because late exposure of problems would delay the project. As I said before, how can you possibly do an ‘intake’ of your test environment, before the first delivery of a product into that environment?
The 3rd part of adding value is analyzing defects.
Many testers think that is ‘not their job’ to analyze the cause of a defect. It’s easy to just report the erroneous behaviour, and then stop. But you’re not making friends that way, because any defect you report just adds to the work load of your colleagues. In the process of testing, it often takes only a little amount of time to dig deeper. For example, you may already have looked into the test database and have found the relevant piece of the code, just to be able to perform your test. In such a case, it would save the team time if you also try to do some analysis.
Remember, if you are willing to do a little bit of code analysis, then your team members may be inclined to do more developer testing, or they may ask you to do some testing together.
By being involved in the work of your co-workers, you can involve them more into testing.
My contribution to the Testing Manifesto workshop at EuroSTAR in 2008: Agile teams are test-infected (Kent Beck) => Be Contagious.