Deriving test cases from state transitions

Apparently, the relationship between test cases and their sources (requirements, state transitions, famous defects) is not trivial. There is no one-to-one-mapping. It would be an over-simplification to limit test cases to those transitions that are shown on STD. A prudent practitioner treats STD as a reminder, as a teaser, while advancing into a very different phase of software process and while creating something totally new, namely creating test cases.

·        A naive user, someone you grab from a street in random - is great to start a usability test. Such person will diligently exercise those functions that are visible to him/her and will keep learning the new system in front of him, until he gets bored.

·        A professional tester (the one who is paid to write test cases) will generate a huge number of tests within a shortest time. These tests will surely cover all documented requirements. As a colorful C-level report showing bi-directional traceability - will accompany test cases.

·        And then, there is an Old Guard,those folks who's been around the block, so to speak. They refrain from an impulse of going after the largest number of test cases; they methodically go after major defects, nothing but major defects. They understand that bugs are crawling from everywhere, not just coding, but even from poorly written test cases.

Remember that in your battalion and in your test team - you need all types - and random users, and professional testers, and, of course, old guard.

‍

‍

‍

‍

‍