The testing mindset
You might have already noticed on yourself that the mindset during testing is entirely different than the one during coding. This causes problems with testing your own code and ensuring quality. But if you accept this fact and work around it, you'll produce better code with better self-QA. Not testing the code you wrote every so often is a lack of professionalism. Company QA does not count; if they push bugs back to you, there is room for improvement in catching them. This is one of the differentiators between people who you'd like to work with and those you wouldn't.
I developed the habit of always testing a feature by clicking through a few cases before shipping. As I usually work as part of a team, shipping code means opening a pull request on GitHub. This practice sounds trivial, but I've noticed that many fellow developers skip it altogether. In many occasions, I've witnessed "completed" features that I could break with a single click.
I've read it a few times that someone other than the main developer should test the code, or in the case of automated testing, write the tests. This is a good practice nevertheless, as it is hard to thoroughly test your own code and account for all edge cases. Also, testing can be done by people who can not write code, and they tend to have lower salaries. So this practice saves some bucks for the business too.
But the only difference is the mindset. When you write the code, you are in a developer mindset, when you test it, you are in a tester mindset. And switching between the two is tiring.
What doesn't work? When you do a testing like:
- See a bug
- Fix it
- Continue testing
You are constantly switching between the two mindsets. As a result, you stop after a few bugs and fail to fix all of them.
- See a bug
- Write it down
- Find all bugs
- Fix all bugs
This way, you don't oscillate between the two mindsets, and you catch a lot more defects. In my experience, after just 10-15 minutes of testing a sizeable feature, hardly any bugs are found later.
The same practice can be applied to automated tests too. In the case of a test-first approach, start by writing all the tests for a given feature and only start the development after that. In the case of a test-last one, write the feature, then write all the tests. The point being, do not alternate between writing tests and writing software.
As a developer, you should test your code before releasing it to other devs, the QA, or to the users. This is the virtue of a professional and highly reliable developer.
But to do it right, don't switch back and forth between testing and coding. If you keep them separated, you'll catch more bugs, and your delivered work will be at a whole different level.