Advanced quality control

Techniques, Practices & Skills
Bassam Al-Khatib
Certified Test Analyst
Certified Technical Test Analyst
Certified Test Manager
Advanced Quality Control
1

 What are your expectations?
Training Expectations
2

Why Do We Test Software ?!
3
Ford Expeditions Shutdown - USA Audi A6 Navigator - Germany Submarine Sink- RUSSIA

1. Testing Software life Cycle
2. Test Management
3. Advanced Test Techniques
4. Applying the Best Technique
5. Defect Management
6. Risk Based Testing
7. Test Analytical Techniques
8. Quality Characteristics for Technical Testing
9. Lessons Learned in Software Testing
What we will talk about?
4

Enhance
decision
making in
test design
Improve
testing
mentality
Increase
testing
coverage
What you will learn today?
5

 Testing Process
 Test Management
 Test Techniques
 Testing Software
Quality Char.
 Defect Management
Advanced Level - Test Analyst
Training Material
6

 Risk Bases Testing
 Analytical Techniques
 Quality Char. For Technical Testing
Advanced Level - Technical Test Analyst
Training Material
7

Training Objectives
Help creating well
educated and
innovative testers
Create technical
testing mentality
Enhance testing
skills
Enhance analytical
skills
Training
Objectives
8

Testing Software life Cycle
10
1. Test
Planning
2. Test
Analysis
3. Test
Design
4. Test
Implementation
5. Test
Execution
6. Reporting
and exit
criteria
7. Test
Closure

 What About Planning?
 Planning is related to the
following people:
 Customer
 Developers
 Technical Writers
 Technical Support
 Project Manager
And off course
Yourself…
11

 Planning is all the time activity, and when changed, testing is
affected
12

 What About Analysis?
 Do you know what Analysis means?!
 How many triangles in the picture:
 6
 7
 8
13

 How many squares in the picture?
 Look carefully there are more than
you might think!
 15
 27
 23
14

 Similarly you should look carefully , because there are more
details than you might think!
 When it comes to software requirements ask your mind the
following questions – This is called Analysis:
 What does the customer ask for ?
 What is really needed?
 What do we already have?
 Identify any gaps and close them…
15

 What About Test Design?
 New test design techniques
should be learned to enhance
test coverage
 Keep the balance between
learning and doing…
16

 Testing Life Cycle and projects life time..
17
1. Test Planning
2. Analysis &
design
3.Implementation &
execution
4. Evaluation &
reporting

Let us describe each activity in detail..
18

 Test analyst shall insure that Test Plan has the following:
 All related testing aspects should be considered as per approved
requirements, Read, Read and Read Requirements
 Review test estimates to ensure that adequate time is budgeted for all
testing activities
1. Test Planning and control
19

 Planning also
includes: The Test
environment
specifications …
20
Operating
systems
Application
servers
Database
vendors
Third party
tools
Virtual
machines
Browsers
and other
software

 Define Testing Techniques to provide adequate coverage
 Define the needed Testing Types
 Define the needed test cases types
21

22
 Sample Testing Types Examples:

 Plan for test documentation
 Define and verify the needed documentation, you may need to work
with the technical writing staff to help prepare data to be used for
screen shots and video clips.
23
List of some Test Documentation
Installation Qualification (IQ)
Test Plan
Summary Report
Validation Plan
Traceability Matrix
Requirement Design Specification (RDS) document
Release Notes

 Identify, analyze and communicate Project Risks with the team.
 Discussions and reviews are so beneficial
24

 Finally ….
 Collecting all information before start planning is part of your
responsibility
 Let’s have a look …
25

 Example Test Plan template.
26

 Two important activities are part of Planning : Requirements
Estimation and Project Scheduling, Which mainly done be
Test Manager.
27

28
 There is a reasonable budget and schedule available to accomplish the
remaining testing work for this test object
28

 Real Projects Schedule
29

 Group practice time, real
time project:
 Prepare Test Plan for a real
project story
 Study the following Project
Specifications
 Approved Requirements
30

 To proceed effectively with test analysis, the following entry
criteria should be met:
 There is a document describing the test object (Feature) that can serve
as the test basis (Requirements)
 This document has passed review with reasonable results and has
been updated as needed after the review
2. Test Analysis
31

 You should define in scope
and out scope requirements
 You should define what areas
of code have been changed ?
2. Test Analysis
32

 Test Analyst selects suitable Testing Techniques to design
specific Test Cases using selected Testing Types in order to
meet the needs of the assigned areas of the test project
2. Test Analysis
33

 Lets get back to the
