1.

TESTING
 It helps to identify the defects and provide quality product to end user.
 It will happen D (Development) to D (Delivery to End User).
 The Product/Application/System will be used in customer point of view
in all positive and negative perception.
 This testing will be done by TESTERS.
 A Defect is an Undesirable State
Undesirable
State

Not Meeting Variance from Desired ER≠AR

Requirements Attribute

2. QUALITY
What is Quality?
• Quality is defined as meeting the customer’s requirements for the first time and
every time.
• Quality is much more than the absence of defects, reliability, efficiency, easy
to use, within budget.
• Producer’s view – Quality of product meets requirements.
• Customer’s view – Quality of product “fit for use”/ meets customer’s needs.
Why Quality?
• Quality is the important factor affecting an organization’s long term performance.
• Quality improves productivity and competitiveness in any organization.
How you achieve quality?
Right the first time - if anything is done perfectly in the first time itself then we can say
that quality is achieved. When the following thing are done then quality can be achieved
Effectiveness - Doing the Right things
Efficiency - Doing the things right
Quality Testing
Verification + Validation
Quality Control
Measures the quality of the product.
Validation is the process of evaluating the final product to check whether the software meets
the business needs.
• QC makes sure that we developed the product right.
• It is product oriented.
• Defect detection based.
• This will happen after the development
• Eg: Testing (Validation)

[Prepared By: Kamal Subramani] Page 1

Software Quality Factors (SQF)
• Correctness
• Reliability
• Functionality Critical
• Efficiency Success
• Maintainability Factors
• Reusability
• Compatibility
• Effectiveness
• Testability
• Interoperability
• Integrity
• Flexibility
• Usability
4. SOFTWARE TESTING
• Software testing is a planned process that is used to identify the correctness, completeness,
security and quality of software.
• Software testing is a process of evaluating a system by manual or tool means and verify that
it satisfies specified requirements or identify differences between expected and actual
results.
Why Software Testing
1. To check the reliability of the software.
2. To be ensured that the software does not contain any bug which can become a
reason for failure.
3. To check the software was made according to its specification.
4. To check that the software meets its requirements.
5. To check that users are capable of using the software.
6. To check software works with other software and hardware it needs to work with
This testing implemented in two ways
1. Manual Testing
2. Tool Testing

Software Testing

Functional Testing Non Functional Testing

Manual Testing Automation Testing Performance Testing

[Prepared By: Kamal Subramani] Page 2

 Manual Testing
APPLICATION

RESULT

TESTER

Tool Testing

APPLICATION

TOOL Result

TESTER

Who Does Testing

1. Software Tester
2. Software Developer
3. Project Lead/Manager
4. End User
5. Information service management
6. Senior organization management
Primary Goal of Testing
• Finding Errors
• Ensure all the functionalities are implemented
• Ensure the software meets the customer requirements
• Ensure the quality of product
Need for Software Testing
Producer View of Quality as Specified

Producer Gap
Producer View of Quality as Delivered
Start

Customer Gap

Customer View of quality as wanted

[Prepared By: Kamal Subramani] Page 3

Some Key Challenges in Software Testing
1. Testing the Complete Application
2. Relationship with developers
3. Regression testing
4. Testing always under time constraint
5. Understanding the requirements
6. One test team under multiple projects
7. Testers focusing on finding easy bugs
8. Which tests to execute first?
9. Lack of skilled testers
10. Mis-communication or No Communication
11. Requirements are not freezed
12. Application is not Testable
13. Lack of resources
14. Lack of Training
Role of QA
• QA team assures the quality by monitor the whole development process.
• Responsibilities of QA team are planning testing execution Process.
• QA Lead creates the time table and agrees on a quality assurance plan for the document.
• QA team communicated QA process to the team members.
• QA team ensures traceability of test cases to requirements.
•
5. Principles of Testing
1. Testing shows presence of defects
Testing can show the defects are present, but cannot prove that there are no defects. Even after testing
the application or product thoroughly we cannot say that the product is 100% defect free. Testing always
reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is
not a proof of correctness.
2. Exhaustive testing is impossible
Testing everything including all combinations of inputs and preconditions is not possible. So, instead of
doing the exhaustive testing we can use risks and priorities to focus testing efforts. For example: In an
application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid
combinations you would need 30 517 578 125 (515) tests. This is very unlikely that the project timescales
would allow for this number of tests. So, accessing and managing risk is one of the most important activities
and reason for testing in any project.
3. Early testing
In the software development life cycle testing activities should start as early as possible and should be
focused on defined objectives.
4. Defect clustering
A small number of modules contains most of the defects discovered during pre-release testing or shows
the most operational failures.
5. Pesticide paradox:
If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer
be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really very important to review the
test cases regularly and new and different tests need to be written to exercise different parts of the software
or system to potentially find more defects.

[Prepared By: Kamal Subramani] Page 4

6. Testing is context depending
Testing is basically context dependent. Different kinds of sites are tested differently. For example, safety –
critical software is tested differently from an e-commerce site.
7. Absence – of – errors fallacy
If the system built is unusable and does not fulfil the user’s needs and expectations then finding and fixing
Defects does not help.

SDLC
• It stands for Software Development Lifecycle.
• It is the entire process of formal, logical steps taken to develop a software product.
• It describes the activities that take place at each stage of software development process.
SDLC PHASES
Requirement collection:
In this phase with an interaction of Clint BA will collect Clint requirement. Collected information will be
documented as BRS (or) customer requirement specifications (CRS).
BRS document describe Clint business needs, like who can access the application and what type
of services application has to provide to the user. After preparation of BRS doc Business analyst will perform
feasibility study which is called pre project activity. In feasibility testing they verify follow8ing factors to check
whether the project (or) product is acceptable or not.
[Prepared By: Kamal Subramani] Page 5
In feasibility study they verify following factors.
1) Finance feasibility.
2) Time feasibility.
3) Ability to accept in terms of technology, environment, Human resources and requirements are reliable
or not. If project is acceptable BA intimate to that lint with help of “statement of work” and “service
level agreement”.
Requirement analysis (or) System analysis:
In this phase system analyst will analyze Clint business needs in BRS document based on that he
prepares detailed document SRS.
SRS contains two types of sub document
1. FRS (Functional requirement spec’s): It describes detailed functionality of the system in order to
cover Clint document to understand functionality of application.
2. NFRS (Non FRS): It describes about Clint expectations like performance factors, security, compatibility
etc.
Design:
In this phase design architect will prepare following documents after analyzing SRS.
1. GUI design doc:
It contains dummy screens of application. A sample application without functionality like
prototypes is helpful to know the future implementation of application and as tester point of view
it is easy to understand application functionality.
2. Data base design doc:
This document describe about data base structure like tables, rules between those tables.
3. Application design document (or) technical design document:
After architecture of application design architect will prepare two sub docs in TDD.
Two doc’s contains in TDD are
1. High level design doc describes no. of modules required for an application and relation between those
modules.
Modularization: It is a process of splitting into set of module for easy construction of application.
Module: Means set of similar requirements grouped together.
2. Low level design document: For each module there will in depend low level design document where it
describes logic of the each module in order to develop programs.
Coding:
In this phase developer will write the program in order to develop application based on design
documents. In general for window base application they use programming languages like java, dotnet, etc. For
web based application they use scripting languages PHP, Perl etc.
Testing:
After writing the program development team will perform unit and integration testing using white box
testing techniques.
Testing engineers validate application as per Clint requirements and expectations in system testing where
they use BBT techniques. After system testing to Clint feedback will perform UAT.
Implementation & Maintenance
Includes implementation of changes that software might undergo over a period of time, or
implementation of new requirements after the software is deployed at the customer location. The
[Prepared By: Kamal Subramani] Page 6
maintenance phase also includes handling the residual errors that may exist in the software even after the
testing phase. This phase also monitors system performance, rectifies bugs and requested changes are made.
Maintenance, often turned support, is a crucial activity for linking the experiences of users/customers with the
product delivery organization. We consider perspectives on high tech maintenance from bug fixing through to
design focused activities.

