New Testers: Stop Worrying about These Things… and You’ll Be Fine

Software testing is challenging and it’s even more challenging for new tester.

Regardless of how much effort you spent on researching software testing, improving yourself and trying hard to do better testing, you still don’t feel that you are making any progress or worse you are not sure if testing is the right one for you.

From my experience, it’s not because you are incapable, it’s because you are worrying too much about things that do not really matter to new testers.
By stopping worrying these things, you will be fine.

1. Terms and Definitions

This is the number one worry I believe even though there’s no official statistics about this.

Why I believe so?

In most of software testing forums, online discussion, the following questions have been asked:

What is QA, QC, Tester?
What is the difference between QA, QC, and Tester?
What is the difference between Bugs, Defects, Errors, Faults?
What is the difference between Test Plan and Test Strategy?

Am I saying that you are not allowed to ask these types of questions? No, absolutely.

terms and definitions

Image courtesy of Surachai at FreeDigitalPhotos.net

When you don’t know a term or get confused, it’s natural for you to ask these questions. However, if you ask these questions again and again with intent to find the BEST definition, you are wasting your time because these types of questions often lead you to nowhere.

You know the beauty of terms and definitions?

Well, people can define things as they wish with their context.

In case you want to be a collector of terms and definition in software testing, I suggest you to stop worrying too much in terms and definitions. Pick up one and go with it.

2. Rejected Bugs

Let me guess.

rejected bugs

Image courtesy of Stuart Miles at FreeDigitalPhotos.net_4

You spent several hours exploring the system and found an amazing bug (at least you think so). You happily reported the bug on to Bug Tracking System and a few hours later, the bug was rejected by developers or your manager.

Note: by “rejected” I mean the bug is invalid and you agree to

You feel like you are “Rejected” and then you worry:

“I had several rejected bugs this month, I wonder if this affects my testing productivity?”
“Developers are laughing in my face for reporting an invalid bug”
“My value is going down”
“Developers don’t like me”
“I have a problem with my testing capability”

Take it easy, my friend.

When you test a product, you know something about the system under test, but there are also things that you don’t know yet. Testing is a learning process. When you test, you go from the known things to the unknown things.

If you have rejected bugs, it could be because you are not updated on the changed features or even don’t know if the feature exists. Learn from it and move forward.

What I’m trying to convey is that don’t let rejected bugs discourage you from finding more good bugs.

Side note to managers: if you are judging tester’s productivity based on counting bugs, can you please just stop?

If you worry about rejected bugs, it’s likely that you are also worrying this thing.

Related: 3 Reasons Why Your Bug Report Sucks (and How to Fix it)

3. “I missed bug”

This may be one of the scariest phrase testers don’t want to hear from their boss. This is one of the most common misperceptions in software testing.

Related: 5 misperceptions in software testing

You feel guilty and worry for every bug escaped and found in the field because:

• Your boss is counting the number of bugs and basing your productivity on them
• You consider yourself as Gatekeeper or Goalkeeper who catches all bugs in the system. If one single bug is leaked, you think you are doing the job right.

If those are the cases, this is a good time for Blame Game starts or the so-called CYA.

“No, it’s not my fault, the bug is missed because [someone] did [something]”
Or you will report every single bug exhaustedly and insist developers fix them all before releasing the build (of course, this is unrealistic because who can detect all bugs and who have all the time in the world to fix them all??)

Instead of worrying too much about bugs missed, you can:

a) Work with team and analyze why we missed the bug. This is not a process to find who is responsible for the problem. This is a process to see how we can avoid the problem from happening next time.
b) Stop considering yourself as Gatekeeper.

Again, side note to managers: if you are judging tester’s productivity based on counting bugs, can you please just stop?

4. “I’m just a manual tester”

With the appearance of automated test, manual testers feel like they are being threatened and replaced by automation tools.

“Who needs manual testers while there are powerful tools out there can run thousand of test cases with an eyeblink.?”
Below is a search result for the term “is manual testing dead”?

is manual testing dead

It looks scary!!! Look like manual testing is dying or at least testers are worrying about that.

Recently, I did a short interview with Augusto (you can read the entire interview here) and here is what Augusto said about this:
“I think that manual and automated testing is a false dichotomy. They are two completely different solutions that resolve two completely different problems; the only link between them is in the name.
Our industry, in particular, some tools vendors, have made a mess by conflating the two concepts. This has confused testers and also encouraged companies to use the wrong tools for the job.
I believe that we need both, test automation and exploratory/manual testing, as I said before, they resolve different problems.”

If you need more to convince you, check out these two blog posts from Michael Bolton (Don’t let the year of the post discourage you, the posts are still worth reading)
http://www.developsense.com/blog/2013/02/manual-and-automated-testing
http://www.developsense.com/blog/2009/08/testing-vs-checking

