Two of the most popular (and least pleasant) conversations between testers and developers, go like this:
- Testers: “It turns they changed it, but they didn’t bother to tell us!”
Dev: “Oh, we didn’t think it was important!” - Testers: “We told them about this issue long time ago, but they didn’t care”
Dev: “From their explanation it didn’t sound like an important issue”
However those conversations are easily eliminated, by following two simple rules:
- Any change that can affect some portion of the code somewhere should cause a discussion with the goal to understand the risks. Change can be “accepted” with no further investigation/testing if it’s not considered to be risky by all sides, or it can cause the need for additional investigation and testing. I don’t call for discussion around each line of code: I’m sure every team can come up with a unit that makes sense for a particular product (e.g. component, module, or any other definition of functional area). And such discussion is especially important when no other changes are done, no extensive testing is planned in the same functional area, and thus regressions can slip undiscovered.
- Similarly any issue or concern that is being raised, should not be discarded without understanding how it affects the product, which risks it involves, whether it requires further investigation and testing, etc. This especially applies to those “last day” findings, which often are discarded too fast, because everyone is in “Let’s ship it!” mood.
KSBYTES 