I had one other bug that I found really inspiring 2 days agos ("learn from your errors", they say,...). I had to create a project, open it, generate test cases, reopen the project and regenerate test cases to get the bug .
The question is: "why would you test that sequence"? Because you have testing experience? Because, it is written in the requirements? Hum, not really. I have never seen "REQ_451 : after 2 successive uses , the software should not crash". This requirement is really an implicit one.
In fact, this is actually an invariant that is worth writing down as such in a requirements document: "REQ_451 : whenever a project is opened, a test generation should not make the software crash ".
Then, you have several ways to test that requirement:
- The "classical" way. Trust your intuition/experience and find a naughty test case to drive the application mad
- The "LTG" way. Use LTG and define an operation that models your invariant: "if (one of my entities in the system has no parent entity) then the application is broken". Then, model valid operations that modify the parent of an entity and generate test cases, that will try to break the invariant.
- your requirements allow a valid sequence of events that may break the invariant. LTG may find tests that show this behaviour, but then you may just conclude that your specification is not tight enough! There's a breach in the specification and it's nice to know it.
- the broken behavior can only appear because of a broken implementation. Then use LTG to concentrate the fire on that specific spot. Generate more test cases that will vary the conditions where the entities parents are modified.
- Intuition because you focus on what could go wrong
- Attitude because you don't try to guess what could go wrong exactly but more likely you test the range of combinations that should be allowed
- Disciplin because you take time to produce many different combinations (of course LTG helps with that matter,...)
No comments:
Post a Comment