Software Testers: What They Do Exactly and 3 Common Misconceptions
December 7, 2021
Do you know what is common between Thomas J Watson and Paul Krugman? Apart from being distinguished professionals in their respective fields (business and economy), they made vastly inaccurate predictions regarding technology and its advancement. While the former said that there is a world for only five computers, the latter claimed that the effect of the Internet on the world economy would be negligible and comparable to that of the fax machine. Nowadays, those claims couldn’t be further from the truth.
Technology and information technology, in particular, have advanced immensely in the last century. In 2021, when a hot topic of discussion is implantable brain machines, this technological advancement hasn’t been impeccable and doesn’t come without let or hindrance.
In our day-to-day lives, we are all using smartphones, using various applications, and we all share one common trait – we get upset when something doesn’t work in the way we expect it to. But why do we become unwilling “casualties” of such imperfections in a machine that is supposed to be “flawless” and meant to serve us? The answer is simple – software is imperfect because humans are imperfect and prone to making mistakes! An approach to overcoming such problems is software testing, especially when done right!
An ongoing common misconception about software testers is that they only run pre-made tests or scripts. In other words, a tester is “feeding” the system under test various inputs, and then he is observing and assessing if the produced outputs are of the needed quality. This activity is a part of the test execution activities. Still, there are more aspects that make up the test process, namely test planning, monitoring and control, design and implementation of tests, reporting test progress, and logging defects. Let’s examine those in closer detail.
Software Testing Essentials
The fundamental test process starts with the test planning activity. Put simply, the tester decides on what his test objectives are and how to successfully achieve those. For example, a typical objective of testing is to evaluate requirements, stories and design, the so-called test basis, by using static reviews (without executing the software or component). Ideally, all testers should be involved in the static reviews of documentation from the very beginning, and in due time this will lead to increased development productivity as reviews of requirements get more effective at detecting defects and the product owner better at mending those defects with each consequent iteration.
Further testing objectives include verifying that all specified requirements have been fulfilled, ensuring that the test object (a whole system or a component) works according to stakeholders’ and end users’ expectations, complying with contractual, legal or regulatory requirements, finding failures and defects and more.
Key Phases of Software Testing
Since unpredictability must always be accounted for, from a testing perspective, in the test monitoring and control phase testers should compare actual with expected test progress and take the necessary corrective actions to mend any deviations from the expected results which have been specified during the test planning phase. An example of a test control activity would be re-prioritization of test cases, as there could be dependencies between them or simply because a component of the system is not yet in a test ready state.
Remember the evaluation of requirements, stories and design mentioned above? Well, in the test analysis phase, testers should identify the features that need to be tested. In test analysis, testers should determine what needs to be tested based on the analysis of the test basis. After the testers determine what needs to be tested, the next logical step is to determine how to test it. This is achieved in the test design phase, where the results from the test analysis phase are translated into tangible test cases with specific inputs and test data needed to exercise the software or component under test.
Before moving to test execution, testers need to set up the test environment and combine the designed test cases in a particular order. This is achieved in the test implementation phase, as testers are making sure that everything is set in stone to start executing tests, gather the results and metrics from the test execution and present those to the involved stakeholders. While executing the tests, testers should observe for any failures and deviations between actual and expected results. Once analyzed, those failures should be logged as defect reports, assigned priority and queued in the backlog.
After executing all the tests, completing all checks and logging all defect reports, testers should gather and summarize all collected data from the test phases. In this phase, we testers report the test progress to the involved stakeholders. The reporting usually happens at a major milestone, e.g. in an Agile context, a major milestone is when we finish an iteration.
Three Most Common Testing Misconceptions
As mentioned above, the most typical misconception regarding software testing is that their core task is to simply run pre-made tests and check if the software is behaving as planned. The last paragraph revealed that software testers have other crucial responsibilities such as test design, planning, analysis and control before diving deeper into test execution.
The second most common misconception about software testers is that they’re concerned only with checking if the system works according to its “requirements”. A requirement usually states what the software should do, so the tester checks if that is correct, and this is it? Now, read those two questions aloud – “Did we build the system right?” and “Did we build the right system?” They’re similar, right? However, the first question is concerned with the term “verification”, i.e., the tester verifies that the software adheres to specified requirements, while the second question is concerned with the term “validation”, i.e., it’s essential for the tester to confirm whether the system meets the operational end users’ and stakeholders’ expectations. In this case, the tester is the end user’s voice and should always take into consideration if the built system provides the needed solution.
In order to better illustrate the significance of validation testing, let’s imagine a system that adheres 100% to the specified requirements but what happens if the requirements were wrong? In this situation, we’re stuck with a perfectly working but misconstructed system that fails to satisfy the end user’s needs. From a business perspective, this could mean potential bankruptcies if a competing system does whatever our system needs to do.
The third most common misconception about software testers is that they’re not “technical” enough. To debunk this misconception, a comparison between software development and software testing has to be made. First of all, those are two separate fields and while they require different skills, they intersect, so they could complement each other. Software development is a highly tech intensive activity, the developer’s thinking revolves around the technical implications of a given task and the solution implementation. In contrast, the software tester mindset revolves around what could go wrong, what has been missed and what the implications could possibly be. Naturally, testers are cautious pessimists and live by the mantra “trust, but verify”. When it comes to tester qualities, “people skills” usually rank higher and what’s important is the tester’s willingness to pick a new skill, so that he could complement his colleagues and do the task to the best of his ability.
Software testing is comparable to being at the beginning of a climb to a summit. You know where you need to go and where you need to end up but you’re not certain of the path you should take. Would you pick a familiar path or would you rather experiment and learn in the process? Whatever the choice, curiosity, attention to detail, willingness to learn and communication are the software testers’ greatest tools and should be used whenever necessary as software testing is a constant roller-coaster.
- Foundations of Software Testing ISTQB Certification, 4th edition
- ISTQB, Foundation Level Syllabus, Version 2018 V3.1 https://www.istqb.org/downloads/send/2-foundation-level-documents/281-istqb-ctfl-syllabus-2018-v3-1.html
- “Testers just Validate Acceptance Criteria”