Some wise sages from mountains said: Each member of Agile Team is a Developer.
What he meant by that is everyone should have at least be able to do a job of other team members, maybe not as efficient. And Yes I am aware that reality, it is not always so brilliant.
But if you can, you should grasp for this chance to develop actual production code.
Why? Cause it will help you understand developers!
I will share with you a story that happened to me recently. You will see how it changed my view of developers. It helped me understand how easy it is to miss-communicate and how prideful we are in our work.
This story Is about the first time I had a feature that was complicated enough to deserve proper Testing by another tester.
And it was strange to experience to be on the other side.
Storytime
So it started as it quite often starts with testing new complex feature. Tester had reported the first bug. After some debugging turned out that it was environmental issues, not the actual bug.
– How many times do we face that? You go to the developer, and he tells you: 'no it is not a bug! The environment is a not setup properly.’ But looking at it from another side. Now I have to spend half hour or more time to check that something was the wrong configuration. – up to that point, I was of the opinion that environmental issue is a bug. (That what I hate testing on dev env and prefer some common environment so I can show it reliably). Now I understand developer frustration on those bugs. There are not they fault and yet they have to investigate and fix it because tester reported and is happy. [expand] I am exaggerating here. But I am sure some developers feel exactly like that [/expand]
Tester also has an excellent case! If he can’t setup environment to test, it is also possible that people responsorial for deployment will have the same problem. But seeing both sides of the coin, I can say that root of the problem was miss communication. I could have explained better the setup process.
So after some time, another bug comes – again wrong configuration. Again communication fault.
And then comes another bug. -This time miss understanding of the requirements. Can’t blame him I had the same problem. But again at the root is miscommunication, we could have written specification better during planning. Or I could explain to him better what I’ve got from PO.
And then another bug. My first assumption was wrong data. – He was wrong three times so far (well not wrong but they weren’t actual bugs).
My knowledge of the code (or rather pride of my work) led me to believe that.
I’ve known that results he is getting are not possible for proper data. So that was my diagnoses. I was looking into it to show which row of data was wrong so I could explain why.
Of course, I was wasting time. It was the actual bug. And straightforward one. But not obvious…
Moral
Reading this article so far do you think he is the bad tester?
The answer is no he is excellent better than me. The whole situation made me reflect on how many false positives I’ve found. At this point, I don’t have concrete data but a lot.
But each such bug is making us look like a boy who cried wolf. Look when he finally found the actual bug I thought it was again false positive. And probably this is what most developers think when we bring them bugs.
Plus it also made me think, outside of developer testing, and code reviews no one is testing automation. How many of that kind of bugs are we missing there? (I will explore this more in the revisited version of my presentation link – That I will be making on days 2017)
So One more time if you can do actual development it will give you a new perspective and better understanding of your teammates. And this is an experience that it is not easy to understand by just reading. Believe me knowing it and experiencing it is not the same
But if they oppose you touching codebase? Fight for it! I won’t tell you how. I was fortunate enough that I had only to ask. But there are others who had to fight. Read Agile Testing by Lisa Crisp it should give you few ideas how to fight for it.
If that would be a problem, I think there maybe another way to achieve this: one of my colleagues Michał Buczko had a nice talk on Dev Pair Testing.
Small bonus:
A friend of mine was showing fluent interfaces on her workshop in writing test automation in Selenium Webdriver.
The reaction of one of the participants:
„Now, I know what devs are doing all day 'Dot, Enter, Dot, Enter’ – it was a joke, but it kinda shows how little some of us understand them.
If you want to read more test inspirations check here.
And one more time:
Develop Something!
Hi there,
I really think you are making a good point here: Some people are so focused on getting numbers that would raise anything as defects and that can disturb the team.
In my opinion, this is due to the fact that the work of the testers is commonly measured for management by the amount of defects they have raised, and that creates the „wrong competition”.
„The good competition” is harder to measure with numbers, but I think that when you are in a team and you all feel you have a common goal, it creates some sort of simbiosis that can help increasing productivity and communication within the team.
I’ve seen this happening even more when everybody is both developing and testing: When the competition is high, people tend to try to make look bad „the enemy” and attacks are a common thing.
I believe this is all bad management, if the team feel connected, then the goal is to have a good quality product and you embrace when they give you feedback rather than feeling „attacked” by it. On the other side, people would tend to give constructive feedback rather than looking for any flaws .
Thanks TestLynx,
I do agree, lots of issues could have one of its roots in bad management but I wouldn’t call it one of the main problem.