Annotations from day 10/0702007 of the Sigist conference on Software Testing.
1) When you measure an object’s weight, the weight do not gets affected. Similarly, when you measure software’s quality, you don’t have influence on the amount of quality.
That’s from Rex Black’s lecture (10 worst things).
The lecture was your standard lecture in which a lot of common-sense ideas are put on a slide, but the clarity, order and side-info gives all a better meaning and things get adjusted on your head. I like these lectures, they help to organize your mind, and surely help you to articulate these thoughts later.
The idea in bold above is a very smart one: Don’t try or pretend to be the Quality Factor in the product you are testing. Don’t be a Quality Assuror. Just because you are a Testing Expert, and know how to measure the quality of an application, does not mean you have the power (or meanings) to increase its quality. Testing is not to improve quality, testing is to give a quality measurement. It is a decision making tool.
2) Don’t be afraid of producing a large amount of test cases. If you need to discard a part, at least you’ll know exactly what you’re giving up.
That’s pretty much self-explanatory. It was one of Vipul Kocher’s points on the “Verb and Noun technique” lecture.
This technique allows for a quick and easy mass-production of test cases. And, for those who are afraid of being overwhelmed by all the test cases, the answer is: “No one is telling you to test them all. But now your choice is conscious.”
3) – Company ‘X’ has no written development requirements whatsoever. It is a bad thing?
– Yes!
– It depends.
The above dialog happened during the “V Model” lecture by Geoff. He was talking about a branch of some company (he named it, I wont. Just know that it is quite big…) that systematically don’t have written requirements.
The categorical reply that one participant gave (and most if not all held too) was the obvious – you’ve got to have requirements to be a good boy. How can I test without requirements?
That’s why the answer is so surprising and so refreshing. If an answer is categorical, it is probably wrong. Your cognitive bias is fooling you again.
If this company has a process, on which all stakeholders agree, and on which the testing department has agreed – then it doesn’t matter so much whether there is place for a ‘Write Requirements’ checkbox on it. If the testing department agrees to test without requirements as we know them, perfect.
Summing up, not everything that is different is bad. If it is well analyzed and well controlled, any process can give you results. You can decide on what is important and how much you want to risk.
3.5) You can use a process model as a display of your place on the project, without having to follow the process.
That’s actually the summary of the lecture. Geoff presented a case study, where although the process was not led by the V-Model principles, and did not follow the V-Model path, the V-Model was used as a clever instrument to show all involved parts what are the dependencies between development and testing. It is a clear diagram to show what parts of testing can/cannot be done with/without proper effort from the development side.
Of course… this rule is true for any other diagram/process, not only V-Model. So you probably can choose the model that better suits your necessities. Just be sure not to be biased 🙂 – anyone can pick the model that fits its own interest and try to apply it to the company reality… Managers should be smart enough to spot where the discrepancies are.
4) Don’t be the one to harms MS Windows, or your own application.
On the “Testing the Windows* registry” lecture, Michael Stahl explained that messing with the Windows Registry can surely disrupt your OS system. Or your application. There are even disclaimers on this everywhere. But he also explained that it only messes the system if you (ok, the programmer) let it happen. If all registry inputs are checked and validated before being used, nothing bad will/shall happen.
There is no excuse – the registry is under the developer control (not the other way around)!