Basic Software Testing

Guide for starting of tester career

SAND 2014

Implementation Project Management

Solution Integrator E2E Tester

Technical Support

Product Owner QA Eng.

PA

Project DeploymentConsultant

Tier-1 24x7

V-Model (software development)

Tier-2 8x5

Tier-3 8x5

#1

#2

#3

#4

#5

#6

#7

Agenda1. Software testing WHAT & WHY ?

2. Fundamentals3. Requirement traceability matrix4. Test Estimation & Planning5. Test Cases, Scripts, Data6. Test Execution7. Classic Testing Mistake8. Improvement

9. Workshop

Software testingWHAT & WHY?

WHAT IS SOFTWARE TESTING?

• Software testing is a process of verifying and

validating that a software application or program

–1. Meets the business and technical requirements

that guided its design and development

–2. Works as expected.

• Software testing also identifies important defects,

flaws, or errors in the application code that must

be fixed.

WHY DO SOFTWARE TESTING?

• Software testing is focused on finding defects in the final product.

• Software testing answers questions that development

testing and code reviews can’t.

Purpose of Testing

• Verification

• Validation

• Defect finding

Cost of fixing a defect

Testing skills and knowledge

Test knowledge▪ test principles▪ techniques▪ tools, etc.

IT knowledge▪ software development▪ requirements▪ configuration management

Domain knowledge▪ business process▪ user characteristics

Soft skills▪ communication▪ critical mind-set▪ presentation and reporting

Fundamentals

Testing Principles

• All tests should be traceable to customerrequirements

• Tests should be planned long before testing begins

• Testing should begin “in the small” and progresstoward testing “in the large”

• To be most effective, testing should be conductedby an independent third party

Test Approach

• Black box testing (Internals NOT known)

• White box testing (Internals Fully known)

• Grey box testing (Internals Relevant to testing known)

Black-box testing

Aims of Black Box Testing

• Find

– Incorrect or missing functionality

– Interface errors

– Errors in data structures used by interfaces

– Behaviour or performance errors

– Initialization and termination errors

White-box testing

Aims of White Box Testing

• Internal security holes

• The flow of specific inputs through the code• Expected output

• The functionality of conditional loops

• Testing of each statement, object and function on an individual basis

Grey-box testing

Aims of Grey Box Testing

• Combination of Black & White box testing

• Search for improper usage of application

• Search for improper structure

• Tester can handle intelligent test scenario for example, data type handling, communication protocol

Methodologies

• Boundary testing

• Equivalence classes

• Decision tables

• State transitional diagrams

• Risk Analysis

Boundary testing

Equivalence classes

Decision tables

State transitional diagrams

Risk Analysis

Types of Testing

• Unit Testing

• Functional Testing

• System Integration Testing

• User Acceptance Testing (UAT)

• Regression Testing

• Beta Testing

Summary

Testing Type Specification General Scope Approach Who generallydoes it?

Unit Low-Level Design Actual Code StructureSmall unit of code no largerthan a class

White Box Programmer who wrote code

Functional High Level Design Whole product Black Box Independent tester

System Requirements Analysis

Whole product In representative Environments

Black Box Independent tester

User Acceptance

Requirements Analysis

Whole productin customer’s Environment

Black Box Customer

Beta Ad hoc Whole productin customer’s Environment

Black box Customer

Regression ChangedDocumentationHigh-Level Design

Any of the above Black BoxWhite Box

Programmer(s)or independent testers

Testing Processes

Requirements TraceabilityMatrix

Traceability matrix (example)

Requirement ID Requirement description TC 001(user login)

TC 002(add user)

TC 003(delete user)

SR-1.1 User should be able to login using LDAP user

x

SR-1.2 User should be able to see error message when fail to login

x

SR-1.3 Admin user should be able to add user on admin page

x

SR-1.4 Admin user can not add duplicate user on admin page

x

SR-1.5 ….. x x

SR-1.6 ………. x

SR-1.7 ………… x

Benefits of using Traceability Matrix

• To make sure that all requirements included in the test cases

• To make sure that developers are not creating features that no one has requested

• Easy to identify the missing functionalities.

Testing without Requirements

• Tester must do the following tasks at the same time– get clarifications, understand the product's features,

