DEV Community

Cover image for As a Developer, Sometimes You Should Play the Role of a Tester
Doan Trong Nam
Doan Trong Nam

Posted on • Edited on

As a Developer, Sometimes You Should Play the Role of a Tester

What is the equivalent of a Software Tester, Quality Analyst, or Quality Assurance Engineer, etc in your country? In Vietnam, we often shorten it to "tester".

Why do I say that developers should also play the role of a tester?

"Playing the role of a tester" here doesn't just mean testing. Because obviously, after coding, testing is a must. But "playing the role" here means you have to approach the problem with the mindset of a tester.

Recently, in the project team I am participating in, we have added a new step to the developer's workflow. We have to write test cases (which was already required before), record videos or take screenshots to prove that we have tested, and the tester will review the test cases before we submit pull requests for the leader to review. Some people may find it redundant and time-consuming, especially when coding is already tiring. However, I believe it is necessary.

Firstly, for the project, it helps to ensure better output quality.

Secondly, for individual developers, I find myself equipped with more skills and mindsets to develop myself.

That's when I realized the importance of playing the role of a tester. So how does a developer — someone always striving to build — embrace the mindset of a tester — someone always looking to break things?

1. Drop the mindset of "Users wouldn't do that bullsh*t anyway."

Most developers tend to have the mindset of "happy case first." This means that we always start by building from the successful scenarios of a feature, and only then consider exceptions such as validation, third-party errors, etc. Testers, on the other hand, always think from the perspective of error cases first. Whether it's entering negative numbers into a money input, entering 31/2 as a date, or even the most ridiculous scenarios that we might consider foolish.
Most testers in my country are women. And I often joke that because women can come up with anything, that's why they work as testers =)))

Contrast
Due to this contrast, sometimes we overlook slightly daunting cases. Just imagine if you approached the problem like a tester, you could cover more edge cases and prevent them from turning into bigger issues. Moreover, it would also avoid unnecessary arguments between the two sides and preserve the harmony 😝

2. Test all related parts, even if you're 100% sure you haven't touched the previous code

Yeah, sometimes what you think is certain turns out to be uncertain. With the human factor involved, achieving 100% certainty becomes even more challenging. Who knows if you didn't accidentally modify a utility or export a function to be used elsewhere? Who knows if you checked which screens call the API you've modified?

War

Sometimes, you don't even trust yourself, so don't wonder why testers don't trust you =)) I've witnessed a colleague arguing with a tester for half an hour just because he was asked to test related parts. He insisted that he didn't change anything in that logic, so there was no need to test it. And he said if there was a bug in that part, it was because of the previous coder, not him. He was also right. But if he had known from the beginning that he needed to test related parts, it would have saved a lot of time arguing. And even if he found out that the bug wasn't caused by him, what's the harm in that??? It still improves the project.

3. If possible, write test cases.

If you have time, write test cases in Google Sheets or Excel like testers usually do. Self-testing is an indispensable process in software development. Imagine every time you fix a bug reported by the testing team, you need to self-test a complete business flow corresponding to the scope of your task. If you have written careful test cases beforehand, self-testing after each fix will be faster.
A good test case file should include:

  • ID or sequence number
  • Description
  • Pre-condition
  • Procedure
  • Expected outcome
  • Test result

4. Take some time to learn about security.

As a developer, you don't need to have all the skills of a security expert. However, you need to grasp some basic techniques to protect your website.

Peace

Sometimes testers are just doing their job. Just like us, they also contribute to making the final product as perfect as possible. But sometimes we think they are finding faults in us. No no, there's no personal attack here. The conflict between developers and testers is a perennial topic. If each side knows how to put themselves in the other's shoes and set aside their egos, then unnecessary conflicts can be avoided. Peace, I'm out.

Top comments (16)

Collapse
 
silviaespanagil profile image
Silvia España Gil

Sometimes or...always.

If is not tested, is not finished. For me QA and Devs must be best friends, their edge cases help us find edge solutions and in the end, the users have the best product possible.

And let's be honest, sometimes QA peers come with some bugs that are just, mind-blowing and I love that mindset.

Testing is the only way we can ensure a quality code. If is it easily broken maybe we need to check it out!

Collapse
 
doantrongnam profile image
Doan Trong Nam

Yes, what I mean is always self-test. But occasionally, be meticulous, careful, and thorough like a true tester. And learn to think, reason like a tester while self-testing instead of having a 'happy case first' mindset during developing

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited

Totally agree with this. Always thoroughly test all of your work - manually. I usually find lots of stuff that QA miss

Collapse
 
marissab profile image
Marissa B

Having a good relationship with the testing side of the house can be a lot of fun. I had a friendly "rivalry" with a Quality Engineer at a previous company where I started to learn his typical ways to break my stuff. I started being more mindful to handle those cases to make my features more robust and stupid-proofed for users, then he one-upped and learned some new testing procedures to dig up weird bugs in the platform itself. It was a fun back-and-forth so we'd have more focus on the intricate, major problems instead of petty little things like "lol this let me enter a string as a number, fix it!" that weren't interesting to either of us.

Collapse
 
bcouetil profile image
Benoit COUETIL 💫

Hello 😊

On your generated cover, you should activate face fixing (if this is Stable Diffusion generated), they look creepy 😅

Collapse
 
doantrongnam profile image
Doan Trong Nam

Thanks for your comment. I used Copilot on Microsoft Edge to create images (they integrate Dall E), and I don't know how to make the faces in the images less creepy =)) Perhaps I'll use a different image

Collapse
 
bcouetil profile image
Benoit COUETIL 💫 • Edited

The new one is perfect ! You can try Stable Cascade for free on huggingface workspaces, faces are better than the initial one you posted 😉

Thread Thread
 
doantrongnam profile image
Doan Trong Nam

lol, the way to avoid creating creepy faces is to choose images without faces. Your tool seems cool, I'll try it in future posts <3

Collapse
 
ranjancse profile image
Ranjan Dailata

We live in a creepy world where nobody is PERFECT :)

Collapse
 
hasan_py profile image
Hasan

Nice post, Testing is one of the crucial parts that developers and stakeholders often overlook when prioritizing fast product development. However, in the long run, as software grows, it becomes increasingly difficult to add new features and test for regressions. Investing time in thorough testing upfront can save significant effort and resources in the future, ensuring a more robust and stable product.

Collapse
 
rsolapade profile image
Raphael Olapade

Yes, most especially in UAT from beginning to the end and allow effective questioning and criticism of your codes; this will allow you to make necessary corrections such that at the end of the day your code will come out stronger and be a friend of users and stakeholders.

Collapse
 
rohiitbagal profile image
Rohit

Ya you are correct mostly at the time of debugging the code ...

Collapse
 
jaga_jaga profile image
Jagatheesh

👏👏

Collapse
 
zoujia profile image
zoujia

Not sometime, it should be always👍

Collapse
 
sreno77 profile image
Scott Reno

I say always. If you don't test your code, it's not ready for users. You, as a programmer, should be able to catch at least 90% of problems before ever passing it off to a tester.

Collapse
 
doantrongnam profile image
Doan Trong Nam

Thanks for the positive feedback! I agree that testing and quality assurance are crucial for trust with stakeholders. Balancing Agile with polished product delivery is key