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 himself, yet not everyone has all the missing pieces to do that. Hopefully, these interviews will give you new ways of improving yourself.

My developer guest is Sergiu Oltean, a passionate software developer who likes to do things properly. He's currently working as a Senior Software Engineer and in his spare time, Sergiu writes 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 who writes automation tests, this one has a big contribution to building automation, which means faster deployment times. In some situations, this is a competitive edge.

A manual tester can find more edge cases by performing exploratory testing and finding 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 do your activities as a developer intersect with the tester’s activities?

It's a close collaboration. Both must understand the business details to be effective. From a developer's perspective, I expect that each bug should be as clear as daylight. Should contain steps to reproduce, expected, and current outcome. In some cases, I even saw GIFs visually describing the issue. In others, I was unpleasantly 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 arises. I have encountered situations where the developer asked the tester not to log the bug because he would 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?

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. Possesses 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 a 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 common sense if you want, thinks like a user, but does 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 rights 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 exist. Automation and manual are complementary, they do not exclude each other.

7. Is it 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 the 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 healthy?

This is a tough one. It depends on their personalities. But some general guidelines, apply not only to devs and testers but to 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 to be good at something you need to like doing it first.

Photo credit: James Pond on Unsplash