You are on page 1of 19

SOFTWARE TESTING

Test Engineer Responsibility

Understanding requirements & functional specifications.


Identifying test scenario.
Writing & Executing Test cases.
Log Test results (test cases pass or fail).
Defect Reporting and Tracking & Fixing Defects.

Test Manager Responsibility

Creating Test Plan


Review

Quality

Quality is fitness for use / Conformance to agreed functional & non functional requirements.
Customers believe that the product meet their needs and expectations.

Continuous Improvement for Quality (PDCA)

Plan: Define the goal and the plan for achieving that goal.
Do/Execute: Depending on the plan strategy decided during the plan stage we do execution accordingly in this
phase.
Check: Check/Test to ensure that we are moving according to plan and are getting the desired results.
Act: During the check cycle, if any issues are there, then take appropriate action accordingly and revise our plan
again.

Customers View Of Quality (People/Stake Holder)

Delivering the right product.


Satisfying customers needs.
Meeting customer expectations.

Treating customers with integrity, courtesy &


respect.
Suppliers View Of Quality ( Organization)
Doing the right things (no waste, rework)
Doing it right way (Standards)
Doing it right the first time
Doing it on time.

User gap (customer) Failure seen by customer interms of difference between user needs and product specifications.
Producer gap (developer) its due to process failure at developer site .need to take improvement plans.
Financial Aspects of quality
Sales price = Cost of manufacturing + cost of quality + profit
Cost of manufacturing - Cost required for developing right product at first time.
Cost of quality - Improving or maintaining quality of a product. Cost incurred like cost of prevention (following process,
standards guidelines), cost of appraisal (cost for reviews and testing) and cost of failure (finding defect any stage of
development).
Bench marking
Software development models (Types of SDLC Models)

Waterfall Model (Classic Life Cycle Model / Linear Sequential Model)


Spiral Model.
Prototype Model.
Rapid Application development Model (RAD).
Iterative and Incremental development Model
Agile Model.

Waterfall Model (Classic Life Cycle Model / Linear Sequential Model)


1) Systematic and sequential approach (all the activities will be carried out sequential manner).
2) Output of each phase will be given as input as next phase.
3) Suitable for Project where requirements are clearly defined & small and medium term duration
Spiral Model

Spiral development process assumes that customer requirements are obtained in multiple iterations and
development also works in multiple iterations.
First some functionality is added and, then product is created and released to customer. After getting benefit of
first iteration of implementation, the customer may add another chunk of requirements to the existing systems.
In spiral model, software is developed in a series of incremental releases . Each spiral consists of a
deliverable product.
Customer can start using the system after every spiral .Each spiral consists of waterfall model.

Prototype model

Identify - It identifies the basic requirement.


Initial prototype A prototype is developed based on the initial understanding of the customer requirements.
The initial prototype dev eloped consists of the use r interface s only.
Review - The customers, including end-users, examine the prototype and prototype feedback on additions
or changes.
Revise and Enhance the prototype Using the feedback both the specifications and the prototype can be
improved .
A visible working prototype helps customer to define the requirements

Advantages

It can be used when customer is not sure about what he wants.


It is a faster way of finalizing t he requirements

Rapid Application development Model (RAD)

RAD enables creation of fully functional software with in a very short time.
If the requirements are well defined and understood, and the project scope is constraint , the RAD process
enable s a development team to create a fully functional system within a very short time period.

Iterative and Incremental development Model

Iterative models assume that changes come from any phases to any previous phases.Changes may have
cascading effect where one change may initiate a chain reaction of changes.
Incremental development models are used for developing huge systems.
These systems made up of several sub systems. Incremental model is considered as collection of sub systems.
It gives flexibility to customers .one system may be created and customer may start using it .the customer can
earn the lessons and use them in second part of the systems is developed.
In an incremental development, the system is developed in different stages, with each stage consisting of
requirements, design, development , and test phases; in each stage a new functionality is added.

Agile Model

