Ask HN: What are tools for writing test case documents?

19 points by muzani ↗ HN
For example, I want to write something like...

Test case: Login

1. If entering username "abc", password "admin", it would log in.

2. If entering password "and", it will pop up error invalid password.

3. If entering password "", it will disable the login button.

Surely someone has created a solution that handles something as repetitive as this? Most people use Word but formatting takes up quite a lot of time.

13 comments

[ 3.0 ms ] story [ 37.6 ms ] thread
Interesting question. I've seen and used Excell myself so I would be interested in other's take on this.
This might be one of those situations where code needs to be the spec. Unravel.io or TagUI are two tools for testing interfaces that have come up recently.
We use a tool called TestLodge and it works well for these types of test cases. You can also create test runs which can be assigned to people on your team.

If you want to have someone actually execute the test cases, you could look at a company called Rainforest that provides Testing-as-a-Service, if you will.

The class of tool you are looking for is a Test Case Management tool (TCM). The basic model of a TCM is a db for holding atomic test cases. Most TCMs let you collect test cases into "test runs", which is a set of test cases to be executed in a context. Test runs can typically be organized into some kind of project bucket (e.g., "drop 11" or "release foo").

TCMs usually support tagging of test cases, so you could for example tag some test cases as "smoke test" and collect them into a smoke test run.

TCMs usually support the manual execution of test cases: the tester works from a "test run" and sets status of that test cases instance to pass/fail/etc. Depending on the state of your test automation, you can also do the same status setting for an automated "test run". Some TCMs support the automatic updating of a test case instance via APIs triggered by integration with test frameworks.

Some TCMs support integrations with bug trackers, for example with Jira. This means you could create a virtuous circle of automated test execution, test run status updating, and bug creation for failed tests, depending on the maturity of your test automation infrastructure and your TCM and bug tracker tool choices.

My current preference is for Testrail (http://www.gurock.com/testrail/) over TestLink.

But here's the deal: a TCM is a far better tool than Word or Excel in tracking test cases or test execution, but TCMs come with gotchas. Any QA or test effort is a dynamic process that should evolve over time. It's easy to put way too much emphasis on the TCM as the goal of your test work, but it's just a tool that supports a process. Don't use a TCM as your strategic test planning tool, because it's a software product written by external teams according to their own crazy software development realities and definitions of process and quality. Figure out what you need to focus on, what your workflow should be, and use a TCM as a tool that helps you right now, and drop it if you find yourself changing your work patterns to suit the tool.

Microsoft OneNote is quite good. Best of Word and Excel, plus has good sharing features and change history.
Do you really want to have someone doing these tests? The particular test you gave as an example would be super easy to implement using python and selenium. Otherwise, I would use markdown for everything that can't be automated (or one of the tools mentioned in other comments).
Sometimes it's good to document what the automated tests are doing too, especially for clients.
I would recommend automating these kind of tests using a test framework. If you do it right, the scripted tests will also serve as a documentation. Look into tools like Robot Framework, Cucumber etc.
Ah thanks. Cucumber is quite close to what I had in mind.
What is this for? For manual testers to run through the list and execute the tests? As a spec for automated test authoring? I'm curious why you need this. Don't have a solution to suggest right now but we're considering adding tools for manual testers to Tesults in the future and I'd be interested in understanding what this is useful for.
Mainly as a spec for the whole program. It saves time on designing code, when management can communicate what exactly they need done rather than just give a vague story. There's usually a lot of this back and forth going on about what the app really intends to do.

It helps a lot in clarifying contracts too. For example, if there is no internet access, the contractor might just want to let it show a vague error pop up, but the client might want it to show a cached version.

Making testing easier and reducing bugs is just a nice side effect.