Timeline for Mathematical / statistical relationship between tests and bugs?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2018 at 9:42 | comment | added | dzieciou | Software engineering is generally hard research domain, especially hard to make generic conclusions. I've been on the other side" we wrote too many end-to-end tests that are more fragile and harder to maintain. We moved them to integration tests -- better isolation, still test more than unit tests. But that's a good question: how do I know my tests contribute to the future of the project? | |
| Jun 29, 2018 at 7:50 | comment | added | Rsf | @dzieciou you are right about over interpretation, I suppose they were trying to make a point. The problem is that even if you find research material there is a good chance it will not be relevant to your case. At the moment I am struggling with a similar question, we produce more unit tests simply because they are easy to write and quick to run but I am not sure about their contribution to the future of the project. | |
| Jun 29, 2018 at 7:33 | comment | added | dzieciou | Interesting read but that's overinterpretation. What they have found in Ericsson is that ". 100% coverage does not entail 100% tested code. ", which means that despite high unit test coverage there still might be bugs, which is expected, that's why there methods of testing like integration testing, exploratory tests etc. However, the question remains which method is more effective, where to put money? Perhaps, lowering unit testing standards (without excluding them completely) and investing more time and resource in other methods is more effective. | |
| Jun 28, 2018 at 17:23 | history | answered | Rsf | CC BY-SA 4.0 |