Software Testing – the Bad, the Good and the Myths
Software testing is a field that has gained a lot more visibility in the past few years, even in Romania. Some people think that being a software tester is boring, only for geeks or that is something anyone can do and get paid a lot of money to do it.
Well, some things are true, some are not. Whyttest’s Software Testing Department contributed in writing the below article in order to tell you what they actually do all day and if the myths really have some truth in them.
It’s pretty hard to describe a day of a software tester, since they vary from project to project, technologies used, skills and thus, it would be easier to better understand if we call it a week in the life of a software tester, which would be more accurate. The activity can be categorized into 6 separate events:
Planning and status check are 2 very important things. Kick-off meetings, daily status, weekly status, beginning and end of sprint reviews, internal training and such, are a good way of ensuring the information needed to do the task is known to all the parties involved. In order to be efficient, software testers need to know about their subject from the get-go and have access to all the necessary information.
Sometimes, a tester has to test an application that he has never interacted with before, so it might be useful for him to review the requirements set by those who do know it and he can also provide some feedback. There is always a lot of mutual learning by doing so.
Sometimes the tester tests without the software requirements specifications and documentation. In this case, he will use exploratory testing, mind maps, and other techniques to learn more about the system.
By examining the requirements and reading the appropriate documentation, software testers know how to get to work and it doesn’t just happen at a flick of a snap. Before executing tests, a tester must understand the technology, the data model, the risks, context, etc. This is when the tester creates the test cases and scripts, sets the time for each case or at least a higher-level estimate for a set of related test cases, among other tasks.
This is where the fun begins. Executing the tests manually or via an automation framework is happening during this phase. A few other important things to mention here are reporting defects, updating test cases on-the-go and providing a status report. Also, a very common practice is to also ask around for clarifications if something seems more than buggy or there is not enough information in the documentation offered.
Further investigation and assistance in root cause analysis – once bugs have been found, it is the tester’s job to explain the reported bugs, including to conduct a causal analysis. This can also cover reproducing the bug, which involves having to re-run the steps of the test to see if the problem happens again. The tester always double checks that a bug has truly been fixed before calling it “case closed”.
Often called retrospectives, after every great software development project, meetings are held for assessing the process, the workload and all in all, how everything went and what can be improved. A lot of the discussion centers around questions like, “What went right? What went wrong? How can we improve the practices and which ones do we need to get rid of?” These are all questions to be asked at the end of any project.
Software testing in a nutshell?
That can be easily summed up into one line from what sounds like a wise military commander: “Long stretches of peace with short bursts of all-out war”.
The long stretches of peace are represented by the preparations and ceremonies needed at the start of a sprint. Ceremonies that are religiously organized and attendance is obligatory. They take the form of Sprint Planning, Sprint Refinement and the Daily Standups. Further preparations include analyzing the requirements so that the testers can build and maintain Test Cases that represent the infrastructure of their test process. Fully developed Test Cases that cover the key functionality of said piece of software are the bread and butter of our work.
Then comes the war, the feverish execution of tests that were carefully planned and developed. This only gets worse during times of high business impact such as E3 or the Christmas season for some company’s products. This phase also includes the running and rerunning of Automated Tests that the testers will build, carefully analyzing the results from those automated Test Cases to pinpoint and scope out exact issues with the software at hand.
How does a workday in a software tester’s shoes looks like?
The day starts around 9:00AM with auto-pilot mode ON and destination set to cafeteria, where 2 cups of black mana potion await to power on what by around 9:30, becomes a software tester.
In the meantime, they usually read emails, and prepare the workspace for the tasks left from the day before. Depending on the project, “workspace preparation” can mean multiple things. They can just open a new sticky note and write the tasks they are going to work on that day, or it can mean setting up a new virtual environment on their machine and installing all the dependencies required by the scripts they will be using.
With everything in place, the actual work can begin. The tasks are different all the time, even if they seem to be repetitive, there is no task as one they did in the past. Every feature is different and requires a different approach.
Most of the time software testers start with a smoke test, to make sure the base functionality still works and a few hours later they find themselves at the developer’s desk or with him at their desk, discussing about how the API that makes the magic behind the scenes works and how it can be checked smarter and faster.
That is the moment automation testing starts on a project. Before it is officially requested by the Project Manager, the testing team already has a bunch of scripts made to speed up the repetitive work and diminish the chances of human error due to tiredness or the boredom of doing the same thing again and again.
To all of this, testers will also have to add at least one call every day when they have the Daily Stand Up meeting with the entire team and talk about what was done, what needs to be done in the future and the right approach for everything. A call like this can last from 5 minutes to one hour, depending on the project status and issues.
And of course, a ton of geeky jokes related to scripting and programming languages are mandatory.
How can YOU become a software tester?
Everyone says it’s about the technical knowledge and that you have to learn a lot of stuff but, just like in school, no one tells you how to do it the proper way.
The most important skillset to be developed and learned by a Software Tester is, believe it or not, soft skills.
Soft skills such as self-discipline, communication with the team, organizational skills, self-planning. Even though the technical part of knowledge (like programming languages and testing tools) is intrinsically part of the testing process, without the soft-skills necessary to organize the much-needed technical skills, a tester can almost become a useless collection of impractical knowledge. Therefore, we deeply recommend sharpening the social skills, the soft-skills, the skills that allow you to better connect with your fellow team members and that will allow them to fully understand and appreciate your work.
Before you start learning about technologies, you have to take a step back and review your way of thinking things. If you want to be a software tester, a good one, you have to know stuff, not just have an idea about how it is supposed to work.
So, you have to learn to question everything. Why does this website work like this? Why this error triggers only when I do that? Why do I have multiple response messages for the same error string? What happens if I tamper an URL parameter?
If you start asking those kinds of questions you will seek answers, on the web or from people around you and guess what? You start leaning things.
Next step is to set a personal project where you can use all the things you learn.
If you do all of this, when the opportunity to become a software tester shows up, your confidence level will be super high and you will know how to approach the interview in the right way (from a technical perspective).
Speaking about opportunities, we guess a lot of you tried to become software testers already but there seems to be no room for you and you end up sad because someone said you will not become one. Sounds familiar?
This happens because the responsibility level is up in the sky. In gaming industry you are part of a big team, maybe 20-30 people, if you miss something, someone else will find and report the bug during a 2 years period or how long the project lasts.
In software testing you are alone, you have your own project, no one tells you when to do something. You are just informed what needs to be done and until when. It is your job to prioritize them and manage the time to be able to deliver until deadline. So, if something goes wrong and an issue goes to production, there is no one else to cover your back.
An issue deployed on live for a software product can do a ton of damage, from making users cancel a subscription, to actually killing people if we talk about medical or automotive solutions.
This is a strong and valid reason for people to be very picky when they look for a new member in the team and often, they prefer to keep the old ones and find out ways to do the job easier, so that the same number of people can cover more areas of the project.
Software testing isn’t a job for everyone. Only dedicated people that have a hunger for knowledge, passion for finding out how stuff really work and aren’t afraid to take the charge, are a good fit. It’s a demanding but also very rewarding position, full of battles, sweet victories and a lot of preparation.