0% found this document useful (0 votes)
10 views50 pages

Fundamentals Day01 - Lecture Slides

Uploaded by

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

Fundamentals Day01 - Lecture Slides

Uploaded by

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

Fundamentals

SOFTWARE QUALITY ASSURANCE (SQA)


SQA

DAY 01
What you will learn Today

►High level Introduction of Software Testing


►Explain Testing Principles and Test Process

2
SQA

Table of Content
►Introduction To Software Testing
►Importance of Testing
►Causes of Failures
►Testing Objectives
►Basic Testing Vocabs
►Testing Principles
►Fundamental Test Process
►Lab Exercise

3
SQA

Introduction to Software
Testing

4
SQA

Importance of Testing

5
SQA

Importance of Testing
Most people have an experience with software that did not work
as expected. Software that does not work correctly can lead to
many problems, including:

• Loss of Money / Time


• Loss of Environment
• Business Reputation
• Injury or Death etc.

6
SQA

Importance of Testing

7
SQA

Importance of Testing
Software Testing is necessary because we all make
mistakes. Some of those mistakes are unimportant, but some
of them are expensive and dangerous.

“We need to check everything and anything we produce


because things can always go wrong – humans make
mistakes all the time.”

8
SQA

Importance of Testing

9
SQA

Importance of Testing

10
SQA

Importance of Testing

11
SQA

Importance of Testing

12
SQA

Importance of Testing

13
SQA

Importance of Testing

14
SQA

Importance of Testing

15
SQA

Importance of Testing

16
SQA

Importance of Testing
Not me!!! Find
LION…

17
SQA

What is Software Testing?


Definition, Quality Vs Testing

18
SQA

?
GOOD QUALITY
MERCEDES-BENZ OR SUZUKI MEHRAN

19
SQA

Two Views of Quality Definition

• Popular View: Quality is directly related to CLASS(Brand)


• Technical View: To meets Customer Level of Satisfaction(Expectation) within
Time Budget and Scope.

20
SQA

Quality Vs Testing
“Quality software is reasonably bug or defect free, delivered
on time and within budget, meets requirements and
expectations, and is maintainable.”

“Software testing is a way to assess the quality of the software and


to reduce the risk of software failure in operation.”

21
SQA

Software Testing
The process of verifying and validating that a software program,
application or product:

• Meets the business and technical requirements.


• Works as expected(To Meet Expectation).

22
SQA

Other Definitions
• 1979: Software testing is a process of executing a program or application with the
intent of finding the errors.

• 1983: Testing is an activity that measures the Software Quality.

• 2002: Testing is a concurrent lifecycle process of engineering, using and maintaining


testware in order to measure and improve quality of software being tested.

23
SQA

Quality Vs Testing
Key Aspects of Quality:

• Good design – looks and style


• Good functionality – it does the job well
• Reliable – acceptable level of breakdowns or failure
• Consistent – remain same
• Durable – lasts as long as it should
• Good after sales service - warranty
• Value for money – cost effectiveness

24
SQA

Seen any software failures in real life?

25
SQA

Examples of Failures
►A smartphone mapping app showed a museum in middle of river – A basic functionality failure
►Ariane 5 crashed 40 sec after takeoff because of incorrect calculation by its inertial reference
system that was taken from Ariane 4 – An incompatible component reuse
►Daraz server went down just after first time launching of 11.11 – A performance failure
►A change in billing system of an electrical provider blacked out a city – An upgrade failure
►A wide area blacked-out due to a hacking incident occurred in Ukraine – A security failure

26
SQA

Causes of Failures
Software failures and their rectification

27
SQA

Causes of failures
►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
►Misunderstandings about intra-system and inter-system interfaces
►New, unfamiliar technologies

28
SQA

Testing Objectives

29
SQA

Typical Objectives
• 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 completed and works as the users/stakeholders expect.
• To build confidence in the level of quality of the test object.
• To prevent defects.
• To find failures and defects.
• To reduce the level of risk of inadequate software quality (undetected failures in operation).
• To comply with contractual, legal, or regulatory requirements or standards.
• To provide sufficient information to stakeholders to allow them to make informed decisions, especially
regarding the level of quality of the test object.

30
SQA

General Testing Vocabulary


Software Testing Key Terminologies and its understanding

31
SQA

Bug
Defect
Error ? Mistake
Fault
Failure

32
SQA

“A human being can make an error (mistake), Mistake/Error


which produces a defect(fault, bug) in the
program, code or in a document. If a defect in
code is executed, the system may fail to do Defect/Fault/Bug

what is should do (or do something it shouldn’t),


causing a failure.”
Failure

Defects in software, systems or documents may result in failures, but not all defects do so.

33
🢇
SQA

34
🢇
SQA

Cost of Prevention Cost


Training QC staff
Document the process

Conformance (build a quality product) Testing Equipment


Time required to do it right

(Good Quality)

Cost of Money spent during the


project
to avoid failures
Appraisal Cost
(assess a quality product)
Running the Test
Destructive Testing Loss

