Can a Software QA take over all the documentations needed for the project?

Question

I have been included in a very big project, with surprisingly, unorganized - to none - documents.

Every meeting, we had been asking for documents back and forth and they can't provide one. There's no Business Requirement Document, No Functional Requirement Documents, no use cases. All they can come up is a 'matrix' - which is also vague - and screen mockups. Then when they deliver something, the documents were not really updated on our shared folders and we are surprised about the changes. We do have change request process apparently they didn't comply with the rules and making it look like they just delivered this for the sake of hey we have done our jobs do yours.. I badly wanted to just clean up everything and make myself feel comfortable to test it but due to no idea or no clue on which parts of the function - or even rules of each one of it - what can I do to improve the quality of the project process?

I am tempted to at least maybe document the functional document or business requirement for them. Is there any thing that I could consider before jumping into this crazy world of documentation?

Answer 1

The answer here falls into the "Yes, but..." category.

Yes, the test team can own documentation. The potential issues here include:

• You will still be surprised by changing business requirements. It doesn't matter who writes the requirements documents: if what the user wants doesn't match what the requirements documents say, there will be problems.
• Your attention will be split. Instead of being able to focus on testing the software (which you can still do without documentation, although it can be more challenging), you will need to focus on testing the software and on communicating with business stakeholders about what the software is expected to do. You may also be trying to work out what the software is expected to do from vague descriptions.
• You run the risk of narrowing your perspective. When you write the requirements/specifications there is a tendency to test solely around the documents you wrote, whereas if you are not the person who wrote the documents you are more likely to look for (and find) mismatches between what's expected and what's delivered, not to mention assumptions that haven't been explicitly called out (oh, oops, the devs assumed the feature was for someone with an always on broadband connection where the feature is going to be used with a flaky dial-up or poor quality wifi).

So yes, you can do this. It may not be the best option in your situation.

Answer 2

The biggest problem with QA owning requirements and documentation is the loss of division of duties.

In a worst case scenario QA could then change the requirements after the software has been developed so that all tests pass. There should be a division of duties between the people who write the requirements, the people who develop software too those requirements, and the people who who validate the software against the requirements.

Similarly documentation should be subjected to it's own QA process. The team writing the documentation should be different from the team that validates the documentation.

What you can do is indicate that you cannot do your job without proper documentation. You can't say "This doesn't match the spec" if there isn't a spec.

Answer 3

Very Big Project has a project manager (or few). They should decide what would be beneficial for the project as a whole.

If QA volunteers to write docs, but no one else will care about providing inputs, you just set up QA for a spectacular fail. Because only the manager can tell others what they have to do, and if QA will have responsibility but not the power to enforce it, such effort cannot end well. Definition of frustration is responsibility without authority.

Answer 4

The situation that you described will not end up good for someone or for whole team if changes in right direction don't occur in time.

Since you probably don't have the authority to change this situation but must do your job, then try to do exactly that.

I would suggest to do this things:

• Create general test documentation where you will have ALL open questions regarding entire project (such as minimal supported version, user journey location, design location, feature list etc)

• Inside that documentation try to make test cases with all features that are implemented into app and for the features that will be for sure in the future, beside each test case, make notes, comments to emphasize missing information required

• Share this documentation that you will create with everyone involved in the project (even the owner, director or whoever is in charge of running your office).

• Pass all of your question strictly via mail or media that you communicate on the company level which cannot be deleted or removed and keep track of all your requests and effort to gather documentation and point issues that can/will occur because of that

• Test the application in the boundaries that you are given and also pay additional attention to bad UI/UX issues, since that can be always reported no matter which document exist and in that matter you will gain some authority over some gray areas

Point of all these suggestion is simply to do your job and to minimize damage that eventually somebody will need to take (at least prevent it to go in your direction).

No matter what is the situation, always be professional, do your job and perform your duties without arguing with other member and if the situation changes for the better, then excellent, if not well at least you did your job in boundaries which are given to you and you have documented all the issues that occurred and that is the most general answer about the topic.