Agile gives complete freedom to use to add requirements at any stage of developments.
Agile gives complete adaptability to user environment and continuous integration of a product .
In Agile Model project is divided in to various sprints. Each sprint contains High-Priority Requirements.
The time period for sprint is typically 2-4 weeks.
In an Agile mode l, daily screen meetings with team to share status and potential issues.
Each sprint is released to customers. Used for critical applications.

Guidelines it is suggested way of doing things.


Standards it is mandatory ways of doing things.
Audit independent assessment of products.

Process Related To Software Quality


Vision - What the organization wishes to achieve in given time.
Mission - Missions are expected to achieve over all vision.
Policy - Policy statement talks about way of doing business defined by senior management.
Goal Goals defines the mile stones to be achieved.
Objective - Expectation from each mission and can be used to measure the success/failure.
Strategy - Defines way of achieving a particular mission.
Test Strategy - It is a part of test plan describing how testing is carried out for the project and what testing types needs to be
performed on the application.

Values values can be defined as principles. And treating customers with courtesy.

Big Bang Approach (System Testing / Final Testing)


This testing is last part of software development, ensuring that requirements are defined and documented in requirement
specifications and design specifications are met successfully.

Software Application Is Basically Categorize In - Two Types As Projects & Products


Projects - If a software application is developed for a specific customer requirement then it is called a project.
Products - If a software application developed for multiple customer requirements then it is called a product .
Errors - Any incorrect human action that produces a problem in the system is caller error.
Defect - Deviation between expected behaviors to actual behavior of the system is called defect.(Customer
Dissatisfaction)
Failure - The deviation identified by end-user while using a system is called a failure.
Mistake - an issue identified while reviewing own documents.

Testing - it is a process of verifying are we developing the right product or not and also validating does the developed
product is right or not.
Defined as execution of work product with intent to find a defect. Also detect the differences from Expected Results and
Actual Results.
Software testing = Verification + Validation
Verification- It is a process of verifying: Are we developing the right product or not. Known as static testing. It involves
reviews ,walk through, inspection, audits.
Validation - It is a process of validating: Does the developed product is right or not. Also called as dynamic testing. It
involves system testing, user interface testing, stress testing.

Positive Testing (traditional approach) - Testing conducted on the application in a


positive approach to determine what system is supposed to do is called a positive testing.

Easy to write test cases.


Goal Shows system working. Success System Working
Negative Testing (Better approach) - Testing conducted on the application in a positive
approach to determine what system is Not supposed to do is called a negative testing.

Difficult to write test cases.


Goal find faults. Success Finding System faults

Why does software have defects?

Incorrect requirements

Wrong design
Poor coding

Complex business logic &


technology
Work pressure
Frequently changing
requirements.
Most Common Defects

Incorrect functionality
Incorrect data edits
Poor performance
Poor security
Incompatibility & Poor User
interface
Poor usability

Software Testing Techniques:

Static Testing
White Box Testing
Black Box Testing
Grey Box Testing.

White box Testing (Glass box, Structural, Clear box testing)


Testing conducted on the source code by developers to check does the source code is working as expected or not is
called white box testing.
Need of white box testing

As the source code is visible, finding and rectifying the problems is easy for developers.
The defects that are identified in white box testing are very economical to resolve.
To reduce the defects as early as possible white box testing is helpful.
To ensure 100% code coverage.

Black box Testing (Dynamic Testing) Testing is conducted on the application by test engineers or by domain experts to
check whether the application is working according to customer requirements.

Levels of Dynamic Testing - Component/ Unit Integration System Acceptance


Need of Black Box Testing

White box testing conducted by developer in a technical perception where as black box testing is conducted by
test engineers with end-user perception.
Programmers will conduct white box testing in a positive perception whereas tester will conduct black box testing
with a negative perception where there is a more chance of finding more defects
White box testing will not cover non functional areas. As functional requirements are also very important for
production system those are covered in black box testing.
The objective of white box testing is 100% coverage whereas the objective of black box testing is 100% customer
business requirement coverage.
Black Box Testing = System Testing + User Accepting Testing which is called as requirement Based Testing (or)
Specification Based Testing.

