|
|
|
|
|
by tbm57
922 days ago
|
|
> To be realistic, it's important to not over-engineer QA measures with a big upfront investment. We shouldn't block progress of the project as a whole and neither will we get the necessary buy-in from all stakeholders with this approach. I suspect that a lot of the bad code that is out there exists because teams are constantly in crunch time where it is important to get certain features out by a deadline. From that perspective, this statement is kind of a contradiction. If every minute is vital to finishing a feature on time, then the act of writing tests will always block progress of the project Basically, I just wish it were more innately profitable to write quality software |
|
So you will deliver that feature, it will fail for your customers, and you will be in panic-mode trying to fix it on live systems. Seriously, that's going to happen.
Finishing a feature must always include at least some minimal time for testing. That testing needs to be done by someone not involved in the development. Developers sometimes misunderstand requirements (or think they "know better") and they will test what they implemented, not what the requirements actually say.