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?
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 =)))
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?
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.
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.