Gray box Testing it is a combinations of black and white box testing. This combines verification technique with validation
techniques.
Successful / Good Tester - The tester who find more no of defects are considered as good tester
Successful / Good Test case The test case which finds more no of defects before going to customer.

Test scenario which address the testing needs and identifies the areas to be tested.
Work bench It comprises some procedures defined for doing work and some procedure defined to check outcome.
Test policy which is defined by senior management covering all aspect of testing. It decides frame work of testing and
overall mission of achieving customer satisfaction.
Test Strategy / Approach which defines what steps are required to perform effective testing. how the test environment
will be created, what testing tool will be used for testing defect capturing and defect reporting .
Test plan (by test manager ) Test plan should contain test objectives and test methods applied for defining test
scenario, test cases and test data. Test plan tries to answer for 6 questions like when, what, where, why, which & how.
Test Objective which measures the effectiveness and efficiency of testing process. Defines what testing, will be
targeting to achieve. Some of the objectives like code coverage, requirement coverage.

Risk
Risk Potential loss to user /organization of software when a problematic Situation occurs. (Unplanned Event Occurs).
Product Risk Potential failure area in the software systems.

Reasons of Risk Facing

Improper use of technology


Repetition of errors again and again
Inability to transfer the user requirements in to technical requirements.
Incorrect data entry
In effective security design.

Measurement of Risk
Probability of risk Indicating that number ranging from 0% to 100% probability of happening of risk.
Impact of risk Impact of the must be measured in terms of loss to the organization.
High Risk - if probability and impact both are high.
Medium Risk - if probability and impact both are Medium.
Low Risk - if probability and impact both are low.
Severity - Important of defect with respect to functional point of view i.e. how critical is defect with respective to the
application.
Priority - It indicates the importance or urgency of fixing a defect.
Risk Formula (RPN / RIN) = Probability of Risk Occur X Impact or loss X Inability of detection
RPN Risk Prioritization Number

RIN- Risk Identification Number

Testing Types

Early Testing - Conducting testing as soon as possible in development life cycle to find defects at early stages is called
early testing. Early testing is helpful to reduce the cost of fixing defects.
Mutation Testing - This is used to check the capability of test program and test cases to find defects.
Risk Based Testing identifying operations which most likely can cause to failure, these testing these functionalities as
priority based.

Skills Needed for Tester

Knowledge about the Testing concepts & levels .


Understanding of Verification / validation.
Writing of efficient test cases.
Knowledge for choosing tools.
Knowledge about testing standards.
Defining and execution of test plan.

Methods of verification

Self Review its a self check before giving work product. (not referred as official review)
Peer Review author and peer (Tester /Developer) involved.(Informal review).
Walkthrough large team involved along with the author (Semi formal review)
Inspection External people [subject expert] involved (Formal Review)
Audits audits conducted by auditors [may not be subject experts] (formal review)

Coverage in verification

Statement Coverage may concentrate important part of coding (Lines)


Path Coverage Sequence of control flow from entry to exit in a given code.
Decision Coverage - There may be two decisions (for, do-while or ECP, BVA)

Coverage in Verification

Requirement Coverage Passing / Failure of such test cases can define whether the requirements have been
achieved or Not.
Functionality Coverage Requirements are expressed in terms of functionality required for the application to work
successfully.
Feature Coverage - Features are group of Functionalities.

Acceptance Testing
Acceptance testing done by user to understand whether the software satisfies the requirements or not (whether fit for use)
Three Levels of Acceptance

Alpha Testing: Testing a software product or system conducted at the developer's site. Usually it is performed by the
end user.
Beta Testing: Testing a software product or system conducted at the Customers site. Usually it is performed by the
end user.
Gamma Testing (When its ready for release)- Testing done by product development organization to understand
customer reaction to enhanced / new product. The application given to few people for using it production,
environment, and feed back is obtained from them.

V and VV model
V Model Validation Model or Test Model

Requirement Phase there is system and acceptance testing


Design phase - there is Interface testing
Program Level - there is integration Testing
Coding level validate individual coding (Units)

VV Model Verification and Validation Model


