It is difficult to determine when to stop testing, as testing is a never ending process. It is difficult
to claim that any software is 100% tested.
Following are the aspects which should be considered to stop the testing:
Testing Deadlines. Completion of test case execution. Completion of Functional and code
coverage to a certain point. Bug rate falls below a certain level and no high priority bugs are
identified. Management decision.
Crash of the dependent hardware, loss of versions can impact the code quality
Lack of skilled resources
Lack of knowledge both Technical and Business can lead to critical, expensive errors. In order
to avoid this, companies should seek people with specialized skills, even though they may come
at a higher price.
Inadequate reviews / walk-through
The defects might go unnoticed and cause the failure.
Changing Requirements
Frequent changes to requirements impacts the quality of code and in turn the software.
Rushing up to meet the deadlines leaves many defects being injected into the code.
Impact of Software Failure
Software failure can lead to:
Loss of money
Loss of time
Loss of business reputation
Injury
Death
a beneficiary name. A spokesperson said that the missing names were due to a software
program maintenance error.
In October 1999 the $125 million NASA Mars Climate Orbiteran interplanetary weather
satellitewas lost in space due to a data conversion error. Investigators discovered that
software on the spacecraft performed certain calculations in English units (yards) when it should
have used metric units (meters).
In June 1996 the first flight of the European Space Agency's Ariane 5 rocket failed shortly
after launching, resulting in an uninsured loss of $500,000,000. The disaster was traced to the
lack of exception handling for a floating-point error when a 64-bit integer was converted to a 16bit signed integer.
Keeping Software Under control
To prevent the software failure, it has to be thoroughly tested before it go live.
Incorrect testing or insufficient testing causes a software to fail.
More and better testing is needed for a defect free software, but it isnot quite as simple to
achieve.
Each and every part of the software has to be tested.
With large and complex systems it will never be possible to testeverything exhaustively.
There is a greater probability of a failure in the large and complexsystem and the impact of
the failure is also greater.
What we test, and how much we test is related to risk involved. Greater risk implies more and
better testing is required.
Testing is done to deliver a quality product. Here quality refers whether the product is meeting
the user's requirements.
Resource Triangle
The items at the corner of the triangle are time, money and quality. These three affect one
another, and also influence the features that are or are not included in the delivered software. If
we need to deliver a system faster (i.e. in less time), it will usually cost more.
Testing is to ensure that key functional and nonfunctional requirements are examined before
any defects are reported to the development team.
Testing cannot directly remove defects, nor can it directly enhance quality.
By reporting defects it makes their removal possible and so contributes to the enhanced
quality of the system.
In addition, the systematic coverage of a software product to be measured.
Testing is one component in the overall quality assurance activity that seeks to ensure that
systems enter service without defects that can lead to serious failures.
Go to Doubts
Software testing is an extremely creative and intellectually challenging task. When testing
follows the principles, the creative element of test design and execution rivals any of the
preceding software development steps.
Principle 1: Testing shows presence of defects
Testing can show that 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.
Principle 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
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.
The above Example is very unlikely that the project timescales would 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.
Principle 3: Early Testing
The sooner we start the testing activities the better we can utilize the available time. As soon
as the initial products, such the requirement or design documents are available, we can start
testing.
It is common for the testing phase to get squeezed at the end of the development life-cycle,
i.e. when development has finished, so by starting testing early, we can prepare testing for each
level of the development life-cycle
Another important point about early testing is that when defects are found earlier in the life-
number of modules within a system. i.e. small number of modules contain most of the defects in
the system.
A small number of modules contains most of the defects discovered during pre-release testing
or shows the most operational failures.
By identifying and focusing on these clusters, testers can efficiently test the sensitive areas
while concurrently testing the remaining non-sensitive areas.
Principle 5: Pesticide Paradox
The same kind of tests are repeated again and again, eventually the same set of test cases
will no longer be able to find any new bugs. This is called Pesticide Paradox.
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.
Anytime a fault is fixed or a new functionality added, we need to do regression testing to make
sure the new changed software has not broken any other part of the software.
However, those regression test cases also need to change to reflect the changes made in the
software to be applicable and hopefully fine new defects.
Principle 6: Testing is context dependent
Testing is basically context dependent. Different kinds of sites are tested differently.
For example, a software application in a medical device needs more testing than a games
software. More importantly a medical device software requires risk based testing, be compliant
with medical industry regulators and possibly specific test design techniques.
The same tests should not be applied across the board because different software products
have varying requirements, functions and purposes
Principle 7: Absence of errors fallacy
A test that finds no errors is different than concluding that the software is error-free. It should
be assumed that all software contains some faults, even if said faults are hidden.
When the built system is unusable and does not fulfill the users needs and expectations then
finding and fixing defects does not help.
Go to Doubts
Quality Assurance
Quality assurance activities are work process oriented.
They measure the process, identify deficiencies, and suggest improvements.
The direct results of these activities are changes to the process.
These changes can range from better compliance with the process to entirely new processes.
The output of quality control activities is often the input to quality assurance activities.
Audits are an example of a QA activity which looks at whether and how the process is being
followed. The end result may be suggested improvements or better compliance with the
process.
Quality Control
What is Quality Control?
Quality control activities are work product oriented.
design.
They evaluate the product, identify weaknesses and suggest improvements.
Testing and reviews are examples of QC activities since they usually result in changes to the
product, not the process.
QC activities are often the starting point for quality assurance (QA) activities.
Previous
General Principles of Testing
Go to Doubts
In the Waterfall model, the different phases of the software development life cycle are explicitly
recognized as mentioned in picture below: .
In this model, the project takes a straight line path.Since different phases are explicitly
recognized,the finalisation of the Contract is seen with reference to delivery and payment
schedules of different phases.
The waterfall model is the oldest and most widely used in software development life cycle. It is
also known as sequential model. Each phase must be completed before the next phase
begins.At the end of each review takes place to determine if the project is on the right track or
not.
Since requirement validation is not done in an explicit manner,it may result in design and
development of large quantities of unusable code. It may also result in extensive rework later,as
document-driven standards, force elaborate specifications of poorly understood user interfaces
and decision- support functions.
Advantages
Below are some of the advantages of the Waterfall Model
Simple and easy to use. Easy to manage due to the rigidity of the model each phase has
specific deliverable and a review process. Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Disadvantages
Adjusting scope during the life cycle can kill a project No working software is produced until
late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and
object-oriented projects. Poor model where requirements are at a moderate to high risk of
changing.
V-Model
V- model is a sequential path of execution of processes.Each phase must be completed before
the next phase begins.Testing is emphasized in this model more so than the waterfall model
though. The testing procedures are developed early in the life cycle before any coding is done,
during each of the phases preceding implementation. Testing of the product is planned in
parallel with a corresponding phase of development.
Advantages
Simple and easy to use Each phase has specific deliverable Higher chance of success over
the waterfall model due to the development of test plans early on during the life cycle Works
well for where requirements are easily understood
Disadvantages
Very inflexible, like the waterfall model Little flexibility and adjusting scope is difficult and
expensive Software is developed during the implementation phase, so no early prototypes of
the
software are produced Model does not provide a clear path for problems found during testing
phases.
The Spiral Model
A well-managed development project should take a straight line approach,right from feasibility
report to analysis, design, testing, and acceptance to operation. But in actuality, the project
needs to proceed iteratively by taking a spiral path. The project starts with the analysis phase,
then proceeds towards design, moves back to analysis and then design, followed by coding
(version 1.0) and back to design and so forth.
The basic idea behind this model is that you start on a small scale,in the middle of the core
functionality, explore the risks (such as poorly understood requirements and architecture,
potential performance problems, problems in underlying technology etc.) and then make a plan
to handle the risks. This should be followed by a commitment to approach, for the next iteration.
Each iteration moves your project to a larger scale. One layer of the project is rolled first, to
check what was actually wanted, and then, work on the next layer is started.
Each iteration involves the following steps:
- To determine objectives, alternatives and constraints
- To identify and resolve risks
- To evaluate alternatives
- To develop the deliverables for that iteration, and to verify their correctness
- To plan the next iteration
- To commit to an approach for the next iteration
Advantages Good for large projects and also for medium to high risk projects High amount
of risk analysis hence avoidance of risk is enhanced String approval and documentation
control Additional functionality can be added at a later date Software is produced early in the
software life cycle.
Disadvantages
Can be a costly model to use. Risk analysis requires highly specific expertise. Projects
success is highly dependent on the risk analysis phase. Doesnt work well for smaller projects.
Incremental model
The whole requirement is divided into various builds. Multiple development cycles make the life
cycle a multi-waterfall cycle. Cycles are divided up into smaller, more easily managed
modules. Each module passes through the requirements, design,implementation and testing
phases. A working version of software is produced during the first module.Each subsequent
release of the module adds function to the previous release. The process continues till the
complete system is achieved
Advantages
Generates working software quickly and early during the software life cycle. More flexible
less costly to change scope and requirements. Easier to test and debug during a smaller
iteration. Customer can respond to each built. Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during each iteration.
Disadvantages
Needs good planning and design. Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally. Expensive than waterfall model
Agile Model
Agile model is also a type of Incremental model which is used for time critical applications.
Software is developed in incremental, rapid cycles. This results in small incremental releases
with each release building on previous functionality. Each release is thoroughly tested to ensure
software quality is maintained.Extreme Programming (XP), Scrum are some of the most well
known agile development model
External link: https://help.rallydev.com/sites/default/files/multimedia/videos/agile_primer.swf
Advantages
People and interactions are emphasized rather than process and tools. Customers, developers
and testers constantly interact with each other. Working software is delivered frequently
(weeks rather than months). Face-to-face conversation is the best form of communication.
Close, daily cooperation between business people and developers. Continuous attention to
technical excellence and good design. Regular adaptation to changing circumstances. Even
late changes in requirements are welcome.
Disadvantages
In case of some software deliverables, especially the large ones, it is difficult to assess the
effort required at the beginning of the software development life cycle. There is lack of
emphasis on necessary designing and documentation. The project can easily get taken off
track if the customer representative is not clear what final outcome that they want. Only senior
programmers are capable of taking the kind of decisions required during the development
process. Hence it has no place for new programmers, unless combined with experienced
resources.
Different software development models have their own advantages and disadvantages. The
right model or combination of models has to be chosen based on the project and all other
related factors.
CC India
Campus Commune
My Channels
Go to Doubts
1. Requirement Analysis
During this phase, test team studies the requirements from a testing point of view to identify the
testable requirements. The QA team may interact with various stakeholders (Client, Business
Analyst, Technical Leads, System Architects, etc) to understand the requirements in detail.
Requirements could be either Functional (defining what the software must do) or Non Functional
(defining system performance /security availability). Automation feasibility for the given testing
project is also done in this stage.
Activities:
Identifytypes of tests to be performed.
Gather details about testing priorities and focus.
Prepare Requirement Traceability Matrix (RTM).
Identify test environment details where testing is supposed to be carried out.
Automation feasibility analysis (if required).
Deliverables:
RTM
Automation feasibility report. (if applicable)
2. Test Planning
This phase is also called Test Strategy phase. Typically, in this stage, a Senior QA manager will
determine effort and cost estimates for the project and would prepare and finalize the Test Plan.
Activities:
Preparation of test plan/strategy document for various types of testing
Test tool selection
organization.
It typically includes the decisions made based on the project's goal and the riskassessment
carried out, starting points regarding the test process, the test design techniques to be applied,
exit criteria and test types to be performed.
The overall approach to testing is described in Test Strategy. For each major group of
features or feature combinations, the approach specified should ensure that these feature
groups are adequately tested. The major activities, techniques, and tools which are used to test
the designated groups of features are also specified in Test Strategy document.
The approach should be described in sufficient detail to permit identification of the major
The test planning process and the plan itself serve as vehicles for communicating with other
members of the project team, testers, peers, managers and other stakeholders.This
communication allows the test plan to influence the project team and the project team to
influence the test plan, especially in the areas of organization-wide testing policies and
motivations; test scope, objectives and critical areas to test.
The test plan also helps us manage change. During early phases of the project, as we gather
more information, we revise our plans. As the project evolves and situations change,we adapt
our plans. Written test plans give us a baseline against which to measure such revisions and
changes. Furthermore, updating the plan at major milestones helps keep testing aligned with
project needs.
At a high level, you need to consider the purpose served by the testing work. In terms of the
overall organizational needs, this purpose is referred to variously as the test team's mission or
the organization's testing policy. In terms of the specific project, understanding the purpose of
testing means knowing the answers to questions such as:
What is in scope and what is out of scope for this testing effort? What are the test objectives?
What are the important project and product risks? What constraints affect testing (e.g.,
budget limitations, hard deadlines, etc.)? What is most critical for this product and project?
Which aspects of the product are more (or less) testable? What should be the overall test
execution schedule and how should we decide the orderin which to run specific tests?
Need for Test Plan
If you fail to plan you plan to fail
One of the keys to successful software testing
Discuss issues early
the situation
And Others
Features to be tested
Which parts of the software specification are to be tested?
User or customer point of view
Contents depend on level of the Test Plan
Help to focus on software risks
Resource clause: Gives overall view of the resources to deliver the tasks.
Environmental Needs
What is needed in the way of testing software, hardware etc.
Are there any special requirements for this test plan, such as special hardware such as
Responsibilities
Lists who has responsibility for delivering various part of the plan like setting risks.
Selecting features to be tested and not tested.
Setting overall strategy for this level of plan.
Ensuring all required elements are in place for testing.
Providing for resolution of scheduling conflicts, especially, if testing is done on the production
system.
Who provides the required training?
Who makes the critical go/no go decisions for items not covered in the test plans?
Schedule
This specifies when the tasks will take place.
o It should be based on realistic and validated estimates.
Build around milestones
o All relevant milestones should be identified
Reference to project schedule.
o It is always best to tie all test dates directly to their related development activity dates. This
prevents the test team from being perceived as the cause of a delay. For example, if system
testing is to begin after delivery of the final build, then system testing begins the day after
delivery. If the delivery is late, system testing starts from the day of delivery, not on a specific
date. This is called dependent or relative dating.
Include deadlines
Estimation and resources are considered
How slippage in the schedule will be handled should also be addressed here.
o If the estimates for the development of the application are inaccurate, the entire project plan
will slip. The first area of a project plan to get cut when it comes to crunch time at the end of a
project is the testing. If the users know in advance that a slippage in the development will cause
a slippage in the test and the overall delivery of the system, they just may be little more tolerant,
if they know its in their interest to get a better tested application.
o By spelling out the effects here you have a chance to discuss them in advance of their actual
occurrence. You may even get the users to agree to few defects in advance, if the schedule
slips.
Quality clause: It specifies to what standard the testing will be completed against the scope.
Introduction section
o This gives a high level view of the testing standard. Specifies overall test objectives.
o A basic description of the project or release including key features,history, etc.,
o An introduction to the plan that describes the scope of the plan.
o Any references to other plans, documents or items that contain information relevant to this
project/process. If required a references section can be created to contain all reference
documents.
o Other items
o Resource and budget constraints, scope of the testing effort, how testing relates to other
evaluation activities (Analysis & Reviews),and possible process to be used for change control
and communication and coordination of key activities.
As this is the Executive Summary the information kept here should be brief and to the point.
Item pass/fail criteria
o This defines how the item being tested has passed and completion criteria for this plan. This
is a critical aspect of any test plan and should be appropriate to the level of the plan. Each test
item needs to have an expected result relative to the test level.
o At the Unit test level this criteria could be as
o All test cases completed.
o A specified percentage of cases completed with a percentage containing some number of
minor defects.
o Code coverage tool indicates all code covered.
o At the Master test plan level this criteria could be as
This could be an individual test case level criterion or a unit level plan or itcan be
generalfunctional requirements for higher level plans.
Describes severity
o The number and severity of defects located
Approach
o This is the overall test strategy for this test plan. It should be appropriate to the levelof the
plan (master, acceptance, etc.) and should be in agreement with all higher andlower levels of
plans. Overall rules and processes should be identified.This gives details of how the testing
process will be followed.
Test deliverables
o This specifies the test documents and other deliverables to be produced.
o Test Plans
o Test Design Specs
o Test Cases
o Custom Tools
o Defect Reports
o Test Summary Reports
o Simulators (if any)
One thing that is not a test deliverable is the software itself that is listed under test itemsand is
delivered by development.
Risk clause: Defines in advance what will happen if something goes wrong with the plan.
Suspension criteria and resumption requirements
o This is a particular risk clause to define when testing will stop and restart.
o Conditions for temporary suspension
o If the number or type of defects reaches a point where the follow ontesting has no value, it
level of defects that will allow the testing toproceed past the defects.
complete by January 1, 19XX, and, if the requirements change after that date, the following
actions will be taken.
o The test schedule and development schedule will move out an appropriate number of days.
This rarely occurs, as most projects tend to have fixed delivery dates.
o The number of test performed will be reduced.
o The number of acceptable defects will be increased.
o These two items could lower the overall quality of the delivered product.
o Resources will be added to the test team.
o The test team will work overtime.
o This could affect team morale.
o The scope of the plan may be changed.
o This clause contains the signatures of the various stakeholders in the plan, to show they
agree in advance with what it says.
o Various stakeholders signature
entire project testing. It covers the general views and objectives that the project should achieve,
in addition to the approaches that should be used to achieve them. It is usually a project-wide
document that is shared with the entire project team and/or the whole company
The test plan is more detailed. It incorporates a lot of the specifics of that which has been
outlined in the test strategy, such as who does the actual testing and how the steps are to be
conducted. However, it will always follow the guidelines as stated in the test strategy. The test
plan may deal with the entire project as a whole or a specific part of the project. In some smaller
projects, the test strategy can also be found as a section of the test plan.
Some companies include the Test Approach or Strategy inside the Test Plan, which is fine
and it is usually the case for small projects. However, for larger projects, there is one Test
Strategy document and different number of Test Plans for each phase or level of testing
Furthermore, the test strategy is a static document, i.e. it is the same throughout the project
from the beginning to the end. However, the test plan may often be revised in face of
unforeseen circumstances faced by the project. Hence, it is versatile
3. Test Design
This phase involves creation, verification and rework of test cases & test scripts. Test data, is
identified/created and is reviewed and then reworked as well.
Activities:
Create test cases, automation scripts (if applicable)
Review and baseline test cases and scripts
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.
Activities:
Evaluate cycle completion criteria based on Time,Test coverage,Cost,Software,Critical
Business objectives and Quality Prepare test metrics based on the above parameters.
Document the learning out of the project Prepare Test closure report Qualitative and
quantitative reporting of quality of the work product to the customer. Test result analysis to find
out the defect distribution by type and severity
Deliverables:
Test Closure report Test metrics
Go to Doubts
The process of testing interfaces and data flows between the programs within a sub system,and
between the sub-systems within a system is known as Integration Testing.
In Integration testing tester must look for bugs in the relationship and the interfaces between
pairs of components and groups of components under test.
Example:
Check whether the calling program in previous example passes the right information relating to
starting station and destination, date of journey, discounts to be applied andclass requested.
System Testing
System Testing is a test, executed by the developer or independent test team in a laboratory
environment that should demonstrate that the developed system or subsystems meet the
requirements set in the functional and quality specifications.
It is a process of proving that the system meets its stated design specifications (design
documents) w.r.t criteria such as recoverability, maintainability and security
Example:
Comprehensive black box testing of railway reservation system with transactionsinitiated and
validations performed on databases and reports generated after thecompletion of the
transactions
Acceptance Testing
It is a test, executed by the user(s) and system manager(s) in an environment simulating the
operational environment to the greatest possible extent, that should demonstrate that the
developed system meets the functional and quality requirements.
Non Functional and Other types of Testing
Performance testing Volume testing Load testing Limit testing Stress testing Disaster
Testing Recovery testing Security testing Reliability testing Installation Testing Usability
Testing Accessibility Testing Regression testing
Go to Doubts
The Reality:
Next
Building a career in Testing
Go to Doubts
Take training on testing tools Take professional training on software testing Complete
software testing certifications Learn the Domain Move up in the hierarchy
Behind every great Developer there is an equally great Tester.
Professional Certifications in Testing
Training & Certification makes a better Test Professional. Assurance Academy which is part of
the Assurance Services Unit caters to the competency development in software testing in TCS.
Below is the list of some of the widely taken up certifications in Testing
Roles and Responsibilities
Prepare test automation design based on the test automation architecture and framework
defined for the project Define standards and guidelines for automation
Test Strategist
Design testing framework including automated testing Review testing deliverables Analyze
testing tools and recommend for use Define test strategy Define Metrics
Test Process Consultant
Assess testing processes and recommend improvement action plan Assess test automation
feasibility Prepare assessment plan and coordinate with the project/program stakeholders
Test Manager
Develop test strategy Planning, effort estimation, resource management and training
Manage and deliver the Testing team activities Establish, track and improve process
efficiencies Identifying risks and formulating mitigation strategies
Business Analyst
Prepare high level test scenarios based on business scenarios and requirements Analyze
requirements for accuracy and completeness from a business perspective Review high level
test scenarios prepared
Test Consultant
Assess testing processes and recommend improvement action plan Prepare assessment
plan and coordinate with the project/programme stakeholders Pre-sales/ business
development
Test Automation Consultant
Automation feasibility analysis and tool evaluation Automation approach and roadmap Presales/ business development Creation of assets Product review/ keep abreast of
developments in product space
Test Center Delivery Manager
End-to-end management of testing delivery for multiple projects / initiatives Identify and
monitor issues, risks and concerns at test centre level Reporting to Customer Management
A good software tester must have strong technical skills. It helps the testers to have a real
insight into the kinds of bugs that come into software and the likeliest place to find them. Also
Technical skills help in test Automation.
Communication skills:
A good software tester must have a good verbal and written communicationskills. It helps in
creation of Testing artifacts like test cases, test plans, test strategies, bug reports. Also in
communicating with developers, clients and management (Negotiation and Soft skills).
Attitude:
A good software tester should have a GREAT attitude.An attitude to Test to break, detail
orientation, willingness to learn, suggest process improvements, upgrade technical skills with
the changing technologies and work independently without much supervision.
Productivity:
A software tester must efficiently manage workload, have high productivity, exhibit optimal time
management and organization skills.
Passion:
A software tester must have a great degree of passion for Testing. The passion should be, to
make a career in testing but not just to treat it as a job.Only then one can excel in this
profession.
Previous
Building a career in Testing
model. 3. Relational model represents data in the form of tables. 4. Some popular examples are
Oracle, Microsoft SQL Server and Microsoft Access.
RDBMS terms
Relation: The Relation is a collection of related data entries and it consists of columns and rows.
Tuple: A tuple, also called a row of data, is each individual entry that exists in a table.
Fields: Every table is broken up into smaller entities called fields. A field is a column in a table
that is designed to maintain specific information about every record in the table.
Keys in DBMS Keys are used to establish and identify relation between tables
Super Key: A Super key is any combination of fields within a table that uniquely identifies each
record within that table.
Candidate Key: 1. A candidate is a subset of a super key. 2. A candidate key is a single field or the
least combination of fields that uniquely identifies each record in the table. 3. The least combination
of fields distinguishes a candidate key from a super key.
Primary key: 1. A primary key is a candidate key that is most appropriate to be the main reference
key for the table. 2. It is a key that uniquely identifies a record in a table.
Foreign key: 1. A foreign key is the field that generally references values from primary key field of
other table
To display all records from table SELECT keyword with asterisk(*) is used:
The above query displays all the records from customer_details
To retrieve selected columns from the table, specific column names separated by commas(,) are
used
The above query displays only id, name and salary columns from customer_details
The above query displays name and age of customers whose salary more than 50000 From
customer_details table
Restricting Selection using IN keyword:
SELECT name,location FROM customer_details WHERE location IN ('Kolkata','Delhi');
The above query displays name and location of customers who are from Kolkata and Delhi
Restrict based on pattern matching:
SELECT name,location FROM customer_details WHERE name LIKE '_a%';
The above query displays name and location of customers whose name's second character is a.
'_' identifies that one character can appear before 'a' and ' % ' identifies that any numbers of
character can appear after 'a'.
Restricting Selection using BETWEEN AND keyword:
SELECT name,location FROM customer_details WHERE age BETWEEN 20 AND 40;
The above query displays name and location of customers whose age ranging from 20 to 40
Restricting based on NULL value:
In Database terminology NULL is referred as value which is unspecified or unavailable
Based on database configuration, NULL value may not display anything but it should not be
misunderstood as zero or blank space.
Condition on NULL value can be given using the keyword IS.
SELECT name, age FROM customer_details WHERE location IS NULL;
The above query displays name and age of customers whose location not specified
SELECT name, age FROM customer_details WHERE age IS NOT NULL;
The above query displays name and age of customers whose age available
DISTINCT Keyword
To eliminate duplicate rows DISTINCT keyword is used in the SELECT statement.
The concatenation( || ) operator can be used to combine character strings and values from table.
The Name, age and the strings are displayed as single output columns
Column Alias
Column heading in the result set can be changed with Column aliases using the keyword AS.
1. The columns name and id are displayed as customer_name and customer_id in the result set.
2. Column headings in the table is unchanged.
DDL statements define the data structure such as tables, views etc.. that make up the database. All
DDL statements are auto committed means the changes will become permanent and database
objects created are available to all users.
Commonly used DDL statements are:
CREATE
ALTER
DROP
RENAME
TRUNCATE
Data Types
A data type identifies or classifies a particular type of information or data.
Some commonly used data types are:
CHAR (size) - Used to store character strings values of fixed length.
VARCHAR2 (size) Used to store variable length string data.
NUMBER (size, precision) Used to store numbers(fixed or floating point)
DATE Used to represent date and time.
LONG Used to store large variable length strings(upto 2GB).
The above statements renames the column name salary to em_sal and drops column age.
INSERT statement
Insert statement is used for inserting data into table.
Insertion of data can be done in multiple ways.
Syntax:
INSERT INTO table_name[(column1, column2,...)]
VALUES(value1, value2,....);
Ex:
If values in all the columns inserted in proper order, column names are not mandatory.
Syntax-:INSERT INTO table_name VALUES(value1, value2,....);
Ex:
Insertion can also be done in interactive way.
The records can be inserted in interactive manner also
Syntax:
INSERT INTO table_name VALUES(&value1, &value2, ..);
Ex:
UPDATE statement
Update command is used to change or modify data of one or more records in a table.
Syntax:
UPDATE Table_name SET Column_name1=value1 [,Column_name2=value2,...]
[WHERE Condition];
Ex.
DELETE statement
1. Delete statement is used to remove one or more records from a table.
2. A subset may be defined for deletion using a condition, otherwise all records are removed.
Syntax:
DELETE FROM Table_Name
[WHERE Condition];
Delete statement using WHERE condition.
Ex:
Note: Delete statement without where condition deletes all the rows from table.
Example-
COMMIT:
It ends the current Transaction by making all pending data changes permanent.
Syntax:COMMIT;
Once commit is issued, data changes will become permanent.
The previous state of the data is permanently lost.
All users can view the results of the recent transactional changes.
Ex: UPDATE employee SET salary =1000 WHERE emp_id = 10;
COMMIT;
SAVEPOINT:
It marks a savepoint with in the current Transaction.
We can create multiple savepoints in single Transaction.
Savepoints can be used to control the reverting of changes.
Syntax:SAVEPOINT <NAME>;
Ex: SAVEPOINT S1;
ROLLBACK:
It ends the current Transaction by discarding all pending data changes.
The data changes are undone.
The previous state of data is restored.
The locks on the affected rows are automatically released.
Syntax: ROLLBACK or ROLLBACK to <SAVEPOINT NAME>;
Ex: UPDATE employee SET salary =1000 WHERE emp_id = 10;
ROLLBACK;
using savepoint the Transaction can be discarded up to the marker by using rollback statement.
Conversion Functions
NVL
NVL2
NULLIF
NVL: let us replace null with a string in the results of a query .
Syntax : NVL( string1, replace_with).
If string1 is null, then NVL returns replace_with .
If string1 is not null, then NVL returns string1.
Ex: SELECT NVL(emp_name,'NA') FROM Employee;
The above query will display 'NA' wherever emp_name is null.
We can also replace with another column.
Ex: SELECT NVL(emp_name,dep_name) FROM Employee;
The emp_name and dep_name should belongs to same data type family.
The above query will display dep_name wherever emp_name is NULL.
Ex: SELECT NVL(salary,0) FROM Employee;
The above query returns 0 only if the salary is defined as NUMBER and is NULL.
NVL2: NVL2 function extends the functionality found in the NVL Function.
It lets you substitutes a value when a null value is encountered as well as when a non-null value is
encountered.
Syntax : NVL2(string1,value_if_not_null,value_if_null)
if string1 is not null then NVL2 returns value_if_not_null.
if string1 is null then NVL2 returns value_if_null.
Ex: SELECT NVL2(emp_name,dep_name,'NOT AVAILABLE') FROM Employee;
NULLIF: NULLIF compares expr1 and expr2. If they are equal, then the function returns null. If they
are not equal, then the function returns expr1 .
Syntax : NULLIF(expr1,expr2)
Ex: SELECT NULLIF( dep_name,'HR') FROM Employee;
The above query returns NULL if dep_name field consists of 'HR', otherwise it returns job.
You cannot specify the literal NULL for expr1.
Character Functions
There are two types of character functions.
Character to character functions accept string as input and will give string as output.
INITCAP
LOWER
UPPER
CONCAT
LPAD,RPAD
TRIM
SUBSTR
REPLACE
Character to number functions accept string as input and will give number as output.
LENGTH
INSTR
INITCAP: This function sets the first character in each word to upper case and the rest to lower
case.
Syntax : INITCAP(expr1)
Ex: SELECT INITCAP(emp_name) FROM Employee:
Amit
Ajay
Sima
Dipa
Anuj
The above query returns all the employee names with the first letter in upper case and rest other
characters in lower case.
LOWER: This function converts all letters in the specified string to lower case. If there are
characters in the string that are not letters, they are unaffected by this function.
Syntax : LOWER(expr1)
Ex: SELECT LOWER (emp_name) FROM employee:
amit
ajay
sima
dipa
anuj
The above query returns all the characters of the employee name in lower case.
UPPER:This function converts all letters in the specified string to uppercase. If there are characters
in the string that are not letters, they are unaffected by this function.
Syntax : UPPER(expr1)
Ex: SELECT UPPER (emp_name) FROM Employee:
AMIT
AJAY
SIMA
DIPA
ANUJ
The above query returns all the characters of the employee name in upper case.
CONCAT: This function allows you to concatenate two strings together.
Syntax : CONCAT(expr1,expr2)
Ex: SELECT CONCAT(emp_name,dep_name) full_name FROM Employee;
The above query returns the emp_name & dep_name concatenated into a single string.
SUBSTR: Returns specified characters from a string, starting from specific position to required
characters length.
Syntax : SUBSTR(col/expr,m,n)
If 'm' is positive,oracle counts from beginning of string, If it is negative Oracle counts from the end of
string.
If 'n' is omitted, Oracle returns all characters to end of the string starting from m.
Ex: SELECT SUBSTR(emp_name,3,2) FROM Employee.
The above query starts searching from the third position of the employee name from the starting of
the string and displays two characters from there.
Ex: SELECT SUBSTR('abcdefg'-4,2) FROM dual;
dc
The above query starts searching from the fourth position of the given string from the end of the
string and display two characters from there.
REPLACE: It returns the every occurrence of search_string replaced by the replacement_string.
If the replacement string is omitted or null all occurrences of search string will be removed.
Syntax : REPLACE(string,search_string,replace_string)
Ex: SELECT REPLACE(branch_name,'Mumbai','Kolkata') FROM Employee WHERE dep_name =
'HR';
The above query replaces branch name to 'Kolkata' wherever 'Mumbai' is available for the HR
department .
LPAD,RPAD:
LPAD pads the character value right justified to a total width of n character positions.
Syntax : LPAD(expr1,padded_length,padded_string)
RPAD pads the character value left justified to a total width of n character positions.
Syntax : RPAD(expr1,padded_length,padded_string)
The default padding character is space.
Ex: SELECT LPAD('jhon',8) FROM dual;
jhon
Since the third parameter is not specified in the result of the above query will be by default space
padded for the previous four positions.
Ex2: SELECT LPAD('jhon',8 ,'x') FROM dual;
xxxxjhon
The above query fills the four blank spaces with 'x' left of the given string.
Ex3: SELECT RPAD('jhon',8 ,'x') FROM dual;
jhonxxxx
The above query fills the four blank spaces with 'x' right of the given string.
TRIM: It enables to trim leading or trailing characters or both from a string.
If we dont specify anything, it will trim spaces.
Syntax : TRIM( [LEADING | TRAILING | BOTH] character FROM string)
LTRIM : Removes the leading characters
RTRIM : Removes the trailing characters
TRIM : Removes both
Ex: SELECT RTRIM('s' from 'ssmithss') FROM dual;
ssmith
The above query removes 'trailing' 's' from the given string.
Ex: SELECT LTRIM('s' from 'ssmithss') FROM dual;
mithss
The above query removes 'leading' 's' from the given string.
Ex: SELECT TRIM('s' from 'ssmiths') FROM dual;
mith
The above query removes 'trailing' & 'leading' 's' from the given string.
Ex: SELECT TRIM(' smith ') FROM dual;
Smith
The above query removes 'trailing' & 'leading' spaces from the given string.
INSTR: This function returns the location of a sub string in a given string.
Syntax : INSTR( string, sub_string [, start_position [, nth_appearance ] ] ).
start_position and nth_appearance are optional. If not specified, always INSTR starts with first
position and will give first appearance.
Ex: SELECT INSTR('internet','e') FROM dual;
4
The above query returns the first position of 'e' searched from the start of the given string.
Ex: SELECT INSTR('internet','e',1,2) FROM dual;
7
The above query returns the second position of 'e' searched from the start of the given string.
The ABS function returns the absolute value of the parameter passed.
Syntax : ABS(number)
Ex: SELECT ABS(-10) FROM dual;
10
The above query returns the absolute value of the given 'number'.
The MOD function returns the remainder value of the parameter passed.
Syntax : MOD(number1,number2)
Ex: SELECT MOD(10,4) FROM dual;
2
The above query returns the remainder when 10 is divided by 4.
POWER and SQRT Function
POWER function returns the argument raised to the specified power.
Syntax : POWER(number1,number2)
Ex: SELECT POWER(4,3) As Cube FROM dual;
64
The above query returns the output when 4 is raised to the power of 3.
SQRT function returns the square root of a number passed as parameter.
Syntax: SQRT(number)
Ex: SELECT SQRT(64) As Square Root FROM dual;
8
The above query returns the square root value of 64.
FLOOR and CEIL Function
The FLOOR function returns the largest integer less than or equal to the value
passed in parameter.
Syntax: FLOOR(decimal number)
Ex: SELECT FLOOR(7.14), FLOOR(7.84) FROM dual;
77
The above query returns the largest integer nearest to 7.14 & 7.84.
Ex: SELECT FLOOR(-7.14) FROM dual;
-8
The above query returns the largest integer nearest to -7.14.
The CEIL function returns the smallest integer greater than or equal to the value
mentioned in parameter.
Syntax: CEIL(decimal number)
Ex: SELECT CEIL(7.14), CEIL(7.84) FROM dual;
88
The above query returns the smallest integer nearest to 7.14 & 7.84.
Ex: SELECT CEIL(-7.14) FROM dual;
-7
The above query returns the smallest integer nearest to -7.14.
TRUNC and ROUND Function
1) The TRUNC function truncates the value present in the column, expression up to decimal places
mentioned in first parameter.
2) If the second argument is 0 or is missing, the value is truncated to zero decimal places.
Syntax: TRUNC(decimal number,number of places)
Ex: SELECT TRUNC(137.5738,3) As Rounded FROM dual;
137.573
The above query returns the decimal number with three digits after the decimal point.
Ex: SELECT TRUNC(137.5738,0) As Rounded FROM dual;
137
The above query returns the integer value.
The ROUND function round off the value present in the column, expression up to decimal places
mentioned in first parameter.
If the second argument is 0 or is missing, the value is rounded to zero decimal places.
Syntax: ROUND(decimal number,number of places)
Syntax: COUNT(*)
Ex: SELECT COUNT(*) FROM Employee;
5
The above query displays the total number of rows in table Employee.
GROUP BY clause
Creates a data set, containing several sets of records grouped together based on a condition.
Syntax: SELECT <columnName1>[,<columnName2>], AGGREGATE
FUNCTION(<expression>) FROM Table_Name GROUP BY <columnName1>[,<columName2>] ;
Ex: SELECT dep_name,COUNT(emp_id) "No of Employee" FROM Employee GROUP BY
dep_name;
HR 2
Marketing 2
Admin 1
The above query displays the number of employee in each department.
WHERE clause
Used to apply a filter condition before the Grouping the rows.
Syntax: SELECT <columnName1>[,<columnName2>], AGGREGATE
FUNCTION(<expression>) FROM Table_Name WHERE <condition_before_grouping_rows>
GROUP BY <columnName1>[,<columName2>] ;
Ex: SELECT Dep_Name,COUNT(Salary) FROM Employee WHERE Salary>15000 GROUP BY
Dep_Name;
HR 1
Marketing 1
Admin 1
The above query displays department wise count of salary more than 15000.
HAVING clause
Used to apply a filter condition on Aggregate values.
Syntax: SELECT <columnName1>[,<columnName2>], AGGREGATE
FUNCTION(<expression>) FROM Table_Name WHERE <condition_before_grouping_rows>
GROUP BY <columnName1>[,<columName2>] HAVING <condition_on_grouped_result>;
Ensure that the software has been represented according to predefined standards
Achieve software that is developed in a uniform manner
Make projects more manageable
Serve as a training ground, enabling junior engineers to observe different approaches to software
analysis, design, and implementation
Serves to promote backup and continuity because a number of people become familiar with parts
of the software that they may not have otherwise seen
Peer Reviews are documented and uses a defect detection process that has peers and technical
specialist as part of the review process.
The Review process does not involve management participation.
It is usually led by trained moderator who is NOT the author.
The report is prepared with the list of issues that needs to be addressed.
Informal - Walkthrough:
It is not a formal process. It is led by the authors.
Author guides the participants through the document according to his or her thought process to
achieve a common understanding and to gather feedback.
Useful for the people if they are not from the software discipline, who are not used to or cannot
easily understand software development process.
Especially useful for higher level documents like requirement specification, etc.
Formal Inspection:
It is the most formal review type. It is led by the trained moderators.
During inspection the documents are prepared and checked thoroughly by the reviewers before the
meeting.
A separate preparation is carried out during which the product is examined and the defects are
found.
The defects found are documented in a logging list or issue log.
A formal follow-up is carried out by the moderator applying exit criteria.
External reference - http://www.cs.toronto.edu/~sme/CSC444F/slides/L09-Inspections.pdf
Dynamic Testing
Testing the software by dynamically executing the application is termed as dynamic testing. Dynamic
testing is a method of assessing the feasibility of a software program by giving input and examining
output (I/O). The dynamic method requires the code be compiled and run. It comes under the
validation.
Dynamic Testing Consists of Two Types:
1) White-Box testing
2) Black-Box testing
There are two types of input equivalence classes, valid and invalid.
Equivalence class technique can significantly reduce the number of test cases that must be created
and executed
Illustration for EP
EP may be best explained with an example of a function which has the pass parameter "month" of a
date. The valid range for the month is 1 to 12, standing for January to December. This valid range is
called a partition. In this example there are two further partitions of invalid ranges.
The first invalid partition would be <= 0 and the second
invalid partition would be >= 13.
Boundary Value Analysis technique
A selection technique in which test data are chosen to lie along "boundaries of the input domain [or
output range] classes, data structures, procedure parameters is known as Boundary Value Analysis
Technique.
Choices often include maximum, minimum, and trivial Values .This technique mainly focus on the
boundaries of the input.
Illustration for BVA
If the same example of a function which has the pass parameter "month" of a date
Valid Class is 1<= month <=12
Invalid Class 1 is month <1
Invalid Class 2 is month >12
When compared to EP, which says select any test case within a range and any on either side of it ,
in BVA the emphasis is on the edges.
1 and 12 for the edges of the Valid class
0 and 13 for the Invalid class
White Box Testing Techniques
Statement coverage technique
It is a technique to satisfy the criterion that eachstatement in a program to be executed at least
onceduring program testing. Coverage is 100 percentage whena set of test cases causes every
program statement to beexecuted at least once.
The chief disadvantage of statement coverage is that it isinsensitive to some control structures.
Example
1 int select ( int a[], int n, int x) 2 { 3 int i = 0; 4 while ( i < n && a[i] < x ) 5 { 6 if (a[i] < 0) 7 a[i] = - a[i];
8 i++; 9 } 10 return 1; 11 }
One test case n=1, a[0]=-7, x=9 covers everything ,
Flow 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11
Branch Coverage technique
In Branch Coverage Technique execution of decisions is considered rather than execution of each
statement. The result of decisions determines which statement will be executed next.
Test every Decision Output both Then and Else part of IF, all possibilities for a CASE statement,
loops i.e execution of the loop body, bypassing of the loop body and return to the beginning of the
loop. Example:
1 int select ( int a[], int n, int x) 2 { 3 int i = 0; 4 while ( i < n && a[i] < x ) 5 { 6 if (a[i] < 0) 7 a[i] = - a[i];
8 i++; 9 } 10 return 1; 11 }
Test Data:
Flow A : 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11
Flow B : 1 - > 2 - > 3 - > 4 - > 10 - > 11
Multiple Condition Coverage technique
A test coverage criteria which requires enough test cases such that all possible combinations of
condition outcomes in each decision, and all points of entry, are invoked at least once.
A large number of test cases may be required for full multiple condition coverage.
Example:
1 int select ( int a[], int n, int x) 2 { 3 int i = 0; 4 while ( i < n && a[i] < x ) 5 { 6 if (a[i] < 0) 7 a[i] = - a[i];
8 i++; 9 } 10 return 1; 11 }
Test Data:
Sample Program:
1 sample ( int x , int y )
{ 2 If ( x > 10 ) 3 x = x + y ; break ; 4 if ( y > 10 ) 5 y = y + x ; break ; } 6 printf (%d %d, x , y);
Go to Doubts
Assumptions
Module Name
Priority
Prerequisite.
Expected Result.
execution.
Test cases should cover valid, invalid, expected and unexpected conditions.
Writing effective test cases is a skill
It requires in-depth study of the application
Breaking down the Test Requirements into Test Scenarios and Test Cases would help the
Go to Doubts
specified in this field. Example, availability of Environment & application under test, test data
appropriate to execute the test case etc.
Test Scenario ID: ID of the Scenario to which test case belongs to be provided.
Test Step: Test Step Number. Usually starts from Step 1, Step 2, Step 3 and so on.
Test Step Description: Each and every action that has to be performed to execute the test
Go to Doubts
Previous
Description of Test case components
Next
Test Step
Go to Doubts
Home
See Leaderboard
Go to Doubts
3. Reservation Function
Lets look at the lower levels for the below one
1.4.1 Validate that a customer record can be entered
Understanding functionalities
Example: Rental Car Application
1. Validate that a Rental can occur.
1.4 Open a Rental ticket
1.4.1 Validate that a customer record can be entered
1.4.1.1 Validate that a new customer can be added to the customer table
1.4.1.1.1 Validate that the first name is all alpha
1.4.1.1.2 Validate that the age is > 21.
1.4.1.1.3 Validate that the phone number is Numeric
1.4.1.1.4 Validate area code is an existing area code number.
1.4.1.2 Validate changing an existing customer
In the above example Validate that a Rental can occur is a Business/functional Requirement.
From the business requirements, scenarios which are high level testable conditions are derived.
In this example Validate that a new customer can be added to the customer table is a
Scenario.
We have multiple conditions to be checked under this scenario like Validate that the phone
number is numeric which is nothing but a test case.
Example 2:
Consider the following set of requirements as an example:
Requirements for calculating Car Insurance Premiums:
R00101 For females less than 65 years of age, the premium is $500
R00102 For males less than 25 years of age, the premium is $3000
R00103 For males between 25 and 64 years of age, the premium is $1000
R00104 For anyone 65 years of age or more, the premium is $1500
Previous
Test Step
Next
Effective way of writing Test cases
Go to Doubts
included. Which field has to be verified for what value has to be explained clearly.
Embed Test Data: Test Data to be used for each of the Test Step should be provided.
Track Test Case changes: Maintain Test Case history to capture changes made to Test
Cases
Others will execute your test cases: Test cases should be written presuming others will
Example: TC_Login_REQ1_3. In this Test Case name, Login page is being tested and
requirements Req-01 and Req-03 are being covered.
100% Requirement Coverage is a must: Check and ensure 100% requirement coverage
and track the requirements covered. Test cases written should be tracked with a Requirements
traceability matrix.
Reusable Test Steps: Common and repeated Test Steps can be made as reusable and can
Example Login, Logout and other common Test Steps can be made as reusable Test Steps and
can be called in other Test Cases.
Test Case review is a must: Ensure that all the test cases are reviewed by required stake
holders (peer reviewed or SME reviewed or client review)
Language Usage: Use Simple and Easy-to-Understand language and use Active voice while
writing test cases
Example:
o Click on OK button
o Navigate to the account Summary page.
Verify word Must: Use words like Verify for starting any sentence in Test Case description
Example:
Verify whether the account information gets displayed on clicking the
Account Summary menu
Future Tense Words for Expected Result: Use always words like Should and Must for
Expected Results.
Example:
o The application should display the account information screen
Go to Doubts
Let's consider an example, If a client says that they want a system to acquire feedback from
their customers then this can be termed as their requirement which requires efforts from
technical team to convert the requirement into the application like feedback portal.
Requirement can be classified into two broad categories
Functional Requirements: These requirements are the desired functionality that the client
operational requirements.
Requirement analysis involves regular interaction with the client to determine their
expectations.
Analysis includes providing visual representations such as screen layouts, UML diagrams etc
for defining the boundaries of the system.
It clearly defines the in scope and out of scope of the system and helps in communicating the
During requirement gathering, If the client is not able to provide the exact details that is
Home
See Leaderboard
Go to Doubts
Go to Doubts
When a defect in the code is executed, the system will fail to do what it is intended to do.
Defects may result in failures, but not all defects lead to failures. Failures can also happen
because of changing hardware conditions.
Defect may occur because of the following reasons like
Fallible nature of human beings
Time pressure
Complex code
Complexity of infrastructure
Changed technologies
Many system interactions etc
See Leaderboard
Go to Doubts
The following category of test cases are not suitable for automation:
Test Cases that are newly designed and not executed manually at least once
Test Cases for which the requirements are changing frequently
Test cases which are executed on ad-hoc basis.
Usability Test cases
Automation Process:
Next
Benefits of Automation Testing
My Doubts
Some more advantages of automation testing over manual testing are mentioned below.
Saves Time and Cost: Automation testing is much faster than manual testing. Hence greater
benefit in saving time and cost.
Improves accuracy
Reduction in Human resources: Human Intervention is not required while execution which in
turn reduces human resources.
Increases Efficiency
tion Testing
Assurance - All Chapters
Home
See Leaderboard
Debug feature available in the tool. It should be easy to debug the automation software
scripts.
Extensive test reports and results
Previous
Benefits of Automation Testing
Next
Testing Tools
Test Management tools: Following are some of the Test Management &
Defect Management Tools
HP Quality Center
TCS Application Life Cycle Manager
IBM Rational Quality Manager
Test Link
Performance Testing tools: Following are the some of the tools which can be used for
Performance Automation testing:
LoadRunner
Silk test performer
IBM Rational performance tester
Open STA
Webload