[Prepared By: Kamal Subramani] Page 7

TEST INITIATION
STLC starts with Test Initiation. In this stage PM can
prepare Word to prepare Test Strategy in IEEE 829 Format. Test Strategy. PM can use
MS-

Requirement
Analysis
Optimal Test Strategy
Risk Test
Analysis Strategy

Test Strategy Document:

1. Scope and Objective
PM Can specify importance of testing in current project / product
2. Business Issues
Budget allocation for testing.
100% Cost of Project/Product

64% 36%
(Development & Maintenance) (Testing)
3. Test Responsibility Matrix
PM can select reasonable test to be conducted in current Project / Product.
S/W Testing Yes/No Comments
Functional Testing Yes -
Usability Testing Yes
Compatibility Testing Yes
H/W Configuration Yes
Performance Testing No Required Test, Resources not available
Security Testing No Required Test, But no Skils
Multi - Language No No Requirement
4. Roles and Responsibilities
Jobs for Testing Team & Responsibilities of each job.
Roles Responsibilities
Test Lead  Prepare Test Plans
 Review Test Cases
 Involving in Defect Tracking
Senior Tester (Quality Analyst)  Prepare Test Cases
 Involving in Defect Reporting
Junior Tester (Quality Controller)  Executing Test Cases
 Prepare Defect Reporting

[Prepared By: Kamal Subramani] Page 8

5. Communication & Status Reporting
PM can specify required communication in between testing team members.
Example:
 Jr.Tester can meet Sr.Tester daily.
 Sr.Tester can meet TL weekly twice.
 TL can meet PM weekly once.
5. Test Automation
Current project / product is suitable for testing and also need for automation testing
7. Defect Tracking & Reporting
The process for defect reporting & tracking will be decided by PM
PM

Test Lead Team Lead

Testers Programmers
8. Testing Measurements and Metrics
PM can define a set of measurements and metrics to be followed by Testers during
testing.
Example:
 25 to 30 Test cases documents preparation per day
 15 to 20 Test cases documents execution per day
 5 Defects detection per day
8. Test Management
Test Management is a part of configuration Management. In general PM is
responsible to provide location to Developers and Testers to save their deliverables for
future reference.
10. Risk Assumptions
PM can guess challenges will come during testing and identify the solutions to
overcome those challenges
Examples:
Risk 1: Lack of time
Risk 2: Lack of Resources
Risk 3: Lack of Documentation
Risk 4: Delays in Delivery
Risk 5: Lack of Skills
Risk 6: Lack of Seriousness to developers
Risk 7: Lack of communication in between developers and testers
Risk 8: Sudden changes in customer requirements.
11. Training Needs
PM can identify need for training to tester for current project / product, Most of the
times PM can skip training for budget control.
TEST PLAN
After completion of Team Formation and Risk Identification, Corresponding TL can start
Test Plan Preparation in MS-Word by following IEEE 829 Standard Format.
A document that defines the overall testing approach is called Test Plan.
A test plan is a document detailing a systematic approach to testing a system such as a
machine or software. The plan typically contains a detailed understanding of the eventual
workflow.

[Prepared By: Kamal Subramani] Page 9

IEEE 829 Test Plan Document format classified into 4parts.
 What to Test?
 How to Test?
 Who to Test?
 When to Test?
TEST PLAN DOCUMENT
1. TEST PLAN DOCUMENT ID:
Unique number or Name for documents
2. INTRODUCTION:
About current project / Product Testing
3. FEATURES & MODULES:
List of all modules in current project
4. FEATURES TO BE TESTED:
List of modules to be tested What to Test?
5. FEATURES NOT TO BE TESTED:
List of modules not to be tested
6. TEST STATEGY:
PM will give Strategy

7. TEST ENVIRONMENT: How to Test?

Required Hardware’s and Software’s need for testers
8. TEST DELIVARBLES:
List of Testing Documents to be prepared by Tester during testing.
Eg: Test Scenario, Test Cases, Test Data, Test Scripts, OR, Test Logs, Review Reports.
9. ENTRY CRITERIA ( When to Start Testing)
Test Environment Established Test
Cases Prepared and Reviewed S/W
Build released from developers

[Prepared By: Kamal Subramani] Page 10

TEST SCENARIO
 Test Scenario is nothing but Hypothetical Story
 Test Scenarios are just a flow of the application.
 A concept which provides one-line information about what to test.
 It is nothing but a particular functionality of the application need to be tested.
 What To Test
 TL & Senior Tester will prepare Test Scenario in MS-Office by following IEEE
829 Standard Format.
TEST CASES
 Test Cases are nothing but set of procedures which we execute in our system to
find the defect
 An input operation and the corresponding expected output” in order to test a small
unit of work.
 Test Cases are derived from Test Scenario
 How To Test
 Senior Tester will prepare the test cases.
Example
Scenario
Checking the functionality of Login button is Test scenario
Test Cases
1. Click the button without entering user name and password.
2. Click the button only entering User name.
3. Click the button while entering wrong user name and wrong password.

[Prepared By: Kamal Subramani] Page 11

 TEST CASES EXECUTION
 Test execution is culmination of testing activities which involves executing
the planned test cases and conducting of the tests.
 Test execution phase broadly involves execution and reporting.
 Test execution consists of following activities to be performed
 Creation of test setup or Test bed
 Execution of test cases on the setup
 Test Methodology used
 Collection of Metrics
 Defect Tracking and Reporting
 Map Defects to Test Cases in RT
 Resting & Regression Testing

DEFECT TRACKING AND REPORTING

Defect Reporting (Bug Life cycle) is the journey of a defect from its identification to
its closure. It starts when defect is found and ends when a defect is closed, after ensuring
it’s not reproduced. Defect life cycle is related to the bug found during testing. The bug has
different states in the Life Cycle.
TEST CLOSURE
Testing team will meet, discuss and analyze testing artifacts to identify strategies that
have to be implemented in future, taking lessons from the current test cycle. The idea
is to remove the process bottlenecks for future test cycles and share best practices for
any similar projects in future.
In the review meeting, testing team discuss below factors.
1. Coverage Analysis
a) Module wise coverage.
b) Testing topic wise coverage.
2. Stability in software
Stability of a software indicates, in 20% of testing we can find 80% of bugs and in 80%
of testing we can find 20% of bugs.
3. Calculate Bug density
Modules in SUT % of bugs
--------------------------------------------------
A 20
B 20
C 40 ----------------> Final regression testing
D 20
------------
100 % of bugs
Note
Testing team can re-execute test cases related to high bug density modules on final SUT
for "Golden bugs" to detected. This testing is called as "Final regression" testing or Post mortem
testing or Pre- acceptance testing or confidence testing. If golden bug was found then testing team
will request the developers to fix as early as possible or request customer site people for later
patch release.
4. Analysis of differed bugs
This analysis indicates, whether differed bugs are postpone or not.
The above four points called as "Exit criteria".