VV model talks about verification and validation activities associated with each phases of SDLC.

Requirement verification and Requirement validation


Design verification and Design validation
Coding verification and Coding validation

DEFECT
Defect

Deviation between expected behaviors to actual behavior of the system is called defect.
This does not meet customer requirements.
Customer Dissatisfaction & Not fitness for use.

Root cause of defect

Requirement no clearly defined.


Wrong design.
Lack of training in product developing.

Fish bone diagram Technique for route cause of defect.


Defect Report Template(Attributes)

Defect name
Defect Id
Defect Name
Project Name
Module Name
Phase Introduced

Phase found
Defect Type (functional / security /user
interface defects)
Severity
Priority.

Defect Life Cycle


New Open Fixed Fix Verified Closed
Defect fixing (Activities)

Identify Risks
Estimate the Probability of impact
Minimize the impact by corrections.

SOFTWARE CONFIGURATION MANAGEMENT


Software Configuration Management (SCM)
The process of identifying, organizing and controlling changes to the software during the development and
maintenance phase. A methodology t o control and manage a software development project.

Configurable item (Artifacts) Some items created during life cycle and undergo change and one needs to control and
track the changes. (Req.Specifications, Design Documents, Test Cases)
Non Configurable item (Artifacts) Some items may or may not change during life cycle and no needs to control and
no needs to track the changes.(Test results, Minutes of meeting)
SCM Needs:

Multiple people have to work on software that is changing.


A project delivering several releases (Builds)
Software must run on different machines and operating systems

Sample list of Software configuration items:

Management plans ( Project Plan, Test Plan , etc.,)


Specification (Requirements, Design, Test cases, et c., )
Customer documentation (Implementation , Manuals, User Manuals, Online help files)
Source code( Java, .Net, PHP, VB, etc.,)
Executable code (exes)
Libraries (Package s, %includes. files, APIS, DLLS, etc.)
Data bases (Data being processed, test data, etc.)
Production documentation.

Problems resulting from poor Configuration Management :

Cant roll back to previous subsystem


One changed overwrites a not her
Which code change belongs to which version.
Faults which were fixed Re-appear.
Test worked perfectly on old versions.

Major Activities:

Configuration planning & Step


Configuration identification
Configuration baseline
Change Management
Configuration release control
Configuration Audit
Control of customer property.

Configuration Management Cycle

Creation of Draft. The artifacts created for the first time or updated from baseline.
Review of draft. The created artifacts will be reviewed by all stake holders and may give comments/suggestions.
Rework if necessary, based on review comments rework will be done.
Baseline (Finalized comments) Closure of comments, when all review comments are closed, and then the
artifacts will be called as baselined.
Versioning Based on the comments closed the version number will be assigned.

Versioning Methods
Identify the different version of the same document.
Two common versioning methods, XX.YY.ZZ and XX.YY
XX.YY.ZZ

XX Major Change.

YY Minor Change.
ZZDraft Version (when an artifact undergo the draft creation, Review, updation)

Example : 00.00.01

(01 review comments and draft versions are keep on changing.)

01 once review comments are closed then change the XX as 01 , if ZZ is 00 Review comments are baselined )

XX.YY
XX Major/Minor Change
YY Draft Version (when an artifact undergo the draft creation, Review, updation)
Example : 00.01

(01 review comments and draft versions are keep on changing.)

01.00
(01 once review comments are closed then change the XX as 01 , if YY is 00 Review comments are
baselined )
Configuration Management Tool

Configuration Management may be done either manually or using Configuration Management Tool. The tools are
better in managing issues efficiently and effectively than doing it manually.
Current version we worked on Microsoft Visual Source Safe 6

(Visual Source Safe) MS VSS6.0 Navigation:

It is commercial software from Microsoft. Available in two types: i.e., 1) Server, 2) Client
Test Engineer responsibilities in configuration management i.e., VSS6. 0
1) Copy files from VSS i.e., check out files from repository
2) Check in files after completion of your work.