document test cases and testing• It is better to create checklist

– All the tests to be conducted.– Proper sequence in which to execute the test cases. The

correct flow will help to focus the thinking of tester at the time of execution of test cases.

• Testing Approach– Ad hoc Testing– Exploratory Testing

Source: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=6443

Test Estimation & Planning

Estimation for Testing

• Questions to be asked

– Requirements finalized. If not, frequency of change

– Types of Testing

– Test Assets & Team are available and clear

– Assumptions/Risks

Test Planning

• Test Plan

• Test Procedure

• Test Report

Test cases,scripts, data

Test Case

Test Cases Contents

• Purpose

• Pre-condition

• Test Data

• Action

• Expected response

• Comment

• Post Condition

Sample test case

Test Data

• Test data can be said. to be ideal if for the minimum sizeof data set all the application errors get identified

• Prepare test data that will incorporate all applicationfunctionality, but not exceeding cost and time constraintfor preparing test data and running tests

• Poorly designed testing data may not test all possibletest scenarios which will hamper the quality of the software.

• Good test data will help us;– Rely on the result of testing– Reduce the testing schedule and effort

Test execution

Test Execution

• Execute the test cases

• Logging Defects

• Re-execute test cases after every change– Automate as much as possible for instance, after each refactoring

• Regression testing– Testing that everything that used to work still works after

changes are made to the system

– rerunning test cases from existing test suites to build confidence

that software changes have no unintended side-effects

Sample Test Results

Defect flow

What if there isn’t enough time for testing?

Classic testing mistakes

Classic testing mistakes

• The developer should not be testing at all– Test before you code

• Testers get only involved once software is done– Testers should be involve since project start

• Toss the software over the wall for testing

– Testers and developers collaborate in developing

the test suite

• Testing team is responsible for assuring quality– Quality is assured by a good software process

Improvement

Become a Better Tester

• Test for quality over quantity

• Practice and improve

• Learn from your own mistakes and from others too

• Be objective and professional

• Don’t be humble with software… think out of the box

• Question. Everything

• Think like the user

• Increase the effectiveness of bug reports

• Be Passionate!

Personal attributes of highly effective testing professionals

• Curiosity• Cautious• Good work ethic• Desire to make a difference• Discipline• Quality focus and orientation• Personal organization• Quick learner• Desire to share information• Communication skills• Team player

Achieve in S/W Testing

•Keep your eye open

•Avoid the work and relax, you may miss some bugs

•Look at the application in the negative way, you will always find the bugs.

•Bugs are in many places, don’t skip your testing. Client does not know a defect is small or big.

•Think of the persons who use the application, define scenarios (Test cases) and execute them

Defect Management

• Thorough understanding• Adhere to processes• Verify defects before distribute• Capture Screenshot and steps• Raise every bugs in the defect tracking tool• Always use the facts• Keep track of impact of bugs and associate to the risks• Some defects may not resolve, prepare for these• Never close the defects because of your feeling or not

finding by developer

Workshop

Workshop1 : ประโยคดา้นลา่งถกูหรอืผดิ (True/False)

B. กอ่นทีก่ระบวนการ Test จะเริม่ขึน้ ตอ้งรอให ้Software พัฒนาเสร็จเรยีบรอ้ยกอ่น

A. การท า Unit Testing อยูใ่นขัน้ตอนการ Develop Software (Construction Phase)

C. การ Develop และการ Test ควรท าโดยบคุคลคนเดยีวกนั

D. การท า Software ตอ้งมกีระบวนการ Test เขา้มาเกีย่วขอ้งเสมอ

Workshop2 : จับคูข่อ้มลูทีส่มัพันธก์นั

ความหมาย ค าที่เก่ียวข้อง

1 เลอืกตวัแทนของขอ้มลูในแตล่ะกลุม่มาทดสอบ Testing from formal specifications

2 การท า Test Case จะเลอืกคา่ขอบบน และขอบลา่งของชดุขอ้มลู

Equivalence Partitioning

3 พจิารณาทกุ ๆ คา่ทีเ่ป็นไปไดข้องขอ้มลูทีจ่ะ inputs, actions และ outputs ทีจ่ะได ้

Finite state machine-based

