How do I know if I can be a good software tester?

Question

I am a developer looking for a QA role. I know that the mindset of a developer and a tester differ fundamentally. Besides hands-on experience in a QA environment, are there any other ways to determine if I have what it takes to become a skilled tester?

Answer 1

Best way to determine if you are a good tester:

1) Are you methodical. Can you repeat the same steps every time with slight differences to exercise different logic paths.

2) Are you extremely anal-retentive.

Either of those is good, both are great.

Answer 2

You can try testing an open-source project: they come at all stages of development (mature or not), and should also have specs. That'd give you a chance to work on a real project with real developers, testers, bug tracking system, etc.

Answer 3

Do you feel that testing is critical or something that just has to be done? Do you currently write tests for your own code? When you write tests, do you have trouble thinking of new tests? When you look at someone else's code are you able to see the errors that are there? Are you able to determine whether a set of tests, with or without full coverage, actually tests the full range of possible paths and behavior? Are you willing to learn more about testing than you already know? Are you willing to be secretly despised, and perhaps feared, by those who merely tolerate testing and don't embrace it? What's your favorite color: green or red? (Hint: the right answer is green!)

Answer 4

To extend on GWLlosa's excellent response.

1 Patience

You must possess an almost infinite patience, because much of what you will be doing is incredibly frustrating (as it is broken) and also incredibly boring. Presuming the applications has options and states, you will be doing largely the same sequence of events over and over.

2 Thorough

One of the things about developers is that they commonly (hopefully) test their own stuff before they check it in. In most cases, this means that the application probably works in the (or a) normal case. However, that is typically on the developers machine, and they usually use the same test case over and over. It is your job to test for a wild variety of perfectly normal seeming test cases, and then test all the edge cases, and then test all the unacceptable cases. Then, if the application has different states, you might need to check all those things again with a seemingly unrelated difference (I.E. changed the colour scheme on your calculator, and now the "+" button does not work).

3 Organized

You must be able to take notes about your every movement. There is nothing more frustrating than having someone report a bug and have no idea how it happened or how to reproduce it. Reproducible problems are 1000x easier to solve, because they can be traced through. Complicated applications, with many interweaving states and screens make it very difficult to fix obscure bugs unless the programmers know how to generate the error in the first place.

4 Creativity/Empathy

Programmers are generally power-users. Both of computers in general, and of their program specifically. They know that the file functions are generally under the file menu, and that buttons need only to be pushed once, and then you wait. Users do not know these things. It is not your job to assume Users are stupid, because they are not, but they don't have the training you have. So you need to be able to understand what they are thinking, and then click a button 100 times as fast as possible. In a lot of applications, this will generate 100 results, which is typically BAD.

I knew of an application where the instructions were to push 'Shift-Enter' and I pressed L-Shift instead of R-Shift. It blew up. The regular users would be typing one handed, so they would 99.9% be using L-Shift, it didn't occur to anyone to bind the other shift as well. That is why you need Creativity as well. You need to be able to fit yourself into a few different roles, and ask yourself how they will be using the software. Then overuse every part of that use case.

---

Ultimately those are just some of the skills required. But as you've noticed, these are all skills which are good to have anyway, so cultivating them is never a bad thing.

Cheers.

Answer 5

Besides the usual stuff like being detail-oriented, having scripting knowledge and having deep understanding of the business domain can make you an outstanding software tester in my opinion, especially if the software is targeted for highly trained professionals in narrow fields. Some examples may be a program that monitors patients heart rate or a program that communicates with autonomous mobile robots in combat zone, etc.. The use case of a trained medical professional would likely be different compared to those who are not.

Answer 6

You really can't know if you'll be a good software tester, until you've been one. There's no one attitude, one background, one skill set that defines a QAer.

It's no different than being a good developer. You can imagine you'll be a good one, because you've tried lots of developer-y things. But until you've done it, you never know.

Ask yourself why you want to switch roles? What attracts you to a QA role?

If you think it will be easier, or you think you will have shorter hours, or you think you will be paid more, or you think everyone will love you - then the QA role may not be for you.

If you are contemplating moving to QA because you were less than successful as a developer - then the QA role may not be for you.

Or, it may all work out, you never know! I know folks in QA who came from all sorts of different backgrounds.

As has been suggested, get yourself in a project (unpaid or paid) where you can perform that role. Then, and only then, will you know if you like it, and are any good at it.

Good luck!

Answer 7

Communication is a key. Knowing how to write an effective bug report is essential.

Clear title

Minimum, quantifiable steps to reproduce the problem

Pictures

Expected and observed results (I love when I don't get the expected results!!!!)

This is a great article on that:

http://itscommonsensestupid.blogspot.com/2008/07/tips-to-write-good-bug-report.html

Answer 8

Simple Thing is " Think Negative "

Always Break Anything for Good

Answer 9

I agree with others who say, "likes to break things."

Also diversity of backgrounds is good on a test team. Former developers often help the team get going with automation, former customer support people can be fierce defenders of a user's right to a useable UI, and so on.

The article, Testers and Developers Think Differently, by Bret Pettichord, contrasts the mindsets and traits that are helpful in each role. For example, it elaborates on themes like these:

• Good testers
  • Empirical
  • What’s observed
  • Skeptics
• Good developers
  • Theoretical
  • How it’s designed
  • Believers

Here are notes from Cem Kaner's Testing Computer Software, on some attributes and skills useful to a tester:

• Integrity, and a commitment to quality
• An empirical frame of reference vs. theoretical. Tests as miniature experiments.
• Education
• Some programming background. Useful, not essential.
• Experience using many computers and many software packages
• Knowledge of combinatorics. How many test cases required to fully evaluate some aspect of a program?
• Excellent spoken and written communication.
• Good at error guessing.
• Fast abstraction skills.
• Good with puzzles.
• Very conscious of efficiency.
• Able to juggle many tasks.
• Good at scheduling
• Careful observer, patient, attends to detail.
• Role-playing imagination.
• Able to read and write specifications.

Answer 10

I think that devinb gives an excellent answer about some skills/qualities that tend to make good testers. Another I'd add is:

Strong Communication

A tester is often translating between non-technical desires from stakeholders, and technical implementation details from coders. Being able to translate in both directions is very handy. Similarly, the main product that testers produce is test reports (both bugs and broader, often both written and verbal). Being able to effectively communicate what the (multiple) consumers of our reports need to hear is key to being effective. This includes both clarity and a helpful/non-judgmental tone so as to foster a collaborative relationship.

Ways To Determine

Looking at your question "are there any other ways to determine if I have what it takes to become a skilled tester?" with an testing mindset, I notice that most of our answers have addressed the "what it takes to become a skilled tester" portion of your question. I want to also spent a minute on "ways to determine".

1. Informational interviews with testers you respect (or at companies you respect). This can allow you to ask more specific questions -- with follow-up -- and give you answers focussed on particular contexts that interest you. (Much of what devinb stated above is generally applicable, but testing commercial web apps v. embedded, life-critical software v. video games -- all will give you different answers.
2. Test open source software. I'm always amazed how few folks trying to break into testing do this. It will help you understand more about what testing is, and build a portfolio of public bug reports that you can link to. Choose whatever OS project in active development that you fancy, and dive in!
3. Study testing There are great books, blogs, and courses out there. Different testers will point you toward different ones, but in my opinion the writings of Cem Kaner & James Bach (books or blogs) are a great start. In terms of coursework, annual membership in the Association for Software Testing gives one free access to the Black Box Software Testing series, an amazing set of high-quality, instructor led courses, designed by Kaner & colleagues.

Best of luck to you!