Levels of Testing
Proposal Testing - Proposal is made to the customer on the basis of Request for Proposal (RFP) / Request for
Information (RFI) / Request for Quotation). Proposal is prepared and reviewed based on customers need.
Requirement Testing - It must be reviewed by Business analyst whether if the requirement will be converted the product
or not. (Clarity,Complete,Measurable)
Design Testing - It must be tested, whether if the design is implemented as per the requirement or not. It includes
creation of data flow, activity, and state transition diagrams.
Code review - It includes reviewing code files , database schema ,classes, object definitions , procedures &
methods.Code must have following clarity,complete,measurable,racable,maintainable.
Unit Testing(Balck Box) - Unit is the small part of the software system which is testable. (Code Files)
Module testing -Many units come together and form a module. The module may work of its own or may need stub/driver
for its execution.
Integration testing (Structural) Integration of modules makes a system integration. And also testing the interfaces
between different modules.
Integration approaches

Bottom up testing Starts from unit module integration System Testing


Top down testing Ends with unit module integration System Testing
Modified top down Approach (Combined bottom up and top down). One after another
1) Starts from unit module

integration System Testing


2) Ends with unit
module

integration
System Testing

Big Bang Approach (System Testing / Final Testing) - This testing is last part of software development, ensuring that
requirements are defined and documented in requirement specifications and design specifications are met successfully.
Sandwich Testing (Combined Top Down and bottom Up )
It includes both features and advantages and it will be done by either simultaneous or one after another.

Critical path first (Main Function) - Testing defines the critical part of the system must be covered first. it is used for
where complete system testing is not possible and systems are so large .
Debugging Code checking to locate the cause of defect.

SPECIAL TESTS
Complexity Testing It is a verification Technique where the complexity of system design and coding is verified through
reviews, walkthroughs or inspection as per planned arrangement.

Control Flow it is process oriented, it defines direction of control flow as per the
decision of system.
Data Flow Information oriented, it will pass the data from one component to
another.
Control Flow Graph
It is a flow control when a program is getting executed. It describes the logical
stricture of software unit, where can go while executing instructions.
If a program have does not any kind of decision, flows happens single direction.
Whenever any decision to be taken by a program, there is a possibility of
different flow graph.

Each flow graph consists of node (Statements/Expressions) and edges (Transfer of


control between nodes).

When decisions are encountered edges e increases than nodes n . And it


represents complexity of the code.
Cyclomatic Complexity This mainly concentrates on number of controls which affects complexity of application.
Measures the amount of decision logic in a single software unit. it is defined for each unit to [e n +2]. Designers must try
to reduce complexity as minimum as possible.
Compatibility Testing - Testing technique that validates how well software performs in a particular hardware/software/operating
system/network environment. It is performed by the testing teams.
Security Testing - A process to determine that an information system protects data and maintains functionality as intended. It can be
performed by testing teams or by specialized security-testing companies.
Vulnerability Testing - There are some weak parts of the system represent the vulnerabilities in the System. These parts of the
systems are less protected and represent weaker Parts.
Performance Testing find whether the system meets is performance requirement under normal condition. Process of measuring
various efficiency characteristics of a system such as response time, through put, load stress transactions per minutes transaction mix.
Volume Testing (Load) it talks about the maximum volume or load a system can accept. (Concurrent users, no of connection,
Maximum size of Attachment).
Recovery Testing - Testing technique which evaluates how well a system recovers from crashes, hardware failures, or other
catastrophic problems. It is performed by the testing teams.

Stress Testing: Checking the application behavior under stress conditions is called
stress testing in other words reducing the system resources and keeping the
load as constant checking how application is behaving is called stress testing.
(Beyond the limits of its specified requirements)
Installation Testing: checking if we are able to install the software successfully or
not as per the guidelines given in installation document.
Un-Installation Testing - Checking if we are able to uninstall the software from the
system successfully or not.
Upgradation testing in order to upgrade it from older version to newer version.
During upgradation installer able to identify that older version of same application.
Regression Testing - After new functionalities added to the existing system or
modifications made to the existing system may introduce side-effects.
Regression testing is Helpful to identify these side effects.