[Prepared By: Kamal Subramani] Page 12

5. In software testing final summary report is called as Requirement
Traceability Matrix (RTM).
DEFECT LIFE CYCLE FLOW CHART
Defect Life Cycle (Bug Life cycle) is the journey of a defect from its identification
to its closure. It starts when defect is found and ends when a defect is closed, after
ensuring it’s not reproduced. Defect life cycle is related to the bug found during testing.
The bug has different states in the Life Cycle.
NEW

VERIFYING REJECTED

SUBMITTED

DEFERRED OR TO BE
VERIFICATION FAILED IN PROGRESS
VERVRIFIED

APPROVED

TO BE VERIFIED

FIXED

CLOSED

PROCESS FLOW OF DEFECT LIFE CYCLE

1. Tester will execute the test cases, if tester found any defect then tester will analyse the
defect whether it’s duplicate or not.
2. If yes, then tester will make updates to original defect.
3. If no, tester will log the defect will keep the status as NEW and will assign to Bug Review
Committee.
4. All defects which are in NEW status will be reviewed by Bug Review Committee (BA, M, TL
and Customer). In this meeting members decide whether the bug is valid or invalid.
5. Then Bug committee validate the defect, review the severity, if it is valid assign to
developer, they will keep the status in SUBMITTED otherwise they reject the defect, will
change the status to REJECTED.
6. Then Developer will start working on it, will change the status to IN PROGRESS

[Prepared By: Kamal Subramani] Page 13

7. Once the issue is resolved and validated in development, developer will change the status
to APRROVED and assign to tester.
8. Once fixed defect is ready to test then tester will valid the defect whether it has been fixed
or not, Tester will change the status to TO BE VERIFIED.
9. If BUG is not resolved Tester will change the status VERIFICATION FAILED and will be
assigned to Developer repeat the process till BUG has to closed. If the bug is resolved
tester will change the status as FIXED and will assign to BUG Review Committee for closer.
10. Bug Review committee will review and closed the BUG, Only BUG Review Committee (BA,
M, TL) has right to keep the status as CLOSED.
11. Few defects which are unable to fix in the current release and important for application
functionality will be in "DEFERRED" status. And will be taken care in next release.
ERROR, DEFECT, BUG, FAILURE, FAULT
ERROR
A human action that produces an incorrect result. Programmatically mistake or
syntax mistake leads to error.

DEFECT
If tester found any mismatch between expected and actual value.
BUG
Once developer accepts tester’s identified defect that is called bug.
FAILURE
Defect reaches the customer then is called failure.
FAULT
When the product/software successfully launched in the market and running properly
but due to any reason if it works unexpectedly is called Fault.
Example
You are driving a car and you are on road while on driving now there is two way on the road
1) left--> mumbai
2) right--> delhi
Now you have to go to delhi it means you have to turn the steering to the right, but by
mistake you turn the steering to the left, from that position that is called as "Error" because
human interaction is there And now Fault is there till you will not reach the Mumbai, but when
you reach Mumbai that is a final stage which is called "Failure" becoz you had to reach Delhi but
now you are in Mumbai.

SEVERITY & PRIORITY

SEVERITY
• Impact of the defect
• How severity the bug is affecting the application.
Critical
This defect is causing system failure. Nothing can proceed further. It may also
be called as a show stopper

[Prepared By: Kamal Subramani] Page 14

 Major
Highly severe defect, is causing the system to collapse, however few parts of the
system are still usable, and/or there are a few workarounds for using the system in the
collapsed state too
Medium
Is causing some undesirable behavior, however system / feature is still usable to a
high degree
Low
Is more of a cosmetic issues, No serious impedance to system functionality is
noted
PRIORITY
• Important of the defect
• Informing to developer which defect to be fixed first.
Urgent
Must to be fixed before any other high, medium or low defect should be fixed.
Must be fixed in the next build.
High
Must be fixed in any of the upcoming builds but should be included in the
release.
Medium
Should take precedence over low priority defects and may be fixed after the
release / in the next release.
Low
Fixing can be deferred until all other priority defects are fixed. It may or may
not be fixed at all.
Examples for Priority & Severity
High Priority & Low Severity
Company logo is not properly displayed on their website.
High Priority & High Severity
Suppose you are doing online shopping and filled payment information, but after
submitting the form, you get a message like “Order has been cancelled”.
Low Priority & High Severity
If we have a typical scenario in which the application get crashed, but that scenario
exists rarely.
Low Priority & Low Severity
There is a mistake like “You have registered success” instead of successfully, success is
written.
BUG LEAKAGE BUG RELEASE
BUG LEAKAGE
When customer or end user discovered a bug which can be detected by the testing
team or when a bug is detected which can be detected in previous build then this is called as
Bug Leakage.
BUG RELEASE
Is when a build is handed to testing team with knowing the defect is present in the
release. The priority and severity of bug is low. It is done when customer want the application
on the time. Customer can tolerate the bug in the released then the delay in getting
application and cost involved in removing that bug. These bug are mentioned in the Release
Notes handed to client for the future improvement chances.

[Prepared By: Kamal Subramani] Page 15

 Types of Testing

STATIC TESTING (VERIFICATION)

Static testing is a process of checking we are developing right system or not. Verification
performed without executing the system's code and functionality and non- functionality of the
system. Also called static analysis.
Walkthrough
Knowledge transfer section are call walkthrough in other word a step by step section
conducted by domain expert about a subject or about process to provided common
understanding to the team member is call walkthrough.
Review
Examining a project related word or a process related word is calling a review. You can
review requirement specification, design specification and code etc. In fact test cases can also
be verified.
Objectives of reviews:
• To find the defects in requirements
• To find defects in design
• To identify deviations in process
• To provide valuable suggestions to improve the process.
Types of reviews
1) Management reviews
2) Technical reviews
3) Formal reviews
4) Informal reviews
5) Load review

[Prepared By: Kamal Subramani] Page 16

1. Management reviews
These reviews will be conducted by the high level management or by the middle level
management to identify deviations in planed effort to actual effort. If any deviations are
identified management will take a necessary corrective action to cover these slippages. So
that you can deliver the application in time to customer.
Slippage: It is a deviation between planned works to actual works.
“Daily or weekly project status meeting are nothing but management reviews”
2. Technical reviews
These reviews are conducted among technical member to decide the best
approach of implementing a task is any queries on that task is any queries on that task.
3. Formal review
If a review is conducted with a prior plan and by following systemic procedure
and proper documentation then these reviews are called formal reviews. Inspection and
audits are the best examples for formal reviews.
Inspection:
If a formal review is conducted while executing a task then it is called inspection.
Audit:
If a formal review is conducted after completion of a task to conform that the task is
accomplish as per predefined procedures or not is called audit.
4. Informal reviews
If a review is conducted without following any predefined procedure then these
reviews are call inspectional reviews. Code reviews are best examples for informal revises.
Code reviews
Review conducted on the source code by developer to check the coding standards is call
code review. In general code review will not follow any predefined procedure.
Peer reviews
Reviews conducted among colleagues
DYNAMIC TESTING (VALIDATION)
• Dynamic testing is nothing executing and using the Software/System/Product.
• Checking the Structural and Functional of the Software/System/Product
• Structural means Logic of the program
• Functional means Functionality & Non- Functionality of the program
• Developer & Tester will implement the Dynamic Testing in Four Levels
1. Unit Testing.
2. Integration Testing.
3. System Testing.
4. User Acceptance Testing.
Levels of Testing
Unit Testing
• Test each module (program, function, procedure, method) individually checking code of
units in application is working as expected or not. It is also called Component Testing or
Module Testing.
• Follows a white box testing (Logic of the program).
• Developers will be involved.

