0% found this document useful (0 votes)
23 views7 pages

Chapter 1

The document outlines the fundamentals of software testing, including types of testing, objectives, and the relationship between testing and quality assurance. It emphasizes the importance of rigorous testing to reduce risks and improve quality, while also detailing the test process and principles. Additionally, it discusses the psychological aspects of testing, highlighting the mindsets of testers and developers.

Uploaded by

mohammed jafri
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views7 pages

Chapter 1

The document outlines the fundamentals of software testing, including types of testing, objectives, and the relationship between testing and quality assurance. It emphasizes the importance of rigorous testing to reduce risks and improve quality, while also detailing the test process and principles. Additionally, it discusses the psychological aspects of testing, highlighting the mindsets of testers and developers.

Uploaded by

mohammed jafri
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Chapter 1

1.1 What is Testing?

type of testing includes:

● Dynamic testing: testing that involves the execution of the component or system being tested

● Static testing: testing that doesn't involve the execution of the component or system being tested

1.1.1 Identify typical objectives of testing:

The objectives of testing can vary, depending upon the context of the component or system being tested.

the objectives of testing may include:

● To build confidence in the level of quality of the test object

● To prevent defects

● To find failures and defects

● To provide sufficient information to stakeholders to allow them to make informed decisions

● To reduce the level of risk

● To comply with contractual, legal, or regulatory requirements or standards

● To evaluate work products such as requirements, user stories, design, and code

● To verify whether all specified requirements have been fulfilled

● To validate whether the test object is complete and works as the users and other stakeholders expect

1.1.2 Differentiate testing from debugging:

Testing: the process of executing tests to show failures that are caused by defects in the software.

Debugging: is the process of finding , analyzing, and fixing the defects.

Confirmation testing (Retesting): the process of checking whether the fixes resolved the defects or not via

rerunning the tests.

Note: in Agile development and in some other life cycles, testers may be involved in debugging and

component testing.
1.2 Why is Testing Necessary?

Rigorous testing can help reduce the risk of failures occurring during operation. When defects are

detected, and 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.

1.2.2 Describe the relationship between testing and quality assurance

● Quality management: includes all activities that direct and control an organization with regard to quality

● Quality management includes both quality assurance and quality control

● Quality assurance is typically focused on adherence to proper processes to ensure a certain level of quality

will be achieved.

● Quality control involves various activities, including test activities, that support the achievement of

appropriate levels of quality

1.2.3 Distinguish between error, defect, and failure

Error (Mistake): a humane mistake.

Defect( fault/bug) : is a flaw in a system caused by a mistake.

Failures: is the state or condition of not meeting a desirable or intended objective.

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

● 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

● New, unfamiliar technologies

Note: failures can also be caused by environmental conditions

False positives: it occur due to errors in the way tests were executed

False negatives: are tests that do not detect defects that they should have detected
1.2.4 Distinguish between the root cause of a defect and its effects

The root causes: is the earliest actions or conditions that contributed to creating the defects.

Root cause analysis can lead to process improvements that prevent a significant number of future defects from being

introduced.

1.3 Seven Testing Principles

● Testing shows the presence of defects, not their absence

○ Testing can show that defects are present, but cannot prove that there are no defects.testing is not

a proof of correctness.

● Exhaustive testing is impossible

○ Testing everything (all combinations of inputs and preconditions) is not feasible

● Early testing saves time and money (shift left testing)

○ Testing early in the software development life cycle helps reduce or eliminate costly changes

● Defects cluster together

○ A small number of modules usually contains most of the defects discovered during pre-release

testing, or is responsible for most of the operational failures.

● Beware of the pesticide paradox

○ If the same tests are repeated over and over again, eventually these tests no longer find any new

defects.

● Testing is context dependent

○ Testing is done differently in different contexts.

● Absence-of-errors is a fallacy

○ fixing all defects found could still produce a system that is failing at fulfilling the users’ needs and

expectations

Note: Predicted defect clusters, and the actual observed defect clusters in test or operation, are an important input

into a risk analysis used to focus the test effort.

1.4 Test Process

A test process consists of the following main groups of activities:

● Test planning: Test planning involves activities that define the objectives of testing and the approach for

meeting test objectives within constraints imposed by the context

● Test monitoring : Test monitoring involves the on-going comparison of actual progress against the test plan.
● Test control: involves taking actions necessary to meet the objectives of the test plan.

○ Test progress against the plan is communicated to stakeholders in test progress reports, including

deviations from the plan and information to support any decision to stop testing.

● Test analysis: During test analysis, the test basis is analyzed to identify testable features and define

associated test conditions. In other words, test analysis determines “what to test” in terms of measurable

coverage criteria.

○ Test analysis activity include:

■ Analyzing the test basis appropriate to the test level being considered

■ Evaluating the test basis and test items to identify defects of various types

■ Identifying features and sets of features to be tested

■ Defining and prioritizing test conditions

■ Capturing bi-directional traceability between test basis and the associated test conditions

