Starting a new job as a tester

First day on the job - so many questions!

Introduction

For this blog I’m going to talk about my experiences in developing a testing department at a software company from scratch. I’ve now been working at the company for 2 years and I have learnt a great deal. I hope that sharing my experiences on here and talking about the lessons I have learned will help someone else in a similar situation. I’m sure while I’m writing this blog I will also learn a lot simply looking back and trying to articulate my thoughts!

This blog post was written from the experience of joining a company that has no existing testing. While I hope that most of my experiences are relevant to any kind of testing and company setup, I don’t believe there is a “one size fits all” solution and I would likely adapt or change my approach for a totally different situation.

The company had around 60 employees with a typical setup consisting of various departments including development, support, sales, marketing, accounts, infrastructure and a “product” department consisting of business analysts.

The system under test was a software application that stored and manipulated data and the end users ranged from customers interested in the data collection to support using their administration tools to accounts managing invoices.

What did I do?

It’s your first week at your new job. Not only do you need to learn what the company or business is and what they do, but you’re busy learning everyone’s name, the processes and where to get lunch! In the first few days it can be stressful trying to learn so much so quickly. Some companies have lengthy induction processes with lots of meetings and some companies leave you to your own devices quite quickly.

In my case, you might find yourself being the only tester in the company. I actually applied for the job because I wanted the challenge and knew I would learn a lot. I got the impression from the interviews that the company didn’t really have any idea what testing really entailed and were happy to let me tackle it how I saw fit. This meant that I had to really be quite aware of what I wanted and know which information was relevant to me and which wasn’t. However, when you don’t know what is important or relevant, you are heavily reliant on what you are presented. I spent my first few weeks learning what was really relevant to testing.

At first I was drowned with very technical information regarding how to work with Ubuntu, how to setup MySQL, Eclipse and various other systems. There was particularly focus given to Git and the development department’s branching model and version control. While this information was important, worrying about these things at the beginning wasted time really as I had simply too much to learn at once and spread my focus too thin.

In my first few weeks I mainly relied on the information I could gather within the development department. We had a typical scrum setup which featured a Scrum Master, Product Owner and a team of developers. In this format I could find out a lot of information from the Product Owner and the developers. The only problem with this was that the information from the Product Owner is naturally filtered from the rest of the business. However, as a base to start from it was enough to start getting the answers to my questions.

I quickly learnt the system in some of the key areas but I found I was lacking in knowledge in others. I only discovered what I didn’t know when issues arose or when different work was required for development. I feel I could have done more to find out this information much earlier and avoided some of these issues as well as provide much faster feedback. I would have tested differently with this knowledge.

What would I change?

I feel the biggest thing I would change is to focus more on information gathering without testing in the first few weeks. While I think it was a valid approach to simply start playing with the system and learn about what the current changes were, it only gave me an understanding of what the system currently does from a low level. It also limited what I understood to either new or changed areas or to whatever I could find through my exploratory testing. There were many areas I simply never knew about but were critical areas for some end users. In future I would instead focus on finding out this very important contextual information and use it to learn the system from a high level first.

I also spread my focus too thin attempting to learn how to manage my environment, conduct my testing, learn the processes used by the development teams, learn about the system and wider business all at once. Naturally I ended up focusing on the areas that had the most readily available information and these were my environment, the processes used by the development teams and how to conduct my testing. I feel I could have chosen to focus more on knowledge gathering for the system and not focused so much on the other areas until later. In hindsight I feel it’s quite important to start building a rapport with the various sources of information outside of your immediate vicinity as these take time to build. The information you gather from end users also greatly shapes how you go about testing and this can affect your requirements for a test environment and the types of tests you want to conduct.

In order to gather this information, I would focus on the following questions:

• What does the system do?
• Who uses it?
• How do they use it?
• What are the most important or critical areas that must always work?

The main goal of these questions is to create a picture in my head of what the ultimate goal is of the system. I want to think as much as I can like an end user as soon as I can, as this will dictate how I will test the system and help guide my understanding. It will also allow me to bring the most value from my skills in the shortest amount of time. The most obvious tests are those that simply check that the system functionally does what it is supposed to. It is from this base that I can then develop more complex tests.

In my experience, the answers I get to these questions will vary wildly from who I ask. I feel it’s worth spending my time asking multiple people, especially people from different departments. In the same way that as a tester we will think about a system in terms of its inputs and outputs and various scenarios, a developer or a salesman will think about the system from their own point of view. From a developer I’m gaining technical information about the inputs, outputs, functionality and influences. From a salesman I’m gaining contextual information on why the system is designed a certain way and how it is sold to users. In my case, we also had an administration section that the support department used and a billing system that the accounts department used. These are yet more examples of different views of the system as well as end users who hold important information that I would like to incorporate into my tests!

I have found that a crucial skill for a tester is tying all of this information together and constructing a unique critical view of the system. The amount of information you gather can dramatically change how you approach your testing, what tests you carry out and how you perform the testing.

Summary

• Focus on gathering knowledge.
• Have confidence to ask questions and speak to people in other departments.
• Don’t worry about how to test until you feel confident you have gathered enough knowledge about the context of what the system does, who the end users are and how it is used.
• Don’t worry about finding defects on your first day on the job.
• Starting testing straight away is still a valid approach and you will learn a lot about the system very quickly, but don’t compromise your information gathering activities early on.

Background

I feel it's important to highlight my background because it helped a great deal in giving me the confidence, skills, tools and knowledge to really hit the ground running when faced with a job where I would be given an open book to start and a very technical product to learn.

I started my career as a tester at Sony after graduating with a Computer Games degree. I had originally intended to work as a programmer but took the first opportunity I could find. I gained a good deal of experience on a wide variety of different projects. Despite only having a couple of years of experience from this job, I learned a lot about testing; especially the key skills.

Thanks to this experience and my background in design and programming in academia, I had a lot to fall back on to give me confidence with my decisions and guide myself on how I wanted to learn and progress. It also meant in an open environment where I was left to my own devices I could pull together what I needed and even write my own tools to help with my testing.