[Prepared By: Kamal Subramani] Page 17

Steps for Unit Testing
1. Create an Unit Testing Test Plan.
2. Create an Unit Integration Testing Test Cases
3. Prepare the Test Data for Unit Integration Testing
4. Execute the Test Cases
5. Bug fixing and tracking the errors
6. Repeat the cycle as necessary.
Entry Criteria for Unit testing phase are:
1. BRS, LLD and Test Data Should be reviewed and approved
2. Environment should be ready
3. Training for developers should be completed
4. Unit testing coding should ready
Exit criteria for the Unit testing phase are:
1. Unit test has been completed
2. All priority a bug have been fixed and closed
3. Internal documentation has been updated to reflect the current state of the product.
Integration testing
• Once unit testing is conducted the programmer will combine all modules together and
will check the interaction between those modules i.e. communicate between the
modules this is called integration testing. It also called as Component Integration
Testing.
• Follows a Grey box testing (Combination of WBT & BBT)
• Both Testers and Developers will be involved
Steps for Integration Testing
1. Create an Integration Testing Test Plan.
2. Create an Integration Testing Test Cases
3. Prepare the Test Data for Integration Testing
4. Execute the Test Cases
5. Bug fixing and tracking the errors
6. Repeat the cycle as necessary
Entry Criteria for Integration testing phase are:
1. Unit test should be completed and all the major bugs should be fixed.
2. HLD and Test Data should be reviewed and approved.
3. Environment should be ready.
4. Training for developers should be completed.
5. Integration coding should ready.
6. Sanitary testing completed.
Exit Criteria for Integration phase are:
1. Integration Testing has been completed.
2. All priority a bug have been fixed and closed.
3. Internal documentation has been updated to reflect the current state of the product.
System Testing
• Validating both functional and non-functional requirements of system is called system
testing
• Follows the black box testing.
• Only Testers will be involved
Steps for System Testing
1. Create a System Testing Test Plan.
2. Create a System Testing Test Cases
3. Prepare the Test Data for System Testing
4. Create and Execute the Automation Test Cases (If Required)

[Prepared By: Kamal Subramani] Page 18

 5. Execute the Test Cases
6. Bug fixing and tracking the errors
7. Repeat the cycle as necessary
Entry Criteria for System testing phase are:
1. Integration testing should be completed and all the major bugs should be fixed.
2. Smoke Testing Completed.
3. SRS, Test Plan, Test Scenario, Test Cases, Test Data should be reviewed and approved.
4. Environment should be ready.
5. Training for developers should be completed.
6. Build should ready.
7. Sanitary testing completed.
Exit Criteria for the System testing
1. System Testing has been completed.
2. All priority a bug have been fixed and closed
3. Internal documentation has been updated to reflect the current state of the product.
User Acceptance Testing (UAT)
• Once the system testing is done then customer or domain expert will test the
application to conform does the application is good for live environment or not.
• It is depend on the business scenario.
• Alpha testing - It is first level of acceptance testing conducted by domain
expert or customer at developer premises.
• Beta testing - It is last level of acceptance testing conducted by domain expert
or customer at customer premises to check whether the application is good
for live usage.
Entry Criteria for UAT phase
1. System Testing and End to End Testing should be completed.
2. All priority a bug have been fixed and closed
3. Defect Report should be ready.
4. Environment should be ready.
5. User acceptance testing should commence upon approval of the user acceptance Test
Lead, Quality Assurance Test Lead and Data Architect/Project Manager who shall
ensure that UAT test entrance criteria have been met.
Exit Criteria for UAT phase
1. UAT testing shall be considered complete upon sign-off and approval of the Production
Support/Release Manager, Project Manager, UAT Test Lead and business owner who
shall ensure that UAT test exit criteria have been met.
2. All required test types have been completed.
TESTING TECHNIQUES
1. White Box Testing
2. Black Box Testing
3. Incremental Testing (Gray Box Testing)
White Box Testing Techniques
White box testing is based on knowledge of the internal logic of an application's code. Tests
are based on coverage of code statements, branches, paths and conditions.
• Statement coverage – execute all statements at least once.
• Decision coverage - execute each decision direction at least once.

[Prepared By: Kamal Subramani] Page 19

 • Condition coverage – execute each decision with all possible outcomes at least once
Black Box Testing Techniques
Black Box Testing is not based on any knowledge of internal design or code. Tests are based
on requirements and functionality
1. Equivalence Partitioning
2. Boundary Analysis
3. Error Guessing
1. Equivalence Partitioning
• It is used to combine same type of test cases related to single functionality / feature /
module.
• A subset of data that is representative of a larger class
• For example, a program which edits credit limits within a given range ($10,000 - $15,000)
would have 3 equivalence classes
 Less than $10,000 (invalid)
 Between $10,000 and $15,000 (valid)
 Greater than $15,000 (invalid)
2. Boundary Value Analysis
 A test data selection technique in which values are chosen to lie along data extremes.
Boundary values include maximum, minimum, just inside/outside boundaries, typical
values, and error values.
 A technique that consists of developing test cases and data that focus on the input
and output boundaries of a given function
 In the same credit limit example, boundary analysis would test:
• Low boundary plus or minus one ($9,999 and $10,001)
• On the boundary ($10,000 and$15,000)
• Upper boundary plus or minus one ($14,999 and 15,001)
3. Error Guessing
• A test design technique where the experience of the tester is used to anticipate what defects
might be present in the component or system under test as a result of errors made, and to
design tests specifically to expose them.
• Based on the theory that test cases can be developed based on experience of the Test
Engineer
• For example, in an example where one of the inputs is the date, a test engineer might try
February 29,2000 or 9/9/99
Incremental Testing
• A disciplined method of testing the interfaces between unit-tested programs as well as
between system components
• Testing where components or systems are integrated and tested one or some at a time, until
all the components or systems are integrated and tested.
• Incremental Testing Types
 Top-down
 Bottom-up
Top-Down
• An integration testing technique that tests the high-level components first using stubs for
lower-level called components that have not yet been integrated and that stimulate the
required actions of those components.
• Begins testing from the top of the module hierarchy and works down to the bottom using
interim stubs to simulate lower interfacing modules or programs
• Stub is a software component that usually minimally simulates the actions of called
components that have not yet been integrated during top-down testing.

[Prepared By: Kamal Subramani] Page 20

