1. Strict separation between developers and testers is economically viable anymore, at least you are on a headcount conservation diet.
2. It's more healthy than unrestrained growth; enforces to improve. In short, limitations liberate.
3. Any attempt to treat testing as an inferior, second class citizens, engineering activity must be resisted.
4. The first question developers must ask themselves is not how to develop it, but rather how to test it. Testability is THE major design decision factor.
5. It is conceivable to assume that we are capable of developing a bug free software in a sense of avoiding crashes, stuck computers or smashed UI screens.
6. The major risk now is to develop a WRONG software, software which does not fail, looks perfectly OK, but does something wrong from the business perspective.
7. For any new non-trivial system nobody knows upfront what is supposed to do.
7. The only sensible way to mitigate this risk is to prepare functional requirements in a form of acceptance test criteria right from the beginning in a human readable form thus avoiding any possible misinterpretations and at the same time ensuring the possibility to change requirements and the system when we finally find what it's really supposed to do.
8. Today the best tool for this kind of testing is FIT. From FIT specifications the unit tests should be more or less formally inferred.
9. FIT is not intended for other kind of tests (which actually ensure the basic assumption of the bug free software): endurance, stress, system e2e and you name
10. FIT tests have to be specified on per story basis BEFORE the development starts.
11. Ideally all engineers on the team should be capable of doing the both: FIT tests specification and developing, rotating on per need basis. Testing should be a mind set rather than different breed.
12. Exploratory tests are supposed to supplement what we cannot envision in advance, more specifically emerging possibilities and defects which appear only when we put a number of stories together, hence at the end of each sprint. The most promising way is to try to do something from the naive, simple user perspective. Chances are the system will broke quite soon.
13. Exploratory does not mean ad hoc. Requires certain skills, discipline and good reflective capabilities.
14. Any defect found in exploratory test should be root cause analysed to see where did it slip through the acceptance and unit or other kind of automatic test safety net and corresponding adjustments should be made (Toyota stop line principle).
15. Since there still legacy components not developed in agile way a tool for overall management, planning, structuring and reporting about test progress is required. Mercury Quality Center seems to be a valid choice.
16. Need to prepare a convincing FIT example with time-line based functionality.
All this is a really matter of survival on the long haul.
No comments:
Post a Comment