After writing our code and revealing our product, we cannot catch the blind spots in the manual tests we do individually. Because we test our product from the perspective we have when writing. In such a case, we are likely to miss the same blind spots again.
Surely then, It logically follows that we also cannot write automated tests for the 'blind spots' - since we fail to identify them in manual tests to start with?
I've been a professional developer for over 26 years and I write/use automated tests extremely rarely. I believe it is much better to develop a thorough enough understanding of the code you are working with to understand the implications of your changes, know how to test it manually, and be confident in your changes. If you write good code, this is almost always possible.
Relying on automated tests is dangerous and lazy - they often contain many layers of 'blind spots' compounded on top of one another. In an ideal world, this wouldn't be the case... but in my experience, sadly, reality is usually like this.
I disagree. And so does Agile and gated check-ins. I successfully write new tests for every push and have been doing it for years. It allows me to refactor at will.
Weirdly I kind of agree with both of you, I've seen a lot of projects where tests exist and pass but don't actually capture bugs that exist in the software. This gives a false sense of security. I'm guessing that John has a well developed sense of how to write tests for his code and therefore benefits from them greatly.
I personally find writing tests on the back end to be more helpful than exercising the code via a front end - for me its faster to develop. On the front end, I'd prefer integration tests to ensure we haven't broken flows.
First of all, thank you for sharing your ideas. I'm learning some things from all of you and it makes me think :)
I also partially agree with both of you. A manual test is always needed in projects where user experience is very important. But when working with DevOps teams, automated testing is vital to the process. Automated tests are also more cost-effective as they do not require constant control.
Hi Mike, true story: I once put in a fix on an IBM midrange that was declared defective in a week. Total cost was over $1 million USD because it went through 37 translations for each country. They didn't fire me, but I had checked out about 10 books on Software testing. The best was from Boris Bezier. That's how I picked up skilled testing techniques.
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.
Surely then, It logically follows that we also cannot write automated tests for the 'blind spots' - since we fail to identify them in manual tests to start with?
I've been a professional developer for over 26 years and I write/use automated tests extremely rarely. I believe it is much better to develop a thorough enough understanding of the code you are working with to understand the implications of your changes, know how to test it manually, and be confident in your changes. If you write good code, this is almost always possible.
Relying on automated tests is dangerous and lazy - they often contain many layers of 'blind spots' compounded on top of one another. In an ideal world, this wouldn't be the case... but in my experience, sadly, reality is usually like this.
I disagree. And so does Agile and gated check-ins. I successfully write new tests for every push and have been doing it for years. It allows me to refactor at will.
Weirdly I kind of agree with both of you, I've seen a lot of projects where tests exist and pass but don't actually capture bugs that exist in the software. This gives a false sense of security. I'm guessing that John has a well developed sense of how to write tests for his code and therefore benefits from them greatly.
I personally find writing tests on the back end to be more helpful than exercising the code via a front end - for me its faster to develop. On the front end, I'd prefer integration tests to ensure we haven't broken flows.
First of all, thank you for sharing your ideas. I'm learning some things from all of you and it makes me think :)
I also partially agree with both of you. A manual test is always needed in projects where user experience is very important. But when working with DevOps teams, automated testing is vital to the process. Automated tests are also more cost-effective as they do not require constant control.
Hi Mike, true story: I once put in a fix on an IBM midrange that was declared defective in a week. Total cost was over $1 million USD because it went through 37 translations for each country. They didn't fire me, but I had checked out about 10 books on Software testing. The best was from Boris Bezier. That's how I picked up skilled testing techniques.