Note: This is guest post written by Thomas Peham-marketing manager at Usersnap
Your software is acting weird. It’s crashing and the front end isn’t working as expected. Well, I guess it’s time to bring a software tester on board.
Software testers are responsible for finding and reporting bugs to developers. That’s their primary job. But what does the day of a software tester look like? Where does a tester spend their time on? In this post today, I would like to share how a typical day of a tester looks like.
Bugs all day long
No matter how much expertise your developers have, and no matter how much time they spend with quality assurance. There will always be bugs.
And as a software tester, it’s your responsibility to deal with them.
A software tester’s main job is to locate and report bugs.
Software testers need a specific set of skills in order to perform their daily tasks of finding and reporting bugs. Once the bugs are fixed, they need to re-visit these bugs to verify that these bugs are fixed.
What makes their day-to-day tasks challenging is the fact that many bugs are not getting fixed right away. Software testers sometimes have to go back and forth with the development team to clarify the bug, to add more information to the bug to help developers understand the bug better so that they can fix the bug thoroughly.
However, finding bugs or coordinating with developers to clarify bugs is not the hardest part of testing. The toughest part is how to deal with bugs missed. By missed bugs, I mean bugs reported by end users, which are generally expected to be found by testers.
Coordinating between departments
When a tester finds that the bug she reported is still unfixed, she usually finds out why and then again documents the bug.
A software tester deals in her day-to-day work with a lot of coordination tasks. Making sure that developers have the right amount of information in order to fix an error, making sure that designers make use of your collected user feedback and aligning customers’ needs with their company’s strategy. There is a lot of coordination needed.
Project updates
Most days of a software tester start with reading emails and project updates. The testers look out for emails from the project manager asking them to run various test cases or tickets.
Testers also scan their mailbox or project management system for emails from their developers giving them an update of the bugs that they had raised the previous day.
After understanding the updates, testers then need to adjust their testing tasks and activities accordingly. Even though people hate change requests, adapting change is part of software testing and testers need to get familiar with that.
Testing, testing, testing
After finishing the organizational and communication part of your work day, a software tester starts testing by picking up the test case with the highest priority.
Priority is generally decided by the chronology of events that occurs in the course of the final release of the product.
Let’s say that there’s a test case that requires checking the functionality of a search bar on a website. The tester has to ensure that the search is functioning as expected.
This case would come in the highest priority if the ticket has to go live (which means that the users at the production end can see the search bar) within the next few hours of sending the email. The test case or the ticket is exchanged many times among the team (usually the tester and the developer).
The first time a tester works on a ticket, he sends it to the developer. If the developer is not sure about the issue, he’ll send the ticket back to the tester with appropriate comments and a screenshot. Therefore, it is important for the tester to understand each comment that the developer leaves on the ticket so that proper testing can be done.
Often each test ticket will run through a series of smaller, individual tests.
Test planning
Many software testers plan their testing activities ahead. As a software tester, you’re responsible for planning future test and QA projects, making sure that there are enough resources available for the projects ahead. Specifically, test plan may include the following:
- Test goals or test objectives
- Features to be tested or not tested
- What test approaches to be used
- What test levels are needed
- Exit criteria (E.g.: When to stop testing)
- Risks
- Roles and responsibilities of team members
- Test milestones
- Test deliverables
This gives testing departments a productive start ahead when they start with their next QA efforts.
Test Reporting
The whole idea of software testing to identify problems or potential problems so that the management can make the informed decision. Finding defects or executing test cases is one part; the other (yet crucial) part is to communicate the test result to management.
As a tester, you’ll need to report as soon as possible (often on a daily basis):
- What you tested and how the test result is
- There’s any critical issue that the management team should know
- How many more tests you need to test
- There’s any roadblock issue blocking your testing
Wrapping it up
When it comes to software testing, a lot of skills are required to achieve the daily tasks. As a software tester, no day is the same and you’ll face new challenges every day. However, these are the basic and most important activities that you often spend your time on. A day in the life of test will become much more meaningful if you do your best job around these activities.
About the author:
Thomas Peham is a marketing manager at Usersnap, a visual bug tracking software used by software companies like Microsoft, Facebook or Hawaiian Airlines. He is also running bugtrackers.io, showcasing the lives of web developers. Say hi on Twitter.
I know that for someone starting their career keeping things simple is important, but, “A software tester’s main job is to locate and report bugs.” is too over simplified and wrong. A software tester’s main job is to provide objective information about the software, of which bugs is just a part.
I hope that someone early in their career can spot that the article was written by someone with a vested interest in raising and reporting progress of bugs and wonder if the article is subjective or objective, a guide to all or a guide to part and if there were no bugs why you would need a paid for system to monitor them. (The difficult question then becomes how do you get no bugs? Answer – Search for the answer. Augusto has a view reading)
Hey John,
Welcome back and thanks for your time visiting my site.
I do agree that the statement may be too over-simplified. I believe Thomas was not trying to mislead new testers to let them assume that the only job testers do is finding and report bugs. However, if we take the definition of bugs “Anything that threatens the value of the product. Something that bugs someone whose opinion matters”, I think the “finding/reporting bugs” aligns well with your opinion of “providing objective information about the software”…so I’m fine with that.
Anyway, thanks for your feedback.
@testers,
Read John’s comment above because he has brought an important point to take note.
This content is really cool. I have bookmarked it. Do you
allow guest post on your page ? I can write hi quality posts for you.
Let me know.