requirements and see what is
in and out of project scope…
 Requirement Analysis
2. Test Analysis
34

 The process of test design includes the following activities:
 Select test cases input method ( Templates)
 As you go re-assess necessary test coverage
 Create test cases that exercise the identified test conditions (Main
Functions/Happy scenarios)
3. Test Design
35

 Test Design guidelines:
 1. The pass/fail and
Expected Results criteria
should be clearly
identified.
3. Test Design
36

 2. Tests should be designed to be understandable by other testers, not
just the author.
 If the author is not the person who executes the test, other testers will need to
read and understand previously specified tests in order to understand the test
objectives and the relative importance of the test
3. Test Design
37

 3. Tests must also be understandable by other stakeholders such as
developers, who might review the tests, and auditors, who may have to
approve the tests.
3. Test Design
38

 It is one of the Test Analyst tasks to design the best types of test
cases for a given situation
3. Test Design
39
Test Cases Types
Concrete Logical

 Concrete Test Cases Characteristics :
 Provide all the specific information and procedures needed for the
tester to execute the test case (including any data requirements) and
verify the results
 Useful when the requirements are well-defined
 When the testing staff is less experienced
3. Test Design
40

 When external verification of the tests, such as audits, is required
 Provide excellent reproducibility (i.e., another tester will get the same
results)
 May also require a significant amount of maintenance effort and tend to
limit tester ingenuity during execution
3. Test Design
41

 Logical Test Cases Characteristics:
 Provide guidelines(Simi Scenarios) for what should be tested
 Might be less reproducible
 Best used when the requirements are not well-defined
 When the Test Analyst who will be executing the test is experienced
with both testing and the product
 When less compliance is required
 When test cases will not be delivered to customers
3. Test Design
42

 Logical test cases may be defined early in the requirements process
when the requirements are not yet well-defined (During Estimate
meeting just to imagine the scope)
 These test cases may be developed to concrete test cases when the
requirements become more defined and stable. (When code merge to
standard Reliance release is scheduled)
3. Test Design
43

 Automated scripts, is it Logical or Concrete ?
3. Test Design
44

 Test Cases
Characteristics
3. Test Design
45
Repeatable
Verifiable
Traceable

Test Cases Structure
Objective Preconditions
Test data
requirements
Expected
results
Post-
conditions
3. Test Design
46

 Test Analysis and Design activities can be enhanced through
the following:
 Review meetings, where Test Plan, Requirements and Testing Scope
are discussed(Example: Business Review , Technical Review and UAT
meetings)
 Static testing ,where problems may be found in the test basis during
this process, Read , Read and Read.
3. Test Design
47

 Concrete and Logical test cases might be Manual or automated
 Take in consideration test cases design challenges, some times
its not easy to write a test case .
3. Test Design
48

 Implementation: is the process of developing and prioritizing
test procedures(instructions and setup), creating test data and
preparing for running automated test scripts.
 In implementation phase all preparations are finalized before
Test Execution begins.
4. Test Implementation
49

 Test Implementation Activities:
 Creating and organizing tests priorities (both manual and automated)
into execution order (Prepare a list).
 Finalizing test environments configuration
50

 More Activities…
 Forming a test execution schedule, including resource allocation
 Coordinate with the development team to ensure that the software will
be released for testing in a testable order.
51

 More Activities….
 Test Cases dependencies must be documented and checked thru test
scripts scheduled maintenance
 Test Analysts create Test Data to be used with data-driven automation
tests as well as for manual testing (e.g., Easy PDF)
52

 More Activities…
 "fit for purpose and usable" test environment is installed
 Ensure that those responsible for the creation and maintenance of the
test environment are known and available (Dev and Tech support
teams)
53

 Test Execution Activities:
5. Test Execution
54
Execute and compare
actual results with
expected results
If expected and actual
results do not match ...
an incident has occurred
When a failure is
identified:
1. Report the failure
2. Modify test cases
to reflect the
change
3. Check the
impacts
4. Re-execute

 More activities…
 Test results must be logged by specifying environment version (Build
Number)
 In some cases, users or customers may participate in test execution.
This can serve as a way to build their confidence in the system (UAT
inside )
5. Test Execution
55

 Implicit Test Execution activities:
 Test Analyst must be sure the product is not misbehaving by doing
something it should not be doing
 Build the test suite and expect it to grow and change over time, building
the test suite is a continuous process
5. Test Execution
56

 More implicit activities…
 Consider creating test cases for defects that were discovered during
