What are the documents maintained in software quality assurance?

Question

What are documents(software quality assurance related only), a software quality assurance engineer,QA lead has to maintain/create while testing a software from the beginning to the end?

Please notice I'm targeting on test automation mostly

We are using agile and there is no one to monitor these documents. I'm doing these stuff for my knowledge and also for future use.
I'm asking this as a general solution which I can add use for all situations. For sprint, test cases etc. Not specified for a sprint or to several test cases.

Sample documents are preferred if possible

Answer 1

It depends

You don't say anything about the industry you're working in or the development methodology that's used. Those two factors plus the company culture will have a huge impact on the nature of the documentation you need to create and maintain.

If you are in a heavily regulated industry - the documentation you need will be largely mandated by the industry regulations, since it's required for audit purposes. For example, software for the healthcare industry in the USA requires maintaining proof of what testing was performed and when. For test automation, that means keeping logs with screenshots as well as clear indications of what tests were performed, and making those logs generally accessible. It also means maintaining a record of what parts of the application are tested through automation vs parts that are manually tested.

If you are working with a waterfall type methodology - a simple web search will give you a listing of the types of documentation that are expected. The key documentation for waterfall-type methodologies is some kind of test plan that indicates what will be tested (and, equally importantly, what will not be tested) plus some form of test case documentation. These can be Word or Excel documents, or they can be built via a tool. The critical aspect for waterfall or CMMI type documentation is that your test cases are mapped to the requirements document and the functional specification.

If you are working in an agile environment - the required documentation for any of the agile methodologies is rather light by comparison - for test automation you could probably work with the auto-documentation functionality of whichever language you are using (Javadoc for Java, Sandcastle for VB or C#, etc.). For other tests it can be as little as notes attached to user stories of what is tested. Again, a web search will give you some examples to work with.

Honestly, the documentation you use is up to you. The Ministry of Testing has some nice examples of lightweight but effective test documentation in different formats (disclaimer: I have written several articles for the site, but I did not write the one I've linked to). Choose something that works for you and adapt it to your needs. Ask your lead/manager what documentation they expect from you, and provide them with what they need.

Answer 2

Take a step back and ask yourself "What is my goal as a QA lead?".

Is your primary goal to generate documents? To write test cases? To provide numbers to project management? Of course not. These things are only useful if they support the ultimate goal of helping deliver a quality product to the customer.

One of the basic tenets of agile is "Working software over comprehensive documentation". Similarly, one of the ideas of context-driven testing is that "Test artifacts are worthwhile to the degree that they satisfy their stakeholders’ relevant requirements".

No one outside of your company can tell you what documents to maintain, because they won't know what would be useful in your context. If you find that writing certain things down is useful, do it! But don't generate paperwork for the sake of generating paperwork. Kate's answer gives several examples of documentation that could be required/useful depending on your context, but only you can determine what is necessary in your particular situation.

In terms of a "general solution which I can add use for all situations", it doesn't exist. Every situation (even different products within the same company!) is going to have different needs, goals, target markets, etc. Rob Sabourin gives some very good examples of this in a talk available on YouTube around the 8:30 mark.

Also, don't be afraid to try things, and if they don't add value, to throw them away and try something else.

Answer 3

The documentation can be the following

For manual: excel, word, jira, whatever you use to record the manual cases and their execution is good≥

For automated: I recommend you rely on using approaches like Cucumber, RSpec, Nunit, etc. where the output from the test runs acts as the documentation, indicating both what is being tested and the fact that it worked successfully.

So that you have output like this:

Given I am a logged in user
When I clicked 'Profile'
Then I am taken to a page with my profile details

As you can see it describes in plain english what is going on.
This largely addresses the main issue in documentation which is keeping it up-to-date and, most importantly, in sync with the actual application code under test

Answer 4

The posters above all have valid points. The documentation depends on methodologies and regulations that your business requires. However, a useful first step is writing documentation that specifies how to run your test suite and what the test suite covers. Such documentation might cover what steps are needed to run a test, what files you need to provide that might be in your gitignore (credentials, etc), and stating the goals of your different test paths. A simple readme can provide tremendous value to a user.