Quality
Inspecting Deliverables

Money spent during Cost of Non- Internal Failure Rework


Scrap
and after the project
Conformance Cost
(failure found by the project)

(Bad Quality)
Liabilities, Law Suites, Product recalls
Money spent during and after
the project because of failures
External Failure Cost Warranty Work
(failure found by customer) Lost Business or Credibility

35
SQA

Testing Terminologies
Test Oracle
Test Basis  Test Condition  Test Case  Test Procedure  Test Implement  Test Execution 
Test Progress Report  Test Summary Report

Test Analysis Test Design

Test SUITE = Test Procedure + Test Case

36
SQA

Testing Principles

37
SQA

Testing always uncovers Testing Shows Exhaustive


defects but never tell us Presence of Testing is It is impossible to test with
how many more are still Defects Impossible every possible input
undiscovered(absence of combinations.
defects).

Testing should start as early


as possible. So that defects
Early Testing
in the requirements or
Saves Time &
It is possible that software design phase are captured
Absence of Money
which is 99% bug-free is in early stages(defects
Errors Fallacy prevention).
still unusable; requirement
or expectation may not be
meet. Defects Clustering Defects present in the form
of clusters; approximately
80% of the problems are
found in 20% of the
modules.

Testing a banking
application is different than If the same set of
testing any repetitive tests are
e-commerce or gaming Testing is Pesticide
executed, then it will be
application. Context Paradox
useless for discovering of
Dependent
new defects.

38
SQA

Test Process

39
SQA

Fundamental Test Process


Plan entire
Test Planning
testing by
determining On-going

Test Monitoring & Control


scope, risks, comparison
objectives, of actual Determines

Test Analysis
approaches progress “What to
of testing, against the test”; “How to

Test Design
resources, test plan, Analyze Test Test”;
entry and Test control Basis to Designing “Do we now

Test Implementation
exit criteria. involves defining and Test have
taking prioritizing environment, everything in Executing

Test Execution
actions test infrastructur place to run tests either
necessary to conditions, e and tool; the tests?” manually or Prepare Test

Completion
Test
meet the Identify Test Setup Test by using test Summary
objectives of features to conditions environment, execution Report,
the test plan be tested. are Implement, tools, Finalized all
elaborated Test Reporting completion
into high- Procedures, defects data
level test Test Suites, based on the gathered,
cases Test Scripts. failures Hand over
observed. testware
Log outcome
of test.

40
Test Planning
• To determine the scope, risks, objectives of testing and test approach.

• To implement the test policy and/or the test strategy.

• To determine the required test resources like people, test environments, PCs, etc.

• To schedule test analysis, test design, test implementation, execution & evaluation.

• To determine the Entry and Exit criteria

41
Test Monitoring and Control
• 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 monitoring and control are supported by the evaluation of exit criteria.
• Checking test results and logs against specified coverage criteria
• Assessing the level of component or system quality based on test results and logs
• Determining if more tests are needed.
• 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.

42
Test Analysis
• Determines “what to test”.
• Analyze Test Basis to defining and prioritizing test conditions for each feature considering
functional, non-functional, and structural characteristics, other business and technical
factors, and levels of risks
• Identifying features and sets of features to be tested
• Capturing traceability between test basis and the associated test conditions
• Test analysis may also result in the discovery and reporting of defects in the test basis.

43
Test Design
• Test design answers the question “how to test?”
• Test conditions are elaborated into high-level test cases, sets of high-level test
cases.
• Designing and prioritizing 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.
44
Test Implementation
• Answers the question “do we now have everything in place to run the tests?”
• Implementation of testware necessary for test execution.
• Implementation of Test Procedures and Test Suites.
• Creation of automated Test Scripts.
• Prioritize and Schedule Test Suite for Test execution.
• Setup the test environment and verifying that required things has been set up correctly.
• Preparing test data and ensuring it is properly loaded in the test environment.
• Verifying and updating traceability between the test basis, test conditions, test cases, test procedures,
and test suites.

45
Test Execution
• Test suites are run in accordance with the test execution schedule.
• Recording the IDs and versions of the test item(s) or test object, test tool(s), and testware.
• 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 (e.g., pass, fail, blocked).
• Re-execute test activities (Confirmation Testing, and/or Regression Testing).

46
Test Completion
• Test completion activities collect data from completed test activities.
• Test completion activities occur at project milestones.
• Checking whether all defect reports are closed.
• Creating a Test Summary Report to be communicated to stakeholders.
• Finalizing and archiving the test environment, the test data, the test infrastructure for later reuse.
• Handing over the testware to the maintenance teams, other project teams, and/or other
stakeholders who could benefit from its use
• Analyzing lessons learned from the completed test activities to determine changes needed for
future iterations, releases, and projects
• Using the information gathered to improve test process maturity

47
SQA

End of Day 01
48
SQA

Lab Exercise
 Reading Exercises
 Identify Defects by using common knowledge
 Exercise of Testing Principles and Test Process (ISTQB)

49
SQA

Q&A
Instructor Notes

50

You might also like