Manual tester will find 100x more bugs than developer could even imagine, that's just insane what these guys can find sometimes. Manual tester is a must have for a product when quality matters more than speed of development. Quite often for new projects, speed is the main priority. Depends on a project.
Many developers would be happy if you take tests away from them, but I would be sad, it's one of my favorite part and I can't express how much it helps to work on features.
Writing test is mental unload:
first, focus on what your code should do and write a test
now forget about requirements, just write the code to make the test pass, and you have to write it in the way it's not too hard to test, as the result code is more modular and better corresponds to what it should do.
test passed, feature seems to be ready, forget about requirements and code quality, you can focus on what can go wrong, and keep writing test after test for each negative scenario, and after each new test case you write the code enough to solve the case
in the end, re-read test case titles - nothing forgotten? Code is modular and nice to use, it is tested, and now that's a good time to look if there is something to improve and refactor it without worries!
Writing tests is not always simple, but often it is way simpler than supporting complex code, and when you deal with complexity, you're resting while writing test, you're resting mentally when seeing passed tests.
The mental load you have mentioned is what it looks like when we don't write test.
we start writing the code, we keep in mind requirements, building and comparing strategies how it can be implemented - in mind, thinking about code quality in parallel, remembering how the system works and what classes/functions we need to use, if we need to make some change need to be very careful to not break anything, and thinking about what can go wrong all the time.
because of this mental load, it's easier to forget about something, to make a mistake
after you realize something is missing or mistake was done, you make a change with a hope it won't break the rest of the code
when all's ready, you're looking at the mess you've done, want to improve, but... You did this mistake before - "small" improvement just before pushing is absolutely always will break something in unexpected way. Better just leave it.
after pushing the code, you still keep thinking of what silly mistakes I could have left
No confidence, mind is blowing. If you were lucky and didn't add any bug - not writing tests is saving time, so that's sometimes acceptable when speed is in highest priority, project is not too complex, no strong requirements for quality.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
I will emphasize, that I do not mean some test folks will write tests instead of devs! Developers are still writing tests but there is a test manager, that kinda like a coach comes and checks if the right kind of tests were written for the right problems, makes sure best practices are reused, that not every team needs to figure out from scratch how to cover layers.
I believe in the right test at the right time. For some tasks, like transforming data I love to write TDD-style tests, since the input and the output is clear, and I can play with my code to find the most expressive version knowing that regardless how many times I change my mind about it the input-output will be the same. This is truly mental unload.
On the other hand, for a UI prototype that by law of nature will change the moment the first product manager/beta customer touches it I find writing an exhausting test suite counterproductive. Once the requirements are tested by reality, you should cover it with tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Manual tester will find 100x more bugs than developer could even imagine, that's just insane what these guys can find sometimes. Manual tester is a must have for a product when quality matters more than speed of development. Quite often for new projects, speed is the main priority. Depends on a project.
Many developers would be happy if you take tests away from them, but I would be sad, it's one of my favorite part and I can't express how much it helps to work on features.
Writing test is mental unload:
Writing tests is not always simple, but often it is way simpler than supporting complex code, and when you deal with complexity, you're resting while writing test, you're resting mentally when seeing passed tests.
The mental load you have mentioned is what it looks like when we don't write test.
No confidence, mind is blowing. If you were lucky and didn't add any bug - not writing tests is saving time, so that's sometimes acceptable when speed is in highest priority, project is not too complex, no strong requirements for quality.
Thank you for your well-written comment!
I will emphasize, that I do not mean some test folks will write tests instead of devs! Developers are still writing tests but there is a test manager, that kinda like a coach comes and checks if the right kind of tests were written for the right problems, makes sure best practices are reused, that not every team needs to figure out from scratch how to cover layers.
Regarding the statement tests automatically results in code quality: I would be careful with it. There is somebody who is more eloquent on this topic: Testing numbs us to loss of intellectual control by George Fairbanks
I believe in the right test at the right time. For some tasks, like transforming data I love to write TDD-style tests, since the input and the output is clear, and I can play with my code to find the most expressive version knowing that regardless how many times I change my mind about it the input-output will be the same. This is truly mental unload.
On the other hand, for a UI prototype that by law of nature will change the moment the first product manager/beta customer touches it I find writing an exhausting test suite counterproductive. Once the requirements are tested by reality, you should cover it with tests.