Feb 5, 2021, Mobile, Web

Software tester’s job – how I survived my first month

Sebastian Wikieł QA specialist

I write this article to share my one-month experience working as a software tester. You can treat it as a word of advice for all the beginners out there or as a showcase of growing into the job. It can be useful if you want to change your career or even a branch. Working in IT gives a plenitude of possibilities, but you have to remember that it requires a specific set of skills and aptitude to make the job satisfactory and effective. 

The workflow organization

A person who is just gaining first experience in the IT branch can be overwhelmed by a quite demanding workflow. The attitude towards work management and methodology from my previous professional experience underlined a decision-making process centralization. The flow of information focused on emails and conversations with your supervisors and was limited to cycles which then resulted in an evaluation of your work. 

Considering all of the above, the organization of a software tester’s job was something totally different. I started every workday from a meeting with the whole QA team. Afterwards, there was a meet-up with people responsible for a specific project. We discussed current work progress, describing yesterday’s tasks and the ones planned for today. Each of the engaged coworkers spoke individually, shared their feedback and talked about the occurred problems. 

We meet every day and such manner of communication is one of the SCRUM’s elements. And what’s SCRUM? It’s an agile framework used commonly in the process of developing a software. Although working in its orthodox form is rather rare, the principle of incremental development as well as the way and rules of everyday work communication are the same as the assumptions. One can wonder if by self-organizing one’s job a team achieves its goals. The answer is – yes. Being a member of a fully engaged team, you want your job to be of the highest quality.

Getting onboard

Growing into one’s duties is strongly connected with planning. The onboarding process is a kind of change management. Regardless of the time it takes (and the time may be different depending on the character of job and project as well as a new employee’s competences), it emphasizes communication which allows a newbie to feel more confident in the new environment. 

Another step is introducing and discussing all of the work tools. In my case it was Jira, Confluence with an extended knowledge base, a whole Google suite pack with a calendar, and a set of safety procedures. The calendar filled with events is a wireframe of your workday and the time between the meetings lets you focus on what needs to be done.

In iteo you can divide the time into working on projects, developing your competencies, and taking part in the company’s events. Although last work taught me to work with short deadlines and fulfill the assigned tasks as quickly as possible, after a few days of work I realised that some things take a longer time than others. I started to forecast the time of some tasks and then confront it with reality. At first, the estimated time could have been doubled to get a real evaluation. After three weeks, I was able to estimate it more precisely. Now, I’m sure that estimation is an ability that grows proportionally to your professional experience.

Constant skills development

What I liked most was a promise that I would be able to develop my competencies in the field of QA. I started to take part in the tests automation training as well as a series of practical training using some of the tester’s tools (‘5 minutes QA’) from the very first week of my work. The company’s initiative to improve the employees competences was another positive experience and an added value that was supposed to pay off in the future – both for me and iteo.  

Apart from the trainings, I could use a knowledge base from Confluence. It allowed me to download some ready-made documentation templates, programming tasks and get familiar with valuable certificates. 

Let the work begin

As Cyceron said: “Usus magister est optimus”. The time for my first project has come. At last, I was able to make use of my theoretical knowledge and tools. It all happened quite soon which was a definite plus. In this part I’d like to tell you what helped me find myself in a project environment and what were the conclusions I drew. 

First, understand the product

While determining my priorities, I decided to focus on understanding a product we develop. It applied to both its purpose and limitations. How to learn more about a certain app? It all depends on a project. Testers who have access to documentation forms, business and technical analysis, UML diagrams, written use cases, UX matrix, etc. are in the most convenient situation. It’s especially important at the beginning of your tester’s job to confront all the project materials with the current version of an application. It allows you to grow into the project’s reality even faster. 

It’s quite important to know where you’re at and where you tend toward. I’d call it a goal perspective. Having one is a motivation itself and it’s strengthened by the fact that the purpose is common for the whole team – and it’s providing a functional software that corresponds with a client’s needs. To achieve it, one has to perceive a product from various perspectives. The information from the documentation should therefore be supplemented with the developers’, Product Owner’s, Project Manager’s, analyst’s, client’s, and other tester’s insights. Each of them has a real impact on the developed product and shapes it from his or her own perspective. Adequate open questions enable us to get valuable answers and get to know how our team members think. 

The ability to communicate, empathize, and being open-minded is as essential as perceptivity or analytics skills. They may not determine gaining knowledge but they make the process much simpler enhancing integration with the team, too. 

Then, have a solid plan

The second of my priorities was the work organization and planning. In my first project, a client demanded extensive tests documentation for each development stage. Thus, the time of work was supposed to be divided into preparing the documentation, tests design, tests planning, smoke testing, exploratory and functional tests, failure reporting, and retests. Most of them had to be conducted on a regular basis depending on the project’s stage. What’s great, I had constant support from the QA team during the whole process.

Summing up

A very active month of implementation resulted in feeling confident about my skills which is quite crucial after choosing a new path of professional development. Apart from that, I know how much I learnt in such a short period of time, and how much there is to catch up. 

An additional motivation is that the products we develop change the reality around us. I am glad that my work is a part of the vector of this positive change.