● Test design: During test design, the test conditions are elaborated into high-level test cases, test design

determines “how to test?”

○ Test design activity include:

■ Designing and prioritizing high-level test cases and sets of test cases

■ Identifying necessary test data to support test conditions and test cases

■ Designing the test environment and identifying any required infrastructure and tools

■ Capturing bi-directional traceability between the test basis, test conditions, test cases, and

test procedures

● Test implementation: During test implementation, the testware necessary for test execution is created

and/or completed, including sequencing the test cases into test procedures. test implementation determines

“do we now have everything in place to run the tests?”

○ Test implementation activity include:

■ Developing and prioritizing test procedures, creating automated test scripts (optionally).

■ Creating test suites from the test procedures and (if any) automated test scripts

■ Arranging the test suites within a test execution schedule in a way that results in efficient

test execution

■ Building the test environment

■ Preparing test data and ensuring it is properly loaded in the test environment

■ Verifying and updating bi-directional traceability between the test basis, test conditions,

test cases, test procedures, and test suites


● Test execution: During test execution, test suites are run in accordance with the test execution schedule

○ Test execution activity include:

■ Recording the IDs and versions of the test item

■ Executing tests either manually or by using test execution tools

■ Comparing actual results with expected results

■ Analyzing anomalies to establish their likely causes

■ Reporting defects based on the failures observed

■ Logging the outcome of test execution

■ Repeating test activities either as a result of action taken for an anomaly (corrected test,

confirmation testing, regression testing)

■ Verifying and updating bi-directional traceability between the test basis, test conditions,

test cases, test procedures, and test results.

● Test compilation: Test completion activities collect data from completed test activities to consolidate

experience.

○ Test compilation activity include:

■ Checking whether all defect reports are closed

■ Creating a test summary report to be communicated to stakeholders

■ Finalizing and archiving testware for later reuse

■ Handing over the testware to whom may benefit from its use

■ Analyzing lessons learned from the completed test activities

■ Logging the outcome of test execution

■ Using the information gathered to improve test process maturity

Note: Test completion activities occur at project milestones such as when a software system is released, a test

project is completed (or canceled).

1.4.3 the process work products: is the outcome of the testing process

● Test planning work products includes:

○ one or more test plans which include:

○ exit criteria

● Test monitoring and control work products include:

○ test progress reports (on a regular basis)

○ test summary reports (on a completion milestones)


○ Test monitoring and control work products should also address project management concerns, such

as task completion, resource allocation and usage, and effort.

● Test analysis work products include:

○ defined and prioritized test conditions

○ may result in the creation of test charters

○ may result in the discovery and reporting of defects in the test basis.

Note: test charters is a concise statement that defines the scope, objectives, and strategy of a test session

● Test design work products include:

○ high-level test cases and sets of test cases

○ the design and/or identification of the necessary test data

○ the design of the test environment

○ the identification of infrastructure and tools

Note: high-level test cases don’t include input data and expected results

● Test implementation work products include:

○ Test procedures and the sequencing of those test procedures

○ Test suites

○ test execution schedule

○ the creation and verification of test data and test environment

● Test execution work products include:

○ Documentation of the status of individual test cases or test procedures

○ Defect reports

○ Documentation about which test item and testware were involved in the testing

● Test completion work products include:

○ test summary reports

○ action items for improvement of subsequent projects or iterations

○ finalized testware

1.4.4 Explain the value of maintaining traceability between the test basis and test work products

In order to implement effective test monitoring and control, it is important to establish and maintain traceability

throughout the test process between each element of the test basis and the various test work products associated

with that element.

good traceability supports:

● Analyzing the impact of changes


● Making testing auditable

● Meeting IT governance criteria

● Relating the technical aspects of testing to stakeholders in terms that they can understand

● Providing information to assess product quality, process capability, and project progress against business

goals

● Improving the understandability of test progress reports and test summary reports

1.5 The Psychology of Testing

1.5.1 Human Psychology and Testing:

Some people may perceive testing as a destructive activity, even though it contributes greatly to project progress and

product quality. in order to avoid this type mentality tester should do the following:

● Start with collaboration rather than battles.

● Emphasize the benefits of testing (testing will save time and money and reduce risk)

● Communicate test results and other findings in a neutral way.

● Try to understand how the other person feels and the reasons they may react negatively

● Confirm that the other person has understood what has been said and vice versa

1.5.2 Tester’s and Developer’s Mindsets:

tester mindset should include:

curiosity, professional pessimism, a critical eye, attention to detail, and a motivation for good and positive

communications and relationships.

A tester’s mindset tends to grow and mature as the tester gains experience.

developer mindset should include:

A developer’s mindset may include some of the elements of a tester’s mindset, but successful developers are often

more interested in designing and building solutions than in contemplating what might be wrong with those solutions.

Note: Having some of the test activities done by independent testers increases defect detection effectiveness, which

is particularly important for large, complex, or safety-critical systems. Independent testers bring a perspective which

is different than that of the work product authors

You might also like