4 การทดสอบทีค่รอบคลมุเรือ่ง Transition Boundary value analysis

5 สิง่ทีใ่ชใ้นการการันตวีา่ Software ถกูตอ้ง Decision Table

Workshop3 : คดิจ านวน Test Case แบบ Equivalence

Partitioning

ตู ้ATM จะจา่ยเงนิเป็นธนบตัรครัง้ละ 20$ โดยสามารถจา่ยธนบตัรไดจ้ านวนเงนิตัง้แต ่20$ ถงึ 300$ หากท าการทดสอบจะมจี านวน Test Case แบบ Equivalence ทัง้หมดเทา่ไหร ่

A. 15B. 3C. 6D. 5

Workshop4 : คดิจ านวน Test Case แบบ Boundary

value analysis

ตู ้ATM จะจา่ยเงนิเป็นธนบตัรครัง้ละ 20$ โดยสามารถจา่ยธนบตัรไดจ้ านวนเงนิตัง้แต ่20$ ถงึ 300$ หากท าการทดสอบจะมจี านวน Test Case แบบ Boundary ทัง้หมดเทา่ไหร่

A. 15B. 3C. 6D. 5

Workshop5 : คดิ Test Case แบบ White box ไดก้ีแ่บบ

จาก Flow ดา้นลา่ง ถา้ตอ้งการทดสอบ White box Testing จะมีจ านวน Test Case อยา่งนอ้ยกี ่Test Case

A. 3B. 4C. 5D. 6

Answer

Answer1 : ประโยคดา้นลา่งถกูหรอืผดิ (True/False)

A. การท า Unit Testing อยูใ่นขัน้ตอนการ Develop Software (Construction Phase) True

B. กอ่นทีก่ระบวนการ Test จะเริม่ขึน้ ตอ้งรอให ้Software พัฒนาเสร็จเรยีบรอ้ยกอ่น False

C. การ Develop และการ Test ควรท าโดยบคุคลคนเดยีวกนั False

D. การท า Software ตอ้งมกีระบวนการ Test เขา้มาเกีย่วขอ้งเสมอTrue

Answer2 : จับคูข่อ้มลูทีส่มัพันธก์นั

ความหมาย ค าที่เก่ียวข้อง

1 เลอืกตวัแทนของขอ้มลูในแตล่ะกลุม่มาทดสอบ Equivalence Partitioning

2 การท า Test Case จะเลอืกคา่ขอบบน และขอบลา่งของชดุขอ้มลู

Boundary value analysis

3 พจิารณาทกุ ๆ คา่ทีเ่ป็นไปไดข้องขอ้มลูทีจ่ะ inputs, actions และ outputs ทีจ่ะได ้

Decision Table

4 การทดสอบทีค่รอบคลมุเรือ่ง Transition Finite state machine-based

5 สิง่ทีใ่ชใ้นการการันตวีา่ Software ถกูตอ้ง Testing from formal specifications

Answer3 : คดิจ านวน Test Case แบบ Equivalence

Partitioning

ตู ้ATM จะจา่ยเงนิเป็นธนบตัรครัง้ละ 20$ โดยสามารถจา่ยธนบตัรไดจ้ านวนเงนิตัง้แต ่20$ ถงึ 300$ หากท าการทดสอบจะมจี านวน Test Case แบบ Equivalence ทัง้หมดเทา่ไหร ่

A. 15B. 3C. 6D. 5

Answer4 : คดิจ านวน Test Case แบบ Boundary

value analysis

ตู ้ATM จะจา่ยเงนิเป็นธนบตัรครัง้ละ 20$ โดยสามารถจา่ยธนบตัรไดจ้ านวนเงนิตัง้แต ่20$ ถงึ 300$ หากท าการทดสอบจะมจี านวน Test Case แบบ Boundary ทัง้หมดเทา่ไหร ่

A. 15B. 3C. 6D. 5

Answer5 : คดิ Test Case แบบ White box ไดก้ีแ่บบ

จาก Flow ดา้นลา่ง ถา้ตอ้งการทดสอบ White box Testing จะมีจ านวน Test Case อยา่งนอ้ยกี ่Test Case

A. 3B. 4C. 5D. 6

L-node+2 = 10-8+2 = 4