"Not a tester, so what are you then?" you might ask.
Being that offending is generally not helpful.
Unless you try to catch the attention as I do in this blog post ;-)
Let's digest the situation in detail.
A friend of mine attended my Scrum Developer class and caught fire during the "Testing" module where we talk about Code Quality, Testing, Test-First approaches, TDD and more.
Boom! After that class, he was on a mission to convince everyone that TDD is the only way to do things.
The 1st day back at work he talked about improving the team and trying TDD and got the following statement from his colleague:
Henri (made up name): "I don't write any tests since I am not a tester".
I know he handled the situation quite well, but he asked me for advice.
One thing to consider is the underlying question to this, which might be: "How do we get people to change their behavior?"
So here are my thoughts.
Yourself?
Things to consider for yourself:
-
Why is the practice or tool that you are suggesting any better than the current way of doing things?
-
Can you explain the value in the proposed change?
-
Can you lead by example?
-
Do you have enough patience and skills to teach others?
I would try to work on yourself before trying to change others.
Roles?
I see this a lot, that people are focused on their role or job title, forgetting the bigger picture of the team and purpose of the work they are doing.
-
Are we 1 team that focuses on the Sprint Goal?
In a Scrum context, there is no "tester", "programmer" or "architect", we are all professional engineers that deliver value through collaboration. -
No matter what, do we stand together and support each other?
-
Are we doing whatever is necessary to deliver a usable product every Sprint?
Done?
Henri: "I don't write any tests since I am not a tester".
Ask: "How do you know when you are done?"
-
What is on our Definition of Done?
-
How can we build a usable, tested and fully integrated product increment every Sprint?
-
Are we doing that already? Why not?
Tests are as important as documentation
Documentation is needed, and one good way to document how software *must* work are tests. I emphasize *must* since documentation only documents how the software might work.
We learned too often that documentation gets out of sync too easily. I blogged about the "Why are *automated tests* so important?" on my personal blog.
Quality
Quality is everyone's responsibility in a Scrum Team. There is no QA Team in a Scrum context, which means the whole Scrum Team is responsible for delivering high-quality software that works and is fully tested.
Quality attributes that are important:
-
Does it work at all?
Huh! -
Does it work well?
-
Is it deployed and useable?
Are the users able to access it? -
Is it useful?
-
Is it successful?
-
Does it make the impact we wanted to achieve?
-> Yes! Value is key
Testing can be fun
Tests are code
Are you a coder?? Yes? Tests are code. So write some tests, especially so that you can sleep better at night.
Still not willing to write tests?
Ask yourself: How can I help? What can I do?
You can always get the team coffee
Show support. We are in this together.
Get test infected in 3 days in my Scrum Developer class!
Recently I did a a video interview where I ask my students 3 questions about the Developer class.
Check it out here https://www.youtube.com/watch?v=oLxBV4hPMkU