So, no, manual testing is not dead until automated tests can help ask great questions to challenge the system under test.

5. “I don’t have any documents, how can I test?”

no documents to test

If you are a tester transitioning from a traditional shop to Agile shop or you are in half-baked project, you may find it shocking when you have to test without a handful of system documents

You don’t know where to start.
You have no clue of sign-off requirements.
You don’t know how to baseline your testing.
You are totally confused and get lost.

Don’t panic. Having no documentation to test is no the end of the world.

Instead of worrying and depressing yourself, try the following:
• If you don’t see documentation, just ask.
• Talk with anyone you think can help you understand the system and have them walk you through the system under test.
• Perform exploratory testing and following oracle heuristics (HICCUPPS). I recommend “Testing Without a Map” from Michael Bolton for the guide of this kind testing

Click here to download “Testing Without a Map” paper

6. “How to get a first job in software testing?”

first job in software testing

Image courtesy of pat138241 at FreeDigitalPhotos.net

What the heck is all above worries mean, if you can’t get the first job as a test engineer.

To some extent, find your first job in testing is the biggest worry ever. This is especially true if you are a new graduate or you are moving to software testing from another industry.

Let me articulate this worry:

• There are hundred thousands of experts out there with years of software testing experience
• Your testing experience is zero
• Most of job ads require at least 1-2 years of experience in testing… for junior tester position

Let’s skip crazy job ads like this from recruiters who have no ideas they are talking about in their job ads. What I can say is that no, you are no in a dead end. There are ways out.

If you don’t have experience, build it.

There are many organizations out there where you can join projects to find bugs. The great thing is that you are paid and work from home. I recommend uTest for this type of project.

How about testing on real products?

You can also practice testing on real products like Facebook, LinkedIn and even on my site AskTester. You may add the following into your CV something like “I found some bugs on Facebook /LinkedIn and one of them crashes the system. Here is what I did…”

The idea is to show people how you really do the testing.

Have I told you that joining forum and online discussion helps too?
Join forum and online discussion to ask questions. The more you ask, the more you learn.

Joining the online discussion will not only help you learn new things in testing, but also make you noticed in the software testing community. Recruiters may find your great questions and passion in software testing on online discussion forum such as LinkedIn and may contact you directly for the job. Yeah, who knows?

Related: My Best Online Resources to Learn Software Testing

7. “I fear Changes”

I fear changesPeople fear change. That’s the fact.

As a manual tester, you worry when you are assigned to automation project where you have to write automated script.

As a traditional tester, you worry when your team is now transforming to Agile where someone one says that you have to test without any document and it’s a chaos.

As a tester, you worry when your project progress does not follow initial plan and your testing schedule is affected accordingly

I can list more, but you get the idea right.

You resist to change because you worry of uncertainty.

You have no ideas of what’s waiting for you ahead and if you are competent enough to deal with changes.

What I can tell is that there’s nothing for you to worry about in those situations

If you worry about automated test because you don’t know how to code, pick up a programming language and check out some courses online to learn. No, you won’t become an expert after learning those courses, but it will provide you enough basic knowledge to start off

Agile is scaring you off?
Testing in Agile is still testing. The core work is testing. The only difference is the way you approach and do the testing. You can research to understand more about Agile (see Agile manifesto)

So, instead of worrying and resisting to change, let’s do a bold action:

“Let’s welcome changes”

“Change is hard because people overestimate the value of what they have-and underestimate the value of what they may gain by giving that up.” – James Belasco and Ralph Stayer

Final thoughts

I’ve just listed out 7 worries that most of testers have to deal with and I had to deal with as well. The earlier you stop worrying those things the better you are. Most of the worries I mentioned above turned out not to be a worry at all. It took me a few years for me to realize that I worried the wrong things in the wrong way and I wished I realized sooner. Now if you are a tester and you are worrying these things, stop worrying right now… and trust me, you’ll be fine.

Like What You’ve Read?

Subscribe now to be updated on future posts!

4 Comments

  1. ThatTestingGuy

    Nice post. I can tell from the flow of topics that you have seen a variety of environments from both traditional and agile processes.

  2. Thanh Huynh

    @Philip,

    Thanks for reading the post and glad that you like it. And yes, I’ve experienced both traditional and agile environments and I often see things from both perspectives. Of course, there are many more experts out there with more lenses than I have 🙂

  3. Hung Dao

    Yeah! your post pings to my heart successfully, and now I’m trying to overcome them.

    Thanks

  4. Ron

    This article is really cool. I have bookmarked it. Do
    you allow guest post on your page ? I can write hi quality articles for you.
    Let me know.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2024 AskTester

Theme by Anders NorenUp ↑