Skip to main content

Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project

Checklist for what new testers on a project need (Note, your project may not include all of the below)

Note to check if user credentials are needed for any of the below

  • Access to test environments 
  • Access to instant messaging groups
  • Added to the correct channels within the IM groups
  • Access to the bug tracking tool 
  • Access to the test tools
  • Access to email
  • Team wiki 
  • Time-tracking system (applies if tester is a contractor/consultant)
  • Version Control e.g. Git 
  • Someone to do a handover/introduction
  • Access to the shared folders
  • *Access to the database

Some starting questions you can use, if you are new to a project (This isn't an exhaustive list; only a starting point)

Test Environments

  • How reliable are they? (this could help when it comes to raising bugs only to find they are environment issues)
  • Do people's actions affect others? (how are environments shared?)
  • How do you set up test environments?


  • Who do I speak to if I have questions about XXXX?
  • (To buddy/mentor) who do you think I should meet?
  • Who do I report to? 

Raising bugs

  • How do bugs get classified? (e.g. Area of Product)
  • What to do if you don't know how to classify? (is there a misc area)
  • Can you show me how to raise bugs in bug tracking tool? (some tools need more explaining than others, especially when it comes to filling in certain fields of the system)

General Testing

  • How is testing done here?
  • Who decides how testing is done? (the tester; test lead; test manager)
  • Are there any testing team meetings? (These might be outside the product team meetings - it depends on your definition of team)
  • *What tests does the team currently have? (both automated and manual tests)

Is there anything I'm missing? Can you think of any other questions to ask? Anything else to add to the checklist?

Updated: Have added some more questions and access needed from others, new ones are marked with *. Thanks Danny Dainton, Lim Sim


  1. Thanks for sharing this post and the efforts you have made in writing this. If you have more info about Software testing companies, please share. I looking forward to hearing from you.


Post a Comment

Popular posts from this blog

A reflection on Let's Test 2015: Part II

Here's the link to A reflection on Let's Test 2015: Part I The sessions (Part II) Below does not include all of the sessions I went to nor all aspects of the session I mention Visual Creativity: Using Sketchnotes and Mindmaps to aid your agile testing - Dan Ashby and Christina Ohanian Before this session I stumbled upon Christina drawing out her sketch notes from the previous session and marvelled at how fascinating it was. Sketch notes were only something I'd only ever seen on the net. They were gorgeous and a clever way to communicate information. When she told me that she was going to have a session on this - I was all in. We 'warmed up' by drawing whichever image came to mind when Dan said a word. It was interesting to see how a lot of people could interpret the same word differently. For example: "Time" could be a clock, a watch or an hourglass.

My Most Used Test Heuristics (with examples)

First, what is a heuristic? A heuristic is a guideline ,  it is fallible.  Therefore, it will give you a good idea of what behaviour you should see BUT it isn't definitely what should happen - it's up to you to confirm that the behaviour you are seeing is correct.  In a previous blog post I shared a step by step guide on  how to test without requirements/little requirements.    But I figured it's good to share my most used test heuristics that I use for testing without requirements. They are: Consistency with History Consistency with User Expectations Consistency within Product Let's take a look at each of them along with some examples to illustrate the concept. 1. Consistency with History  The feature's or function's current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense) Example: Whitcoulls, a