testing and add them to the regression test suite.
 Hint: Find the defects before regression testing. Time is often limited for
regression testing and finding failures during regression testing can
result in schedule delays.
5. Test Execution
57

 And Finally
 Check what level of compliance you are executing for….
5. Test Execution
58

 When the exit criteria is defined in the planning stages it helps
to measure Progress towards Completion
 Test Analyst is responsible for supplying the information for the
Test Manager to evaluate progress toward meeting the exit
criteria
6. Reporting and Exit Criteria
59

 Good Exit criteria example….
60
Customer will accept project if only the following criterion are met:
All Null pointer exception issues should be fixed.
95% Pass rate across all test cases
Only browser related issues can be ignored

 Weak Exit Criteria…
61
Customer will accept project if only the following criterion are met:
80% Pass rate across all test cases
10% Fail rate across all test cases
10% Passed with exception rate across all test cases

 What does Passed with exception means ???
 Does “passed with exception” mean that a defect was found but it is not
affecting the functionality of the system?
 What about a usability defect that causes the user to be confused?
 What about “failed” but the cause of the failure is not a defect (e.g., the
test environment was improperly configured) ? (False-Fail)
62

 Test Analyst must clarify with the Test Manager all confusions
so the information can be tracked accurately and consistently
throughout the project
 Test Analyst is responsible to report the status during the
testing cycles as well as to contribute to the final report at the
end of the testing
63

 Test Analyst is responsible about the following:
 Known defects deferred or accepted should be communicated to those
who will use and support the use of the system
 Participate in retrospective meetings (“Lessons Learned”)
7. Test Closure
64

1. Who will do
the Test
2. What
aspects of the
software you
are testing?
(Coverage,
Scope)
3. What type
of problems
you are
looking for ?
(What are the
Risks)
4. What testing
type you will
implement?
5. How will
accept the
software?
(Acceptance
Criteria)
Testing is a decision making ….
65

 It is Test Analyst responsibility to monitor test progress
 Test Manager will seek the information needed from the Test
Analyst
But how is it possible to
monitor tests thoroughly?
Test Management
67

 Test Progress – Monitoring Dimensions
Test Progress Monitoring and Control
68
• This requires that the identified risks will
be mitigated thru test cases that will be
executed and passed
1. Product (Quality) Risks

69
69
• As defects are recorded, particular
classification information about each
defect is recorded as well (Impact
Analysis)
2. Defect Tracking

70
70
•Test case creation status (e.g., designed, reviewed)
•Test case execution status (e.g., passed, failed, skipped)
•Test case execution information (e.g., Date and time, Tester
name)
•Test case execution artifacts (e.g., screen shots, logs)
3. Test Cases Status

71
71
• The test cases should be mapped to the
requirements items they test (Traceability
Matrix) or (RDS)
4. Testing Coverage

72
72
• Accurate tracking of the coverage as well
as tracking the reviewed status of the
requirements themselves can be used as
a confidence measure
5. Confidence

 Test design techniques :
Procedure used to derive
and/or select test cases.
 Test design techniques can be
divided as follows:
Advanced Test Techniques
74
Test
Techniques
Static Dynamic

 These techniques are complementary (Optionally Selected)
and may be used as appropriate for any given test activity,
regardless of which level of testing is being performed
 All categories of techniques can be used to test both functional
or non-functional quality characteristics
75

 It is common to combine techniques to create complete,
comprehensive and high coverage test cases …
76

 Static Techniques will be discussed further inside “Test
Analytical Techniques”
77
Static
Techniques
Static
Analysis
Data Flow Control Flow
Informal
Reviews
Walkthroughs
Technical
Reviews
Inspection

 Dynamic Techniques
78
Dynamic Techniques
Specification Based
1
Equivalence
Partitioning
2
Boundary
Value
Analysis
3
Decision
Tables
4
State
Transition
5
Use case
Testing
Structure Based
1
Statement
2
Decision
4
Condition
3
Multiple
condition
Experience
Based
1
Error
Guessing
2
Exploratory
Testing

 Specification-Based Techniques
 An approach to testing in which
test cases are designed based on
test objectives and test conditions
derived from requirements, e.g.,
tests that exercise specific
functions.
79
Specification Based
1
Equivalence
Partitioning
2
Boundary
Value analysis
3
Decision
Tables
4
State
Transition
5
Use case
testing

80
 Specification-Based Techniques
 Applied to the test requirements
