At the London Tester Gathering event last week, I overheard someone ask the question: “What’s the first task that a tester should do on a project?”. There were various contrasting responses, such as: “write test case documentation”, “play with the product”, and “give an estimate for the testing effort”.

Although many projects are run differently (which is probably the reason for the vast array of answers), I believe that the first task for a tester on any project should be to get familiar with the product that you need to test.

I’m not saying “wait for the product to be developed and passed to you so you can play with it to get familiar with it“… I’m saying that you need to start learning about what the product is right from the very start of the project. You need to build up your knowledge of what you are going to be asked to test: what it’s going to be used for, who is going to use it, what do they want and need it to do, are there any specific necessities, any special requirements, or any standards that the product must meet, what areas or functions are going to be the most used, what areas will least be used, etc.

Asking questions such as these will build up an idea in your head of how the system should operate, and there are many places where you can find the answers!

There might be a formal specification that the customer has written, which would be a great place to start gaining knowledge (but not the only thing that should be looked at)! Or there might be no documentation at all, which is where your investigation and communication skills really get the chance to shine. You should get involved with the customer to discuss the product – not just with the “product owner”, but also with the soon-to-be users of the system (if possible). You could look at competitor products to compare and stem ideas about the product. Or if the new product is going to be replacing an existing product, then use the existing product to learn about what the new system needs to do – find out what they don’t like about their existing product and equally, find out what they do like about it. You should talk with the developers to get their thoughts and ideas about the product and to see how they plan to approach building the new system.

There is a whole host of ways that you can learn about the expectations and desires that the customer has of their new system, which should stem lots of test ideas. Additionally, During this process of gathering information on the product, I like to brain-dump my knowledge of the system on to a mind map as I go. This allows me to plan continuously add test ideas and scenarios around the functionality and use the mind map as a test plan, which I continually update during my exploratory testing sessions.

This is what I believe the first task for a tester should be…  What do you think?