Timeline for How to Mitigate Risks Before Delivering a Project with Limited Testing?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 20, 2024 at 8:27 | comment | added | Doc Brown | @gidds: I agree, but I had more a situation in mind where the OP envisions the worst possible bug they can imagine in their software. Even then, the risk to deliver without more tests might be acceptable - or not. | |
| Dec 20, 2024 at 8:21 | history | edited | Doc Brown | CC BY-SA 4.0 | added 252 characters in body |
| Dec 19, 2024 at 10:56 | comment | added | gidds | The range of possible bug impact is even greater than that… Depending on the nature of the software and where and what it's used for, failure could merely mean that a couple of folk elsewhere in the company have to spend a couple more minutes on something, or that a screen used internally doesn't look quite as elegant as it should. Or it could cause many deaths and injuries! | |
| Dec 19, 2024 at 10:51 | comment | added | QuestionablePresence | Risk option C: the result (financial data etc.) is faulty in a way that looks plausible at first glance. Aka a bug is not noticed until the IRS raids your customers offices in 5 years or someone down the line in 10 years notices inconsistencies. Or c* if they externally validate the result anyway so any potential bugs would be caught immediately, massively limiting liability/damage. But as your answer perfectly states: without context from OP no call can really be made | |
| Dec 18, 2024 at 4:53 | history | answered | Doc Brown | CC BY-SA 4.0 |