without reference to its internal
structure (Code)
Specification Based
1
Equivalence
Partitioning
2
Boundary
Value analysis
3
Decision
Tables
4
State
Transition
5
Use case
testing

 1. Equivalence Partitioning:
 Used to reduce the number of test cases that is required to effectively test the
handling of inputs, outputs, internal values and time-related values
 For Example, if an input field accepting number from 2 – 5, then the following
classes are:
 Valid Classes: [2-5]
 Invalid Classes: [-1 to 1.999] and [5.1 – 6]
81
-1 1 2 3 4 5 6

 Applicability :
 When all the members of a set of values to be tested are expected to
be handled in the same way and where the sets of values used by the
application do not interact
82

 Limitations/Difficulties:
 If the assumption is incorrect and the values in the partition are not
handled in exactly the same way, this technique may miss defects
 For Example: When too many classes need to be handled.
83

 Types of Defects
 This technique finds functional
defects in the handling of
various data values
84

 2. Boundary Value Analysis :
 Used to test the values that exist on the boundaries of ordered
equivalence partitions
 boundaries are defined by the maximum and minimum values in the
defined equivalence partition
85

 Take the following partition from 1 to 5
 For Example, if an input field accepting number from 2 – 5, then the
following values are:
 Valid Values: 2,3,4,5
 Invalid Values: -1, 1,1.999, 5.1,6
86
Lower Boundary Upper Boundary
-1 1 2 3 4 5 6

 Applicability:
 When ever s needed to check the boundaries
 For Example
87

 Types of Defects:
 This technique finds defects regarding the handling of the boundary
values, particularly errors with less-than and greater-than logic
88

 Example, SJM eMDR report Intervals
 Requirement Analysis
 Test cases
89

 Decision Tables:
 A design technique in which test cases are designed to execute the
combinations of inputs and/or stimuli (causes) shown in a decision
table
 The goal of decision table testing is to ensure that every combination of
conditions, relationships and constraints is tested
90

 Applicability:
 In order to design a valid decision table, the tester must be able to
derive all expected outcomes for all condition combinations from the
specification or test oracle.
 For Example when need to test over multiple:
 Operating Systems
 Application servers
 Web browsers
 Database vendors
91

 Incorrect processing based on particular combinations of conditions
resulting in unexpected results.
92

 The EasyPDF story …
93

 State Transition:
 Used to test the ability of the software to enter into and exit from
defined states via valid and invalid transitions.
 Events cause the software to transition from state to state and to
perform actions.
94

 Events may be qualified by conditions (sometimes called guard
conditions or transition guards) which influence the transition path to be
taken.
 For example, a login event with a valid username/password
combination will result in a different transition than a login event with an
invalid password.
95

96
Check User
name &
Password
Login
Home
Page
Start
Logout

 Applicability:
 Applicable for any software that has defined states and has events that
will cause the transitions between those states (e.g., changing screens)
e-commerce sites
97

 Incorrect processing in the current state that is a result of the
processing that occurred in a previous state, incorrect or unsupported
transitions, states with no exits and the need for states or transitions
that do not exist.
98

 ATM Example:
99

 Use case Testing:
 A test design technique in which test cases are designed to execute
user scenarios.
 Applicability:
 Usually applied at the system and acceptance testing levels
100

 Use case Testing Example : Purchasing from e-commerce site
101

 Use case Testing Example : Deriving Test cases – Normal
Workflow
102

 Use case Testing Example : Deriving Test cases - Exceptions
103

 Experience Based Techniques:
 Utilize the skill and intuition of the
testers, along with their
experience with similar
applications or technologies.
 These tests are effective at
finding defects but not as
appropriate as other techniques
to achieve specific test coverage
levels.
104
Experience Based
Exploratory Testing

 Experience Based Techniques
 Test Analyst uses experience to guess the potential errors that might
have been made when the code was being designed and developed
 Exploratory Testing is a good example for Experience Based
Techniques
105

 Experience Based
Techniques – Exploratory
Testing
 like checklist testing, often
follows some basic guidelines,
like a checklist, and often relies
on tester judgment and
experience to evaluate the test
results.
106

107
 Exploratory Testing Tours:
Money Tour:
• In this tour you should test variations on
the main functions, answering such
questions like “What if we did this?” or
“How about if I want to do that?”

 Exploratory Testing Tours
108
Landmark Tour:
• You would determine various key features that are to be
visited
• Navigate to those features using different paths
• You can get to them thru menus
• Change the order in which you navigate from place to place

 Exploratory Testing Tours:
109
FedEx Tour:
• You need to be able to track the data thru the various
stages as it flows thru the application. Where data
get displayed? Does the data get manipulated ad is
moves thru the system? Is it delivered properly
(EsayPDF Conversion)

 It is a free style testing where
you can select and execute
test cases based on your
decision
110

Applying the Best Technique
111

 All Test techniques are almost always useful but have to be
selected based on project circumstances like:
 No specifications are available
 There is poor documentation of the system under test
 Insufficient time is allowed to design and create detailed tests
112

 If testers are experienced in the domain and/or the technology
 Using more than one technique in one project to fill the gaps in test
coverage that result from systematic weaknesses in these techniques
 Keep in your mind that all of these techniques are complementary with
each others
113

 What is the right time to detect a defect?
 Through static testing, which can start as soon as we have a draft
requirements specification
 Through dynamic testing, which can start as soon as we have an
executable unit
Defect Management
115

Detection
Recording
Classification
Prioritization
Investigation
Resolution
Defect Management
116
 Defect Life Cycle

 Relative cost to fix defects
Defect Management
117

 Actionable defect reports are:
Defect Management
118
Complete
• All the
necessary
information is in
the report
Concise
• No extraneous
information is in
the report
Accurate
• Information in
the report is
correct and
clearly states
expected and
actual results as
well as proper
steps to
reproduce
Objective
• Report is a
professionally
written
statement of
fact

 Defect reports some times conducted by the person who
investigates and either fixes the problem or determines the
problem should not or cannot be fixed.
 Test Analyst shall identify the root cause via discussing this with
the developer.
Defect Management
119

 Unclear requirement
 Missing requirement
 Wrong requirement
 Incorrect design implementation
 Incorrect interface implementation
 Code logic error
 Calculation error
 Hardware error
 Interface error
 Invalid data
 Root Cause Analysis:
 Typical defects root cause
are…
Defect Management
120

 A type of software testing that is used to prioritize the tests of
features and functions in software, based on:
 Risk of failure
 Function of their importance
 Likelihood or impact of failure
Risk Based Testing
122

 Used to reduce the level of product risks and inform project
stakeholders of their status
 Can be used before final test execution is starting or, when
adding big features in the last days (e.g., Nested Views on 9.0
and final execution of 10.0)
 It involves Risk Identification, Risk Analysis, and Risk Mitigation
Risk Based Testing
123

 Although Test Analyst should
be actively involved in the
following risk-based testing
tasks:
 Risk Identification
 Risk Assessment
 Risk Mitigation
 While Test Manager often has
overall responsibility for
establishing and managing a
risk-based testing strategy
Risk Based Testing
125

Risk Identification Risk Analysis Risk Mitigation
Risk Based Testing
126

 Risk Identification:
 The process of identifying risks using techniques such as
brainstorming, checklists, and failure history
Risk Based Testing
127

 Sample risks that might be identified include:
 Performance risks (e.g., inability to achieve response times under high
load conditions)
 Security risks (e.g., disclosure of sensitive data through security
attacks)
 Reliability risks (e.g., application unable to meet availability specified in
the Service Level Agreement)
Risk Based Testing
128

 Risk Analysis:
 The process of assessing identified risks to estimate their impact and
probability of occurrence (likelihood).
 The Technical Test Analyst contributes to finding and understanding the
potential technical risk for each risk item
 Whereas the Test Analyst contributes to understanding the potential
business impact of the problem should it occur.
Risk Based Testing
129

 General Risks can be :
 Complexity of Tools and technology
 Complexity of code structure
 Conflict between stakeholders regarding technical requirements
 Communication problems resulting from the geographical distribution of
the development organization
Risk Based Testing
130

 Time, resource and management pressure
 High change rates of technical requirements
 Large number of defects found relating to technical quality
characteristics
 Technical interface and integration issues
Risk Based Testing
131

 Technical
Test
Analysis
deliverables
Risk Based Testing
132

 Risk Mitigation:
 The process through which decisions are reached and protective
measures are implemented for reducing risks to, or maintaining risks
within, specified levels.
Risk Based Testing
133

 Technical Test Analysts influence how testing responds to the
identified risks. This generally involves the following:
 Reducing risk by executing the most important tests and by putting into
action appropriate mitigation and contingency activities as stated in the
test strategy and test plan
Risk Based Testing
134

Test Analytical Techniques
135

 There are two types of
analysis:
 Static Analysis
 Dynamic Analysis