Bottom-Up
• An integration testing technique that tests the low-level components first using test drivers
for those components that have not yet been developed to call the low-level components for
test.
• Begins testing from the bottom of the hierarchy and works up to the top Bottom-up testing
requires the development of driver modules which provide the test input, call the module or
program being testing, and display test output
• Driver is a software component or test tool that replaces a component that takes care of the
control and/or the calling of a component or system.
Functional Testing
1. Unit Testing
Test each module (program, function, procedure, method) individually checking code
of units in application is working as expected or not. It is also called Component Testing or
Module Testing.
2. Integration Testing
Once unit testing is conducted the programmer will combine all modules together and
will check the interaction between those modules i.e. communicate between the modules this is
called integration testing. It also called as Component Integration Testing or Interface Testing.
3. System Testing
Validating both functional and non-functional requirements of system is called
system testing.
4. User Acceptance Testing
Once the system testing is done then customer or domain expert will test the
application to conform does the application is good for live environment or not.
5. Alpha testing
It is first level of acceptance testing conducted by domain expert or customer at
developer premises.
6. Beta testing
It is last level of acceptance testing conducted by domain expert or customer at
customer premises to check whether the application is good for live usage.
7. Smoke Testing or Sanitary Testing
It is a group of test cases that establish system is stable and all major functionality is
present and works under “normal” conditions.
8. Regression Testing
It is process of testing to make sure that (changes made in fixing bug should not affect
the other part of the program) Old programming still works well with new changes.
Regression testing is carried out to examine whether the new code works properly and
has not damaged any previously-working functionality
9. Retesting
Retesting is a testing a whether a specified bug has been fixed by the developer or not.
That is testing a particular bug alone to find out whether the bug has been fixed or not
10. End to End Testing
Validating all core functionality of the system right from the beginning till end and its
data integration as well.

[Prepared By: Kamal Subramani] Page 21

11. Mutation Testing
It is a process of wontedly injecting defects by developer to check whether
testers are testing application properly or not.
12. Exhaustive Testing:
Testing functionality with all positive and negative perception is called exhaustive
testing and it is also called as in detail testing.
13. Ad Hoc Testing
Testing the application without following any Pre-planned procedure is called Ad-hoc
testing.
Non-Functional Testing
1. Usability testing
Validating the user friendliness of the system i.e. how easily end user can
understand and use the system.
2. Performance testing
It is a process of checking various efficiency characteristics of the system such as
response time, through put, load transaction per minute, transaction needs, resources
consumption and stress.
3. Compatibility testing
Validating whether the application is compatible with various hardware and
software environments or not.
4. Load testing
Testing an application under heavy loads, such as testing of a web site under a
range of loads to determine at what point the systems response time degrades or fails.
5. Stress testing
Testing conducted to evaluate a system or component at or beyond the limits of
its specified requirements.
6. Security testing
Validating whether all security conditions are properly implemented in the
application or not.
7. Exploratory testing
Exploring the application adding or modifying the existing test cases for better
testing.
8. Authorization Testing
Checking does the application has provision to define login account, setting, and
changing privileges or not.
9. Authentication Testing or Confidentiality Testing
Validating does the sys is able to recognize the register users and providing
right information to the right users or not is called authentication testing.
10. GUI Testing
Checking does the application user inter phase designed professionally or not.
11. Error guessing
With prior experience and knowledge tester will guess the area in application where
there could be an error and tester will test the application with that perception.
12. Recovery Testing
Validating does the sys having a permission of back up ,restore options when you restore
the back up all the data getting backed up or not and also testing the sys how well it is handling
unexpected situations like power failures and sys crashes.

[Prepared By: Kamal Subramani] Page 22

13. Globalization Testing:
Validating does the sys having privatization to change languages. Date and time
format according global requirements.
Test Metrics
INTRODUCTION
Metrics are defined as “standards of measurement” and have long been used in the IT
industry to indicate a method of measuring the effectiveness and efficiency of a particular
activity within a project. Also known as Software quality metrics.
There are several test metrics identified as part of the overall testing activity in order to
track and measure the entire testing process. These test metrics are collected at each phase of
the testing life cycle /SDLC and analyzed and appropriate process improvements are
determined and implemented as a result of these test metrics that are constantly collected and
evaluated as a parallel activity together with testing both for manual and automated testing
irrespective of the type of application.
Complete Metrics data helps in building the “Trustworthy, Capable, Reliable and
Predictable” Product or Application.
PROCESS Related Test Metrics
Defect removal efficiency, Review efficiency, etc., Test Case Efficiency, Test Efficiency,
Test Effectiveness, etc.
PRODUCT Related Test Metrics
Defect Density, Cumulative weighted defect density, Defect Severity index, etc.
Objectives of Test Metrics
This metric indicates the quality of the product under test. It can be used as a basis for
estimating defects to be addressed in the next phase or the next release. This is an Organizational
Measurement.
Test Metrics is a mechanism to know the effectiveness of the testing that can be
measured quantitatively. It is a feedback mechanism to improve the Testing Process that is
followed currently.
When to introduce Test Metrics?
1. Identifying Test Metrics is done at the beginning of the test project.
2. Test Metrics are collected at each phase of the testing.
What are the inputs for Test Metrics?
1. Quantity of test cases prepared / performed.
2. Quantity of Defects found.
3. Size of code developed in KLOC.
Formulae for frequently used Test Metrics
1. Defect Removal Efficiency (DRE) = (E/ E+D) x 100 where
E = Pre-delivery errors (detected during all QC / QA)
activities D= Post –delivery Defects
Objective
Reduce Pre and Post Delivery Defects in all Deliveries. Indicates the efficiency of defect
removal methods, as well as indirect measurement of the quality of the product.
Unit
Average (%)

[Prepared By: Kamal Subramani] Page 23

2. Review efficiency (RE) = (No. of Defects found in Review) x 100 / Total No. of
Defects found before Delivery (both Reviews and Testing)
Objective
Reduce Pre-Delivery Defects.
Unit
Average (%)
3. Defect Density = Defects found/Size in KLOC
Objective
This metric indicates the quality of the product under test. It can be used as a basis
for estimating defects to be addressed in the next phase or the next version. Reduce defect
leakage while coding/design.
Unit
No. of Defects per unit size.
eg: Defects per KLOC
4. Cumulative Weighted Defect Density = No. Of weighted defects (review
issues + testing defects) / Product Size (actual in KLOC)
Here Weighted defects = Major defects + (Minor defects)/3 (Trivial defects)/5
Objective
To know the weightiness of the issues found during review and testing phase.
Unit
No. of Defects per unit size
5. Defect Severity Index = [Sum of (Defect * Severity Level)]/Total number of defects
Here A number is assigned against each severity level: 4 (Critical), 3 (Major), 2 (Medium),
1 (Minor)
Objective
Provides a direct measurement of the quality of the product—specifically, reliability,
fault tolerance and stability.
Unit
No unit only a real number
6. Test Case Efficiency = (Number of defects detected / Number of test
cases run)* 100 Objective
To know the efficiency of the test cases that are being executed in the testing phase.
The quality of the test cases can be determined.
Unit
Average (%)
Test Efficiency & Test Effectiveness:
These are two vital metrics, which always come to my mind, when I think about
metrics.
Let us talk about the meaning of efficiency, most of the definitions state efficiency as the
percentage of ratio of output to input of any system using unit measures (delivered
/supplied). But I agree to the following definition.
Noun
The ratio of the effective or useful output to the total input in any system
Therefore, efficiency is an attribute which means to maximize the useful output for a
given input reducing wastage or losses. Efficiency cannot be more than a 100%, in a sense
that a 100% efficient system will have zero losses
7. Test Efficiency (TE)

[Prepared By: Kamal Subramani] Page 24

 A Consultant as part of any engagement would want to deliver, the solution on time,
within budget, on specs, having an acceptable level of quality, quantified by the customer.
To achieve this goal, the team should work with efficiency, which is to constantly show
progress to the effort put in. Test efficiency is a quality attribute of the test team, to carry
out all testing activities in an efficient manner saving cost and time. To mention few of test
efficiency focus areas,
1. Resources
2. Tools
3. People
4. Process
5. Time
Let us look at the broader picture of the metric, test efficiency is not only about test
execution alone, but all or most of test activities, like test planning, comprehension, test
cases creation, review, execution, defect tracking and closure. TE is not just one single
derivation but a number of calculations at each phase and activity of testing. What activities
or phases one is interested in, what is particularly measured, depends on lot of other things,
the type of project, complexity, availability of resources, the situation, customer
requirement etc.
8. Test Effectiveness:
Test effectiveness (TEF) can be calculated for specific set of test activities. For e.g.:
Test preparation efficiency will be the time taken for ‘X’ number of test cases to be
prepared, reviewed and reworked to finalize them. There is a catch here, the quality
standards of the test cases should be predefined by using defining standards, as I have tried
to state a few of them here.
1. The Test cases are complete with respect to Use Cases on which they are based.
2. A tester should be able to execute this test case using only this test case and any directly
referenced items given the proper software and hardware configuration.
3. Test data must be specific. For example, don’t say “select any menu option to navigate out
of current page.” Say “Click the Back button.” Don’t leave any test data to the imagination of
the tester.
4. Usually, each test step should contain a single action. E.g. “Save” and “Search”
functionalities should be split into 2 steps
5. Test Case names follow the agreed upon naming convention
6. No grammatical mistakes
Let us assume that there are two test teams with equal number of resources with
comparable skill set, functional expertise etc. working on the same product, and If test team
‘A’ has prepared 400 Test cases with agreed quality, for the product in 5 days and for the
same product if test team ‘B’ prepares 400 Test cases in 4 days, then which team can we say
is efficient? Definitely team B is efficient, but there is no guarantee that Test team ‘B’ is
effective, we are not sure how many defects can team ‘B’ uncover as compared to team ‘A’.
That is our next top.
Test Effectiveness (TEF) Efficacy in contrast to efficiency is focused to just produce
the desired result or effect or achievement as such and not the resources or time spent.
Noun Effectiveness means the capability of producing an effect.
Let us look at what Test effectiveness is, Test effectiveness of a technique or a system
or a team is the ability to find defects and isolate them, from a product or deliverable. Test

[Prepared By: Kamal Subramani] Page 25

effectiveness is to ensure quality and close the two quality gaps, namely producer’s quality
gap and customer’s quality gap. As definition of quality goes, quality is both process and
product quality which is meeting customer requirements and conformance to product
specification. These metrics should be quantified, as they closely relate to quality, and for
many people the term quality is relative.
Defect originated/Injected
Defect found in
phase Requirement Design UT IT ST Total
Requirement 2 2
Design 3 12 15
UT 2 1 22 25
IT 1 2 4 15 22
ST 1 2 2 2 6 13
Production 1 1 1 2 3 8
Total 10 18 29 19 9 83
The table shows the defect origin, on the X-axis, where a defect was injected, where
he belongs to? And on the Y-axis, where the defect was detected.
Let us calculate the test effectiveness of the Integration testing activity
Total number of defects of all origin found during Integration testing activity = 22
Total number of defects existing while entering in IT = (10+18+29) – (2+15+25) = 15
Total number of defects injected in the current stage = 19
Effectiveness of IT test phase = Total defects found in this phase/ (No of defects existing +
injected)
Effectiveness = 22/ (15+19) * 100 = 64.70%
Things to Remember
1. Keep Test Metrics Simple
2. Create Meaningful Metrics
3. Use Metrics to Manage the Project
4. Track Metrics
Conclusion
It is not enough to have a set of metrics that are tracked on a regular basis. The
metrics must also be reviewed and analyzed regularly, as they can provide value feedback
during and after a software development project.
Acronym
DRE - Defect Removal Efficiency
IT - Integration Testing
KLOC - Kilo Lines of Code
QC - Quality Control
QA - Quality Assurance
RE - Review Efficiency
SDLC - Software Development Life Cycle
ST - System Testing
TE - Test Efficiency
TEF - Test Effectiveness
UT - Unit Testing

[Prepared By: Kamal Subramani] Page 26

 TESTING MODELS
1. WATER FALL MODEL

The Waterfall Model was first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed fully before the next phase can begin. This type of
model is basically used for the project which is small and there are no uncertain
requirements. At the end of each phase, a review takes place to determine if the project is on
the right path and whether or not to continue or discard the project. In this model the
testing starts only after the development is complete. In waterfall model phases do not
overlap.
ADVANTAGES
 This model is simple and easy to understand and use.
 It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 In this model phases are processed and completed one at a time. Phases do not
overlap.
 Waterfall model works well for smaller projects where requirements are very
well understood.
DISADVANTAGES
 Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.

[Prepared By: Kamal Subramani] Page 27

  Not suitable for the projects where requirements are at a moderate to high risk of
changing.
When to use the waterfall model
 This model is used only when the requirements are very well known, clear and
fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.
Very less customer enter action is involved during the development of the product.
Once the product is ready then only it can be demoed to the end users. Once the product is
developed and if any failure occurs then the cost of fixing such issues are very high, because
we need to update everywhere from document till the logic.
2. MODIFIED WATER MODEL

• Systematic & Sequential approach model.

• Similar to WATERFALL model.
• Development always in forward direction.
• Major difference is flexible when compare to pure WATERFALL model, Request for
change in requirements at any stage
• It allows to go back to any phase as required and continue the process.
[Prepared By: Kamal Subramani] Page 28
ADVANTAGES
 Useful for the projects where requirement are well known and stable.
DISADVANTAGES
 Comparing to waterfall model, this is not a simple approach
3. V-MODEL

[Prepared By: Kamal Subramani] Page 29

 The V-Model (or VEE model) is a systems development model designed to simplify the
understanding of the complexity associated with developing systems.
The V-Model demonstrates the relationships between each phase of the development
life cycle and its associated phase of testing.
“V” stands for Verification & Validation
ADVANTAGES
• Simple and easy to use.
• Testing activities like planning, test designing happens well before coding. This
saves a lot of time. Hence higher chance of success over the waterfall model.
• Proactive defect tracking – that is defects are found at early stage.
• Avoids the downward flow of the defects.
• Works well for small projects where requirements are easily understood.
DISADVANTAGES
• Very rigid and least flexible.
• Software is developed during the implementation phase, so no early prototypes of
the software are produced.
• If any changes happen in midway, then the test documents along with requirement
documents has to be updated.
WHEN TO USE THE V-MODEL
• The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
• The V-Shaped model should be chosen when ample technical resources are available
with needed technical expertise.
• High confidence of customer is required for choosing the V-Shaped model approach.
Since, no prototypes are produced, there is a very high risk involved in meeting
customer expectations.

AGILE METHODOLOGIES (SCRUM METHODOLOGIES)

In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players
engaged with each other to get a job done.
Everything depends on VELOCITY & TIME
D=VxT
D – Done Feature
V – Resource Capacity
T – Time Line
Timeline will be in weeks not more than 3weeks
Duration of each work is called as SPRINT

[Prepared By: Kamal Subramani] Page 30

SECTION 1
SPRINT PLANNING
• Attendances – Scrum Master, Scrum Developer, Product Owner
Product Owner: In Scrum, the Product Owner is responsible for
communicating the vision of the product to the development team.
Scrum Master: The Scrum Master acts as a liaison between the Product
Owner and the team. The Scrum Master does not manage the team. Instead, he
or she works to remove any impediments that are obstructing the team from
achieving its sprint goals.
Scrum Developers: In the Scrum methodology, the team is responsible
for completing the work.
• Discuss on Product backlogs:
• Output of this meeting is finalized the Product Backlogs document for this
Current Sprint

