A Testing Library of Resources?

I’m curious to know if anyone maintains a test library as an internal resources used for projects. I don’t mean ‘books’, more a tool kit to help your team do testing better/faster/easier.

  • how do you decide what to include?
  • do you have templates?
  • team or testing processes?
  • of perhaps testing type checklists?
  • what kind of documentation exists?
  • what kind of documentation is required?
  • who uses it? just the ‘test team’ or others?
  • does it outlink other potential useful areas of the business?
  • how do you communicate to others about its existence?
  • is it useful to onboard new testers?
  • how do you maintain it?
  • does it actually get used?

I would love to hear stories of what works for your software testing team.

3 Likes

I have literally hundreds of OneNote pages.

How do you decide what to include?
I include anything I learn and want to recall. Nothing is exempt, but not everything ends up being useful. If it’s specific to a business it goes in a separate non-sync notebook for that business.

Do you have templates?
Yes. I have a generic charter template I adjust to team and company processes. I have tabluated checklists for areas of a product to test or test processes I want to do. I have bug report templates that I adapt to each situation. I have a lot of templates.

Team or testing processes or perhaps testing type checklists??
Tons. If I need to do something over and over I have a system to help me to do that. If I need to do something again in a different context I have master pages I adapt as necessary.

What kind of documentation exists/is required?
Templates, checklists, reports, charters. Reference for test theory, models, approaches, ideas. Methodologies, value statements, writings on ethics. Anything and everything. What gets used is the combination of what’s mandated and what’s useful.

Who uses it? Just the ‘test team’ or others?
I do, usually. If anyone I work with wants a copy I’m happy to provide one. Some checklists are used by the team, e.g. in breakdowns/kickoffs.

How do you communicate to others about its existence?
It’s how I like to work and how I like to store information. It doesn’t make much sense without a grounding in a certain background. I pull from it to build training sessions to communicate the ideas. Some of it I print out and give to people (e.g. team templates).

Is it useful to onboard new testers?
It can be. Onboarding is one of the areas of theory it contains, and it also serves to show one approach to work.

How do you maintain it?
I sometimes reorder the categories or link specific information in an overview. Sometimes I’ll type bits out again to help me remember it.

Does it actually get used?
Most used thing in my testing career.

5 Likes

We have a test management guideline document, with our standards that should be taken into consideration when we are designing TCs, executing TCs, creating test data, organizing our testing tool, etc. It was a good idea having the document, so we all have one place to go, however, I confess its hard to keep it up to date, as we are always inspecting and adapting our processes, so updates are needed.

One other place we document things, but then its more overall process, not just testing, is in our WiKi page, within our tool, used not only by QA team, but also by dev.

1 Like

I would love a copy! Sounds like you have an impressive collection of test artifacts

Note that I work for a consulting company, so a lot of what we write is owned by our clients…which means we have to do internal projects or write separate things to keep for ourselves, rather than reuse what we write most of the time.

It also means that a lot of specifics don’t transfer well from project to project, but I’ll answer as I can.

Stealing @kinofrost 's format
How do you decide what to include?
Anything that we have worked on across projects tends to find its way into our library. Also, anything particularly tricky to figure out tends to get written down (though not always consistently!)

Do you have templates?
Our templates tend to be around automation, as well as specific documentation that we find important/is required for a certain client.

Team or testing processes or perhaps testing type checklists??
We don’t really have this, though I think we probably should!

What kind of documentation exists/is required?
Test logs are a big one we use, as well as Test Plans and manual test documentation.

Depending on the client, we may have specific documents we have to produce, especially around formal test execution in regulated environments.

Who uses it? Just the ‘test team’ or others?
Anyone in the company who is working on testing. This is usually any tester on the team, as well as at least some of the developers.

How do you communicate to others about its existence?
We honestly broadcast out blog posts that include some of our automation testing framework tricks. For other documentation, it usually isn’t broadcasted out, which we should probably work on.

Is it useful to onboard new testers?
I don’t know that what we have is, though this has me thinking of what would be useful to have for onboarding.

How do you maintain it?
Not well, this is another area where we run into a problem of very fractured projects…we may not need a specific technique, tool, or document for a year or more.

Does it actually get used?
Fairly well used, it may not be all of the time, but I’ve been thankful anytime we’ve had something stored and someone could point me to it!
[/quote]