Why Is Testing Necessary? – Foundation Level 2018 ISTQB

1.2 Why is testing necessary?

Software (Program Code) is present everywhere.

From Banking to e-commerce, from cars to electrical appliances, health apparatus, Heating Systems and many more.

Failure results in financial loss, waste of time, loss of reputation or, in worst cases, injury and even loss of life.

Testing reduces the risk of software failure.

People make mistakes due to their own limitations and fallibility as well as external pressures.

i.e.:

• No attention to detail – Detail-oriented focus  – which can be a weakness in some cases, such as when attention needs to be split up among various tasks or projects simultaneously without the appropriate time for full concentration on any one of them;
• Time constraint – where the insufficient time available may lead someone into taking an action that they wouldn’t otherwise have taken if given more time;
• Lack of Knowledge – which is present whenever there are unknown conditions in need of consideration, but no knowledge about how these conditions will affect something else (which may not become evident until later); and also when following instructions provided by others who are ignorant regarding the specific circumstances at hand;  
• Experience – it becomes problematic once experience with problem-solving methods relies solely on trial-and-error strategies rather than deductive reasoning skills, which could potentially increase the likelihood that something won’t work out according to plan during execution.

Accordingly with the ISTQB syllabus…

“Rigorous testing of components and systems, and their associated documentation, can help reduce the risk of failures occurring during operation. When defects are detected, and subsequently fixed, this contributes to the quality of the components or systems. In addition, software testing may also be required to meet contractual or legal requirements or industry-specific standards.”

ISTQB 2018 Foundation Level

 1.2.1 Give Examples Of Why Testing Is Necessary

Throughout the history of computing, it is quite common for software and systems to be delivered into operation with defects or not meet stakeholders’ needs. However, using appropriate test techniques can reduce the frequency of this kind of problematic delivery when those techniques are applied with proper expertise- at certain levels and points during a project’s development cycle it can certainly help alleviate issues finding their way throughout the software development lifecycle.

Going back again to the early involvement of testers at the early stages of the software development lifecycle can certainly help, with the requirements review, and user story refinement, reducing the risk even before the coding starts.

Getting testers involved with system designers at an early stage is also essential prior to starting to code a system.

And when developers are coding. a system, it is also another great opportunity to both understand what the code does and what impact that would have else wherein the system, all the relevant risks can be detected during that exercise.

And the obvious step is to test the software by verifying and validating to detect any failures that almost certainly get missed and not catching the defects earlier causing failures to the system and not meeting stakeholders’ needs and not satisfying requirements.

Read again, go back to 1.1.1 Identify Typical Objectives of Testing that contributed to the overall software development and maintenance success.

“Throughout the history of computing, it is quite common for software and systems to be delivered into operation and, due to the presence of defects, to subsequently cause failures or otherwise not meet the stakeholders’ needs. However, using appropriate test techniques can reduce the frequency of such problematic deliveries, when those techniques are applied with the appropriate level of test expertise, in the appropriate test levels, and at the appropriate points in the software development lifecycle. Examples include:

• Having testers involved in requirements reviews or user story refinement could detect defects in these work products. The identification and removal of requirements defects reduces the risk of incorrect or untestable features being developed.
• Having testers work closely with system designers while the system is being designed can increase each party’s understanding of the design and how to test it. This increased understanding can reduce the risk of fundamental design defects and enable tests to be identified at an early stage.
• Having testers work closely with developers while the code is under development can increase each party’s understanding of the code and how to test it. This increased understanding can reduce the risk of defects within the code and the tests.
• Having testers verify and validate the software prior to release can detect failures that might otherwise have been missed, and support the process of removing the defects that caused the failures (i.e., debugging). This increases the likelihood that the software meets stakeholder needs and satisfies requirements.”

ISTQB 2018 Foundation Level

1.2.2 Describe the relationship between testing and quality assurance and give examples of how testing contributes to higher quality

People refer to testing or test analysis as being equal to QA (Quality Assurance) but in fact, there’s a difference between these two, and putting it simply, here is what you should have in mind:

Testing – Testers seek to uncover bugs before users come across them. One of the main tasks of a tester is to find bugs.

QA – The focus of quality assurance under the larger concept of quality management, which ties them together in quality management, is to work on constant improvement of the development process. Working on the proper execution of the entire process contributes to the prevention of bugs appearing.

As described in sections 1.1.1 Identify Typical Objectives Of Testing and 1.12 Differentiate Testing From Debugging, testing contributed to the achievement of quality in a variety of ways.

“While people often use the phrase quality assurance (or just QA) to refer to testing, quality assurance and testing are not the same, but they are related. A larger concept, quality management, ties them together. Quality management includes all activities that direct and control an organization with regard to quality. Among other activities, quality management includes both quality assurance and quality control. Quality assurance is typically focused on adherence to proper processes, in order to provide confidence that the appropriate levels of quality will be achieved. When processes are carried out properly, the work products created by those processes are generally of higher quality, which contributes to defect prevention. In addition, the use of root cause analysis to detect and remove the causes of defects, along with the proper application of the findings of retrospective meetings to improve processes, is important for effective quality assurance. Quality control involves various activities, including test activities, that support the achievement of appropriate levels of quality. Test activities are part of the overall software development or maintenance process. Since quality assurance is concerned with the proper execution of the entire process, quality assurance supports proper testing.”

ISTQB 2018 Foundation Level

1.2.3 Distinguish between error, defect, and failure

All defects start with a human error (for example a typo, misunderstanding, lack of planning, capability, etc.) The tester’s job is to expose the defect by causing a failure before the software gets to production.

Error: Humans make a mistake in the code or in the development of a document specification.

Defect: A problem caused by an error.

Fault: A failure of the system or component caused by a defect.

Failure: Failures don’t only happen due to defects, but also environmental conditions, hardware problems, etc.

“A person can make an error (mistake), which can lead to the introduction of a defect (fault or bug) in the software code or in some other related work product. An error that leads to the introduction of a defect in one work product can trigger an error that leads to the introduction of a defect in a related work product. For example, a requirements elicitation error can lead to a requirements defect, which then results in a programming error that leads to a defect in the code. If a defect in the code is executed, this may cause a failure, but not necessarily in all circumstances. For example, some defects require very specific inputs or preconditions to trigger a failure, which may occur rarely or never.

Errors may occur for many reasons, such as:

• Time pressure
• Human fallibility
• Inexperienced or insufficiently skilled project participants
• Miscommunication between project participants, including miscommunication about requirements and design
• The complexity of the code, design, architecture, the underlying problem to be solved, and/or the technologies used
• Misunderstandings about intra-system and inter-system interfaces, especially when such intrasystem and inter-system interactions are large in number
• New, unfamiliar technologies

In addition to failures caused due to defects in the code, failures can also be caused by environmental conditions. For example, radiation, electromagnetic fields, and pollution can cause defects in firmware or influence the execution of the software by changing hardware conditions. Not all unexpected test results are failures. False positives may occur due to errors in the way tests were executed, or defects in the test data, the test environment, or other testware, or other reasons. The inverse situation can also occur, where similar errors or defects lead to false negatives. False negatives are tests that do not detect defects that they should have detected; false positives are reported as defects, but aren’t actually defects.”

ISTQB 2018 Foundation Level

1.2.4 Distinguish between the root cause of a defect and its effects

If there’s a single word you can focus on here is the root cause. A defect causes a failure given the effects of the system not working as expected. The ISTQB foundation level 2018, only covers the basics in this subject and that’s all you need to know, for now, further in-depth are detailed in the Expert Level – Test Management ISTQB-CTEL-TM and Expert Level – Improving the Testing Process ISTQB-CTEL-ITP

In this example here, I tried to replicate, graphically to easier understand the process of a root cause of a defect and its effects based on the ISTQB syllabus.

“The root causes of defects are the earliest actions or conditions that contributed to creating the defects. Defects can be analyzed to identify their root causes, so as to reduce the occurrence of similar defects in the future. By focusing on the most significant root causes, root cause analysis can lead to process improvements that prevent a significant number of future defects from being introduced.

For example, suppose incorrect interest payments, due to a single line of incorrect code, result in customer complaints. The defective code was written for a user story that was ambiguous, due to the product owner’s misunderstanding of how to calculate interest. If a large percentage of defects exist in interest calculations, and these defects have their root cause in similar misunderstandings, the product owners could be trained in the topic of interest calculations to reduce such defects in the future.

In this example, the customer complaints are effects. The incorrect interest payments are failures. The improper calculation in the code is a defect, and it resulted from the original defect, the ambiguity in the user story. The root cause of the original defect was a lack of knowledge on the part of the product owner, which resulted in the product owner making an error while writing the user story.”

ISTQB 2018 Foundation Level

This is it for this section. Tell me what you think. Any feedback is welcome. Thank you and see you at the next one.

If you prefer to watch the whole video about this section in one go instead of parts of the video as I have embedded them above, go and watch it here…

Don’t forget to subscribe, like and share. It will support this channel, will help others and will motivate me to create even more content for everyone.