Error handling Testing - Checking that the application able to detect error and
handle (Display) the error message while normal user entering wrong data or
selecting wrong option.
Smoke Testing with help of accessing major functionality, it tells the tester
whether the application is alive or not.
Control testing checks data Validity (Accuracy & completeness), File Integrity
(allows authorized user), and Backup and recovery.
Inter System Testing Checking that the Interfaces between two or more systems
and also information is transferred between different systems.
Sanity Testing Sanity testing performed to test the major behavior of functionality
of the Application. Depth of sanity is more than Smoke Testing.
Ad-Hoc Testing( Monkey , Exploratory, Random) - Testing performed without Planning and Documentation.
Monkey Testing - Testing

conducted on an application unevenly (Randamly) or zig-zag


way with an Intension of finding tricky defects is called monkey testing.
Execution Testing Checks system achieves desired level of proficiency in
production environment or user environment.
Operations Testing Operation Testing is performed to check that operating
procedures are correct as documented and staff can execute the application by using
the documentation.
Compliance Testing -

Which checks whether the system was developed in accordance with standards, procedures and

guidelines.

Decision table(Axiom) testing It creates different combination of true / false for


all input conditions to making decision

Documentation Testing - when the system is delivered to user , whether


product is delivered along with documentations or not (for future
maintainance).
Training Testing - checks that users are trained for using the system was
developed. Also checks whether training materials are delivered or not.
User Interface Testing - which is performed to check how user-friendly the application. Font colors, screen
background, navigations, etc.,

Rapid Testing This finds the biggest bugs in shortest time and provides highest
value for money.
Requirement (Specification) Testing - checks system being made will be
sufficient the user need. and checks requirements are complete and valid.
Benchmarking testing - Takes best (Perfect) product as reference for evaluate the
current product. Based on that difference can improve the current product as the
best one.

COTS Testing (commercial of the shelf) Softwares readily available in the


market and user can buy and use them directly.
Example: a development organization developing softwares for bank, finance
institutes,etc.,.it may not be develop automation testing tool for its test
requirements.in such case the organization may buy software from outside and use it
without investing much time and resource for making such software in house.
Concurrency Testing checks that whether multiple users can access the
application same time or not.
Data Warehouse Testing it focuses on data storage. And data analyst may
perform complex queries and analysis, checks that whether slowing down the
operational system or not.
Agile Testing: Software testing practice that follows the principles of the agile manifesto, emphasize testing from the perspective of
customers who will utilize the system. (Delivering the working software in faster speed)

TESTING TOOLS
Guidelines for Selecting tools

Tool must watch its intended purpose.


Selecting a tool that is appropriate for a life cycle phase.
Matching tool with skills of tester.
Affordable cost of tool

Category of tools
Static(Verification) Tools

Code complexity tool for measuring complexity of code.


Data profiling tool to optimizing the database.
Code profiling tools to optimizing code.
Test data generator - creating test data
Syntax checking tools verify correctness of code.

Dynamic(validation) Tools
Regression testing tools
Defect tracking tool & Communication tool
Performance,load,stress testing tools

When to Use Automation Tools

Complexity of test cases


No of iterations of testing
Test case dependency ( direct effect on next test case).

Test Scripts created for executing test cases in automated environment.

Boundary value analysis and equivalence partitioning both are test case design strategies in black box
testing.
Equivalence Partitioning:
In this method the input domain data is divided into different equivalence data classes. This method is
typically used to reduce the total number of test cases to a finite set of testable test cases, still
covering maximum requirements.
.
E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing
thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.Using
equivalence partitioning method above test cases can be divided into three sets of input data called as
classes. Each test case is a representative of respective class.
So in above example we can divide our test cases into three equivalence classes of some valid and invalid
inputs.
Test cases for input box accepting numbers between 1 and 1000 using Equivalence
Partitioning:
1) One input data class with all valid inputs. Pick a any single value from range 1 to 1000 as a valid test
case. So one test case for valid input data should be sufficient.
2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test
case.
3) Input data with any value greater than 1000 to represent third invalid input class.

Boundary value analysis:


The input values at the extreme ends of input domain cause more errors in system. More
application errors occur at the boundaries of input domain. Boundary value analysis testing technique
is used to identify errors at boundaries rather than finding those exist in center of input domain.
Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases
are selected at the edges of the equivalence classes.

Test cases for input box accepting numbers between 1 and 1000 using Boundary value
analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our
case.

2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.

Sample test scenario and Test cases for login Screen

Enter valid username and password.


1. Click on forgot password link and retrieve the
password for the username.
2. Click on register link and fill out the form and register
username and password.
3. Use enter button after typing correct username and
password.
4. Use tab to navigate from username textbox to
password textbox and then to login button.
Negative test cases
1. Enter valid username and invalid password.
2. Enter valid password but invalid username.
3. Keep both fields blank and hit enter or click login
button.
4. Keep username blank and enter password.
5. Keep password blank and enter username.

Positive test cases.

Test Scenario

6. Enter username and password wrong

Test Scenario (Positive) functional view


Test Scenario
Expected Result
User with a valid username and password User should be displayed the email screen once
should be allowed to login.
he submits the login credentials.
Test Scenario (Negative) Security and Functional view
Test Scenario
Expected Result
User with an invalid username and password User should be displayed an error message for
should not be allowed to login.
invalid username and password.
Sample Test case Template

Fuzz testing It is a black box testing technique which uses a random bad data to attack a program to check if anything breaks in the
application.
Scalability Testing - It is used to check whether the functionality and performance of a system, whether system is capable to meet
the volume and size changes as per the requirements.
Date Driven Testing - It is Automation testing process in which application is tested with multiple set of data with different
preconditions as an input to the script.
Interface testing - It is done to check whether the individual modules are communicating properly as per specifications.
Test Harness It is configuring (construct) a set of tools and test data to test an application in various conditions.
Entry Criteria and Exit Criteria Software Testing

Entry Criteria - SRS , Use Case , Test Case, Test Plan


Exit criteria - Test Summary Report, Metrics, and Defect Analysis Report.

Globalization Testing - Process of verifying software whether it can be run independent of its geographical and cultural environment.
Ex: Checking if the application is having features of setting and changing language, date, format and currency if it is designed for
global users.
Localization Testing - Verifying of globalized application for a particular locality of users, cultural and geographical conditions.
Compatibility Testing -Checking if the application is compatible to different software and hardware environment or not .
Test Case - A set of preconditions steps to be followed with input data and expected behavior to validate a functionality of a system.
Good Test Case - Test cases that have high priority of catching defects in called a good test case.
Use Case Testing - Validating software to confirm whether it is developed as per the use cases or not.

Defect Age - The time gap between date of detection & date of closure of a defect.
Bucket Testing data and elements are together that are grouped together within a bucket. Mostly used to study the impact of the
various product designs in website metrics.
User Acceptance Testing (UAT) - Testing of computer system by client to verify if it adhered to the provided requirements.
Code Walk Through - Informal analysis of the program source code to find defects and verify coding techniques.
Early Testing - Conducting testing as soon as possible in development life cycle to find defects at early stages of SDLC.
Exhaustive Testing - Testing functionality with all valid, invalid inputs and preconditions is called exhaustive testing.
Defect Clustering - small module or functionality may contain more number of defects concentrate more testing on these
functionality.
Pesticide Paradox - If prepared test cases are not finding defects, add/revise test cases to find more defects.
Static Testing - verification of the code without executing the program is called as static testing.
End-to-End Testing - Testing the overall functionality of the system including the data integration among all the modules.
Exploratory Testing - Exploring the application, understanding the functionality, adding (or) modifying existing test cases for better
testing .
Usability Testing - Checking how easily the end users are able to understand and operate the application.

Software Testing Life Cycle (STLC) - Write Test Plan ,Test Scenarios, Test Cases ,Executing Test Cases,Test Results, Defect
Reporting, Defect Tracking , Defect Closing , Test Release.
CMMI - Capability Maturity Model Integration.