What I wanted most from a test management tool, is to communicate testing setup to customers and higher management: how the testing costs are spend, what level of quality to expect with the current expenses and to what degree we can change this proportion; the test cases we have.
Also the transparency of testing process is necessary to involve developers into test planning, in order to:
I designed the best in my opinion report which makes all that visible. And the data entry is direct edit of this report. That makes the tool very simple - everything is on the same simple view.
(Unlike some other tools with dozen of views to edit test plan, test cases and their steps, test runs, results. Due to complex UI and data model, lack of reasonable reporting, most of the team is blocked from the testing process and all we see are bugs submitted by testers into issue tracker).
Confidence is the key concept. No testing can guarantee 100% absence of errors - another system, different data may reveal bugs overlooked during testing. In the real world there are no 100% guarantees, we act based on probabilities and aim the highest probability of our product reliable work.
Also, in the real world we care about expences - full testing of every version/platform is often too expensive.
We increase the confidence by applying our limited testing resources to the areas where they reduce quality risks most, and by recording results.
The data layout of our test sheets enables managers, developres and testers to plan testig work together, based on:
Applying resources rationally we get the same results at significanlty cheaper cost.
Even in smallest teams of 1-2 members, you can once in a while sit and click through some functionality module of your product. Keeping records in test-sheet turns such a rare testing into a contineous, coordinated and effective process.
The same simple view for all the project participants: product owners, managers, developers, testers.
Everyone sees what exatctly is tested and how.
Provides both high level and detailed view.
You can edit the whole test tree in a single text area.
Most often a test case is described by a short sentence (long specifications are also supported). No need to overly formalize the test specifications - people collaborating via test-sheet know their project and are involved for a long time (years).
When a manager sees in overview that 8 test cases were performed on Map, he already can imagine what those test cases may be, because he knows the project functionality.
If necessary, he expands the test suite and sees a short, informal summaries of the test cases.
Automated testing can not always replace manual testing, especially in early stages of development, when software evolves quickly.
Lets assume a manual test case takes 3 minutes and developing an automated test for it takes 4 hours; if we consider it enough to retest this feature once a month, then the automated test should be in use for 6 years before the time invested pays off. Not all functionality survives that long in agile product evolution.