The QA Brain

Software testers come from all kinds of backgrounds- computer science, biology, English, business, music… some find it tedious while others find it enthralling. From the outside, filing bugs, executing tests, planning QA schedules is straight forward enough, but some people excel in what other people can’t bare. I’ve found that good testers develop (or are have inherently) a common mindset.

A QA is:

Detail oriented. This goes with out saying. A software tester is always aware of changes in UI, in functionality, or inconsistencies in the product they are tested. They are responsible for watching out for the minute details that often fall through the cracks. You might stare at the same text or the same few pages day after day, but you have got to keep yourself focused enough to notice the details.

Destructive. Software development is very constructive- software engineers creatively design and build their systems to work.  They create functionality where nothing existed before. Software testers need to be destructive. We need to test not only that it works, but also that it doesn’t work correctly. Confirming that all functionality works is only half of our job, and arguably, not even the most important part. We need to test what happens when the software encounters a situation no one has thought about. How does it fail? Where does it fail? How does it recover from failure? How far can it be pushed before it goes down?  QAs go in to test and try to break it in as many ways as possible. Users will find creative ways use the system and QA needs to make sure that they have already tested those creative ways before it goes out. This is the biggest difference in the mindset between a software engineer and a software tester. A good tester will think negitively- look for all the loopholes, cracks and over sights.

Creative. A software tester needs to look for bugs where you don’t expect them. Issues are there; they just need to be found. There are always bugs in software; the best QA is often the most creative in imaging crazy test cases.

A good communicator. A lot of how successful you are as a QA goes back to your language skills. Clearly communicating a bug can make the difference between getting it fixed and getting it rejected. A bug needs to express its importance quickly, and give clear reproduction steps and reference documents in away that anyone can understand quickly. Good document ambiguity review requires you not just to know what questions to ask, but how to ask them well. If you are maintaining documents, they need to be easily accessible for many different types of people. Often a QA needs to be understood by engineers, project managers and clients. Sometimes (often) each of those groups speaks a very different language. QA documents, test plans, bugs, and participation in meetings needs to be understood and respected by each of those groups. Know at least enough tech to understand how the devs work and how your system works, and always be eager and open to learn more.

Patient. When it is you job to work with buggy, broken, early versions of software, you will need to be patient. Maybe you need to wait for documents to be ready, maybe you have to help an engineer understand why your bug is an issue, and maybe you need to debug an automated test that you just can’t seem how to fix. Software testers need to stay calm and rational, dig through the problem instead of running up against it.

Organized. You are nowhere with out organization. You will be responsible for keep track of your own test cases, test results, bug status and product schedule. You might have help there, but there is a good chance you are going to have a lot going on that you need to keep on your radar. Test management programs are a lifesaver, but QAs successfully use excel spreadsheets and online documents as well.

Self-Disciplined. The great thing about QA is that you often get a lot of freedom. You have schedules to adhere to and functionality to test- but you usually have a lot of leeway in how you go about getting your work done. This is great for people who can stay on track. You can be creative, ask questions, set your own pace, push yourself and try new things. The challenge with that is to stay focused and keep your tasks organized and prioritized.

A Multitasker. This goes back to the organization piece. If you can’t multitask, software testing is going to be very difficult. You need to juggle automation results, debugging, manual tests and quick fixes. Some people don’t work that way. Some people love to zoom in on one task and carefully complete it-and only it. When those people try to test they often get distracted by weird, corner case bugs and miss the showstopper issues. Multitasking is essential, to keep your testing moving forward, keep you focused on what you need to do and what the rest of the team is doing, and keep track of previous issues filed and new features coming up.

Stubborn. If you find a bug, and you know it is a bug, you need to be stubborn enough to push back when it is rejected. Devs can be intimidating- they wrote the code, of course they know how it should work. But really, that isn’t their job- it’s yours. You should find out how the product works

An overachiever. You could stop testing when all your bugs are verified, but if you have time, why not try a little more? Why not ask questions about something that seems to be working strangely, just to confirm that it is ok? Why not actively hunt down bugs instead of passively testing functionality? A lot of testing is going out in search of things- ambiguities, proper behavior, bugs, rules, compatibility/connectivity rules, you take all your data and roll it up into a picture of what needs to be tested and how urgently. Take the time to make sure you are looking in the right places, asking the right questions and, schedule

Advertisements

One response to this post.

  1. […] is an interesting blend between scientific and creative, between destructing and constructing. It requires a flexible yet ordered mind and, as with any scientific approach, it requires […]

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: