Run manual tests - the right way

Features

Manual tests

A healthy coverage of automated tests is always highly recommended, but not everything can be tested by automated tests, no matter how sophisticated they become. Some things are more practical to test manually by a real human being. That's why manual testing still is and will continue to be highly relevant, despite all test automation and AI hype.

Test cases in plain text

Write test cases in plain text. Use any text editor of your choice. Search, replace, copy - naturally. Plain text editing is way more efficient than any custom web app will ever be. Avoid vendor lock-in with proprietary test case editors.

Test cases in Git

Keep your test cases in a Git repo. Get full history, visibility and traceability. Use the most mature, industry-standard tools in the world, catering for a whole suite of use cases. (Example: Want to approve test cases? Use merge requests!) Store and version test cases alongside the sources of the tested system.

You wouldn't write source code in a proprietary web app, why should you do that with test cases?

Issues go to issue tracker

Issues found during testing are recorded into your issue tracking system, where the devs and other stakeholders can see them and deal with them. Every issue automatically links to the particular failed test step to provide context for the issue without requiring the tester to fill it in by hand.

ManTester workflow

1. Write test cases in Markdown-based plain-text format using your favorite text editor or IDE.
2. Maintain test cases in a Git repository.
3. Load test cases from the Git repo into a test run in ManTester.
4. Execute test cases manually in ManTester.
5. Create issues into your favorite issue tracker.

Test case editor

This is how you can write test cases in plain text format based on Markdown in ManTester:

1. Second-level heading starts a test case (start line with ##).
2. Assign a distinct code to each test case (wrap test case code in backticks ` within the heading).
3. Start word with a bang (!) to set the test case category.
4. Start words with at (@) to set test case groups.
5. Third-level heading starts test case steps (start line with ###).
6. Top-level list item defines a step (start line with dash and space -).
7. When a step requires a result to be filled-in by the tester, define its name after a pipe (|) separated by spaces.

Here's an example test case. Feel free to change anything - it will be reflected in the test case!
You can even write your own test case...

Pricing