Sqa and software testing in bsit curriculum

SIA1 = Software Quality Assurance

SIA2 = Software Testing

ISTQB = international software testing qualification Board

founded nov. 2002

non-profit organization

registered in Belgium

has defined ISTQB Certified Tester

ISTQB Roadmap

foundation level - no specialization

advance level = manegerial decision

expert level = ung tinetake na ng mga directors

Foundation level course outline:

fundamentals of testing

testing throughout the software life cycle

testing design techniques

test management

tool support for testing

learning obj:

level 1: Remember (K1) - candidate will recognize, remember and recall a term/

concept

level 2: Understand (K2) - candidate can summarize, differentiate, classify and

give examples
level 3: Apply (K3) - candidate can select the correct application of a concept

or technique and apply it to a given context

level 4: Analyze (K4) - candidate can separate info related to a procedure/technique

into its constituent parts for better understanding

exam structure:

20 items in k1

12 items in k2

8 items in k3&k4

----------------

40 items in total

exam fee $250 in Raudra

software system -business app, consumer products, medical

systems, aircraft and mobile phone

software that doesn't work can lead to many problems:

- loss of money

- loss of time

- damage to business reputation

- environmental damage

- injuries / death

impact of software failure:

Mars Climate Orbitor Crash

3.4 million vehicle recalled due to faulty airbags

causes of software failure:

- error(mistake) + human action - time pressure

- Complex codes

- complex infrastructure

- changing technology

- many system interaction

- defect(fault/bug) + a problem in the program code

- failure + system failing to do what it should do / doing something

that it should not do

- Defects + Environmental Condition

benefits of rigorous testing of systems and documentation:

1. helps reduce risks of problems occurring in delivered systems

2. contributes to the quality of the software systems if defect

are corrected before the system is released.

requirement:

- contractual

- legal

- industry-specific

3. on average, testing uses 35% of the IT budget, but can use

80% on safety-critical systems

testing can help:

1. measure the quality of the software in terms of defects found, for both functional a

and non-functional software requirements and characteristics

2. can give confidence in the quality of the software if it finds few or no defects

+ few defects - confidence in quality increases

+ reduces overall level of risks when a property designed test have passed

3. when testing finds defects, the quality of the software increases when those

defects are fixed.

4. testing should be integrated as one of the quality assurance activities

quality assurance - part of quality management focused on providing confidence that

quality requirements will be fulfilled.

- lessons should be learned from previous projects. Understanding

the root causes of defects found in other project, processes

can be improved, which should prevent tose defects from

reoccurring, therefore improve the quality of future systems.

- testing is one of the quality assurance activities

sqa vs. software testing

- documentation - execution

- prevention - detection

how much testing is enough?

- take account level of risk and project constrants

risks: project constraint:

-technical -time

-safety -budget

-business -people

testing should provide sufficient information to stakeholders

what is testing?

 Debugging
 Rerquirement
 Review
 Test Case
 Testing
 Test Objective

Testing-background

Testing activities exist before and after test execution. These includes:

- Planning and Control

- Choosing Test Conditions
- Designing and Executing Test Cases
- Checking Results
- Evaluation Exit Criteria
- Reporting on Test Process and System under Test
- Finalizing/Closure after completing a test Phase
- Reviewing Test Documents
- Conducting Static Analysis

Common Objective of Testing:

- Finding defects – why do we perform testing

- Gaining confidence about the level of quality – the lower the defect, the higher the quality
- Providing information of decision-making – deciding whether it’s a software feature or software
failure
- Preventing defects – testing to prevent defects that causes software failure
- The balance changes based on the situation – documents prior to the testing of software
 Changes na wala sa documents – changes prior
to the situation

Test objectives across the life cycle

- Waterfall
- V-model – Integrate water fall

Software testing life cycle: V-Model

Code/component test – if programmer commit mistake or error that could lead to mistake

Design/integration testing – check front end and back end. Makita na dapat ditto lahat ng failure na
pwedeng mangyare at lahat ng defects na pwedeng magawa ni developer
 Development testing – to cause as many failures as possible so that the defects in the
software are identified and can be fixed.

Specification/System Testing – masatisfy si software at hardware. Software and Hardware

Specification

Requirements – review of documents and the identification and resolution of issues helps to
prevent the defects appearing in the code.

 To check if your software meets the client’s requirement

Acceptance testing – use to check if the clients requirements are satisfied

2 Types of acceptance testing:

 Quality evaluation – assess quality of software; give information to stakeholders
of the risk of releasing the system at a given time
 Acceptance Testing – to confirm that the system works as expected and to gain
confidence that it has the requirements.

Operational:

o Operational Testing – includes testing that no new defects have been introduced during
the implementation of the changes.
o Maintenance Testing - to asses ongoing system characteristics such as reliability or
availability.

Testing VS Debugging VS Retesting

o Tester
 dynamic testing reveals failures
 re-testing ensures that the fix really resolves the failure

2 types of testing

 static testing – ndi tinetest or ineexecute si code. Use To test

documents.
 dynamic testing – reveals failures on the spot. Executes the code and
test the output
o Developer
 Debugging locates, analyses and removes the cause of the failure(defects)
7 Testing Principle:

Principle 1 Testing shows presence of defects

 Testing reduces the probability of undiscovered defects remaining in the software but even
if no defects are found, it is not a proof of correctness.

Principle 2 Exhaustive testing is impossible

 If you were to test all the possible combination, project Execution time and cost will rise
exponentially. We need optimal amount of testing based on the risk assessment of the
application.

Principle 3 Early Testing

 Testing should start as early as possible in the SDLC

Principle 4 Defect Clustering

 a small number of modules contain most of the defects detected.

Principle 5 Pesticide Paradox

 If the same test are repeated over and over again, eventually the same test cases will no
longer find new bugs

Principle 6 Testing is context dependent

 The way you test an e-commerce site will be different from the way you test a commercial
off-the-shelf application

Principle 7 Absence of errors – fallacy

 Software does not meet the needs and requirements of the client
Fundamentals of Test Process

Test Planning – what is the goal of the project, address risk

 We understand the goals and objectives of the customers, stakeholders, and the project.
 Understand the risks which testing is intended to address.
 Set goals and objectives for testing based on goals and objectives of customers,
stakeholders and project
Major Task of Test Planning

1. Identify the objectives of testing based on the scope and risk of project.

 Decide which components, systems or other products are in the test scope
 Decide the business, product, project and technical risks which need to be addressed
 Decide the objective of testing
o to uncover defects,
o to verify that the software meets requirements
o to demonstrate if software is fit for use

2. Determine the test approach

 how testing will be carried out?

 What test techniques will be used?
 What needs to be tested and what extent of test coverage required?
 Who is involved and when?
 Decide test deliverable’s to be produced(test cases, test data).

3. implement the test policy and/or test strategy.

 If the organization test policy and strategy exists then during planning ensure that
testing adheres to those policy/strategy.

4. determine the required test resources – the hardware/software

 Define the required resources for testing like testers, hardware and software etc.

5. scheduling test analysis and design tasks, test implementation, execution, and evaluation.

 You need to prepare the schedule for all the tasks so that tracking can be done and
progress is captured.

6. determining the exit criteria.

 Criteria set to find out when to finish testing. The tasks that must be completed for the
test level before we can exit the test phase.

Test Control

 After test planning we need to measure and control the progress

 Test Control is the ongoing activity of comparing actual progress against the plan
 Test control reports the status of test progress including any deviations from the actual plan
 Test control monitors the testing throughout the project
The Major task of Test Control

1. Measure and analyze results of reviews and testing

 Track test pass/fail percentage
 Track tests remaining
2. Monitor and document test progress, coverage and exit criteria
 Track how many tests executed
 What is the testing outcome(Number of tests passed/failed)
 Risk assessment of test outcome
3. Provide information on testing
 Provide regular test progress reports to stakeholders
4. Initiate corrective actions
 Putting more efforts in debugging
 Prioritizing defects
5. Make release decisions
 Based on information gathered during testing decision are made — Like to continue
testing, stop testing, release software or not to release.

Test Analysis and Design

- During Test Analysis and Design we build test designs and test procedures (Scripts)
The major tasks of test analysis and design are:
1. Reviewing the test basis
 Review software requirements specification (SRS) Document, design document
 Start designing black box tests using test basis
 This identifies gaps and ambiguities in specifications and prevents
2. Identifying the test conditions
 Based on the analysis of test items and specifications prepare the test conditions
3. Designing the tests
 Apply test design techniques to design your test
4. Evaluate testability of the requirements and system
 Make sure that all the requirements are testable
5. Design the test environment
 Hardware and software required to test
 Any supporting tools like test management tools etc.

Test Implementation and Execution

 Take test conditions and make them into test cases

 Build test environment where test execution needs to be done
Major Tasks:

1. Test Implementation
 Develop test cases and prioritise them
 Apply test design techniques to develop test cases
 Prioritize test cases based on the risk assessment
 Create test suites (Logical collection of test)
 Prepare test environment
2. Test Execution
 Execute test cases
 Record the test execution outcome with details like environment, software version
 Compare actual with expected result (Report incident – incident is then analysed and
bug is logged if it’s an actual defect)
 Perform re-test after defect is fixed to ensure that defect is corrected after fix