100 days of testing: observations from a rookie tester
Having completed Assurity’s Graduate Programme as part of the July 2014 intake, Chloë Wood gives a rookie tester’s view of her first 100 days on a client site.
I’ve been working as a professional tester on client site for just over 100 working days. It’s had its challenges and frustrations, but it’s also extremely satisfying to see the project I’ve been working on make its way to completion.
Though I now have a taste of the industry and some experience, I still consider myself a rookie tester and will continue to do so for a while longer. Even after only 100 days of testing, I’ve found the niggling temptation to approach a product/system/idea with my own assumptions and preconceived ideas of how it should behave has already kicked in. However, I’ve also found that, although it is helpful to have clear expectations, our assumptions can be dangerous and misleading.
Two observations as a rookie tester are:
- The client can know what they want
- The developers can know what they want to make
- These two things aren’t necessarily the same
As consultants, we can have an insight into the workings of the two parties. A key part of our role is to open up communication channels between the people involved in the project and to help them to work alongside one another – as opposed to heading in completely different directions. I found it really helpful working directly with those on the client side and the team of developers.
Clear bug reporting tools helped promote transparency between all involved. One man’s bug may be another’s pet – but at the end of the day, the client has final call on what is desired behaviour and what is not.
If this information is accessible to everyone and in a format that promotes discussion, then there is visibility, a quick feedback process and a way of tracking how these requirements evolve over time.
- Testers get less and less popular as deadlines get closer and closer
It’s human nature not to like people critiquing our work and highlighting our mistakes. Even as a tester, I’m not a huge fan of people scrutinising my work and trying to pull it to pieces. Therefore, it makes perfect sense that the testing team doesn’t always have the most popular job.
However, if testing is approached with genuine care and concern for the quality of the project – both the client and the developers seem to pick up on this. Everyone will be a lot less defensive and more cooperative if they know that you are working with and not against them.
We developed good relationships with the developers and the client, enabling both parties to see that we were on their team and keen to help push the project to success. This happened gradually over time. We intentionally worked on site with the developers – as well as spending time on site with the client.
Despite the convenience of emails and phone calls, when it comes to building relationships with people, nothing trumps talking to them face-to-face! We gradually bonded over a mutual understanding of the product, frustration with its issues and a keenness to get it across the line with a high level of quality.
We also discovered the areas where we were able to help one another out to support the overall progress of the project.
A little food bribery every now and again also goes a long way!