Software Testing Tutorial, Software Development Life Cycle, Software Test Levels, Software Test Types, Software Test Design Techniques, and Software Test Life Cycle.
Manual testing is a software testing process that is carried out manually in order to find defects without the usage of software test tools or automation scripting.
Manual Testing Steps:
• Understand and Analyze requirements from the software requirement specification document
• Create a test plan
• Write test cases that cover all the requirements defined in the document
• Get test cases reviewed by the QA lead
• Execute test cases and detect bugs
• Report bugs, if any and once fixed, run the failed tests again to re-verify the fixes
Software Testing Syllabus
1. Software Development Life Cycle and SDLC Model
i. Requirement Gathering
ii. Analysis
iii. Design
iv. Coding / Development
v. Testing
vi. Deployment & Maintenance
SDLC Models
i. Waterfall Model
ii. V Model
2. Software Test Levels
i. Unit Testing
ii. Integration Testing
iii. System Testing
iv. Acceptance Testing
3. Software Test Types
i. Functional testing
ii. Non-functional testing
iii. Structural testing
iv. Change related testing
4) Software Test Design Techniques
i. Static Test Design Techniques
a. Reviews (Manual Examination)
1. Informal Review
2. Walkthrough
3. Technical Review
4. Inspection
b. Static Analysis (Automated Analysis)
ii. Dynamic Test Design Techniques
a. Specification-based or Black-box Techniques
1. Equivalence Partitioning (EP)
2. Boundary Value Analysis (BVA)
3. Decision Table Testing
4. State Transition Testing
5. Use Case Testing Etc…
b. Structure-based or White-box Techniques
1. Statement Coverage
2. Decision Coverage
3. Condition Coverage
4. Multi Condition Coverage
5. LCSAJ etc…
c) Experience-based Techniques
1. Error Guessing
2. Exploratory Testing Etc…
5) Software Test Life Cycle
i. Requirement Analysis
ii. Test Planning
iii. Test Design & Development
iv. Test Environment Setup
v. Test Execution
vi. Test Cycle Closure
Manual Testing Step Step Videos
Software Testing Tutorial
1. Software Development Life Cycle
Software Development Life Cycle
> Software Development Life Cycle is a systematic approach to develop software. It is a Process followed by Software Developers and Software Testing is an integral part of Software Development, so it is also important for Software Testers…
> Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test software. The SDLC aims to produce high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.
> ISO/IEC 12207 is an international standard for software life-cycle processes. It defines all the tasks required for developing and maintaining software.
Phases of Software Development Life Cycle,
These phases may vary from one organization to another, but the purpose is almost all same, that is “Develop and Maintain Quality Software”,
i) Requirement Gathering
ii) Analysis
iii) Design
iv) Coding / Development
v) Testing
vi) Deployment & Maintenance
Note: It is General Software Development Life Cycle, we have various SDLC Models in the IT Industry, Waterfall Model, V Model, Spiral Model, and Agile Development Models, etc…,
The Software Development process varies from one SDLC Model to another.
i) Requirement Gathering
> Requirement Gathering is the most important phase in the software development life cycle, Business Analyst collects the requirements from the Customer/Client as per the client’s business needs and documents the requirements in the Business Requirement Specification, and provides the same to Development Team.
Note: Document name may vary from one organization to another, Some examples are Customer Requirement Specification (CRS), Business Requirement Document (BRD), etc…
> Suppose Our Planned Software is not intended for a single customer and the software product for multiple customers then Business Analyst or Business Team collects Requirements from the Market and also evaluate Other similar products in the Market
> Key Role in this phase is Business Analyst and Outcome of the phase is “Business Requirement Specification”
ii) Analysis
> Once the Requirement Gathering is done the next step is to define and document the product requirements and get them approved by the customer. This is done through SRS (Software Requirement Specification) document. SRS consists of all the product requirements to be designed and developed during the project life cycle.
> Key people involved in this phase are the Project Manager, Business Analyst, and Senior members of the Team. The outcome of this phase is Software Requirement Specification.
iii) Design
> In Design phase Senior Developers and Architects, they give the architecture of the software product to be developed. It has two steps one is HLD (High Level Design) or Global Design and another is LLD (Low Level Design) or Detailed Design,
> High Level Design (HLD) is the overall system design, covers the system architecture and database design. It describes the relation between various modules and functions of the system.
> Low Level Design (LLD) is the detailed system design, covers how each and every feature in the product should work and how every component should work.
> The outcome of this phase is High Level Document and Low Level Document which works as an input to the next phase Coding…
iv) Coding / Development
> Developers (seniors, juniors, fresher) involved in this phase, this is the phase where we start building the software and start writing the code for the product.
> The outcome of this phase is Source Code Document (SCD) and the developed product.
v) Testing
> Once the software is complete then it is deployed in the testing environment. The testing team starts testing (either test the software manually or using automated test tools depends on process defined in STLC)
> Testing is done to verify that the entire application works according to the customer requirement.
> During this phase, Testing team may find defects which they communicate to developers, the development team fixes the defect and send back to Testing for a re-test. This process continues until the software is Stable, and working according to the business needs of that system.
vi) Deployment & Maintenance
> After successful testing, the product is delivered (deployed to the customer for their use), Deployment is done by the Deployment/Implementation engineers and Once when the customers start using the developed system then the actual problems will come up and needs to be solved from time to time.
> Fixing the issues found by the customer comes in the maintenance phase. 100% testing is not possible – because, the way testers test the product is different from the way customers use the product. Maintenance should be done as per SLA (Service Level Agreement)
Software Development Life Cycle Models
> There are various software development life cycle models defined and designed which are followed during the software development process. These models are also referred as Software Development Process Models”.
i) Waterfall Model
> Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In “The Waterfall” approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.
Phases of Waterfall Model:
a) Requirements Gathering:
> This first step is also the most important, because it involves gathering information about what the customer needs and defining, in the clearest possible terms, the problem that the product is expected to solve.
b) Software Requirements:
> In this phase Business Requirements are converted as Software Requirements.
c) Design:
> In this phase Global and Detailed design can be produced based on Software Requirements.
d) Coding:
> This step consists of actually constructing the product as per the design specification(s) developed in the previous step. Typically, this step is performed by a development team consisting of programmers, interface designers and other specialists, using tools such as compilers, debuggers, interpreters and media editors. The output of this step is one or more
product components, built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements.
e) Testing:
> In this stage, System will be tested by testers, if the find any mismatch they report defects. Developers /Programmers fix the defects and then testers close defects by performing confirmation testing (Regression Testing).
f) Release & Maintenance:
> Release team (consists of a few developers, testers, and tech-support people etc…) install software in Customer environment and they consider below factors;
Correct & Complete installation, User Management, Services Management, Coexistence with other software, Handling of Input & Output devices, and Handling of secondary storage devices
Etc…
Maintenance team process Customer issues based on service agreements.
Advantages of Waterfall Model :
a) Simple and easy to use
b) Easy to manage due to the rigidity of the model- each phase has specific deliverables and a review process.
c) Phases are processed and completed one at a time.
d) Works well for smaller projects where requirements are very well understood.
Disadvantages of Waterfall Model :
a) No working software is produced until late during the life cycle
b) High amount of risk and uncertainty
c) Poor model for complex and object oriented projects.
d) Poor model for Long and ongoing projects
e) Poor Model where requirements are at a moderate to high risk of changing.
ii) V Model
> It is Verification & Validation model, known as V Model, in this model all development phases can be integrated with Testing phases.
> The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.
> V Model was inaugurated in order to avoid drawbacks in Waterfall model and its main focus on multiple stages of testing.
> Multiple stages of Testing avoids defects multiplication.
Development Phases Integration with Testing Phases
a) User Requirements Vs Acceptance Testing
> Business Analyst category people gather requirements and the document the requirements, after documentation Reviews, Meetings like verification will take place in order get correct & Complete Requirements.
End Users conduct Acceptance Testing using Business / User Requirements.
b) Software Requirements Vs System Testing
> Development Manager/Tech Manager converts User Requirements as Software Requirements and Reviews, Meetings like verification methods will be performed on Software Requirements, after Verification Project manager provides Approval.
> Independent testers generate test cases from Software Requirements in order to perform System Testing
c) Global Design Vs Integration Testing
> System Architect / senior developer creates Global design, Informal Review/ Walk through / Technical Review / Inspection like Verification methods will be applied on Design documents.
> Developers perform Integration Testing based on Software Global Design.
d) Detailed Design Vs Unit / Component Testing
> Developers perform Unit /Component Testing based on Software Detailed Design.
Advantages of V Model:
a) Tester role will take place in the requirement phase it self
b) Multiple stages of Testing available so that Defects multiplication can be reduced.
c) Can be used for any type of requirements
d) Due to Multiple stages of Testing and Multiple teams involvement Quality can be improved.
e) The V Model Supports wide range of development methodologies such as Structured and Object oriented systems development.
f) The V Model supports tailoring.
Disadvantages of V Model:
a) It an expensive model than Waterfall model, needs lot of resources, budget and time.
b) Co-ordination and Maintenance are difficult.
c) Adoption of changes in Requirements and Adding New Requirements at middle of the process are difficult.
d) It needs an established process for proper implementation.
2. Software Test Levels
There are mainly four testing levels are:
i) Unit Testing
ii) Integration Testing
iii) System Testing
iv) Acceptance Testing
i) Unit Testing
> In Unit Testing level individual units/ components of a software are tested. The purpose is to validate that each unit of the software works as designed.
> Unit Testing can be done Manually as well as automated
> Unit Test Tools – NUnit, JUnit, TestNG etc…
> Developers conduct Unit Testing using White Box Test Design Techniques…
ii) Integration Testing
> In Integration Testing Level, individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units.
Popular Integration Test Tools:
FitNesse, Rational Integration Tester, Protractor, TESSY and Jasmine etc…
> Independent Testers conduct this level of Testing,
iii) System Testing
> In System Testing level a complete and integrated software is tested. The purpose of this test is to evaluate the system’s compliance with the specified software requirements.
> System Testing can be done Manually and Automated…
Popular Testing Tools are:
Selenium, UFT, RFT (Functional Testing)
LoadRunner, JMeter, RPT (Performance Testing)
SoapUI – Web Services Testing
Appium – Mobile Testing etc…
> Independent Testers conduct System Testing using Block Box Test Design Techniques…
iv) Acceptance Testing
> In Acceptance Testing level a software system is tested for acceptability. The purpose of this test is to evaluate the system’s compliance with the business requirements
Here, Acceptance basically two types,
1) Internal Acceptance Testing (Alpha Testing): It is conducted by members of the development organization who are not directly involved in the project, Usually, it is the members of Product Management, Sales and/or Customer Support people.
2) External Acceptance Testing / User Acceptance Testing (Beta Testing) is conducted by the end users of the software.
Note: Acceptance Testing environment and System Testing environment almost all same, but Unit Test Environment and integration Test environment are different.
3. Software Test Types
> A test type is a group of test activities aimed at testing specific characteristics of a software system, or a part of a system, based on specific test objectives. Such objectives may include:
> Evaluating functional quality characteristics, such as completeness, correctness, and appropriateness
> Evaluating non-functional quality characteristics, such as reliability, performance efficiency, security, compatibility, and usability
> Evaluating whether the structure or architecture of the component or system is correct, complete, and as specified
> Evaluating the effects of changes, such as confirming that defects have been fixed (confirmation testing) and looking for unintended changes in behavior resulting from software or environment changes (regression testing)
i) Functional Testing
> Functional testing of a system involves tests that evaluate functions that the system should perform. Functional requirements may be described in work products such as business requirements specifications, epics, user stories, use cases, or functional specifications, or they may be undocumented. The functions are “what” the system should do.
> Functional tests should be performed at all test levels. Functional testing considers the behavior of the software
ii) Non-functional Testing
> Non-functional testing of a system evaluates characteristics of systems and software such as usability, performance efficiency or security. Non-functional testing is the testing of “how well” the system behaves. non-functional testing can and often should be performed at all test levels, and done as early as possible. The late discovery of non-functional defects can be extremely dangerous to the success of a project.
iii) Structural Testing
> Structural Testing derives tests based on the system’s internal structure or implementation. Internal structure may include code, architecture, work flows, and/or data flows within the system.
iv) Change-related Testing
> When changes are made to a system, either to correct a defect or because of new or changing functionality, testing should be done to confirm that the changes have corrected the defect or implemented the functionality correctly, and have not caused any unforeseen adverse consequences.
> Confirmation Testing: After a defect is fixed, the software may be tested with all test cases that failed due to the defect, which should be re-executed on the new software version.
> Regression Testing: It is possible that a change made in one part of the code, whether a fix or another type of change, may accidentally affect the behavior of other parts of the code, whether within the same component, in other components of the same system, or even in other systems.
> Changes may include changes to the environment, such as a new version of an operating system or database management system. Such unintended side-effects are called regressions.
> Regression testing involves running tests to detect such unintended side-effects. Confirmation testing and regression testing are performed at all test levels.
> Regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation. Automation of these tests should start early in the project.
4. Software Test Design Techniques
> What is Technique?
An efficient way of doing or achieving something.
> What is Test Design Technique?
A test design technique is used to select a good set of tests from the all possible tests for a given system.
> Why we need to use Test Design Techniques?
Exhaustive Testing is not possible, so we need to use Test Design Techniques in order to reduce the size of the input.
Exhaustive Testing is a Test approach in which the test suite comprises all combination of input values and preconditions.
Exhaustive Testing is not recommendable due to Time and Budget considerations.
Categories of Test Design Techniques?
There are two main categories of Test Design Techniques, They are:
i) Static Techniques
ii) Dynamic Techniques
i) Static Techniques
> Testing of the software documents manually or with a set of tools but without executing the Software.
Two types of static testing techniques
a) Reviews (Manual Examination)
b) Static Analysis (Automated Analysis)
——————————-
a) Reviews
Types of Reviews
1) Informal Review
2) Walkthrough
3) Technical Review
4) Inspection
b) Static Analysis
Static analysis tools are typically used by developers, Compilers offer some support for Static analysis,
ii) Dynamic Test Design Techniques
> The software is tested by executing it on computer.
Categories of Dynamic Test Design Techniques
a) Specification based or Black box Techniques
1) Equivalence Partitioning (EP)
2) Boundary Value Analysis (BVA)
3) Decision Table Testing
4) State Transition Testing
5) Use Case Testing Etc…
b) Structure based or White box Techniques
1) Statement Testing and coverage
2) Decision Testing and Coverage
3) Condition Testing,
4) Multi Condition Testing
5) LCSAJ etc…
c) Experience based Techniques
a) Error Guessing
b) Exploratory Testing
————————————————–
2a) Black box Test Design Techniques
1) Equivalence Partitioning (EP)
2) Boundary Value Analysis (BVA)
3) Decision Table Testing
4) State Transition Testing
5) Use Case Testing Etc…
1) Equivalence Partitioning (EP)
• It can be applied at any level of testing (Unit, Integration, System and Acceptance Testing)
• In Equivalence Partitioning, inputs to the Software are divided into groups that are expected to exhibit similar behavior.
• Equivalence Partitions/Classes can be found for both valid data and invalid data.
Example 1 (Data Range):
Tickets field in a Reservation system accepts 1 to 10 Tickets only.
Partition 1 Partition 2 Partition 3
-Ne to 00 0 1 to 10 11 to 99 or above
(Invalid) (Valid) (Invalid)
Example 2 (Data Type):
Customer Identification Number field in a CRM system accepts only numbers.
Partition 1 Partition 2 Partition 3 Partition 4
Alpha bytes Numbers Special Characters Alpha-numeric
(Invalid) (Valid) (Invalid) (Invalid)
Example 3 (Data Size)
Phone Number filed accepts 10 digits number only
Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)
Example 4 (Others)
A Payment management system accepts credit card payments only
Partition 1 Partition 2 Partition 3
Credit card Net Banking Cash on Delivery
(Valid) (Invalid) (Invalid)
2) Boundary Value Analysis (BVA)
• The maximum and minimum values of a partition are its boundary values.
• Behavior at edge of each equivalence partition is more likely to be incorrect than behavior within the partition.
• Boundary value analysis can be applied at all Test levels(Unit, Integration, System and Acceptance Testing).
Example 1:
Partition 1 Partition 2 Partition 3
0 1 to 10 11 to 99 or above
(Invalid) (Valid) (Invalid)
Minimum/maximum 0
Minimum 1
Maximum 10
Minimum 11
Maximum 99
————————————-
Example 3 (Data Size)
Phone Number filed accepts 10 digits number only
Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)
Minimum -9
Minimum and Maximum – 10
Maximum -11
—————————————-
Example: User Id field accepts 10 to 20 characters
Partition 1 Partition 2 Partition 3
Below 10 10 to 20 21 to 99
Minimum -1
Maximum – 9
Minimum – 10
Maximum – 20
Minimum – 21
Maximum -99
3) Decision Table Testing
• The decision tables are good way to capture system requirements that contain logical conditions.
• It may be applied for all situations when the action of the software depends on logical decisions.
BSRB (Govt) System Job eligibility criteria,
Age should be in between 21 and 35
Conditions:
i) For SC or ST Candidates 5 Years age relaxation
ii) For BC Candidates 5 Years age relaxation
iii) PHC Candidates 5 Years age relaxation
Category Age Valid/Invalid
———————————————-
OC 20 Invalid
OC 21 Valid
OC 35 Valid
OC 36 Valid
BC 36 Valid
BC 39 Invalid
SC 39 Valid
PHC 39 Valid
ST 40 Valid
—————————————————–
Banking System interest rates For fixed deposits.
1 to 2 years 7%
2 to 3 Years 8%
3 to 5 Years 10%
Condition:
For Senior citizens 0.5% extra for all ranges
Age Period Interest Rate
———————————–
25 1year 7%
35 2.5 8%
56 4 10%
66 4 10.5%
4) State Transition Testing
• In State transition Testing Test cases are designed to execute valid and invalid state transitions.
• A System (Application Under Test) may exhibit a different response on current conditions or previous history.
Example: Internet Banking System Fund Transfer operation
Initial Balance: 45000
Transaction Transaction Amount Transaction Result
1 20000 Successful (Pass)
2 20000 Successful (Pass)
3 20000 Unsuccessful (Pass)
5) Use Case Testing
• In Use Case Testing Test Cases are designed to execute User Scenarios or Business Scenarios.
• A Use Case describes interactions between actors, including users and the system.
• A Use case usually has a mainstream scenario and sometimes alternative scenarios.
Example:
Business Scenario: ATM Cash Withdrawal operation
Mainstream Scenario:
1)
User: Inserts ATM Card
System: Asks for PIN
2)
User: Enters PIN
System: Validates PIN and asks to select language
3)
User: Selects Language
System: Asks to select Account Type
4)
User: Selects Account Type
System: Asks to enter Amount
5)
User: Enters Amount
System: Releases Money
————————————————–
Alternatives
2a) Suppose if user enters invalid Pin
System: Shows error message and asks to enter correct PIN
User: Enters Correct PIN
———————–
4a) Suppose if user selects incorrect Account Type
System: Shows error and asks to select correct Account Type
User: Select correct account type
5a) If User enters incorrect amount (More than the balance amount or more than the day limit)
System: Shows Error message and asks to enter correct amount
User: Enters correct amount
5. Software Testing Life Cycle
> Software Testing Life Cycle (STLC) identifies what test activities to carry out and when to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle.
> Just like Software Developers follow the Software Development Life Cycle (SDLC), Software Testers also follow the Software Testing Life Cycle.
> Software Test Process is not a single activity, it consists of many different activities which are executed to achieve a good quality product.
There are different phases in STLC which are given below:
i) Requirement Analysis
ii) Test Planning
iii) Test Design & Development
iv) Test Environment Setup
v) Test Execution
vi) Test Cycle Closure
We have Entry and Exit Criteria for all levels in the Software Testing Life Cycle…
Entry Criteria: Entry Criteria gives the prerequisite items that must be completed.
Exit Criteria: Exit Criteria defines the items that must be completed.
i) Requirement Analysis
> In the Requirement Analysis phase, the test team studies the requirements and identify the testable requirements.
Entry Criteria: Requirements Document available (both functional and non functional), Application Architectural document or Product should be available…
Exit Criteria: RTM should be signed off and The customer should sign off on the test automation feasibility
Activities in this phase:
a) Identify types of tests to be performed.
b) Risk Analysis
c) Prepare Requirement Traceability Matrix (RTM).
d) Identify Test environment details
e) Automation feasibility analysis (if required).
Deliverables:
a) Requirement Traceability Matrix (RTM)
b) Automation feasibility report(Optional)
ii) Test Planning
> In this phase the Test Manager or Test Lead prepares the Test Plan and Test strategy documents.
Entry Criteria: Requirements Document, Requirement Traceability Matrix (RTM) and Automation Feasibility Report
Exit Criteria: Approved Test Plan document, Test Strategy document and Effort estimation document
Activities in this phase:
a) Selection of Testing Approach
b) Test Estimation
c) Team Formation
d) Preparation of Test Plan, Test strategy documents
e) Configuration Management Planning
f) Resource planning
g) Test Tool Selection (if required)
h) Training Requirement
Deliverables:
a) Test Plan, Test Strategy document.
b) Test estimation document.
Etc..
iii) Test Design & Development
> In Test design phase, testers prepare test scenarios, test cases/test scripts and test data based on the Requirement Document/s and Test Plan.
Entry Criteria: Requirements Document/s, RTM and Test Plan, Automation analysis report
Exit Criteria: Reviews Test cases, Test Scripts (if automation) and Test data.
Activities in this phase:
a) Derive Test Scenarios
b) Test Case Documentation
c) Review Test Cases
d) Update RTM – Map Test Cases to Requirements in RTM
e) Creation of Test Scripts if required
f) Collect Test Data
Etc…
Deliverables:
a) Test cases
b) Test scripts (for automation if required)
c) Test Data
iv) Test Environment Setup
> It is a combination of hardware and software environments on which the tests will be executed.
> Test Environment supports test execution with software, hardware and network configured. Test environment configuration must mimic the production environment.
> Readiness of the test environment can be validated by smoke testing performed by the Testing team.
Entry Criteria: System design document/s, Architectural document of the application and Environment set-up checklist. Provision of Test Plan, readiness of Smoke Test cases and preparation of test data.
Exit criteria: Test environment should be ready and smoke testing should be performed successfully.
Activities:
a) Setup Test Environment and Test Data
b) Verify Test Environment by Conducting Smoke Tests
Deliverables:
a) Test Environment ready with test data set up
b) Smoke Test Results.
v) Test Execution
> In Test Execution phase the test cases are executed in the testing environment, while execution of the test cases the Testing team may find bugs which will be reported, bugs are fixed by the developer and they are retested by the Testing Team.
Entry Criteria: Test Plan document, Test cases, Test data, Test Environment
Exit Criteria: Test case execution report. Defect report, RTM
Activities:
a) Execution of Test Cases
b) Document test results, and log defects for failed cases
c) Update RTM – Map defects to test cases in RTM
d) Retest the Defect fixes
e) Track the Defects to Closure
Deliverables:
a) Test execution Report
b) Updated test cases with results
c) Completed RTM with execution status
d) Opened and Closed Bug Report/s
vi) Test Cycle Closure
> Testing team will meet , discuss and analyze testing artifacts and evaluate Test cycle completion criteria. Identify strategies that have to be implemented in future and taking lessons from the current test cycle.
Entry Criteria: Test case Execution report and Opened and closed Defect Reports
Exit Criteria: Test Closure Report signed off by client, Test Metrics
Activities:
a) Evaluate Test Cycle completion criteria
b) Prepare test metrics
c) Documentation of the learning from the project
d) Prepare Test closure report
Deliverables:
a) Test Closure report
b) Test metrics
———————————————————————
Note: This Software Testing Life Cycle or Software Test Process is for conducting Software
Testing at System Testing Level and It is Manual Testing Process…
System Test Plan Documentation
I) Test Planning Phase
Input or References:
Requirement Specifications
Project Plan Document
Test Strategy Document
Global design document
Low Level Design document
Development and Test process standards
Corporate standards and guidelines
Tasks:
Understanding & Analyzing the Requirements
Risk Analysis
Test Strategy Implementation
Test Estimations (in terms of time, budget, resources, and scope of the project)
Team formation
Test Plan documentation
Configuration management planning
Creating Traceability matrix
Defining test environment setup
Output:
Test Plan document
Test Plan Template
1) Test Plan ID:
Some type of unique company generated number to identify this test plan.
2) Introduction:
Describe the purpose of the Plan, possibly identifying the level of the plan (System Test Plan etc.). This is essentially the executive summary part of the plan.
3) Test Items:
These are things you intend to test within the scope of this test plan.
4) References:
List all documents that support this test plan. Refer to the actual version/release number of the document as stored in the configuration management system.
5) Features to be Tested:
This is a listing of what is to be tested from the Users viewpoint of what the system does. This is not a technical description of the software, but a Users view of the functions.
6) Features not to be Tested:
This is a listing of what is NOT to be tested from both the Users viewpoint of what the system does and a configuration management/version control view. This is not a technical description of the software, but a Users view of the functions.
7) Test Approach:
This is your overall test strategy for this test plan; it should be appropriate to the level of the plan (master, acceptance, etc.) and should be in agreement with all higher and lower levels of plans. Overall rules and processes should be identified.
8) Entry Criteria:
It describes when to start Testing
9) Exit Criteria:
It describes when to stop testing
10) Suspension Criteria:
It describes when to stop testing temporarily.
11) Roles & Responsibilities
Team Lead or Test Lead and Team members Roles and Responsibilities.
12) Schedule:
Schedule for all Test activities in this Software Test Process.
13) Training:
> Training on the application/system (Domain Training)
> Training for any test tools to be used.
14) Test Environment / Lab:
It describes Require Hardware and software for setting-up Test Environment or Test Lab.
15) Test Deliverables:
Lists out that what is to be delivered as part of this plan?
16) Approvals
Who can approve the process as complete and allow the project to proceed to the next level.
17) Glossary:
Define terms and acronyms used in the document, it can be used to understood the terms used in this plan.
Software Test Plan Documentation
A Sample Test Plan Document for Internet Banking Application
1) Test Plan ID: IBS_ST_TP_001
2) Introduction:
It is System Test Plan for Interment Banking System, internet web application, provides access to Account holders and guest users from any ware in the world. It has two interfaces one is Admin interface another is User interface. Admin can be accesses by Bank authorized users, user interface can be accessed by Bank account holders and guest users.
The propose of the system (Application) is to provide bank information and services online (through Internet), Bank account holders can get Banking services from any ware, without visiting the Bank branches.
3) Test Items:
Admin Interface:
Master Data
User Management
Reports
etc…
User Interface
Information
Personal Banking
Corporate Banking
Business
Etc…
4) References:
Requirements
Project Plan
Test Strategy
—
Use cases (If available)
High Level Design doc
Low Level design docs
Process guide line doc
Prototypes
5) Features to be Tested:
a) Admin Interface:
i) Master Data
1) Add new branch, Edit Branch /Delete Branch
2) Add new ATM
3) Add new loan type
4) Add new account type
5) Add new deposit type
….
ii) User Management
1) Create new user
2) Edit user
3) Delete user
etc…..
iii) Reports
1) Branch wise report
2) User wise report
3) Day, month, yearly reports
4) Service wise report (only loans, only new account. fixed deposits)b)
User Interface:
i) Information
1) Branch locators
2) ATM locators
3) Loans information
4) Bank history
5) Bank financial details
6) Fixed deposits information
7) Calculators
etc…
ii) Personal Banking
1) Login
2) Balance enquiry
3) Bill payment (utilities, subscriptions)
4) Fund transfer (transfer to same bank, others banks)
5) Statement generation (mini stmt, detailed report)
etc…
iii) Corporate Banking
1) Add user, Edit user, Delete user
2) Balance enquiry
3) Money transfer
4) Payroll
5) Reports
etc..
6) Features not to be tested:
NA
7) Entry Criteria:
a) Test Design
Team formation, Responsibilities, Schedule,
Requirements, Test Case Template etc…
Training on Domain, on Automation tools
b) Test Execution:
Readiness of Test Lab
Readiness of AUT
Requirements
Test Case docs
Test Data
Defect Report Template
Etc…
8) Exit Criteria:
All possible test cases executed
Maximum defects fixed, Final Regression performed successfully
Confidence on Test process
Time Limitations
Budget Limitations
9) Suspension Criteria:
Show-Stopper bug found
Supplier issues
Vast changes in requirements
If resolving defects are more
10) Roles & Responsibilities
Sno Name Role Responsibilities Remarks
1 Kareemulla SK Test Lead Test Planning, guidance, Monitoring and Test control
2 Venkat Rao P Sr. Tester Test Data Collection, Generating Test Scenarios.
3 Swapna DK Tester Test Case Documentation, Test execution, defect reporting and tracking for Admin module.
4 Srinivas V Tester Test Case Documentation, Test execution, defect reporting and tracking for Personal Banking module.
5 Suneetha B Tester Test Case Documentation, Test execution, defect reporting and tracking for Corporate Banking module.
6
11) Schedule:
Sno Task Days Duration Remarks
1) Understanding & Analyzing Requirements. 5 2nd July to 6th July
2) Review Meeting 01 9th July
3) Generating Test Scenarios. 10 11th July to 22nd July
4) Reviews 02 25th July to 26th July
5) Test Case Documentation 40 29th July to 12th August
6) Reviews 04 14th August to 18th August
7) Test Data collection 06 20th August to 26th August
8) Reviews 01 28th August
9) Verifying Test Environment setup 01 29th August
10) Create Test batches 02 30th, 31st August
11) Sanity Testing 01 3rd September
12) Comprehensive Testing 25 4th September to 2nd October
13) Sanity Testing 01 3rd October
14) Selecting Test cases 02 4th and 5th October
15) Regression Testing 05 8th October to12 th October
16) Sanity Testing 01 15th October
17) Selecting Test cases 01 16th October
18) Regression Testing Cycle 2 04 17th October to 22nd October
. . . .
. . . .
. . . .
28) Final Regression 08 19th November to 28th November
29) Evaluating exit criteria 01 or 02 29th, 30th of November
30) Collecting all artifacts 02 3rd, 4th December
31) Test Summary Report 01 5th December
Note: Regression Testing depends on Application and strength of Development team.
12) Training
Training Program on Banking Domain
Test Automation Training using Selenium Tool
13) Risks & Mitigation
Team members issues
Vendor issues
Time
Budget
14) Test Environment / Lab
Application Type: Web Application, Internet and Public
Server side:
Windows Server 2016
UNIX server
Ms Exchange Server
a) Web Server, b) EDP, 3) Data storage
Bugzilla Tool
VSS
MS Office
Selenium Tool etc….
Browser MS Edge
——————————-
Client side:
Windows 10
VSS
MS Office
Selenium
Etc…
———————————-
AUT Environment
.NET (C#, VC++, ADO)
IIS -web server
COM+ -App server
SQL Server 2017 for Database server
———————
15) Test Deliverables
Test Plan,
Review Reports,
RTM
Test Scenario docs
Test Case docs
Test data
Opened, Closed Defect Reports
Test Summary Report
16) Approvals
SNO Task/s Author /Role Date & Signature
1) Test Plan Documentation Kareemulla SK (Test Lead)
2) Review Hari Prasad (QA Analist)
3) Approval Vinod Rao (Project Manager)
17) Glossary
AUT -Application Under Test
.
.
.
PIN -Project Initiation Note
.
.
.
SRS- Software Requirements Specification
.
.
.
Software Test Case Documentation
> What is Test Case?
A set of input values, execution preconditions, expected results and execution post conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.
> Test Case Template
Test Case Template may vary from one company to another, some times one project to another in the same company. If you familiar with anyone Test Case then you can easily write test Cases using any type of Test Case Template.
I am going to introduce a Model Test Case Template,
Sample Test Case Template:
1) Test Case Id: a Unique Name to identify the Test Case
2) Test Case Title: Title or Name of the Test Case
3) Module Id: Name of the main module or sub-module being Tested
4) Precondition: Status before the Test Case Execution
5) Test Steps: Steps for Executing the Test Case
6) Test Data: Required Input Data for Executing the Test Case
7) Expected Result: Expected Result as per Requirements
8) Post-condition: Status After Test Case Execution
9) Actual Results: (During & After Test Case Execution)
10) Status: Pass or Fail Status after comparing Expected Results with Actual Results
11) Comments: (Optional)
Test Case Writing
1) Test Case Id: U_TC_001
2) Test Case Title: Gmail Login Functionality
3) Module Id: User
4) Precondition: Valid Gmail Id and Password
5) Test Execution Steps:
i) Launch the Browser and Navigate to www.Gmail.com
ii) Write / Type Valid Gmail ID in the “Edit Box”
iii) Click on “Next” Button
iv) Write / Type Valid Password in the Edit Box
v) Click on “Sign In” Button
6) Test Data:
i) Gmail Id: gcr1977
ii) Password: gcbannureddy
7) Expected Result:
i) Gmail Home Page is Opened
ii) Gmail ID is Entered
iii) Another Web page is opened which gives an option to Enter Password
iv) Password is Entered
v) User is logged in to Gmail.
8) Post-Condition: User Gmail Page opened with all options like Compose,Delete etc…
9) Actual Results: (* During Test Case Execution)
10) Status: (* After Test Case Execution)
11) Comments:
> Our Test Case after the Execution
1) Test Case Id: U_TC_001
2) Test Case Title: Gmail Login Functionality
3) Module Id: User
4) Precondition: Valid Gmail Id and Password
5) Test Case Steps:
i) Launch the Browser and Navigate to www.Gmail.com
ii) Write / Type Valid Gmail ID in the “Edit Box”
iii) Click on “Next” Button
iv) Write / Type Valid Password in the Edit Box
v) Click on “Sign In” Button
6) Test Data:
i) Gmail Id: gcr1977
ii) Password: gcbannureddy
7) Expected Result:
i) Gmail Home Page is Opened
ii) Gmail ID is Entered
iii) Another Web page is opened which gives an option to Enter Password
iv) Password is Entered
v) User is logged in to Gmail.
8) Post-Condition: User Gmail Page opened with all options like Compose, Delete etc…
9) Actual Results:
i) Gmail Home Page Opened
ii) Gmail ID Entered
iii) Another Webpage opened and It has an option to Enter Password
iv) Password Entered
v) User logged in to Gmail.
10) Status:
i) Step 1: Pass
ii) Step 2: Pass
iii) Step 3: Pass
iv) Step 4: Pass
v) Step 5: Pass
Test Case: Pass
11) Comments: Smooth Execution, and Fields also User Friendly
Note 1: You can some fields to this Test Case if required, Ex: Tester’s Name, Environment, Date of Creation, Date of Execution etc…
Anyhow Test Case Template may vary form one company to another and one project to another, based scope of the Project usually we can Select Test case Template.
Note: Usually we write Manual Test Cases in Excel File using our Company prescribed format, if we use any Test Tool like, ALM, Jira etc… then they provide Test Case temple and User/Tester can document Test Cases, and one more thing some Test Tools provide options to customize the Test Case Template.
Defect Reporting
Application Life Cycle (ALM)
Development Phase Testing Phase Production Phase
Error Defect Failure
Mistake Bug
Fault
————————————–
We have 3 phases in Software Application Life Cycle
a) Development Phase
In this phase If developers find any mismatch, they call it as Error or Mistake.
b) Testing Phase
In this phase If Testers find any mismatch, they call it as Defect or Bug or Fault.
c) Production Phase
In this phase If End users find any mismatch, they call it as Failure.
Note: Terminology vary from one phase to another.
————————————————-
Defect Management:
Defect Reporting, Defect Tracking, and Status Tracking is called Defect Management.
Some companies use Manual Process (Excel workbook), and some companies use Tool based process
for Defect Management.
Tools Examples:
Bugzilla / Issue-Tracker / PR-Tracker etc…
Jira, QC
Model Defect Report Template:
1) Defect Id: any unique name for Identifying the Defect (Alphanumeric)
2) Defect Description: Details about the Defect
3) Test Case Id: Corresponding Test Case Id for tracking
4) Tester: Tester’s name (who found the Defect)
5) Product Version: Version of the Product on which defect was found
6) Build Version: Version of the Build on which defect was found
7) Priority: Importance of the Defect based on Business /Customer
8) Severity: Importance of the Defect based on Functionality
9) Status: Status of Defect
10) Reproducible or not: Yes / No
If Reproducible:
Steps:
If not Reproducible:
Attachments
11) Reporting to: Corresponding Developer
12) Remarks : Comments (Optional)
——————————————————-
Status: Status of Defect
New: Tester provides new status while Reporting (for the first time)
Open: Developer / Dev lead /DTT opens the Defect
Rejected: Developer / Dev lead /DTT rejects if the defect is invalid or defect is duplicate.
Fixed: Developer provides fixed status after fixing the defect
Deferred: Developer provides this status due to time etc…
Closed: Tester provides closed status after performing confirmation Testing
Re-open: Tester Re-opens the defect with valid reasons and proofs
——————————————-
Note: Defect Reporting Template vary from one company to another
If we use Tool for Defect management, every tool provides their own template.
Defect Reporting Process
——————————————-
The defect Reporting Process vary from one company to another.
a) Small scale Company
Tester -> Developer
b) Medium-scale Company
Tester -> Test Lead -> Development Lead -> Developer
c) Large scale Company
Tester -> Test Lead -> DTT -> Development Lead -> Developer
A Sample Defect Report
1) Defect Id: FR_Usr_Df001
2) Defect Description: Agent Name accepting Numeric values
3) Test Case Id: FR_Usr_Tc-004
4) Tester: Kanaka Rao
5) Product Version: 1.0
6) Build Version: 1.0
7) Priority: Medium
8) Severity: High
9) Status: New
10) Reproducible or not: Yes
Steps:
i) Launch the Application
ii) Enter Numeric values into Agent Name field
iii) Enter valid Password
iv) Click on default(OK) button
11) Reporting to: xyz
12) Remarks : Comments (Optional)
————————————
Severity:
Severity Levels depends on Company strategy
a) 5 Level Severity
Urgent
Very High
High
Medium
Low
———–
b) 3 Level Severity
High
Medium
Low
——————————————-
Priority
Priority Levels depends on Company strategy
a) 5 Level Priority
Urgent
Very High
High
Medium
Low
———–
b) 3 Level Priority
High
Medium
Low
——————————————————————–
Defect Life Cycle
——————————————————————–
Different Flows of the Defect
a) New -> Opened -> Fixed -> Closed
b) New -> Opened -> Rejected -> Closed
c) New -> Opened -> Fixed -> Re-opened -> Fixed -> Closed
d) New -> Opened -> Deferred
e) New -> Opened -> Rejected -> Re-opened -> Fixed -> Closed
Etc…
Test Summary Report
A test summary report is a Quality work product / Test Document that formally summarizes the
results of all testing.
Test Lead or Test Manager prepares this document at end of the Testing, means in Test Closure
phase (Last phase in STLC/Software Test Process.
Purpose:
To enable Project management and Customer to know the status of testing status of the
project and Application Quality Level.
Advantages:
All stakeholders of the Projectable to get project test status, Application Quality status
and they can take corrective actions (if required)
Guidelines:
A Test summary report can be generated for every software release
• It should have metrics, charts and table forms, if possible
• It has to summarize all test activities based on Quality work products.
Test Summary Report Template
Introduction:
Test Items:
Reference documents
Target Audience
Test Summary
a) Test Suite Information:
• Number of test suites planned.
• Number and percentage of test suites implemented.
• Number and percentage of test suites executed.
b) Test Case Information:
• Number of test cases planned.
• Number and percentage of test cases implemented.
• Number and percentage of test cases executed.
• Number and percentage of test cases passed.
• Number and percentage of test cases failed (total and by severity).
c) Defect Report Information
Number of defects found in comprehensive Testing
Number of Test Cases selected for Regression Testing Cycle1
Number of defects found in Regression Testing Cycle1
Number of Test Cases selected for Regression Testing Cycle 2
Number of defects found in Regression Testing Cycle 2
Number of Test Cases selected for Regression Testing Cycle 3
Number of defects found in Regression Testing Cycle 3
.
.
.
Number of Test Cases selected for Final Regression.
Number of opened defects in this release.
Approvals
A Sample Test Summary Report
Introduction:
It is for Internet Banking System Application Version 2.0, IBS (Internet Banking System) has
Information, Personal banking, Corporate Banking, Master Data, User Management and Reports
modules already. Now in this release some features added to Personal Banking Module and One
New module “Small Business” added.
Test Items:
Personal Banking
New Business
Reports
Reference documents:
Test Plan, Test Case documents, Opened and Closed Defect Reports, Metrics docs, Review
Reports.
Target Audience:
Project Manager, Release Team, Maintenance Team and Customer (End Users).
Test Summary
a) Test Suite Information:
• Test suites planned: 42
• Test suites implemented: 39
• Test suites executed: 38
b) Test Case Information:
• Test cases planned: 983
• Test cases implemented: 978
• Test cases executed: 967
• Test cases passed: 940 (Final)
• Test cases failed: 14 (Final)
• Test Cases pending: 3
c) Defect Report Information
Defects found in comprehensive Testing: 148
Test Cases selected for Regression Testing Cycle1: 320
Defects found in Regression Testing Cycle1: 96
Test Cases selected for Regression Testing Cycle 2: 213
Defects found in Regression Testing Cycle 2: 42
Test Cases selected for Regression Testing Cycle 3: 107
Defects found in Regression Testing Cycle 3: 26
.
.
.
Test Cases selected for Final Regression: 512
Number of opened defects in this release: 14
Approvals
Name Role Responsibility Date & Signature
abcd Test Lead Test Summary 20-06-2012
Report preparation
xyz QA Analyst Review 25-06-2012
pqr Project Manager Approval 29-06-2012
* On 29-06-2012 Test Summary Report baselined (Finalized).
