Unless your name is capital G-O-D, you, me and the rest of humanity will never make, never see and never use perfect software apps. With so many fresh college graduates (and even high school kids) wanting to be the developer of “the next killer app”, doesn’t it make you wonder who actually checks them before you pay for the right to use them? Oh, I forgot. Many don’t check—and others, still, don’t pay.
Anyway, there are such people who actually make peaceful sleep possible knowing your app is fine. They are the unsung heroes of pre-release dates: the quality assurance specialists!
A day in the life
The software QA guys—the footmen of which are the software testers—go through their days receiving fresh apps and problem logs from software developers. Business analysts or project managers would tell them how a properly functioning app should be working under normal use and behave when given undesirable inputs.
There is more geeky logic and math involved in cranking out cool apps than just running a few random checks and calling it a day. Just imagine selling your software like pancakes one day, only to see your customers uninstall them and blog about your products in social media the next day. Which costs more? Taking time to develop your apps and having them tested, or getting negative reviews and being forced to close shop?
Software QA specialists have laid-out procedures called test scripts that contain a number of test cases; each one is answerable by either “pass” or “fail” and has an expected result and a space for actual result. Each test case will check for one software behavior. There is normally one test case for feeding, say, a whole-number input box with acceptable data (a range of acceptable whole numbers), and several other individual test cases for “bad” data like decimals, off-range integers, letters, symbols and blanks (in required fields).
In typical black-box testing, where the software under test is run through the test script without the QA specialists knowing about the program code, the QA specialists will run through each test case one by one, recording results as they occur. Actual results will be compared to expected or ideal results. Dates when the tests were performed will also be recorded to keep track of the age of errors to be resolved and turnover times. When the test script is finished, a report tallying passes and fails will be prepared.
Before you think that a 75%-passed software is ready to roll out, think again; don’t treat this job like your typical high school or college brain-dump during midterm exams. The software just tested will not get to roll out until all tests report “passed.” It would be their job now to report their findings to developers and the project manager. If one can’t play and hold on to the role of “Bad Cop” (Liam Neeson’s character in the LEGO Movie), then this job is not for you.
Your need-to-know
This job can get tediously meticulous, to say the least. But you’re going to be paid considerable bucks to be the bad guy. There is every reason why many senior QA specialists are paid middle- to upper-five-digits just to be the software developers’ character foil.
The good news for QA candidates is that you’re going to be job-secure. Like I said, unless you’re the Man Upstairs, nobody creates perfect software. If at one time every test turned out to be “passed”, somebody from User Acceptance Testing (UAT) or in real-life use is going to report some sort of anomaly at one point or another. That’s not a matter of “if”; that’s a matter of “when.” It could be your job or that of Tech Support to plan the next software patch roll-out.
Before you decide that you’re cut out for this job, know your state and decision modeling. You need to be able to visualize every conceivable error arising from software behavior. For that, you need to brush up on your counting techniques: permutations and combinations. Some software behaviors also have causations: they don’t appear until a certain event happened first, so know how to make decision trees (or tables) and state diagrams.
If you will be thrust in white-box testing, you should have been a developer first. You will be required to perform a code walkthrough wherein you have the chance to spot potential errors—in the code—even before an app is run. A good imagination is therefore as indispensable as having keen senses. Being “OC” (obsessive-compulsive) is not necessary (or you’ll need to see a shrink), but being firm on judgment and error-identification is.
Math skills are as important here as logic. Aside from counting techniques, you need to be able to compute rates of resolutions after keeping track of how long it takes to resolve each one and by whom. Software errors and error resolutions have costs. Time is money; how quickly resolutions are made is essential to the reputation of the software application—and its developers and the entire company!
You are a good SQA specialist if...
...You can read the logic in code and the relationship among chunks of them. You can think of just about every way things can go wrong before they do. You can spot more errors and release error documentation in a short time. If you can do those, you save your company lots and lots of money as well as countless reputation--all without losing your sanity.
Other more serious career-advice articles from Yours Truly:
Anyway, there are such people who actually make peaceful sleep possible knowing your app is fine. They are the unsung heroes of pre-release dates: the quality assurance specialists!
A day in the life
The software QA guys—the footmen of which are the software testers—go through their days receiving fresh apps and problem logs from software developers. Business analysts or project managers would tell them how a properly functioning app should be working under normal use and behave when given undesirable inputs.
 |
| A sample test script from the book Software Engineering by Kuwaiti University professor Kassem Saleh. |
Software QA specialists have laid-out procedures called test scripts that contain a number of test cases; each one is answerable by either “pass” or “fail” and has an expected result and a space for actual result. Each test case will check for one software behavior. There is normally one test case for feeding, say, a whole-number input box with acceptable data (a range of acceptable whole numbers), and several other individual test cases for “bad” data like decimals, off-range integers, letters, symbols and blanks (in required fields).
In typical black-box testing, where the software under test is run through the test script without the QA specialists knowing about the program code, the QA specialists will run through each test case one by one, recording results as they occur. Actual results will be compared to expected or ideal results. Dates when the tests were performed will also be recorded to keep track of the age of errors to be resolved and turnover times. When the test script is finished, a report tallying passes and fails will be prepared.
 |
| If Prof. Saleh says "Finding errors is an asymptotic nonlinear function of time", Earl of Lemongrab screams "UNACCEPTABLE!!! ONE MILLION YEARS DUNGEON!" (Fig. 8.1 from Software Engineeering, J. Ross Publishing; Earl of Lemongrab animated GIF from Cartoon Network) |
Before you think that a 75%-passed software is ready to roll out, think again; don’t treat this job like your typical high school or college brain-dump during midterm exams. The software just tested will not get to roll out until all tests report “passed.” It would be their job now to report their findings to developers and the project manager. If one can’t play and hold on to the role of “Bad Cop” (Liam Neeson’s character in the LEGO Movie), then this job is not for you.
Your need-to-know
This job can get tediously meticulous, to say the least. But you’re going to be paid considerable bucks to be the bad guy. There is every reason why many senior QA specialists are paid middle- to upper-five-digits just to be the software developers’ character foil.
 |
| If you apply to be a SQA tester, don't expect to be this minifigure's alter ego. Quick! Use "Kragle" on jack-ass developers before they say "I quit!" (Bad Cop from the LEGO Movie official web site) |
Before you decide that you’re cut out for this job, know your state and decision modeling. You need to be able to visualize every conceivable error arising from software behavior. For that, you need to brush up on your counting techniques: permutations and combinations. Some software behaviors also have causations: they don’t appear until a certain event happened first, so know how to make decision trees (or tables) and state diagrams.
If you will be thrust in white-box testing, you should have been a developer first. You will be required to perform a code walkthrough wherein you have the chance to spot potential errors—in the code—even before an app is run. A good imagination is therefore as indispensable as having keen senses. Being “OC” (obsessive-compulsive) is not necessary (or you’ll need to see a shrink), but being firm on judgment and error-identification is.
Math skills are as important here as logic. Aside from counting techniques, you need to be able to compute rates of resolutions after keeping track of how long it takes to resolve each one and by whom. Software errors and error resolutions have costs. Time is money; how quickly resolutions are made is essential to the reputation of the software application—and its developers and the entire company!
You are a good SQA specialist if...
...You can read the logic in code and the relationship among chunks of them. You can think of just about every way things can go wrong before they do. You can spot more errors and release error documentation in a short time. If you can do those, you save your company lots and lots of money as well as countless reputation--all without losing your sanity.
Other more serious career-advice articles from Yours Truly:
