How Does a DEVELOPER See Testers
This is a series of blog post interviews, aiming to help testers understand how different IT departments see the role of a tester. Every tester wants to become a better version of itself, yet not everyone has all the missing pieces in doing that. Hopefully, these interviews will give you new ways of improving yourself.
My developer guest is Sergiu Oltean, passionate software developer which likes to do things properly. He's currently working as Senior Software Engineer at Winnow and in his spare time, Sergiu's writing technical stuff on his personal blog.
1. How do you see, as a developer, the role of a tester within the team?
It depends. If you're Google or Facebook probably you think testers are overrated since they have a CI/CD in place with everything automated (developers write the tests). Also depends on which type of tester.
If we're talking about a tester which writes automation tests, this one has a big contribution to build automation, which means faster deployment times. Is some situations this is a competitive edge.
A manual tester is able to find more edge cases by performing exploratory testing and find things no one thought of. Also some of the tests just cannot be automated (or it's too hard).
From my point of view each team should have both types.
2. How does your activities as developer intersect with tester’s activities?
It's a close collaboration. Both must understand the business details in order to be effective. From a developer's perspective I expect that each bug should be clear as daylight. Should contains steps to reproduce, expected and current outcome. In some cases I even saw GIF's visually describing the issue. In others I was unpleasant surprised by the lack of any details. Just a bug name shortly describing the problem(I cannot read minds).
As a developer, my responsibility is that every bug should only be found once. That means I need to write a unit/integration test for each bug found. Nobody likes the same bug being reopened (especially multiple times).
Developers should not be defensive when a bug arise. I have encountered situations where the developer asked the tester not to log the bug because he will fix it asap. This is just weak. Accept your mistakes and go on.
3. In your opinion, what skills (technical / non-technical) does a tester should have?
In order to be effective you need to be passionate. This is the main driver of doing anything. You don't feel it's work when you enjoy what you do. Posses some detective like skills. Attention to detail, written and oral communication.
Technical I would expect some basic knowledge of networking (http, ip) and some scripting ability (bash at least). An automation QA needs programming skills and deep understanding of testing frameworks. Also to be familiar with processes (i.e Scrum, Kanban) which is valid for any type of tester.
4. How do you solve the “this is not a requirement, it’s a nice-to-have” situation?
You mean it's not a bug, it's a feature type situation. This happens when the developer implements the written requirements and the tester uses the common sense if you want, thinks like a user, but did not read carefully the requirements.
It's like that joke: "How do you know a man is a programmer? Send him shopping and tell him: "Get a loaf of bread and if they have eggs get 10." If he comes back with 10 loaves of bread, he's a programmer." Sometimes (most times) we think like machines and testers like humans. And they both have right in this case. The solution is to go to the product owner and ask him to create another task/story for that feature. This is just an example of a tester creating business requirements.
5. Should developers test their own code?
Hell yeah. I am just gonna state here the testing pyramid from Clean Coder by Uncle Bob.
It's our job to make sure the tester does not find anything. It's an overstatement, of course, but something to use as a guideline. The code should not go to production without tests. The code review should not pass without the presence of tests. This is just common sense.
6. What ratio of automated - manual testing do you consider to be ideal?
The pyramid from above it's a good guideline. The main requirement of automation is to cover the critical paths of the system, the rest is nice to have. Manual testing should not overlap with these and focus on other parts. But exceptions of course exists. Automation and manual are complementary, they do not exclude each other.
7. Is is true or is it just a myth that developers and testers are like cats and dogs?
It depends. We need to look at Conway's Law. They are both true depending on the organization. I personally think that the developers and testers are just wheels in same mechanism. They need to work together and be professionals. And by playing cats and dogs, cats and mice, cops and robbers it's just unprofessional.
8. And how do you make the relationship between developers and testers be healthy?
This is a tough one. It depends on their personalities. But some general guidelines, which apply not only for devs and tester, but for humans in general. Don't blame, condemn or complain. See the situation from the other's point of view. Start the conversation on a positive note, see the things you agree on. Don't be aggressive, as it will put the other on the defensive and build resentment. Build extra work relations (beers, sports).
9. What advice would you give to a tester willing to write code?
First of all you need to invest time. Read a basic programming book to understand the concepts. Do some tutorials. Find a tester who has made this transition and ask for guidance. Spend more time with a developer and ask questions. See if writing code is for you or not. Remember in order to be good at something you need to like doing it first.
Photo credit: James Pond on Unsplash