According to State of Testing report, software testing industry is growing like never before. It’s not surprising that more and more people want to become a tester too. Testers also often send me emails sharing how much they are enjoying their journeys.
I’m glad to hear that and happy for them.
Unfortunately, I also see complaints from people that how much they don’t like software testing. They feel like they chose the wrong path and that they wasted their time with testing after doing testing for a few months.
Why did that happen? Aren’t those people who used to be very interested in and excited about software testing in the first place?
There are several reasons to explain why that happened, but there’s one big reason to me is this: disillusion
They thought software testing is easy, now they see it’s not
They thought software testing is about finding bugs, now they realize there are more involved activities that they simply don’t enjoy doing every day.
They get confused and uncertain if testing is the right career paths to follow or not.
It’s bad when that happened. However, you can avoid such situation by knowing what software testing looks like, what testing activities are waiting for you ahead so you can decide if you want to get along with it…well from the first place.
That’s exactly what I’d like to share with you in today’s post
Note: Before start reading those testing activities, please note that software testing activities are not limited to what I mentioned in this post. Based on my experience, I’ll try to list some but I’m sure it’s not the ultimate list. Also, at the same, please be aware that some companies use different terms to refer to the same things that I provide on this list.
Now let’s get started.
1) Read documents
Finally, you made it. You’re hired after several rounds of interview with some tough and good questions (some are stupid too) but it’s not important anymore. Now you’re qualified for the position and now you’re a tester.
Imagine this is your first day at work. Your manager/leader will introduce you to the team members. If you’re lucky, your team is co-located and you are introduced your team member names and faces. After getting to know each others, you’re very excited right now for the first tasks assigned to you.
“Here are documents of the project, start reading them” your manager says.
Okay, I’m exaggerating a little bit but basically, you will be assigned a task to read some documents like specification, guide, help, etc so you know more about the system you’ll test.
While you’re eager to expect to be a rock star where you find a lot of bugs that wow your manager or hit the ground and run, I have to say that reading the documents to know the system under test is one of the very first things you do in the project.
So take this opportunity to read and ask as many questions as possible about the system you gonna test. If your project does not have any document, ask your manager about how to know more about the system.
After you finish a reading document session, you may have to present what you’ve read and how you understand things to team members/leader. You may also use the knowledge you get to start other testing activities like design test cases which I’ll talk about it then
How long is this activity?
It depends on how your project is doing. Some projects are small so you make need take 1-2 days to read. Some projects are big, it may take you more days.
How interesting is this activity? Boring. I’ve never seen any testers claim that they love reading the specification. It’s even more boring in some cases when you do not have access to the system while reading documents. It means that you may read the document and image how the system and components will work together.
How important is this activity? Very Important. Even though document reading is boring in its nature, this activity is very important. The more you know about the system under test, the better you can write test cases or find bugs.
2) Test case design or test case writing
If your project is a classic project following a traditional software development life cycle and you’re at the beginning of the project, you will surely do this activity.
This activity is called test case design or test case writing.
I assume you already knew what I mean when I say test case design. If you don’t, you may want to take a look at my free course on how to design test case (it’s free by the way)
Please note that there are various ways to write or present your test cases. They can be building a checklist, building a mindmap or scripting a detailed step-by-step test case like the one I share in my course.
That sounds overwhelmed but don’t worry for now. More often, your manager will provide you some kind of instruction on how to design test case so you can follow easily.
Another entailing activity of test case designing is this one:
Test case reviewing:
Since you’re new, you’re often well taken care of. It means that things you do often are reviewed by your test leader or your peer.
Once you’re done with your test cases, your leader/peer will sit back with you to verify and validate your test cases to make sure you do the right things and you do it right. If you make it right right the first time, it’s great, but more often you have to go back and modify your test case here and there a little bit.
Don’t take this as a bad thing. It’s always good to have someone review things you do, give their opinion and make you better. This is also a great opportunity for you to ask questions and clarify things so you know more about the system.
Even though designing test case is not something super fun, it’s not too boring either. Some testers I know do like this activity because they have a chance to be creative in how they want to test the system.
3) Test execution/regression
Once you have a new build to test, you need to re-run test cases that have been written. We call it regression testing activities.
I talked about regression testing here, but basically, regression testing is:
If you have 10 test cases for a feature, you need to re-run all those 10 cases
If you have 100 test cases for your system, you need to re-run those 100 cases
Hope you got the idea.
Regression testing is very beneficial for testing but you may face another problem: test case updating
When you re-run your test cases against the new build, you realize that some functions in your system have been changed and now your scripted test cases become obsolete. Now you need to go back to your test cases, modify to make them up-to-date and run them. It’s not a big deal if the change is minor and there are just a few test cases need to be updated. However, it would become a pain in the @ss if it’s a major change happening across functions and you have a few hundred test cases to update…and that’s not fun at all.
But don’t worry, your system is not always changing. Some good days, your test cases do their jobs and you can even find some important defects by running your test cases too.
How interesting is this regression testing activity?
So-so
If you just have to run a few rounds of regression, you’re okay but if your regression cycle is short and you need to repeatedly re-run your whole test suite, this can become boring. However, like I said before regression testing is really important, so like it or not, sooner or later, you’ll have to do it.
4) Exploratory testing
Most of the testing activities are quite boring so far but as a tester I’m sure you will love this activity: exploratory testing (or ad-hoc testing if you’d like to call)
This is now time for you to rise and shine. This is an opportunity for you to use all your knowledge of the system, your bug finding skills to find bugs in the system.
Disregard if you’re following session-based technique to explore or you just do a free test session, I have to admit it’s fun to do this activity. You will find bugs that not covered in your scripted test cases. You will unleash your creativity and imagination to think of scenarios where the end users will use the system and how things may go wrong.
Since exploratory testing is an important activity and it’s fun to do, I do always recommend we should schedule a good amount of time for this type of testing in the project. It’s really helpful.
5) Bug reporting
If you’re a tester, sooner or later you’ll find a bug and you need to report it. Basically, it’s just an activity for you tell people what problem you found, bring them to attention and have them fixed.
I wrote a blog post and put everything a tester needs to know how to write good bug report here, so take a look.
Is it difficult?
More often, your team also has a set of guideline or the format for you to follow. Stick to it and you’ll be fine then.
Is it boring?
Not really. I don’t know you but writing bug report is quite interesting to me. It’s not only because it’s a way to “show off” my testing output but also it helps me practice writing skills. If I can write a good bug report, people can understand the problem quickly and how critical the problem is.
Is it important? Very important. Please note that when you do testing, you’re not only testing but also you’re providing services and your job is to provide as much information about the system under test as possible and bug reporting is one of them. Do it right, people will see your value.
Some pitfalls to take note:
- Avoid reporting a duplicate bug
- Avoid reporting invalid bugs
- Avoid report unreproducible bugs
- Avoid blaming someone for the cause of the bugs
- Avoid missing important information in the bugs like titles, descriptions, step-to-reproduce, etc
6) Meetings
(Image credit: http://dilbert.com/strip/2016-01-25)
“Oh well meeting”…there’s a ugly truth about meetings, but like it or not, meeting is unavoidable in projects.
There are different types of meetings happening throughout project lifetime. Here are some common ones:
Daily meeting:
If your team is working following Scrum framework, daily meeting is considered a must. In this meeting, each team member will take turn to update the working progress by answering these three questions:
- What you did yesterday?
- What you do today?
- Is there any roadblock?
If you’re not following Scrum, daily meeting is also important very important in cases where you have a large team and team members do not have frequent communication.
Bug meeting/bug triage meeting
In this meeting, team members, team leader and/or manager will review bugs reported by test team (mean: you) and discuss them in order to:
- Clarify some unclear points of bugs or ask for more information from testers
- Decide which one to fix first, which one to fix later
People don’t like meeting in general. However, if the project is large, complicated or your team is not co-located, a frequent meeting may enhance team communication. So take this opportunity to ask good questions to know more about the project, the system under test, the plan of the project. The more you know the better you can test the system.
7) Reporting your testing progress
If your team does not often have daily meeting or you’re part of outsourcing team, you may need to report your testing progress, test result. You can report your testing progress via email or meeting or …both. This can be done on daily or weekly basis depending on your team and your role.
Don’t under-estimate the value of test reporting. Sharing your testing progress, your test result or blocking issues you observe will help managers have information and data to make decision accordingly.
So, there you have it. I’ve shared with you some common testing activities that you should know in advance as a tester.
I told before and I’d like to stress it again, these are activities I experienced not all activities out there. Also, what I shared here based on my view, my feeling and my projects. However, knowing this can give you a heads-up on what may be waiting for you ahead. Knowing this can help you answer the question if these are activities you’re okay to do…sometimes every day. In fact, you would or would not do the exact same activities I share here. Just take it as a reference. Sometimes, you need to experiment and see things through your lens.
Great information. I’m moving into a career in software testing and this was very helpful. Thank you for sharing.