[Prepared By: Kamal Subramani] Page 31

SECTION 2
SPRINT COMMITMENT
• Analyzing the User Stories / Requirement
 What to do
 How to do
 Who to do
 When to do
• Scrum Master, Scrum Developer and BA will give the commitment to
Product Owner
• Scrum commitment will be based on Resources
• Scrum Developers (Dev Team & Testing Team)
SECTION 3
SPRINT EXECUTION
• Testing Team
• Test Scenario Preparation
• Test Case Preparation
• Test Case Review
• Test Case Execution
• Daily Standup Meetings
• Duration 15mins
• Scrum master will lead this
• Task should be boarded on Scrum Board
• What have you done – Yesterday / Today
• What are you going to work – Today / Tomorrow
• Obstacles
• Every Scrum Developers has to answer the above questions
SECTION 4
SPRINT REVIEW MEETING
• What we have done on Current Sprint
• `Scrum Master, Scrum Developers will demonstrate the product to Product
Owner
• Product Review
SECTION 5
SPRINT RETROSPECTIVE
• The team discusses the just-concluded sprint and determines what could be
changed that might make the next sprint more productive.
• What went well during the sprint cycle? – KEEP DOING
• What could we do differently to improve? – START DOING
• What went wrong during the sprint cycle? – STOP DOING
• Key elements of the sprint retrospective:
• Process improvements are made at the end of every sprint.
This ensures that the project team is always improving the way
it works.

[Prepared By: Kamal Subramani] Page 32

 • The retrospective is a collaborative process among all
members, including the team, the product owner, and the
ScrumMaster.
• All team members identify what went well and what could be
improved.
• The team members discuss the process that they are following
and give any suggestions for improvement.
• The team members discuss any other ideas that could improve
their productivity.
• The ScrumMaster prioritizes actions and lessons learned based
on team direction.
• The retrospective supports team formation and bonding,
particularly as any areas of conflict can be identified and dealt
with.
• The retrospective helps build the team's sense of ownership and
its self-management.
• Process Review
SCRUM BOARD

[Prepared By: Kamal Subramani] Page 33

 Windows Azure Active
Directory User Maintenance
Services

Version Control
Version Date Description of Change Author
0.1 21st May 2015 Initial version Shivanandini Kuncham
0.2 25th May 2015 Updated with review Shivanandini Kuncham
comments
0.3 11th June 2015 Added requestorID in the input Shivanandini Kuncham
request message fields
0.4 29th June 2015 Till date updates added in Shivanandini Kuncham
orange

Create User Service

“Create User”
Request

User already
No
Existing

Yes

Create new
AAD user
Is exact Yes
Match

Configure user to
the user groups
Return user No provided in the
objectId to calling request
application
Return message
that found partial
match and
respond with the Return user object
same provide to calling
details masked application

Reply back to calling application

accordingly

Steps: Search if there is any existing user with the same UserPrincipalName
1. If user exists & if it is exact match (Match with display name, mobile, otherMails) then assign that
user with the new group and respond with the user objectID + message that you linked to
existing user as you found exact match.

[Prepared By: Kamal Subramani] Page 34

 a. Do not link disabled user (accountEnabled = false) associated with some groups. In case
disabled user without any groups then enable it, link it and add basic license if not
associated with one already.
b. otherMails is collection of emails. In case one email address matches it should be considered
as exact match
c. In case requested group does not exist throw error back to calling application.
d. If user already associated with the group convey the same in the response
e. On the response back to caller reply with displayname, objectID, masked Mobile &
otherMails and all groups user is associated with
2. If user exists & If it is NOT exact match (Case when one or more of these properties not matching -
display name, full phone number/mobile, primary email address) then respond back with the
partial match user displayname, objectID, masked mobile & otherMails ( eg.,
******6538, s*********@yahoo.com). Also provide details of all the groups partial match users are
associated with.
3. If user does not exist -
a. Create a new user with the details provided in the input request
b. Assign user to the groups requested. If groupID does not exist send error response
c. Assign basic license -- Refer Appendix B section below
d. Enable MFA by default, unless value provided in input request to override. – Not as part of first
release. Part of JIRA EAI-2087
e. Set password to value passed in input. If empty from source use a random value generated
within ES for the same (send the same in response too). (Need to comply with the password
policy in AAD)
4. One user create request for a partner use
Update User Service (for both user details and user name)

“Update
User”
Request

User objectID
No
exists

Yes
Give error
response back
to caller Is update request
on unique No
mandatory fields

Yes

Any existing
Update as
duplicate value for No
required
requested data

Yes

Give error
response back
to caller

Reply back to calling application

accordingly

Steps:
1. If objectID does not exist respond with error to the calling application

[Prepared By: Kamal Subramani] Page 35

 2. In case requested update is for UserPrincipalName, display user then check if the requested value
is already associated with another user, if not then only update otherwise respond back with error
to calling application.
3. For updates to any other field update accordingly
4. One update user request per partner user
5. As per new input structure XSD adding users to group is only possible through add user to
group service and not through update user service.
Add User to Group Service
“Add User to
group”
Request

Group & User

exists

Yes

Add user to the

group.
No

No

Reply back with

success or failures
(if any) to caller

Steps:

1. If user or group do not exist, then reply with error to calling application. In case of user do not
exist check for group too and provide consolidated response
2. If user & group exists, add user to the group. Repeat for all the groups mentioned in the request (if
any). Respond back with success message
3. One request per partner user but can be with multiple groups
Remove User from a Group Service
“Remove
User from a
group”
Request

User exists

Yes

Remove user from

the group.
No

No

Reply back with

success or failures
(if any) to caller

Steps:

1. If user do not exist, then reply with error to calling application

2. If user exists, remove user from the group mentioned. Repeat for all the groups mentioned in the
request (if any). In case one or many of the groups do not exist remove from the groups which exist
and reply back indicating the same

[Prepared By: Kamal Subramani] Page 36

 3. After removing user from group if the user is left with no groups then disable the user (accountEnabled
= false)
4. One request per partner user but can be with multiple group

SOFTWARE REQUIREMENTS SPECIFICATION SAMPLE

DOCUMENT

OrangeHRM – My Info Module

Live Project
Project Functional Requirement Specification ,
Version 1

This is a sample SRS document for the live project training. Please read this
document and use it as a reference for our live software testing project

[Prepared By: Kamal Subramani] Page 37

1. Purpose of the document:
This is not a project plan. It is a guide for system architecture and development, not for phasing,
timelines or deliverables.
This document is divided into three sections:
• Project Overview
• Information Architecture
• Site Design
2. Project Overview:
2.1 Audience:
This document is intended as a complete guide for ESS-User in using OrangeHRM 3.0. This document is
specially designed for non- specialists; specialists may find the document a useful point of reference. By
reading this guide, you will learn how to use OrangeHRM through the elements of the graphical user
interface and what's behind some of the advanced features that are not always obvious at first sight. It
will hopefully guide you around some common problems that frequently appear for users of
OrangeHRM.
2.2 Hardware and Hosting:
OrangeHRM’s servers will be hosted at X company’s site.
OrangeHRM will be hosted on two servers: One to host the actual website and (language)code, and the
other to host the (database name)database.
3. Information Architecture
Log in to the OrangeHRM System using your ESS-User account that has been created by the HR
Admin

[Prepared By: Kamal Subramani] Page 38

3.1 My info Module
My Info Module is a powerful tool providing employees of the company with the ability to view
relevant information such as personal information and updating personal information with an
internet enabled PC without having to involve the HR department.
The functionality of this module spans through the entire system, making information available
anywhere, anytime. All information is subject to company’s defined security policy, where
he/she can only view the information he/she is authorized to. An ESS-User can only edit certain
fields in the ESS Module, maintaining the security and confidentiality of employee information
3.1.1 My Info Module
When an ESS-User logs into the system for the first time, the first thing they will see is the
“Personal Details” screen as shown in Figure 1.1. They are able to edit and enter certain fields.

The following are restricted fields where an ESS-User cannot make changes to the following
details and need to be populated by the HR Admin and the respective ESS-Supervisor.
Personal Details

 Employee ID
 SSN No
 SIN No
 Driver License No
 Date of Birth

[Prepared By: Kamal Subramani] Page 39

3.1.2 Photograph
The ESS-User can add a photograph of himself/herself by clicking on the photograph at corner
of the screen and the screen as shown in Figure 1.2 will appear.

Click “Browse” and then select a photograph from the relevant path. Click “Upload” once you
have selected the picture .The picture selected will be populated on the photograph section.
*Note: You may only upload a maximum size of 1 Megabyte in jpg, png, gif format.
3.1.3 Contact Details
Contact information can be entered from here. Click on “Contact Details” under the Employee
Details column and the screen as shown in Figure 1.3 will appear.

[Prepared By: Kamal Subramani] Page 40

Click “Edit” to enter the information.
You can edit the following:
Country– Select the country from the drop down
Street 1
Street 2
City/Town
State/Province– If the country is United Sates you can select from the drop down or you need to
enter it manually
ZIP Code
Home Telephone
Mobile
Work Telephone
Work Email
Other Email
Once you have completed this form click “Save”.
3.1.4 Emergency Contact
Contact details which will be needed during an emergency can be entered here. Select
“Emergency Contacts” on the “Personal” column and the screen as shown in Figure 1.4 will
appear.

Enter the “Name” of the person you wish the company to contact in case of emergency, your “Relationship”
with the contact person provided and a “Home Telephone” or “Mobile Number” the company can reach
him/her.
Click “Save” once the fields are added, the emergency contact will be listed as shown in Figure 1.5.

[Prepared By: Kamal Subramani] Page 41

You may add multiple entries of emergency contacts.
To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
You may also upload any attachment that would support the details you have entered on the form by
clicking “Add” under the “Attachment” and selecting a file from a relevant path and upload the
following file by clicking “Upload”.
3.1.5 Dependants
If you have any dependents you can enter them here. To add a dependent, click on “Dependents”
under the “Personal” column and the screen as shown in Figure 1.6 will appear.

Enter the “Name” of your dependent, the “Relationship” of the dependent to you and his/her “Date of Birth”.
Click “Save” once you have entered the following fields and your dependent will be listed as
shown in Figure 1.7.

You may add multiple entries of dependants.

To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.

[Prepared By: Kamal Subramani] Page 42

You may also upload any attachment that would support the details you have entered on the form
by clicking “Add” under the “Attachment” and selecting a file from a relevant path and uploading
the following file by clicking “Upload”.
3.1.6 Immigration
Your immigration information can be entered here. To add your immigration information, select
“Immigration” under the “Personal “column and the screen as shown in Figure 1.8 will appear.

Select the document type (Passport or Visa) you wish to add details of, the “Number” whether it
is a passport number or a visa number, the “ Issued Date” , “Expiry Date”, the “Eligible Status” of
your Passport/Visa and the “Eligible Review Date” as to when the eligibility status was reviewed.
You may write a comment if necessary.

Click “Save” once the fields are added and the following immigration documents will be listed as
shown in Figure 1.9.

[Prepared By: Kamal Subramani] Page 43

You may add multiple entries of immigration documents.
To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
You may also upload any attachment that would support the details you have entered on the
form by clicking “Add” under the “Attachment” and selecting a file from a relevant path and
uploading the following file by clicking “Upload”.
3.1.7 Job
The ESS-User cannot make changes in the job details. You are only able to view your job details
that have been pre-defined by the administrator as shown in Figure 2.0. You are restricted from
editing the following fields:
●Job Title
●Jobs Specification
●Employment Status
●Job Category
●Joined Date
●Sub Unit
●Location
●Employment Contract Start Date
●Employment Contract End Date
●Attachments

[Prepared By: Kamal Subramani] Page 44

3.1.8 Salary
The salary information field is completely hidden from the ESS-User as shown in Figure 2.1. Only the HR
Admin has access to this information and has to be manually communicated to the ESS-User. You are
restricted from editing the following fields:
Salary
●Salary Component
●Pay Frequency
●Currency
●Amount
●Comments
●Direct Deposit Details
●Attachments

3.1.9 Report To
As an ESS-User, you are only able to view the list of supervisors that you report to and if you are an
ESS-Supervisor as well, you will see the list of your subordinates as shown in Figure 2.2.
You are restricted from editing the following fields:
●Assigned Supervisors
●Assigned Subordinates
●Attachments

3.1.10 Qualifications
● Work Experience
Your previous work experiences can be entered here. To enter previous work experiences, click “Add” under
“Work Experience” and the screen as shown in Figure 2.3 will appear.

[Prepared By: Kamal Subramani] Page 45

Click “Save” once all the fields are entered and the particular work experience will be listed as
shown in Figure 2.4.

You may enter multiple entries of work experience.

To delete an entry, click on the check box next to a particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
● Education
You are able to enter details of your education here. To enter education details, click “Add”
under “Education” and the screen as shown in Figure 2.5 will appear.

[Prepared By: Kamal Subramani] Page 46

Click “Save” once all the fields are entered and the particular education details will be listed as
shown in Figure 2.6.

You may enter multiple entries of education.

To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
● Skills
If you have any special talents or skills they can be entered here. To enter skills, click “Add”
under “Skills” and the screen as shown in Figure 2.7 will appear.
[Prepared By: Kamal Subramani] Page 47
Click “Save” once all the fields are entered and the particular skill will be listed as shown in Figure 2.8.

You may enter multiple entries of skills.

To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
● Languages
You can enter the various languages that you are competent in, with the level of competency. To
enter your language of competency, click “Add” under “Language” and the screen as shown in
Figure 2.9 will appear.

[Prepared By: Kamal Subramani] Page 48

Click “Save” once all the fields are entered and the particular language of competency will be
listed as shown in Figure 3.0.

You may enter multiple entries of languages.

To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
● License
Here you can enter the licenses that you may have. To enter licenses, click “Add” under “License”
and the screen as shown in Figure 3.1 will appear.

[Prepared By: Kamal Subramani] Page 49

Click “Save” once all the fields are entered and the particular license will be listed as shown in Figure 3.2

You may enter multiple entries of licenses.

To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
●Attachments
Any supporting documents regarding your qualification that you think is needed by the management can be
attached here. Please note that each document cannot exceed 1 megabyte, but you can attach more than on
document. To add an attachment, click “Add” under attachment and the screen as shown in Figure 3.3 will
appear.

Click “Browse” and select the file from the relevant path and click “Upload” to upload it.

[Prepared By: Kamal Subramani] Page 50