136

 Static Analysis:
 Detect actual or potential faults in code and system architecture and to
improve their maintainability
 Analysis for software artifacts, e.g., requirements or code, carried out
without execution of these software development artifacts
137

 Static Analysis - Control Flow
Analysis :
 Used to detect and monitor
code flow inside a feature
 Either through the use of a
control flow graph(While might
represent the code or
functionality flow) or a using
tool.
138

 There are a number of exceptions which can be found in a system
using this technique, including loops that are badly designed (e.g.,
having multiple entry points)
 Ambiguous targets of function calls in certain languages (e.g.,
Scheme), incorrect sequencing of operations, etc.
139

 One of the most common uses
of control flow analysis is to
determine Cyclomatic
Complexity
140

 Complexity Analysis
 Cyclomatic Complexity.
 It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate code
complexity of a software
 It directly measures the number of linearly independent paths through a
program's source code
The more complex the system, the harder it would be to
maintain, and the more defects it would contain, and the more
test cases needed
141

Test Analytical Techniques - Example
142

 Where:
 E = the number of edges of the
graph.
 N = the number of nodes of the
graph.
 P = the number of connected
components.
 Can be calculated as follows:
M = E − N + 2P
143

Let’s Calculate….
M = E − N + 2P
10 8 2
144

 The more complex the system, the harder it would be to
maintain, and the more defects it would contain.
 M represents the minimum number of test cases to have good
level of coverage
145

 Static Analysis is used for Improving Maintainability:
 Poorly written, uncommented and unstructured code tends to be harder
to maintain
 Finding repeated code which help in code refactoring
 Decrease difficulty of testing tasks
 Decrease difficult of navigation for the user
146

 Dynamic Analysis:
 Used to detect failures where the symptoms may not be immediately
visible
 Prevent failures from occurring by detecting wild pointers and loss of
system memory
 Analyze system failures which cannot easily be reproduced
 Evaluate network behavior
 Improve system performance by providing information on run-time
system behavior
147

 It is recommended to perform Static and Dynamic analysis early
in the project to reduce the cost of maintenance and fixing.
148

Quality Characteristics for Technical
Testing
149

 Products quality characteristics provided in ISO 9126, which is
a guide to describing the characteristics of high quality software
 These Chars. can be used when we are working on an
environment that is affected by compliance requirements
Quality Characteristics for Technical Testing
150

 It is important to understand those requirements and to ensure
that both the testing and the test documentation will fulfill the
compliance requirements
 Functional and Non-Functional testing is done to insure high
quality of software products
151

152

 Typical risks must be recognized so that an appropriate testing
strategy can be formed and documented
 Quality characteristic testing requires particular attention to
lifecycle timing, required tools, software and documentation
availability and technical expertise.
153

Lessons Learned in Software Testing
154

 Testing is a service role. Feel
good about that.
 Different needs, desires and
interests
 People we serve are ….
155
Project Manager
Developers
Technical Writers
Technical Support
Marketing
Top Management
Customers

 Good Testers think
technically, creatively,
critically, and
practically.
156
Technical Thinking
• Ability to model technology and understand causes
and effects
Creative Thinking
• Ability to generate ideas and see possibilities
Critical Thinking
• Ability to evaluate ideas and make inferences
Practical Thinking
• Ability to put ideas into practice

 A requirement is a
quality or condition
that matters to some
one who matters.
157

 To test , you must explore… Exploring involves a lot of thinking.
158

 Technical Test Analyst
focuses testing on "how" the
product works.
 But Test Analyst focuses on
functional aspects of "what"
it does.
Lessons Learned
159

The End!
160
1. Testing Software life Cycle
2. Test Management
3. Advanced Test Techniques
4. Applying the Best Technique
5. Defect Management
6. Risk Based Testing
7. Test Analytical Techniques
8. Quality Characteristics for Technical Testing
9. Lessons Learned in Software Testing

 RBCS:
 http://www.rbcs-us.com/
 Sticky Minds:
 http://www.stickyminds.com/better-software-magazine-archive
Recommended Sites
164

 Prepare and Implement the following activities:
 1) Prepare Test Plan
 2) Define In scope and out scope requirements
 3) Deign and Implement Test Cases
Send me all deliverables by mail so I can check and
send feedback to you.
Home Work!
165

Advanced quality control

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Advanced quality control

Similar to Advanced quality control (20)

More from Bassam Al-Khatib

More from Bassam Al-Khatib (7)

Recently uploaded

Recently uploaded (20)

Advanced quality control

Editor's Notes