As a Developer, Sometimes You Should Play the Role of a Tester - España - DEV Community

Descripción

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

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.

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

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

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

Thank you for the great post, that's what many of us need to hear. In my experience in commercial contexts, poor testing and lack of Quality Assurance often not only slow developers down, but also disrupts stakeholders' trust. Agile development and leaving some testing to the end users is fine in moderation but it's our job to ship not just good priest, but polished too

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

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

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

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

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

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

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.

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.

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.

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

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.

Within minutes after installing Sentry, software teams are able to trace performance issues back to a poor performing API call as well as surface all related code errors. Engineering Managers and Developers now have a single tool to optimize the performance of their code and deliver fast customer experiences.