So what makes a system/means of managing test cases ‘Agile’? It depends of course. Marketing teams certainly try through the use of smoke-and-mirrors to make their products Agile … and sometimes that works. But to me, there is a barrier to entry.
- Version Controllable – When I am coaching new test teams, I use the phrase ‘If it has value, then it is versioned. If it does not have value, it does not get created’. You need to version for (at least) two reasons; to compare between two versions and to know what is the ‘golden’ copy of whatever you are using for test cases
- Natural Language – Test cases should be made by humans and consumable by humans. That does not mean that that a machine cannot also consume it (such as in the Executable Specifications context).
- Text – Application source code is just text, so why not your test cases as well. They are just as important. But the big thing is that it does not need to be fancy. The facts, and just the facts as it were. It does not need to be underlined, bolded, multi-sized etc. This means you don not need to use MS Word, etc. as the editor. Heck, you don’t really even need to use HTML (unless you are using something like Fitnesse which uses that as it’s storage means). The loophole around this when it is something visual (like a mindmap or screenshot)
- No Fluff, Just Stuff – This is a general comment, but I’ll put it here anyways. You do not need to have version data in your test cases — that is what version control is for. You also do not need an executive summary, or a definition section, etc.Brain On – Testing is a sapient activity; it is brain on. If the person executing the case can do it without turning on their brain, then it is too limiting. Automated Acceptance Tests and Exploratory Testing are parts of Agile testing; rote script execution is not.
Of course, these are all heuristic. There are absolutely situations where each of these attributes are false, but I think those are few-ish and far-ish between.