2

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?

  • 1
    No, not. Every project has BA, Developer, QA, Architect, Manager...and so on. Everyone have different roles as per their position. BA prepares the Requirement gathering related documents like- FRS, BRS, SRS and QA - Test case, Test scenario, Test plan, RTM etc. Architect will prepare High level & low level design- mock-ups which contributes UI Team also. Development team write Unit Testing scenarios... So everyone has different roles to make a software/product. – Bharat Mane Feb 20 '18 at 18:22
  • 1
    I don't think there is a clear answer to this. But if you can do it, probably everyone on team would be happy. Risk is that you wont have time to test and write various docs properly at the same time or will step on someones toes if place is very formal (why is QA doing this job etc). Best to discuss with boss/team. – George Feb 20 '18 at 20:14
  • 2
    This is something which has to answered by calculating various parameters like what is the value add if you do so? Would it affect other deliverable? How badly others need it? Was this supposed to be implemented and did not? Once you have answers for all those questions by analyzing the situation it would be your call. – Bradz Feb 21 '18 at 6:03
  • 1
    Excellent question , every tester faces this documentation spectrum at some level. – Vishal Aggarwal Feb 22 '18 at 21:48
  • 1
    @BharatMane - not every project or company has all of those (separate) roles - it may be implicit (or even assumed) that someone will fill them, or maybe the team is very small (or even one person) – Andrew Feb 23 '18 at 15:30
2

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.

1

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.

  • I really agree. But what's going on as well is that the partner team are not transparent on which is an issue, and which one should be tested on a sprint. I just feel like I am throwing stones in the dark. – Marj Feb 20 '18 at 21:36
1

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.

  • The project manager itself wasn't really that transparent too. Everything is passed thru verbal. What I didn't like was they wanted to pass the "Tested" app to us and just accept it. No more complaints. The App isnt even working. So.. I am not really sure what would be my place in this – Marj Feb 20 '18 at 22:32
  • 1
    @Marj - Your role is to inform project manager that you need documentation to ensure requirements will be fulfilled. IN WRITING because QA might be set up for a failure as a scapegoat. How to manage your manager was extensively hashed out by many questions/answers in workplace politics SE – Peter M. - stands for Monica Feb 20 '18 at 22:42
  • I agree here, after 2 months of craziness in this project our project manager got kicked out because one project manager wants to take over and questioned our documents - I have all the test cases but since they don't know anything about testing and documentation they pinpointed things in the document that is really there but they think it does not make any sense. I think they are looking for UAT test documents not QA test documents. Oh and yes, we still don't have requirements documents that is why it was so tough to map out requirements that constantly changes.. – Marj Apr 14 '18 at 16:36
  • corporate politics suck big time – Marj Apr 14 '18 at 16:36
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.