Documentation which is used while onboarding new Tester

Question

What do you call a document which is created to help new Tester in a team to understand the product/Application?

Answer 1

I've worked as a tester for many years now but as far as I know, there is no official call for the document to help the new tester in a team to understand the company product.

Rather, in each company there is a standard way of doing things, especially if you work in big ones, for smaller ones, there almost none. As a senior QA tester, I've created documents that help the new board tester to understand the products that we are testing (E.g. flow of the system, how to create clearer steps in test cases, reporting bugs, simple presentation on how does the system works and etc).

Although, I always say to them that they need to think as consumer/user when they are testing. That they should not stick to whatever documents that they received rather explore it with their own so that they will not be biased when testing and improve the quality of the tested websites or mobiles system.

This is just my opinion as a tester though.

Answer 2

An Onboarding document

is exactly that.
It should contain references and pointers to information such as:

1. Unit Tests
2. End to End Tests
3. Product documentation
4. Product demos and videos
5. Links to the produce/service
6. Information about the various environments
7. Information about accounts and logins to use

The first task of any new employee is to follow and update the onboarding documentation. This is the only way to get it relevant for newbies who don't know all the language, terms, domain, etc. It has to be updated in the first week or two or the newbie moves on to other tasks, plus they start to know and use all the terms that they initially found so baffling.

One thing that you will need to consider is 'New tester in a team or new tester in an organization'. If the tester is new to the organization they will need a lot of domain training on terms and meanings and workflows. If they are just new to this team and a sub product then training will be different and will only need to focus on specifics about that project.

Depending on the organization you may wish to formalize the above into

• QA New Employee Onboarding document

• Product Team Member Onboarding document

and maybe even

• QA Product Team Member Onboarding document

It all depends on your organization structure, size, complexity, product, industry, and many other things.

Be very cautious in creating documentation. It can be easy to go over-board. Especially in compliant orgs. remember the agile principle of working software over comprehensive documentation. Automated tests are a good example of working software over artifacts such as detailed test plans which are becoming a relic from the past and a severe limitation on companies moving forward in today's Agile environments.

Answer 3

In my experience as a Tester, it depends on the company. In small ones, there's usually no written document about the system(s). In corporations, it might be the exact opposite, so many documents that nobody really maintains, so they capture reality only so much.

What's usually helpful to read at least to some extent (if available):

• requirements
• user stories
• old test cases
• old bugs
• e2e automation tests if they are readable easily (e.g. BDD style)

It's also important to interact with other people, that's a huge source of information. And of course your own exploration.

Answer 4

While on-boarding a new tester organizations dealing in software quality assurance services have bunch of documents. Below are the list of the same:

1. On boarding New Jonee Checklist.
   
2. Product Guidelines.
   
3. Demo Videos.
   
4. Test-cases.
   
5. Defect Writing Guidelines.
   

There can me much more in the list but the above are the important one's.

Answer 5

It can be called a multiple things depending on what it contains and can also be divided into separate documents.

Most commons that I have come across are:

1. QA Workflows/SOPs.
2. QA Test plan standards.
3. Environment documentation.

one more document which isn't available readily is a stripped down version of Product demo including but not limited to requirements and functionality.