Test Plan Overview: V Model and Waterfall Model

http://www.h2database.com/html/grammar.
html
V Model and Waterfall Model

The Waterfall Model
This is one of the first models of software development, presented by B.W.Boehm. The Waterfall
model is a step-by-step method of achieving tasks. Using this model, one can get on to the next
phase of development activity only after completing the current phase. Also one can go back
only to the immediate previous phase.
In Waterfall Model each phase of the development activity is followed by the Verification and
Validation activities. One phase is completed with the testing activities, then the team proceeds
to the next phase. At any point of time, we can move only one step to the immediate previous
phase. For example, one cannot move from the Testing phase to the Design phase.
'V' Model
Many of the process models currently used can be more generally connected by the 'V' model
where the 'V' describes the graphical arrangement of the individual phases. The 'V' is also a
synonym for Verification and Validation.
By the ordering of activities in time sequence and with abstraction levels the connection
between development and test activities becomes clear. Oppositely laying activities complement
one another (i.e.) server as a base for test activities. For example, the system test is carried out
on the basis of the results specification phase.
Sections of a Test Plan
Test plan overview

The test plan describes the scope of the overall test effort and provides a record of the test
planning process. The test plan can be configured to meet the needs of your team. Typically, a
test plan identifies requirements, risks, test cases, the test environments to be tested, business and
quality objectives, test schedules, and other items. Related test plans can be grouped together in a
nested master-child relationship.
Test plan sections

A test plan in IBM® Rational® Quality Manager includes several predefined sections.
Each section includes its own editor. Some sections, such as the Business Objectives and Test
Objections sections, consist of a rich-text editor for text input. These editors provide common
formatting features such as table support, font support, bullets, and numbered lists.
Other test plan sections, such as the Requirements and Tests Cases sections, provide links to
these additional test artifacts.
Still other sections include tables that establish and measure against criteria such as Exit Criteria,
Entrance Criteria, Quality Objectives, and Test Schedules.
You can add your own sections and remove sections that you do not need using the Manage
Sections feature.
Test plan templates

A test plan is based on a test plan template. When you create a new test plan, you choose a
template to base it on. You can start a new test plan with one of the default templates, or you can
create new ones. You can also designate which templates are the default.
A test plan template is a collection of test plan sections. You create a template by adding and
removing existing sections or creating new sections. If the section names do not match what you
are accustomed to, create new sections and add them to a template.
Each test organization can design their own test templates. This flexibility makes the test plan
suitable for both agile and formal test teams and for teams that perform different kinds of testing,
such as functional regression testing, performance testing, system verification testing,
globalization testing, and so on.
Test plan categories

Test plan categories are used in the Summary section of a test plan.
You can use test plan categories to help organize your test plans into logical groups. Later, when
you use the All Test Plans feature to list all of your test plans, you can sort the listing using the
categories.
By default, two test plan categories are provided: Product and Release. You can add your own
products to the Product category and your own Release numbers. You can also create your own
categories, such as Test Type, Component, or Division.
Test plan work items

A work item is a way of keeping track of the tasks and issues that your team needs to address.
The status and number of work items are indicators of the health of your project. Out-of-the-box,
Rational Quality Manager includes the following work item types:
 Task-Quality - a specific piece of work usually associated with an artifact such as a test
plan, test case, or test script. For example, when a user is asked to complete a section of a
test plan, that user is assigned a Task-Quality work item.
 Task-Review - a work item assigned to a user who has been asked to review or approve a
particular artifact, such as a test plan or test case.
 Requirement - a requirement created in Quality Manager or imported from a
requirements management tool.
 Defect - A work item used to track a defect in the software under test.
 Task - any other generic work item.
To assign a section of a test plan to another team member, click Work Item: Create on the right
side of the test plan section and specify a summary description, owner, and completion date of
the work item. This results in the creation of a Task-Quality work item.
Test plans and their relationship with other test artifacts

From a test plan you can manage other test artifacts, such as test cases and requirements.
However, it is also possible to use the product without a test plan. The topic on test artifact
relationships describes the relationships between tests plans and other test artifacts, such as test
cases, requirements, test scripts, keywords, test data, and so on.
Test plan tasks

Here are some of the many tasks that you can perform with the Rational Quality Manager test
plan:
 Set up a formal review process that is visible at all times to all members of the larger
project team
 Import project requirements from external requirements management tools and associate
these requirements with test cases
 Create a test plan snapshot and use it as the basis for a new test plan
 Create test cases and associate them with the test plan
 List platform coverage and the various test environments supported and tested by the test
plan
 Estimate the overall test planning and test execution effort
 Define schedules for each test iteration.
 Define business objectives, test objectives, quality goals, and entrance and exit criteria
Below are some key sections that should be part of your test plan:
1. Introduction
2. Purpose
3. Audience – This section should state the groups that the document is written for
4. Abbreviations, Acronyms & Definitions – State the specific terms that will be used in the
document.
5. Requirements for Test – This section should list the project documents (use cases,
functional requirements, non-functional requirements, etc.) that have been identified as
targets for testing.
6. Major Milestones & Dependencies – These are testing milestones with their
dependencies and corresponding start and end dates. These tasks and dates should line up
with the Project Plan
7. Testing Scope – The primary scope of testing should be to ensure the project objectives
and requirements have been met. You should also include the items below so everyone
know what exactly is going to be part of the testing effort.
o List the changes/features that will part of the testing effort
o List the changes/features that will NOT be part of the testing effort
o List the planned testing types
o List the configurations of the testing machines
8. Test Data – In order to test the AUT against the approved requirements there may need to
have new test data created by another group. This section is a good way to list out what
your data requirements are so they can be ready before testing starts.
o List the data requirements for each of the planned testing types
9. Testing Deliverables – This section should specify which testing deliverables will be
created and delivered to the project team.
10. Logical & Physical Environments – This section should specify the different
environments as well as which testing type will be executed in each.
11. Applications Affected – This section should list out any other application affected by the
project from either incoming or outgoing interfaces.
12. Assumptions – This section should list out any & all assumptions that were used to create
the test plan.
13. Resources – This section shows the staffing assumptions for the testing effort. Individuals
may hold multiple roles. Refer to the QA Roles & Responsibilities for definitions of the
responsibilities for each of the roles.
14. Acceptance Section for Sign Offs – After review of the test plan you should request
signoff.
15. Revision History – Just like any other document a revision history is very important so
everyone can see what changes were done and why.
http://www.jayphilips.com/2010/03/12/what-types-of-documents-are-needed-for-
software-testing/
…………………………………………..
The following are some of the items that might be included in a test plan, depending on the
particular project:
• Title
• Identification of software including version/release numbers: Which is the software for which
this document captures the test process
• Revision history of document including authors, dates, approvals: A document could go
through many versions, so this field captures the current version number
• Table of Contents: Very useful, and needed for most documents
• Purpose of document, intended audience
• Objective of testing effort: What should be the goal of the testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans,
etc.: A test plan by itself is not complete, since a project has different areas covered by different
documents
• Relevant standards or legal requirements
• Traceability requirements: Traceability determines how the various requirements are mapped
to the different test plans
• Relevant naming conventions and identifier conventions: Very useful for people not involved
in the preparation of this test plan
• Overall software project organization and personnel/contact-info/responsibilties: Such a
section provides contact details of the key people in the group
• Test organization and personnel/contact-info/responsibilities: The same as above, but covers
people in the testing organization
• Assumptions and dependencies: Assumptions can make a lot of difference to the success and
failure of a project (and its test plan) and need to be carefully validated
• Project risk analysis: Risk analysis provides a good list of items that could cause risk to the
project
• Testing priorities and focus: Any testing process has certain areas of focus (high risk areas, high
impact areas, high change areas), and these need to be highlighted
• Scope and limitations of testing: There are some parts of the testing that may not be able to
be covered, and this section attempts to cover this part
• Test outline – a breakdown of the test approach by test type, feature, functionality, process,
system, module, etc. as applicable
• Data structures – Outline of data input, equivalence classes, boundary value analysis, error
classes
• Details of the Test environment – hardware, operating systems, other required software, data
configurations, interfaces to other systems; all these items should be detailed so that anybody
picking up the test plan will have enough information
• Test environment validity analysis – differences between the test and production systems and
their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes: CM stands for Configuration Management
• Test data setup requirements
• Database setup requirements: If the software requires a database, then these instructions will
be needed
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture
software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help
track the cause or source of bugs
• Test automation – justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution – tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs: For some cases, people doing the testing may need some special
training
• Test site/location: Where will the testing be done. For some specialized equipment, the testing
would need to be done at the location where the equipment is based.
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables,
contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues – These are very important from
a legal point of view
• Open issues
• Appendix – glossary, acronyms, etc.
All of these sections, when completed, will provide a test plan that should be the single
document that will guide the testing process
/////////////////////////////////////////////////////////////////////////////
TEST PLAN TYPES
One can have the following types of test plans:
 Master Test Plan: A single high-level test plan for a project/product that unifies all other
test plans.
 Testing Level Specific Test Plans:Plans for each level of testing.
o Unit Test Plan
o Integration Test Plan
o System Test Plan
o Acceptance Test Plan
 Testing Type Specific Test Plans: Plans for major types of testing like Performance
Test Plan and Security Test Plan.
TEST PLAN TEMPLATE
The format and content of a software test plan vary depending on the processes, standards, and
test management tools being implemented. Nevertheless, the following format, which is based on
IEEE standard for software test documentation, provides a summary of what a test plan
can/should contain.
Test Plan Identifier:
 Provide a unique identifier for the document. (Adhere to the Configuration Management
System if you have one.)
Introduction:
 Provide an overview of the test plan.

 Specify the goals/objectives.
 Specify any constraints.
References:
 List the related documents, with links to them if available, including the following:
o Project Plan
o Configuration Management Plan
Test Items:
 List the test items (software/products) and their versions.
Features to be Tested:
 List the features of the software/product to be tested.

 Provide references to the Requirements and/or Design specifications of the features to be
tested
Features Not to Be Tested:
 List the features of the software/product which will not be tested.

 Specify the reasons these features won’t be tested.
Approach:
 Mention the overall approach to testing.

 Specify the testing levels [if it's a Master Test Plan], the testing types, and the testing
methods [Manual/Automated; White Box/Black Box/Gray Box]
Item Pass/Fail Criteria:
 Specify the criteria that will be used to determine whether each test item
(software/product) has passed or failed testing.
Suspension Criteria and Resumption Requirements:
 Specify criteria to be used to suspend the testing activity.

 Specify testing activities which must be redone when testing is resumed.
Test Deliverables:
 List test deliverables, and links to them if available, including the following:
o Test Plan (this document itself)
o Test Cases
o Test Scripts
o Defect/Enhancement Logs
o Test Reports
Test Environment:
 Specify the properties of test environment: hardware, software, network etc.

 List any testing or related tools.
Estimate:
 Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed
estimation.
Schedule:
 Provide a summary of the schedule, specifying key test milestones, and/or provide a link
to the detailed schedule.
Staffing and Training Needs:
 Specify staffing needs by role and required skills.

 Identify training that is necessary to provide those skills, if not already acquired.
Responsibilities:
 List the responsibilities of each team/role/individual.
Risks:
 List the risks that have been identified.

 Specify the mitigation plan and the contingency plan for each risk.
Assumptions and Dependencies:
 List the assumptions that have been made during the preparation of this plan.
 List the dependencies.
Approvals:
 Specify the names and roles of all persons who must approve the plan.
 Provide space for signatures and dates. (If the document is to be printed.)
TEST PLAN GUIDELINES
 Make the plan concise. Avoid redundancy and superfluousness. If you think you do not
need a section that has been mentioned in the template above, go ahead and delete that
section in your test plan.
 Be specific. For example, when you specify an operating system as a property of a test
environment, mention the OS Edition/Version as well, not just the OS Name.
 Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
 Have the test plan reviewed a number of times prior to baselining it or sending it for
approval. The quality of your test plan speaks volumes about the quality of the testing
you or your team is going to perform.
 Update the plan as and when necessary. An out-dated and unused document stinks and is
worse than not having the document in the first place.
Defect Life Cycle and Defect Status – Difference between Severity and Priority
Defect Life Cycle

Life cycle of a Software Defect/Bug:
Defect Life Cycle (Bug Life cycle) is the journey of a defect from its identification to its closure.
The Life Cycle varies from organization to organization and is governed by the software testing
process the organization or project follows and/or the Defect tracking tool being used.
Nevertheless, the life cycle in general resembles the following:
Status Alternative Status
NEW
ASSIGNED OPEN
DEFERRED
DROPPED REJECTED
COMPLETED FIXED, RESOLVED, TEST
REASSIGNED REOPENED
CLOSED VERIFIED
Defect Status Explanation
 NEW: Tester finds a defect and posts it with the status NEW. This defect is yet to be
studied/approved. The fate of a NEW defect is one of ASSIGNED, DROPPED and DEFERRED.
 ASSIGNED / OPEN: Test / Development / Project lead studies the NEW defect and if it is found to
be valid it is assigned to a member of the Development Team. The assigned Developer’s
responsibility is now to fix the defect and have it COMPLETED. Sometimes, ASSIGNED and OPEN
can be different statuses. In that case, a defect can be open yet unassigned.
 DEFERRED: If a valid NEW or ASSIGNED defect is decided to be fixed in upcoming releases
instead of the current release it is DEFERRED. This defect is ASSIGNED when the time comes.
 DROPPED / REJECTED: Test / Development/ Project lead studies the NEW defect and if it is
found to be invalid, it is DROPPED / REJECTED. Note that the specific reason for this action needs
to be given.
 COMPLETED / FIXED / RESOLVED / TEST: Developer ‘fixes’ the defect that is ASSIGNED to him or
her. Now, the ‘fixed’ defect needs to be verified by the Test Team and the Development Team
‘assigns’ the defect back to the Test Team. A COMPLETED defect is either CLOSED, if fine, or
REASSIGNED, if still not fine.
 If a Developer cannot fix a defect, some organizations may offer the following statuses:
o Won’t Fix / Can’t Fix: The Developer will not or cannot fix the defect due to some
reason.
o Can’t Reproduce: The Developer is unable to reproduce the defect.
o Need More Information: The Developer needs more information on the defect from the
Tester.
 REASSIGNED / REOPENED: If the Tester finds that the ‘fixed’ defect is in fact not fixed or only
partially fixed, it is reassigned to the Developer who ‘fixed’ it. A REASSIGNED defect needs to be
COMPLETED again.
 CLOSED / VERIFIED: If the Tester / Test Lead finds that the defect is indeed fixed and is no more
of any concern, it is CLOSED / VERIFIED. This is the happy ending.
Priority
This field describes the importance and order in which a bug should be fixed compared to other
bugs. This field is utilized by the programmers/engineers to prioritize their work to be done.
Severity
This field describes the impact of a bug.
blocker Blocks development and/or testing work
critical crashes, loss of data, severe memory leak
major major loss of function
normal regular issue, some loss of functionality under specific circumstances
minor minor loss of function, or other problem where easy workaround is present
trivial cosmetic problem like misspelled words or misaligned text
Request for enhancement
enhancement
What is the difference between severity and priority?

Severity Value : S1 : Catastrophic Blocking :
The use case cannot be completed with any level of workaround. Problem causes data loss, corruption,
or distortion. There is defective program functionality with no workaround. A system or product crash or
fatal error occurs. Program produces an incorrect result, particularly when the result could cause an
incorrect business decision to be made. Problem causes inability to use the product further. Problem
results in considerable performance degradation, (i.e., 3+ times longer than requirement). The error will
definitely cause a customer support call. A severity 1 bug would prevent the product from being
released.
Severity Value : S2 :Serious (Critical/Major) :

The failure is severe and can be avoided with some level of workaround. There must be some means of
completing the use case, however,the workaround is undesirable.. Program does not function according
to product or design specifications. Product produces data or results that are misleading to the user.
Problem results in performance degradation that is less than required (i.e., takes twice as long). There is
a serious inconsistency or inconvenience. Problem is likely to cause a customer support call.
Severity Value : S3 : Normal

Soft failure, the main flow of the use case works but there are behavioral or data problems.
Performance may be less then desired.Problem is a of less intensity or typographical issue. There is a
minor functional problem with a reasonably satisfactory workaround. Problem is a minor inconvenience.
Problem is a non-intuitive or clumsy function. Problem is not likely to cause a customer support call. A
defect that causes the failure of non-critical aspects of the system. . The product may be released if the
defect is documented but the existence of the defect may cause customer dissatisfaction.
Severity Value : S4 : Small (Minor) :

There is no failure, the use case completes as designed. Fix would slightly improve the use case behavior
or performance. A minor condition or documentation error that has no significant effect on the
Customer's operations. Also: Additional requests for new features and suggestions, which are defined as
new functionality in existing License Software.Generally, the product could be released and most
customers would be unaware of the defect's existence of only slightly dissatisfied.Such defects do not
affect the release of the product.
Priority Value : P1 :
FIX the bug ASAP
Bug can be fixed before current itteration/minor release.
The bug is very minor. A fix for this defect is not expected during the current itteration/minor release.
This defect does not need to be addressed in the current final release.
Type Of Defect :
High Severity & Low Priority (S1/S2 & P4) :
1) An application which generates some banking related reports weekly, monthly, quarterly & yearly by
doing some calculations. If there is a fault while calculating yearly report. This is a high severity fault but
low priority [Exception : If this defect is discovered during last week of the year] because this fault can
be fixed in the next release as a change request.2) An inability to access a rarely used menu option may
be of low priority to the business, but the severity is high as a series of tests cannot be executed, all
dependent on access to the option.
High Severity & High Priority (S1/S2 & P1) :

1) If there is a fault while calculating weekly report. This is a high severity and high priority fault because
this fault will block the functionality of the application immediately within a week. It should be fixed
urgently.
Low Severity & High Priority(S4 & P1):

1) If there is a spelling mistake or content issue on the homepage of a website which has daily hits of
lakhs. In this case, though this fault is not affecting the website or other functionalities but considering
the status and popularity of the website in the competitive market it is a high priority fault.
2) A spelling mistake would be deemed as a low severity by the tester, but if this mistake occurs in the
company name or address, this would be classed as high priority by the business.
Low Severity & Low Priority(S4 & P4) :

1) If there is a spelling mistake on the pages which has very less hits throughout the month on any
website. This fault can be considered as low severity and low priority.
/////////////////////////////////////////////////////
Exit and Entry Criteria

The Entrance Criteria specified by the system test controller, should be fulfilled before System Test can
commence. In the event, that any criterion has not been achieved, the System Test may commence if
Business Team and Test Controller are in full agreement that the risk is manageable.
* All developed code must be unit tested. Unit and Link Testing must be completed and signed off by
development team.
* System Test plans must be signed off by Business Analyst and Test Controller.
* All human resources must be assigned and in place.
* All test hardware and environments must be in place, and free for System test use.
* The Acceptance Tests must be completed, with a pass rate of not less than 80%.
The Exit Criteria detailed below must be achieved before the Phase 1 software can be recommended for
promotion to Operations Acceptance status. Furthermore, I recommend that there be a minimum 2
days effort Final Integration testing AFTER the final fix/change has been retested.
* All High Priority errors from System Test must be fixed and tested
* If any medium or low-priority errors are outstanding - the implementation risk must be signed off as
acceptable by Business Analyst and Business Expert
* Project Integration Test must be signed off by Test Controller and Business Analyst.
* Business Acceptance Test must be signed off by Business Expert.
Entry criteria:
1)All source codes are unit tested
2)All QA resource has enought functional knowledge
3)H/W and s/w are in place
4)Test plans and test cases are reviewed and signed off
Exit criteria:
1)No defect over a period of time or testing effort
2)Planned deliverable is ready
3)High severity defects are fixed
Use Cases and Test Scenarios

1. Use case:
It will be developed by Business Analyst based on the requirement specification.
It is a detailed description of the Specification in a simplified version with realtime
scenarios.
Based on Use case, test cases will be written by the testers.
Each use case have some preconditions and post conditions.
2.Scenario:
While writing a test case for a module, you write different tests for that module say,
Creating a user.
There may be several ways to create a user like, creating a user thru wizard or thru
uploading set of users.
These are all the things we can call as a scenario. This is the literal meaning.
Test case:
What are all the steps we should follow for creating a user using a wizard and
What are all the steps we should follow for creating a user using upload are called as
test case.
Use Case: A UML element for capturing the requirements of a system. Each Use Case Element
represents a user's goal when interacting with the system.
Actor: A UML element representing the role of a person, object or device that interacts with a
system.
Use Case Diagram: A UML behavior diagram that visually describes the functional requirements of
a
proposed system and shows the relationships between Actors and Use Cases.
Scenario: A brief user story explaining who is using the system and what they are trying to
accomplish.
Step: A Scenario is made up of a number of simple, discrete steps that are designated as being
performed by either the “System” or a “ User”. In Enterprise Architect, each step may reference
Results,
Uses and State information to provide greater context and improved traceability.
Basic Path: Describes the sequence of events when everything goes as expected. Also known as
the
“Happy Path”, “Basic Course”, “Sunny Day Scenario”, “Primary Path” or “Expected Path”.
Alternate Path: Each tested rule may produce an Alternative Path, with an alternative set of steps
that
run in parallel with part of the Basic Path.
Exception Path: The result of a step in the Basic Path that fails to produce a successful result.
Test Case: A specific executable test that examines inputs and outputs to determine whether a
system is
working correctly. Test Cases can be automatically derived from a Structured Scenario.
Activity Diagram: A UML diagram used to display the sequence of activities. Ideal for detailing
situations where parallel processing (eg. Alternative Paths) may occur. Each Activity is represented
by a
rounded rectangle, while Decision and Merge nodes are represented by a diamond
shape.
When to Start Testing and when to Stop

Testing strats from the reqiurment analysis so we should able to write the test case for the reqirement
How to write test cases from requirements

Requirements should represent exact functionality of AUT.
First of all you have to analyse the requirement very throughly in terms of functionality. Then you
have to think about suitable testcase design techniques (Black Box design techniques like Equivalance
Partitioning, Boundry Value Analysis, Error Guessing and Cause Effect Graphing) for writing the
testcase.
By these concepts you should write a testcase which should have the capability of finding the absence
of defects.
To answer your first question, the requirements are authored by someone in the business sector who
has worked closely with customers or client to bring together everything that has been disclosed to
fulfill what the customer requires. These requirements are typically written in the form of use cases--
narratives that describe how the system is to be used from a customer-centric perspective. Each use
case is broken down into individually testable functionalities. If the functionality is complex, it is a good
idea to create a work-flow diagram or activity diagram and let the author of the use case review it for
accuracy. This diagram will illustrate the various paths that will need to be tested.
Remember, the requirements don't cover all of your tests cases. You may also need to create test cases
from the specifications as well.
Testing strats from the reqiurment analysis so we should able to write the test case for the requirement
1. Differentiate different Modules, then different forms in those modules

2. Check if application is made for all sort of users or there is any particular access rights
to particular user for example which forms can be accessible by admin and which are
accessible by all other users.
3. General Page Appearance Requirements
4. Positive test cases / negative test case
5. Take one example of login page, check password limit and validations for it.
Test Set - is nothing but set of test data

Test bed - is test environment
Test Suite - Numbers of test cases to be executed
Test Module - is the piece of develped software delivered to the test team
Requirement Coverage and Test coverage

What is test coverage??
Simply put, code coverage is a way of ensuring that your tests are actually testing your code. When you
run your tests you are presumably checking that you are getting the expected results. Code coverage
will tell you how much of your code you exercised by running the test. Your tests may all pass with flying
colours, but if you've only tested 50% of your code, how much confidence can you have in it?
Answer
The aim of coverage based testing method is to 'cover'

the
program with test cases that satisfy some fixed coverage
criteria.
Coverage base testing criteria are:
Statement Coverage or Node Coverage

Branch coverage or Decision Coverage
Decision/Condition Coverage
Multiple Condition Coverage
Path Coverage
Requirement Coverage:
The coverage of requirements is a fundamental need throughout the software life cycle. Be it
during design, coding or testing, the ability to ensure that the software meets the expected
requirements is something that every developer and project manager aspires for. However, the
challenge is how do we as developers or project managers ensure that the piece of software delivered
did meet all the requirements? As a client, how do I make sure that the outsourced requirements are
being delivered? Moreover, as the software matures and goes into several iterations of enhancements
and bug fixes, it becomes more and more daunting to ensure requirement coverage in the software.
Several techniques and tools have been invented to target requirement coverage. Some tools offer the
capability of mapping requirements to the other project artifacts, such as, use cases, test cases and
design documents. Some projects prefer to follow simple spreadsheet based traceability matrix of
requirements to various other artifacts. As the project enters the coding phase, maintaining
requirement coverage becomes even more challenging. Many a times the individual developers may not
be the requirements experts. However, they are supposed to deliver what the requirements demand
from the software. Also, they may not be using the same requirement coverage tool or techniques on a
daily basis that were used in the earlier phases of the project.
What is Boundary Value analysis and Equivalence Partitioning?

Equivalence Partitioning:
The idea behind the technique is to divide or partition a set of test conditions into groups or
sets that can be considered the same or equivalent, hence ‘equivalence partitioning’. Equivalence
partitions are also known as equivalence classes, the two terms mean exactly the same thing.
Boundary value analysis:
It is based on testing on and around the boundaries between partitions. If you have done “range
checking”, you were probably using the boundary value analysis technique, even if you weren’t
aware of it. Note that we have both valid boundaries (in the valid partitions) and invalid
boundaries (in the invalid partitions).
What is Boundary value analysis and

Equivalence partitioning?
Posted In | Questions & answers, Testing Concepts, Testing Interview questions
Boundary value analysis and Equivalence partitioning, explained with simple example:
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.
In short it is the process of taking all possible test cases and placing them into classes. One test
value is picked from each class while testing.
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 single value from range 1 to 1000 as a valid
test case. If you select other values between 1 and 1000 then result is going to be same. 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.
So using equivalence partitioning you have categorized all possible test cases into three classes.
Test cases with other values from any class should give you the same result.
We have selected one representative from every input class to design our test cases. Test case
values are selected in such a way that largest number of attributes of equivalence class can be
exercised.
Equivalence partitioning uses fewest test cases to cover maximum requirements.
Boundary value analysis:
It’s widely recognized that 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.
Boundary value analysis is often called as a part of stress and negative testing.
Note: There is no hard-and-fast rule to test only one value from each equivalence class you
created for input domains. You can select multiple valid and invalid values from each
equivalence class according to your needs and previous judgments.
E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you can select test
case values like: 1, 11, 100, 950 etc. Same case for other test cases having invalid data classes.
This should be a very basic and simple example to understand the Boundary value analysis and
Equivalence partitioning concept.
We will understand what is Equivalence partitioning and Boundary Value analysis.
Equivalence partitioning : is a testing technique where input values required for testing are
grouped into two classes
1. Valid Inputs Class: Class which holds all the valid inputs.
2.Invalid Inputs Class: Class which holds all the Invalid inputs
Eg; To Check the Password which can accept all the characters except underscore("_") and
Semicolon(";")
and which accepts characters length 6 and maximum 12.
We Define a Equivalence classes

Now to perform positive testing, Consider set of values from class EC1,When the password is
entered "Password is accepted"
To perform Negative Testing choose the values from class EC2 and EC3, When the password is
entered from these classes "Password shall not be accepted by the System"
Boundary Value analysis : Is a testing technique , where values for testing are chosen from the
class which falls within different boundries
Eg; To test the password field which accepts minimum of 6 characters and Maximum of 12
Characters.
We will define the boundary of each class of Inputs
To satisfy Boundary value, tester will have to write Test Cases considering values from Valid
region and each Invalid Region and Values which define exact boundary.
For our example we require 5 Test Cases
1. Consider password length less than 6
2. Consider password of length exactly 6
3. Consider password of length between 7 and 11
4. Consider password of length exactly 12
5. Consider password of length more than 12
Note : 1st and 5th Test Cases are considered for Negative Testin
/////////////////////////////////////////////////////////////////////////////////////
Build Release and Cycles – How does code move and how is project planning done
Time based release trains have been shown to produce the best quality Free software. A time based
release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on
time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing.
It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases
based on the previous stable version. Thus if you have a need for the very highest quality version, it can
make sense to defer a move until the first or perhaps second minor point release.
Difference between build and release and versioning?
Build is a Executable file which is handed over to the tester to test the functionlity of the developed part
of the project.
Release is that which we finally hand it over to the client of the project after the develpoment and
testing phases are completed.
Versions are based on builds (and not vice versa)
Version is the number of releases made according to the

addition of the requirement of the client.
Eg of the Version [ Product] may be diff versions of

Automation Tools like Win-Runner 7.0 , Win-Runner 8.0 etc
What kind of testing is required during the build and release phase of a project?
I am going to make some presumptions because the shops I work in, and have worked in, do not
use that specific term, and I want to be clear on the context in which I answer this question. I
presume that you are approaching this as related to, or part of, Continuous Integration. (In this
case, we call it generically “build & testing.”)
First, “What kind of testing is required?” Simply put: None. You don’t need to test. There may
be business needs or legal requirements you must meet, but that will vary by context. Likewise,
there may be business and legal ramifications if you do not test. Again, that will vary by context.
Having said that, most of us find we should do some checking – that is, machine-driven checks
against specific expected results for specific conditions as opposed to testing with a human being
involved, even if it is only reviewing results from each run (for the sake of convenience, I’ll call
these checks “tests,” even though I really don’t think they are.)
There are some types of tests that I suspect are a generally good idea. I believe that unit tests
designed around each of the components is a good start. That seems pretty obvious to most, no?
Then you might add some simple tests around basic functions and exercising basic integration of
the individual units and building toward logical function and function integration tests. Building
levels of complexity in the tests may help in establishing some level of confidence in the build
being generated.
Some warnings around these ideas: First, the higher level the tests, in my experience, the greater
the likelihood of false alarms in the results. This may lead to the temptation to allow for
“variances” to by-pass some of these tests as “getting in the way.” Some of these variances may
be legitimate, some will need closer scrutiny. The Build Master will need to consider how these
situations need to be balanced.
Looking at these in turn, one great challenge to creating tests to support CI efforts is to make
tests that will be relevant and meaningful. The more complex or high-level you make your tests,
the greater the likelihood that they will encounter difficulties and trip false errors. The more
times your tests “cry wolf” with false errors, the more likely it is that legitimate problems will be
overlooked, if not lost in the chatter of false failure reports.
Finally, a general cautionary note. Too often people rely on these automated checks to do all
their testing. This is a potentially a dangerous idea. These tests cannot replace the work done by
skilled testers in critically measuring and critiquing a system or application. I have encountered
programmer/developers who argue that the test group must have done something wrong, because
the build tests all “worked.” Alas, that may need discussion another time except to say, “Do not
fall into that trap.”
A software release life cycle is the sum of the phases of development and maturity for a piece of
computer software: ranging from its initial development to its eventual release, and including
updated versions of the released version to help improve software or fix bugs still present in the
software.
Contents
 1 Stages of development
o 1.1 History
o 1.2 Pre-alpha
o 1.3 Alpha
o 1.4 Beta
 1.4.1 Open and closed beta
 1.4.2 Impact of the World Wide Web
o 1.5 Release candidate
 2 Release
o 2.1 Release to manufacturing (RTM)
o 2.2 General availability (GA)
o 2.3 Release to web
 3 Support
o 3.1 End-of-life
 4 See also
 5 References
 6 Bibliography
 7 External links
Stages of development
History
The origin of the "alpha/beta" test terminology is IBM. As long ago as the 1950's (and probably
earlier), IBM used similar terminology for their hardware development. "A" test was the
verification of a new product prior to public announcement. "B" test was the verification prior to
releasing the product to be manufactured. And "C" test was the final test prior to general
availability of the product. As software became a significant part of IBM's offerings, the alpha
test terminology was used to denote the pre-announcement test and beta test was used to show
product readiness for general availability. Martin Belsky, a manager on some of IBM's earlier
software projects claimed to have invented the terminology. IBM dropped the alpha/beta
terminology during the 1960's, but by then it had gotten fairly wide notice. The usage of "beta
test" to refer to testing done by customers was not done in IBM. Rather, IBM used the term
"field test." .[1]
Pre-alpha
Pre-alpha refers to all activities performed during the software project prior to testing. These
activities can include requirements analysis, software design, software development, and unit
testing. In typical open source development, there are several types of pre-alpha versions.
Milestone versions include specific sets of functions and are released as soon as the functionality
is complete.
Alpha
The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the
first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test
the software using white box techniques. Additional validation is then performed using black box
or gray box techniques, by another testing team. Moving to black box testing inside the
organization is known as alpha release.[2]
Alpha software can be unstable and could cause crashes or data loss. The exception to this is
when the alpha is available publicly (such as a pre-order bonus), in which developers normally
push for stability so that their testers can test properly. External availability of alpha software is
uncommon in proprietary software. However, open source software, in particular, often have
publicly available alpha versions, often distributed as the raw source code of the software. The
alpha phase usually ends with a feature freeze, indicating that no more features will be added to
the software. At this time, the software is said to be feature complete.
Beta
Beta (named after the second letter of the Greek alphabet) is the software development phase
following alpha. It generally begins when the software is feature complete. Software in the beta
phase will generally have many more bugs in it than completed software, as well as
speed/performance issues. The focus of beta testing is reducing impacts to users, often
incorporating usability testing. The process of delivering a beta version to the users is called beta
release and this is typically the first time that the software is available outside of the organization
that developed it.
The users of a beta version are called beta testers. They are usually customers or prospective
customers of the organization that develops the software, willing to test the software without
charge, often receiving the final software free of charge or for a reduced price. Beta version
software is often useful for demonstrations and previews within an organization and to
prospective customers. Some developers refer to this stage as a preview, prototype, technical
preview (TP), or early access. Some software is kept in perpetual beta—where new features and
functionality are continually added to the software without establishing a firm "final" release.
Open and closed beta
Developers release either a closed beta or an open beta; closed beta versions are released to a
restricted group of individuals for a user test by invitation, while open beta testers are from a
larger group, or anyone interested. The testers report any bugs that they find, and sometimes
suggest additional features they think should be available in the final version. Examples of a
major public beta test are:
 In September 2000 a boxed version of Apple's Mac OS X Public Beta operating system was
released.[3]
 Microsoft's release of community technology previews (CTPs) for "Longhorn" in January 2005.[4]
Open betas serve the dual purpose of demonstrating a product to potential consumers, and testing
among an extremely wide user base likely to bring to light obscure errors that a much smaller
testing team might not find.
Impact of the World Wide Web
As the Internet has facilitated rapid and inexpensive distribution of software, companies have
begun to take a looser approach to use of the word "beta".[5] Netscape Communications was
infamous for releasing alpha level versions of its Netscape web browser to the public and calling
them "beta" releases.[citation needed] In February 2005 ZDNet published an article about the recent
phenomenon of a beta version often staying for years and being used as if it were in production
level, disparagingly called "perpetual beta". It noted that Gmail and Google News, for example,
had been in beta for a long period of time and were not expected to drop the beta status despite
the fact that they were widely used; however, Google News did leave beta in January 2006,
followed by Google Apps, including Gmail, in July 2009.[6] This technique may allow a
developer to delay offering full support and responsibility for remaining issues. In the context of
Web 2.0, people even talk of perpetual betas to signify that some software is meant to stay in
beta state. Also, "beta" is sometimes used to indicate something more like a release candidate, or
as a form of time limited demo, or marketing technique.[7]
Release candidate
A release candidate (RC) is a beta version with potential to be a final product, which is ready to
release unless significant bugs emerge. In this stage of product stabilization, all product features
have been designed, coded and tested through one or more beta cycles with no known
showstopper-class bug. A release is called code complete when the development team agrees
that no entirely new source code will be added to this release. There could still be source code
changes to fix defects, changes to documentation and data files, and peripheral code for test
cases or utilities.
Some users disparagingly refer to release candidates and even final "point oh" releases as
"gamma test" software, suggesting that the developer has chosen to use its customers to test
software that is not truly ready for general release. Beta testers, if privately selected, will often be
credited for using the release candidate as though it were a finished product. Beta testing is
conducted in client's or customer's location and to test the software from users perspective.
Release
Release to manufacturing (RTM)
The term "release to manufacturing" or "release to marketing"[citation needed] (both abbreviated

RTM, initials also commonly used for the quite different "return to manufacturer" of faulty
goods)—also known as "going gold"—is a term used when software is ready for or has been
delivered or provided to the customer. It is typically used in certain retail mass-production
software contexts—as opposed to a specialized software production or project in a commercial
or government production and distribution—where the software is sold as part of a bundle in a
related computer hardware sale and typically where the software and related hardware is
ultimately to be available and sold on mass/public basis at retail stores to indicate that the
software has met a defined quality level and is ready for mass retail distribution. RTM could also
mean in other contexts that the software has been delivered or released to a client or customer for
installation or distribution to the related hardware end user computers or machines. The term
does not define the delivery mechanism or volume; it only states that the quality is sufficient for
mass distribution. The deliverable from the engineering organization is frequently in the form of
a gold master CD used for duplication or to produce the image for the web. RTM precedes
general availability (GA), when the product is released to the public.
General availability (GA)
General availability or general acceptance[citation needed] (GA) is the point where all necessary
commercialization activities have been completed and the software has been made available to
the general market either via the web or physical media.
Commercialization activities could include but are not limited to the availability of media world
wide via dispersed distribution centers, marketing collateral is completed and available in as
many languages as deemed necessary for the target market, the finishing of security and
compliance tests, etc. The time between RTM and GA can be from a week to months in some
cases before a generally available release can be declared because of the time needed to complete
all commercialization activities required by GA.
It is also at this stage that the software is considered to have "gone live". The production, live
version is the final version of a particular product. A live release is considered to be very stable
and relatively bug-free with a quality suitable for wide distribution and use by end users. In
commercial software releases, this version may also be signed (used to allow end-users to verify
that code has not been modified since the release). The expression that a software product "has
gone live" means that the code has been completed and is ready for distribution. Other terms for
the live version include live master, live release, and live build.
In some areas of software development it is at this stage that the release is referred to as a grand
or gold release; the latter seems to be confined mainly to game software though Apple also refer
to GM (gold master) releases. Some release versions might be classified as a long term support
(LTS) release, which should guarantee the ability to upgrade to the next LTS release and will be
supported/updated/patched for a longer time than a non-LTS release.
Release to web
Release to web or web release is a means of software delivery that utilizes the Internet for
distribution. No physical media are produced in this type of release mechanism by the
manufacturer. Web releases became more common as Internet usage grew.
Support
During its supported lifetime, software is sometimes subjected to service releases, or service
packs, sometimes also called "interim releases". For example, Microsoft's Windows XP
operating system had three major service packs during its lifetime. Such service releases contain
a collection of updates, fixes and enhancements, delivered in the form of a single installable
package. They may also implement new features. Some software is released with the expectation
of regular support. Classes of software that generally involve protracted support as the norm
include anti-virus suites and massively multiplayer online games. A good example of a game that
utilizes this process is Minecraft, an Indie Game created by Markus Persson, which features
regular "updates" featuring new content and bug fixes.
End-of-life
See also: End-of-life (product) and abandonware
When software is no longer sold or supported, the product is said to have reached end-of-life, to
be discontinued or obsolete, but user loyalty may continue its existence for some time, even long
after its platform is obsolete—e.g., the Atari ST and Commodore's Amiga.
What are different Project Risks
Types of Risks in Software Projects

Posted In | Basics of Software testing, Quality assurance, Test strategy
Are you developing any Test plan or test strategy for your project? Have you addressed all risks
properly in your test plan or test strategy?
As testing is the last part of the project, it’s always under pressure and time constraint. To save
time and money you should be able to prioritize your testing work. How will prioritize testing
work? For this you should be able to judge more important and less important testing work. How
will you decide which work is more or less important? Here comes need of risk-based testing.
What is Risk?
“Risk are future uncertain events with a probability of occurrence and a potential for loss”
Risk identification and management are the main concerns in every software project. Effective
analysis of software risks will help to effective planning and assignments of work.
In this article I will cover what are the “types of risks”. In next articles I will try to focus on
risk identification, risk management and mitigation.
Risks are identified, classified and managed before actual execution of program. These risks are
classified in different categories.
Categories of risks:
Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed
properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project
failure.
Schedules often slip due to following reasons:
 Wrong time estimation

 Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
 Failure to identify complex functionalities and time required to develop those functionalities.
 Unexpected project scope expansions.
Budget Risk:
 Wrong budget estimation.

 Cost overruns
 Project scope expansion
Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events
risks.
Causes of Operational risks:
 Failure to address priority conflicts

 Failure to resolve the responsibilities
 Insufficient resources
 No proper subject training
 No resource planning
 No communication in team.
Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
 Continuous changing requirements

 No advanced technology available or the existing technology is in initial stages.
 Product is complex to implement.
 Difficult project modules integration.
Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are
outside the control of the program.
These external events can be:
 Running out of fund.

 Market development
 Changing customer product strategy and priority
 Government rule changes.
The simple differences between Product

Risks & Project Risks
By Joel Montvelisky on January 3, 2009 in Bug Reporting, Management, Test Process
Going into the subject of Test Project Strategy and more specifically around MTPs there are 2
points where we are not always sure what to do and what are our responsibilities as testers and
test managers:
Product Risks & Project Risks
The first step is to understand these are 2 different entities:
Product Risks are areas in the AUT where there is a high risk you will find (important or
numerous) defects, usually due to changes or other internal factors.
Project Risks are situations that may or may not happen (risks), if they materialize they usually
cause delays in the project’s timelines, and the source of these risks may be internal or external.
Product Risks
As testers one of our tasks is to manage Product Risks.
We are paid (at least in part) to be aware of all Product Risks, to make sure the rest of the project
team is also aware of them, and to coordinate this information with Project Management to make
sure our schedules are taking these risks into account.
In addition, we are expected to plan our testing strategy based on these risk, scheduling more
tests (and earlier tests) on areas with higher risks in order to find these issues faster.
My preferred method for handling Product Risks starts by listing them as part of my MTP and
reviewing them with all the Project Stakeholders. During these reviews I try to get inputs into the
relevance of these risks, as well as information about additional risks I may be unaware off. Once
the project starts we review and update all product risks as part of the coordination meetings with
the rest of the project team.
Examples of Product Risks are:

- Complex features affecting multiple areas of the existing product, like an upgrade/migration of
the system.
- New Technologies used in the product; for example a new DB server, a new programming
language, a new integration, etc.
- New Developers or Development Teams, who may lack experience and thus pose a higher risk
to the existing product.
- Tight Schedules, that make people work in a rush and commit more mistakes.
etc
Project Risks
The responsibles for Project Risks are the Project Managers, who are also in charge of the
project’s schedule. The QA, as part of the overall team, is responsible for the Project Risks
within our work areas.
Project Risks are usually managed in an Excel Sheet (or Google Docs Spreadsheet) where we list
and manage all the risks for the project. For each risk we collect and manage the following
information:
1. Risk Name & Description
2. Risk Index (we use this field in order to sort our list) – calculated by multiplying its
probability by its consequence
3. Risk owner
4. Date of relevance – when does the risk starts been relevant and prevention actions can start
taking place
5. Prevention Actions – how to avoid this risk
6. Contingency Plans – what do we do if the risk materializes
The most usual project risks related to the QA & Testing work are:
- Delays in the delivery of the AUT for testing
- Lack of technical knowledge on specific areas of the product
- Lack of testing environments and/or data that effectively simulate real customer usage
etc.
Risks are a big part of any manager’s work. We are expected to be in the lookout for the things
that may happen and prepare accordingly.
Most of the task related to Risk Management are not complex but they require good
understanding of the project and product as well as the strict discipline required to keep
following and managing these risks throughout the whole lifecycle of the project.
DATABASE+SQL
Data bas testing basically include the following. 1)Data validity testing. 2)Data Integritity
testing 3)Performance related to data base. 4)Testing of Procedure,triggers and
functions. for doing data validity testing you should be good in SQL queries For data integrity
testing you should know about referintial integrity and different constraint. For performance
related things you should have idea about the table structure and design. for testing Procedure
triggers and functions you should be able to understand the same. 
Database testing involves some indepth knowledge of the given application and requires
more defined plan of approach to test the data. Key issues include :
1) data Integrity
2) data validity
3) data manipulation and updates.
Tester must be aware of the database design concepts and implementation rules
Data Integrity: the completeness or wholeness of the data. eg: When you enter a record in
your application, you check that the data is entered correctly in the database
data validity: rules like check the constraints (null value, primary key, referential key,
unique key etc)
data manipulations: update the data, delete the data etc
What is way of writing testcases for database testing?

To write testcase for database its just like functional testing.
1.Objective:Write the objective that you would like to test. eg: To check the shipment that i
load thru xml is getting inserted for perticular customer.
2.Write the method of input or action that you do. eg:Load an xml with all data which can
be added to a customer.
3.Expected :Input should be viewd in database. eg: The shipment should be loaded
sucessfully for that customer,also it should be seen in application.4.You can write ssuch
type of testcases for any functionality like update,delete etc.
Writing test cases for database may sound as a generic term but there are different
approaches you got choose based on the scenario.
some examples are:
1- Database migration
2- Database upgrade
3- Schema changes and DB design updates
In case of point 1
Data is moving from one DB to another may because of a hardware or OS upgrade so you
will have to do functional as well as DB related tests.
Functional:
- How data will be backed up
- What is the size on disk
- How much time it takes to backup and restore the data
- Error handling cases and etc...
DB:
- Verify that the migration is successful by looking at the logs
- Try to compare list of DB items from UI of older version against the new
- Verify the Data integrity manually by checking some tables selectively
- Use some tool to compare two databases and spot the differences in terms of DB meta
data and Data
- A round of regression of the product
- Scheduled jobs of DB
- Performance testing
In case of point 2
You DB system is getting upgraded from version X to Y
- Verify the upgrade is successful
- Do a round of regression
- Scheduled jobs
- Performance testing
- Verify the Data integrity manually by checking some tables selectively
In case of point 3
- Analyze the changes
- Depending on the need Verify the Data integrity manually by checking some tables
selectively
- Depending on the need use some tool to compare two databases and spot the differences in
terms of DB meta data and Data
- A round of selective regression specific to the change
- Performance
- Security testing of UI features if there are any UI forms are developed which store data in
DB
How to Test database in Manually? Explain with an example.
Observing that opertaions, which are operated on front-end is effected on back-end or

not. The approach is as follows : While adding a record thr' front-end check back-
end that addition of record is effected or not. So same for delete, update,...... Ex:Enter
employee record in database thr' front-end and check if the record is added or not to the
back-end(manually). 
Based on front end toll check whether desired records are appearing or not with the help of
back end operation. example:- There is a vendor column which is representing all vendors
for particular firm, when the vendor did one transaction with the company that would be
delete, update or new transaction, Database developer do the any above operation and end
user has to see in front end report. if they could able to see the record then the operation
got success ed else it is wrong. so every time the developer can't do such operations
manually he can do this kind of things through a package or Store procedure. When
developer developed the above program test engineer need to test with sample data if it
reflected at front end the program was correct else need to advise the developer to modify
code according to the requirement
Select Queries – How to extract data from tables
Table is:
Query1: to fetch complete data from the database (select * from

table name)
SELECT * FROM Employees
Query 2: to fetch particular field from the database

SELECT EmployeeID, FirstName, LastName, HireDate, City FROM Employees
WHERE Clause
Query 3: to start limiting, or filtering, the data we fetch from the database

WHERE City = 'London'
resulting in
Query 4: for the employees who do not live in London, you would write

WHERE City <> 'London'
Query 5: For Employees who, where hired on or after a given date, you would write

WHERE HireDate >= '1-july-1993'
Resulting rows
Query 6: To know which employees were hired between two given dates, we could
write

WHERE(HireDate >= '1-june-1992') AND (HireDate <= '15-december-1993')
resulting in
Query 7: special BETWEEN operator that checks to see if a value is between two values
SELECT EmployeeID, FirstName, LastName, HireDate, City

FROM Employees
WHERE HireDate BETWEEN '1-june-1992' AND '15-december-1993'
Query 8: NOT operator, to fetch those rows that are not between the specified dates:
SELECT EmployeeID, FirstName, LastName, HireDate, City

FROM Employees
WHERE HireDate NOT BETWEEN '1-june-1992' AND '15-december-1993'
The SQL SELECT DISTINCT Statement

In a table, some of the columns may contain duplicate values. This is not a problem, however, sometimes you will want to list
only the different (distinct) values in a table.
The DISTINCT keyword can be used to return only distinct (different) values.
SQL SELECT DISTINCT Syntax

SELECT DISTINCT column_name(s)
FROM table_name
ORDER BY DESC Example

Now we want to select all the persons from the table above, however, we want to sort the persons descending by their last name.
We use the following SELECT statement:
SELECT * FROM Persons

ORDER BY LastName DESC
Referential Integrity
Definition: Referential integrity is a database concept that ensures that relationships between
tables remain consistent. When one table has a foreign key to another table, the concept of
referential integrity states that you may not add a record to the table that contains the foreign key
unless there is a corresponding record in the linked table. It also includes the techniques known
as cascading update and cascading delete, which ensure that changes made to the linked table are
reflected in the primary table.
Consider the situation where we have two tables: Employees and Managers. The Employees
table has a foreign key attribute entitled ManagedBy which points to the record for that
employee’s manager in the Managers table. Referential integrity enforces the following three
rules:
1. We may not add a record to the Employees table unless the ManagedBy attribute poi
nts to a valid record in the Managers table.
2. If the primary key for a record in the Managers table changes, all corresponding records
in the Employees table must be modified using a cascading update.
3. If a record in the Managers table is deleted, all corresponding records in the Employees
table must be deleted using a cascading delete.
Referential integrity prevents inconsistent data from being created in the database by ensuring that any
data shared between tables remains consistent. To put it another way, it ensures that the soundness of
the relationships remains intact.
Difference between Primary Key, Unique key and composite Key
Difference..
Primary Key..
1.It will not accept null values.
2.There will be only one primary key in a table.
3.Clustered index is created in Primary key.
4.Primary key allows each row in a table to be uniquely identified and ensures that no duplicate
rows exist.
Unique Key..
1.Null values are accepted.
2.More than one unique key will be there in a table.
3.Non-Clustered index is created in unique key.
4.Unique key constraint is used to prevent the duplication of key values within the rows of a
table and allow null values.
CANDIDATE KEY:-A nominee's for primary key field are know as candidate key.
Super key : set of one or more attributes (eventually converted to columns in database table) of an
entity set which uniquely determine each entity (eventually becoming the row in the table). These are
also temed as alternate keys
EmpID, EmailID, SSN, Salutation + FirstName+LastName+Middle Name, FirstName+LastName+Middle
Name + Date of Birth in Employee entity set
2. Candidate Key: it is mimimal Super key
A composite Key can be either Primay or Unique Key

More then One Key columns are said to be composite keys
How to find 5th highest record from a Database

How to Retrieve nth maximum salary from the salary table
SELECT *
FROM Employee E1
WHERE (N-1) = (
SELECT COUNT(DISTINCT(E2.Salary))
FROM Employee E2
WHERE E2.Salary > E1.Salary)
Query to Find Nth Highest Salary of Employee In Sql Server | Query to Find 2nd or 3rd
highest salary of employee in SQL Server
Posted by: Suresh Dasari
Labels: General, SQL Server
Introduction:
In this article I will explain how to find nth highest salary of the employee in SQL Server.
Description:
In many sites we will find one frequent question that is like how to find 2 nd highest salary of
employee or how to find 3rd highest salary of employee or how to find nth highest salary of
employee in SQL Server. To get required highest salary we are having different alternative
ways.
Before write queries to get 2nd, 3rd or nth highest salary of employee first design table in
database and give name as “EmployeeDetails”
EmpID EmpName Salary
1 Suresh 7000
2 Prasanthi 8000
3 Mahesh 9000
4 Sai 10000
5 Nagaraju 11000
6 Mahendra 12000
7 Sanjay 13000
8 Santhosh 14000
9 Raju 15000
10 Phani 10000
11 Kumar 12000
12 Prasad 9000
13 Siva 12000
14 Madhav 14000
15 Donthi 11000
Once table design completed now we will see different ways to get 2 nd, 3rd, etc or nth
highest salary of employee.
Get Highest Salary from Employee Table
Use the below query to get 1st, 2nd, 3rd, 4th, 5th ….etc highest salary of employee
SELECT MAX(Salary) as 'Salary' from EmployeeDetails
where Salary NOT IN
SELECT TOP n-1 (SALARY) from EmployeeDetails ORDER BY Salary Desc

)
Here in above query we need to replace the “n” value with required highest salary of
employee
To get 2nd highest salary of employee then we need replace “n” with 2 our query like will
be this
where Salary NOT IN
SELECT TOP 1 (SALARY) from EmployeeDetails ORDER BY Salary Desc
Output will be like this
Salary
14000
To get 3rd highest salary of employee then we need replace “n” with 3 our query like will
be this
where Salary NOT IN
SELECT TOP 2 (SALARY) from EmployeeDetails ORDER BY Salary Desc

Salary
13000
The above query will help us to get highest salary from EmployeeDetails table suppose if we
want to get Employee Details with particular highest salary then we need to use below
query to get required details.
Get Employee Details with Particular Highest salary
Use the below query to get Employee Details with 1st, 2nd, 3rd, 4th, 5th ….etc highest salary
from table
SELECT *
FROM EmployeeDetails e1
WHERE (n-1) = (
SELECT COUNT(DISTINCT(e2.Salary))
WHERE e2.Salary > e1.Salary)
Here in above query we need to replace the “n” value with required highest salary of table
To get 2nd highest salary of Employee Details then we need replace “n” with 2 our query
like will be this
SELECT *
WHERE (1) = (
8 Santhosh 14000
14 Madhav 14000
To get 3rd highest salary of employee then we need replace “n” with 3 our query like will
be this
SELECT *
WHERE (2) = (
7 Sanjay 13000
In this way we can get required employee details with particular highest salary.
Difference between “OrderBy” and “Group By”

Group by is used to group set of values based on one or more values.
Order by is to sort values either in ascending or descending order
In Group By clause the results are displayed in group

wise
manner means it group all the records in a relation
together
and then displayed them for a selected set of fields from
the relation and in Order By clause the results are
displayed in some specified order
GROUP BY vs ORDER BY
Lately, when I was designing a query for a website, I was wondering about the exact difference
between group by and order by in a query. The easiest explanation is that order by is doing the
sorting of a table and the group by clause is used for aggregation of a field. Ok, this is for the
theory, let's see an example:
The following table contains the items bought by several people last week:
cust_id item total price

1 balloon 1
2 apple 3
1 apple 4
1 pillow 25
3 plastic bag 1
Order By
Let's see the following query:
SELECT * FROM shopping ORDER BY total_price

The output will be:
cust_id item total price

1 balloon 1
3 plastic bag 1
2 apple 3
1 apple 4
1 pillow 25
as you can see the fiels have been ordered by the price. The default order is ascending. If you
want to specify how the data is ordered, write either ASC or DESC at the end of your query.
Example:
SELECT * FROM shopping ORDER BY total_price DESC

will give the same table, but starting with the pillow.
Group By
Now we are going to use the group by statement. The group by statement, as said before, is
especially useful for aggregating, meaning to apply some function. Let's see an example:
SELECT cust_id, SUM(total_price) FROM shopping GROUP BY cust_id
This query returns the total amount of money spent by each customer during all their shoppings.
The table returned looks like this:
cust_id SUM(total_price)
1 30
2 3
3 1
The way you have to understand the query is that we compute the sum of all amounts for each
customer. This is expressed by the GROUP BY cust_id. Now, if we would try to do this for each
product. This would correspond to the total money gained per product. The query looks like this:
SELECT item, SUM(total_price) FROM shopping GROUP BY item
This query returns the following table:
item SUM(total_price)
apple 7
balloon 1
pillow 25
plastic bag 1
That's already it!
Difference between Delete and Truncate
DELETE
The DELETE command is used to remove rows from a table. A WHERE clause can be used to
only remove some rows. If no WHERE condition is specified, all rows will be removed. After
performing a DELETE operation you need to COMMIT or ROLLBACK the transaction to make
the change permanent or to undo it. Note that this operation will cause all DELETE triggers on
the table to fire.
SQL> SELECT COUNT(*) FROM emp;

COUNT(*)
----------
14
SQL> DELETE FROM emp WHERE job = 'CLERK';
4 rows deleted.
SQL> COMMIT;
Commit complete.
COUNT(*)
----------
10
TRUNCATE
TRUNCATE removes all rows from a table. The operation cannot be rolled back and no triggers
will be fired. As such, TRUCATE is faster and doesn't use as much undo space as a DELETE.
SQL> TRUNCATE TABLE emp;
Table truncated.
COUNT(*)
----------
0
DROP
The DROP command removes a table from the database. All the tables' rows, indexes and
privileges will also be removed. No DML triggers will be fired. The operation cannot be rolled
back.
SQL> DROP TABLE emp;
Table dropped.
SQL> SELECT * FROM emp;

SELECT * FROM emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
DROP and TRUNCATE are DDL commands, whereas DELETE is a DML command. Therefore DELETE
operations can be rolled back (undone), while DROP and TRUNCATE operations cannot be rolled back.
From Oracle 10g a table can be "undropped". Example:

SQL> FLASHBACK TABLE emp TO BEFORE DROP;
Flashback complete.
PS: DROP and TRUNCATE are DDL commands, whereas DELETE is a DML command. As
such, DELETE operations can be rolled back (undone), while DROP and TRUNCATE
operations cannot be rolled back.
SQL Delete Statement

The DELETE Statement is used to delete rows from a table.
The Syntax of a SQL DELETE statement is:
DELETE FROM table_name [WHERE condition];
 table_name -- the table name which has to be updated.
NOTE:The WHERE clause in the sql delete command is optional and it identifies the rows in
the column that gets deleted. If you do not include the WHERE clause all the rows in the table is
deleted, so be careful while writing a DELETE query without WHERE clause.
For Example: To delete an employee with id 100 from the employee table, the sql delete query
would be like,
DELETE FROM employee WHERE id = 100;
To delete all the rows from the employee table, the query would be like,
DELETE FROM employee;
SQL TRUNCATE Statement

The SQL TRUNCATE command is used to delete all the rows from the table and free the space
containing the table.
Syntax to TRUNCATE a table:
TRUNCATE TABLE table_name;

For Example: To delete all the rows from employee table, the query would be like,
TRUNCATE TABLE employee;
Difference between DELETE and TRUNCATE Statements:
DELETE Statement: This command deletes only the rows from the table based on the
condition given in the where clause or deletes all the rows from the table if no condition is
specified. But it does not free the space containing the table.
TRUNCATE statement: This command is used to delete all the rows from the table and free the
space containing the table.
SQL DROP Statement:

The SQL DROP command is used to remove an object from the database. If you drop a table, all
the rows in the table is deleted and the table structure is removed from the database. Once a table
is dropped we cannot get it back, so be careful while using RENAME command. When a table is
dropped all the references to the table will not be valid.
Syntax to drop a sql table structure:
DROP TABLE table_name;
For Example: To drop the table employee, the query would be like
DROP TABLE employee;
Difference between DROP and TRUNCATE Statement:
If a table is dropped, all the relationships with other tables will no longer be valid, the integrity
constraints will be dropped, grant or access privileges on the table will also be dropped, if want
use the table again it has to be recreated with the integrity constraints, access privileges and the
relationships with other tables should be established again. But, if a table is truncated, the table
structure remains the same, therefore any of the above problems will not exist.
What is commit and Roll Back

 COMMIT commits the current transaction, making its changes permanent
 ROLLBACK rolls back the current transaction, canceling its changes
What is commit and rollback?
Transaction management systems on z/OS

In transaction systems, commit and rollback refers to the set of actions used to ensure that an
application program either makes all changes to the resources represented by a single unit of
recovery (UR), or makes no changes at all. The two-phase commit protocol provides commit and
rollback. It verifies that either all changes or no changes are applied even if one of the elements
(like the application, the system, or the resource manager) fails. The protocol allows for restart
and recovery processing to take place after system or subsystem failure.
The two-phase commit protocol is initiated when the application is ready to commit or back out
its changes. At this point, the coordinating recovery manager, also called the syncpoint
manager, gives each resource manager participating in the unit of recovery an opportunity to
vote on whether its part of the UR is in a consistent state and can be committed. If all participants
vote YES, the recovery manager instructs all the resource managers to commit the changes. If
any of the participants vote NO, the recovery manager instructs them to back out the changes.
This process is usually represented as two phases.
In phase 1, the application program issues the syncpoint or rollback request to the syncpoint
coordinator. The coordinator issues a PREPARE command to send the initial syncpoint flow to
all the UR agent resource managers. In response to the PREPARE command, each resource
manager involved in the transaction replies to the syncpoint coordinator stating whether it is
ready to commit or not.
When the syncpoint coordinator receives all the responses back from all its agents, phase 2 is
initiated. In this phase the syncpoint coordinator issues the commit or rollback command based
on the previous responses. If any of the agents responded with a negative response, the syncpoint
initiator causes all of the syncpoint agents to roll back their changes.
The instant when the coordinator records the fact that it is going to tell all the resource managers
to either commit or roll back is known as the atomic instant. Regardless of any failures after that
time, the coordinator assumes that all changes will either be committed or rolled back. A
syncpoint coordinator usually logs the decision at this point. If any of the participants abnormally
end (or abend) after the atomic instant, the abending resource manager must work with the
syncpoint coordinator, when it restarts, to complete any commits or rollbacks that were in
process at the time of the abend.
On z/OS®, the primary syncpoint coordinator is called Resource Recovery Services (RRS).
Also, the IBM® transaction manager product, CICS®, includes its own built-in syncpoint
coordinator.
During the first phase of the protocol, the agents do not know whether the syncpoint coordinator will
commit or roll back the changes. This time is known as the indoubt period. The UR is described as having
a particular state depending on what stage it is at in the two-phase commit process:
 Before a UR makes any changes to a resource, it is described as being In-reset.

 While the UR is requesting changes to resources, it is described as being In-flight.
 Once a commit request has been made (Phase 1), it is described as being In-prepare.
 Once the syncpoint manager has made a decision to commit (phase 2 of the two-phase commit
process), it is In-commit.
 If the syncpoint manager decides to back out, it is In-backout.
Figure 1 illustrates the two-phase commit.
Figure 1. Two-phase commit
Most widely used transaction management systems on z/OS, such as CICS or IMS™, support
two-phase commit protocols. CICS, for example, supports full two-phase commit in transactions
with IMS and the DB2® database management system, and supports two-phase commit across
distributed CICS systems.
There are many restrictions imposed on application developers attempting to develop new
applications that require updates in many different resource managers, perhaps across a number
of systems. Many of these new applications use technologies like DB2 stored procedures and
Enterprise Java™ Beans, and use client attachment facilities of CICS or IMS that do not support
two-phase commit. If any of these resource managers are used by an application to update
resources, it is not possible to have a global coordinator for the syncpoint.
The lack of a global syncpoint coordinator might influence an application design for the following
reasons:
 The application is not capable of having complex and distributed transactions if not all of the
resource managers are participating in the two-phase commit protocol.
 The application cannot be designed as a single application (or unit of recovery) across multiple
systems (except for CICS).
The application programmer would have to program around these limitations. For example, the
programmer could limit the choice of where to put the business data to ensure that all the data
could be committed in a single unit of recovery.
Also, these limitations could affect the recoverability of the protected resources or their integrity
in case of a failure of one of the components, because resource managers have no way to either
commit or roll back the updates.
What are constraints?
constraint is a rule which can not be voilated by end

users.
Different types of constraints are available.They are:-
1)default constraint:-which is used to define a default
value.
2)primary key:-the key which does not allows duplication
and null values.
3)foreign key:-the key used to refer primary key defined
field in another table and it allows duplication.
4)null:-which allows NULL values.
5)not null:-which does not allows NULL values.
6)unique key:-which does not allows duplication but
allows
NULL values.
SQL Constraints
Constraints are used to limit the type of data that can go into a table.
Constraints can be specified when a table is created (with the CREATE TABLE statement) or
after the table is created (with the ALTER TABLE statement).
We will focus on the following constraints:
 NOT NULL
 UNIQUE
 PRIMARY KEY
 FOREIGN KEY
 CHECK
 DEFAULT
You can place constraints to limit the type of data that can go into a table. Such constraints can
be specified when the table when the table is first created via the CREATE TABLE statement,
or after the table is already created via the ALTER TABLE statement.
Common types of constraints include the following:
 NOT NULL Constraint: Ensures that a column cannot have NULL value.
 DEFAULT Constraint: Provides a default value for a column when none is specified.
 UNIQUE Constraint: Ensures that all values in a column are different.
 CHECK Constraint: Makes sure that all values in a column satisfy certain criteria.
 Primary Key Constraint: Used to uniquely identify a row in the table.
 Foreign Key Constraint: Used to ensure referential integrity of the data.
SQL NOT NULL Constraint

The NOT NULL constraint enforces a column to NOT accept NULL values.
The NOT NULL constraint enforces a field to always contain a value. This means that you
cannot insert a new record, or update a record without adding a value to this field.
The following SQL enforces the "P_Id" column and the "LastName" column to not accept
NULL values:
CREATE TABLE Persons

(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255)
)
Constraints
SQL Server 2008 R2
Other Versions
5 out of 12 rated this helpful - Rate this topic
Constraints let you define the way the Database Engine automatically enforces the integrity of a
database. Constraints define rules regarding the values allowed in columns and are the standard
mechanism for enforcing integrity. Using constraints is preferred to using DML Triggers, rules,
and defaults. The query optimizer also uses constraint definitions to build high-performance
query execution plans.
Classes of Constraints
SQL Server supports the following classes of constraints:
 NOT NULL specifies that the column does not accept NULL values. For more
information, see Allowing Null Values.
 CHECK constraints enforce domain integrity by limiting the values that can be put in a
column. For more information, see CHECK Constraints.
A CHECK constraint specifies a Boolean (evaluates to TRUE, FALSE, or unknown)

search condition that is applied to all values that are entered for the column. All values
that evaluate to FALSE are rejected. You can specify multiple CHECK constraints for
each column. The following sample shows creating the constraint chk_id. This constraint
additionally enforces the domain of the primary key by making sure that only numbers
within a specified range are entered for the key.
CREATE TABLE cust_sample

(
cust_id int PRIMARY KEY,
cust_name char(50),
cust_address char(50),
cust_credit_limit money,
CONSTRAINT chk_id CHECK (cust_id BETWEEN 0 and 10000 )
)
 UNIQUE constraints enforce the uniqueness of the values in a set of columns.
In a UNIQUE constraint, no two rows in the table can have the same value for the
columns. Primary keys also enforce uniqueness, but primary keys do not allow for NULL
as one of the unique values. For more information, see UNIQUE Constraints.
 PRIMARY KEY constraints identify the column or set of columns that have values that
uniquely identify a row in a table. For more information, see PRIMARY KEY
Constraints.
No two rows in a table can have the same primary key value. You cannot enter NULL for
any column in a primary key. We recommend using a small, integer column as a primary
key. Each table should have a primary key. A column or combination of columns that
qualify as a primary key value is referred to as a candidate key.
The following example creates the part_sample table and specifies the part_nmbr field as
the primary key.
CREATE TABLE part_sample

(part_nmbr int PRIMARY KEY,
part_name char(30),
part_weight decimal(6,2),
part_color char(15) );
 FOREIGN KEY constraints identify and enforce the relationships between tables. For
more information, see FOREIGN KEY Constraints.
A foreign key in one table points to a candidate key in another table. In the following
example, the order_part table establishes a foreign key that references the part_sample
table defined previously.
CREATE TABLE order_part

(order_nmbr int,
part_nmbr int
FOREIGN KEY REFERENCES part_sample(part_nmbr)
ON DELETE NO ACTION,
qty_ordered int);
GO
You cannot insert a row with a foreign key value, except NULL, if there is no candidate
key with that value. The ON DELETE clause controls what actions are taken when you
try to delete a row to which existing foreign keys point. The ON DELETE clause has the
following options:
o NO ACTION specifies that the deletion fails with an error.

o CASCADE specifies that all the rows with foreign keys pointing to the deleted
row are also deleted.
o SET NULL specifies that all rows with foreign keys pointing to the deleted row
are set to NULL.
o SET DEFAULT specifies that all rows with foreign keys pointing to the deleted
row are set to their default value. For more information, see Defaults.
The ON UPDATE clause defines the actions that are taken if you try to update a
candidate key value to which existing foreign keys point. This clause also supports the
NO ACTION, CASCADE, SET NULL and SET DEFAULT options.
Column and Table Constraints
Constraints can be column constraints or table constraints. A column constraint is specified as

part of a column definition and applies only to that column. The constraints in the previous
examples are column constraints. A table constraint is declared independently from a column
definition and can apply to more than one column in a table. Table constraints must be used
when more than one column must be included in a constraint.
For example, if a table has two or more columns in the primary key, you must use a table
constraint to include both columns in the primary key. Consider a table that records events
occurring in a computer in a factory. Assume that events of several types can occur at the same
time, but that no two events occurring at the same time can be of the same type. This can be
enforced in the table by including both the event_type and event_time columns in a two-column
primary key, as shown in the following example.
CREATE TABLE factory_process

(event_type int,
event_time datetime,
event_site char(50),
event_desc char(1024),
CONSTRAINT event_key PRIMARY KEY (event_type, event_time) )
What do you mean by Joins – Read all Joins carefully(inner Outerm Left
Outer, Right Outer, Equi Join)
SQL Joins
SQL joins are used to query data from two or more tables, based on a relationship
between certain columns in these tables.
SQL JOIN
The JOIN keyword is used in an SQL statement to query data from two or more tables, based on a relationship between certain
columns in these tables.
Tables in a database are often related to each other with keys.
A primary key is a column (or a combination of columns) with a unique value for each row. Each primary key value must be
unique within the table. The purpose is to bind data together, across tables, without repeating all of the data in every table.
Look at the "Persons" table:
P_Id LastName FirstName Address City
1 Hansen Ola Timoteivn 10 Sandnes
2 Svendson Tove Borgvn 23 Sandnes
3 Pettersen Kari Storgt 20 Stavanger
Note that the "P_Id" column is the primary key in the "Persons" table. This means that no two rows can have the same P_Id. The
P_Id distinguishes two persons even if they have the same name.
Next, we have the "Orders" table:
O_Id OrderNo P_Id
1 77895 3
2 44678 3
3 22456 1
4 24562 1
5 34764 15
Note that the "O_Id" column is the primary key in the "Orders" table and that the "P_Id" column refers to the persons in the
"Persons" table without using their names.
Notice that the relationship between the two tables above is the "P_Id" column.
Different SQL JOINs

Before we continue with examples, we will list the types of JOIN you can use, and the differences between them.
 JOIN: Return rows when there is at least one match in both tables
 LEFT JOIN: Return all rows from the left table, even if there are no matches in the right table
 RIGHT JOIN: Return all rows from the right table, even if there are no matches in the left
table
 FULL JOIN: Return rows when there is a match in one of the tables
SQL INNER JOIN Keyword

The INNER JOIN keyword return rows when there is at least one match in both tables.
SQL INNER JOIN Syntax

SELECT column_name(s)
FROM table_name1
INNER JOIN table_name2
ON table_name1.column_name=table_name2.column_name
PS: INNER JOIN is the same as JOIN.
SQL INNER JOIN Example

The "Persons" table:
The "Orders" table:
O_Id OrderNo P_Id

1 77895 3
2 44678 3
3 22456 1
4 24562 1
5 34764 15
Now we want to list all the persons with any orders.
SELECT Persons.LastName, Persons.FirstName, Orders.OrderNo

FROM Persons
INNER JOIN Orders
ON Persons.P_Id=Orders.P_Id
ORDER BY Persons.LastName
The result-set will look like this:
LastName FirstName OrderNo
Hansen Ola 22456
Hansen Ola 24562
Pettersen Kari 77895
The INNER JOIN keyword return rows when there is at least one match in both tables. If there are rows in "Persons" that do not
have matches in "Orders", those rows will NOT be listed.
SQL LEFT JOIN Keyword

The LEFT JOIN keyword returns all rows from the left table (table_name1), even if there are no matches in the right table
(table_name2).
SQL LEFT JOIN Syntax

FROM table_name1
LEFT JOIN table_name2
PS: In some databases LEFT JOIN is called LEFT OUTER JOIN.
SQL LEFT JOIN Example

The "Orders" table:
O_Id OrderNo P_Id
1 77895 3
2 44678 3
3 22456 1
4 24562 1
5 34764 15
Now we want to list all the persons and their orders - if any, from the tables above.

FROM Persons
LEFT JOIN Orders
Hansen Ola 22456
Hansen Ola 24562
Svendson Tove
The LEFT JOIN keyword returns all the rows from the left table (Persons), even if there are no matches in the right table
(Orders).
SQL RIGHT JOIN Keyword

The RIGHT JOIN keyword returns all the rows from the right table (table_name2), even if there are no matches in the left table
(table_name1).
SQL RIGHT JOIN Syntax

FROM table_name1
RIGHT JOIN table_name2
PS: In some databases RIGHT JOIN is called RIGHT OUTER JOIN.
SQL RIGHT JOIN Example

The "Orders" table:
O_Id OrderNo P_Id
1 77895 3
2 44678 3
3 22456 1
4 24562 1
5 34764 15
Now we want to list all the orders with containing persons - if any, from the tables above.

FROM Persons
RIGHT JOIN Orders
Hansen Ola 22456
Hansen Ola 24562
34764
The RIGHT JOIN keyword returns all the rows from the right table (Orders), even if there are no matches in the left table
(Persons).
SQL FULL JOIN Keyword

The FULL JOIN keyword return rows when there is a match in one of the tables.
SQL FULL JOIN Syntax

FROM table_name1
FULL JOIN table_name2
SQL FULL JOIN Example


The "Orders" table:
O_Id OrderNo P_Id
1 77895 3
2 44678 3
3 22456 1
4 24562 1
5 34764 15
Now we want to list all the persons and their orders, and all the orders with their persons.

FROM Persons
FULL JOIN Orders
Hansen Ola 22456
Hansen Ola 24562
Svendson Tove
34764
The FULL JOIN keyword returns all the rows from the left table (Persons), and all the rows from the right table (Orders). If there
are rows in "Persons" that do not have matches in "Orders", or if there are rows in "Orders" that do not have matches in
"Persons", those rows will be listed as well.
Sub Queries
SQL Subquery
Subquery or Inner query or Nested query is a query in a query. A subquery is usually added in
the WHERE Clause of the sql statement. Most of the time, a subquery is used when you know
how to search for a value using a SELECT statement, but do not know the exact value.
Subqueries are an alternate way of returning data from multiple tables.
Subqueries can be used with the following sql statements along with the comparision operators
like =, <, >, >=, <= etc.
 SELECT
 INSERT
 UPDATE
 DELETE
For Example:
1) Usually, a subquery should return only one record, but sometimes it can also return multiple
records when used with operators like IN, NOT IN in the where clause. The query would be like,
SELECT first_name, last_name, subject

FROM student_details
WHERE games NOT IN ('Cricket', 'Football');
The output would be similar to:

first_name last_name subject
------------- ------------- ----------
Shekar Gowda Badminton
Priya Chandra Chess
2) Lets consider the student_details table which we have used earlier. If you know the name of
the students who are studying science subject, you can get their id's by using this query below,
SELECT id, first_name

WHERE first_name IN ('Rahul', 'Stephen');
but, if you do not know their names, then to get their id's you need to write the query in this
manner,
SELECT id, first_name

WHERE first_name IN (SELECT first_name
WHERE subject= 'Science');
Output:
id first_name
-------- -------------
100 Rahul
102 Stephen
In the above sql statement, first the inner query is processed first and then the outer query is
processed.
3) Subquery can be used with INSERT statement to add rows of data from one or more tables to
another table. Lets try to group all the students who study Maths in a table 'maths_group'.
INSERT INTO maths_group(id, name)

SELECT id, first_name || ' ' || last_name
FROM student_details WHERE subject= 'Maths'
4) A subquery can be used in the SELECT statement as follows. Lets use the product and
order_items table defined in the sql_joins section.
select p.product_name, p.supplier_name, (select order_id from order_items

where product_id = 101) as order_id from product p where p.product_id = 101
product_name supplier_name order_id
------------------ ------------------ ----------
Television Onida 5103
Correlated Subquery
A query is called correlated subquery when both the inner query and the outer query are
interdependent. For every row processed by the inner query, the outer query is processed as well.
The inner query depends on the outer query before it can be processed.
SELECT p.product_name FROM product p

WHERE p.product_id = (SELECT o.product_id FROM order_items o
WHERE o.product_id = p.product_id);
NOTE:
1) You can nest as many queries you want but it is recommended not to nest more than 16
subqueries in oracle.
2) If a subquery is not dependent on the outer query it is called a non-correlated subquery.
© 2007-2012 Beginner-Sql-Tutorial.com | Beginner-SQL-Tutorial.com Privacy Policy | All

rights Reserved |
SQL - Subqueries
Subqueries are query statements tucked inside of query statements. Like the order of operations
from your high school Algebra class, order of operations also come into play when you start to
embed SQL commands inside of other SQL commands (subqueries). Let's take a look at a real
world example involving the orders table and figure out how to select only the most recent
order(s) in our orders table.
Advertise on Tizag.com
To accomplish this, we are first going to introduce a built-in SQL function, MAX(). This
function wraps around a table column and quickly returns the current highest (max) value for the
specified column. We are going to use this function to return the current "highest", aka most
recent date value in the orders table.
Limit the number of rows to 10 in a select * command
The TOP Clause

The TOP clause is used to specify the number of records to return.
The TOP clause can be very useful on large tables with thousands of records. Returning a large number of records can impact on
performance.
Note: Not all database systems support the TOP clause.
SQL Server Syntax

SELECT TOP number|percent column_name(s)
FROM table_name
How do I limit the number of rows returned

by an Oracle query after ordering?
Is there a way to make an Oracle query behave like it contains a MySQL

up vote 101 limit clause?
down vote favorite In MySQL, I can do this:
30 select *
from sometable
order by name
limit 20,10
to get the 21st to the 30th rows (skip the first 20, give the next 10). The rows
are selected after the order by, so it really starts on the 20th name
alphabetically.
Add rows into a Table,
The INSERT INTO Statement

The INSERT INTO statement is used to insert a new row in a table.
SQL INSERT INTO Syntax
It is possible to write the INSERT INTO statement in two forms.
The first form doesn't specify the column names where the data will be inserted, only their
values:
INSERT INTO table_name

VALUES (value1, value2, value3,...)
The second form specifies both the column names and the values to be inserted:
INSERT INTO table_name (column1, column2, column3,...)

Add only select values in the columns of a table
The INSERT INTO statement is used to insert a new row in a table.

SQL INSERT INTO Syntax
It is possible to write the INSERT INTO statement in two forms.
The first form doesn't specify the column names where the data will be inserted, only their values:
INSERT INTO table_name

The second form specifies both the column names and the values to be inserted:
INSERT INTO table_name (column1, column2, column3,...)

Insert Data Only in Specified Columns

It is also possible to only add data in specific columns.
The following SQL statement will add a new row, but only add data in the "P_Id", "LastName" and the "FirstName" columns:
INSERT INTO Persons (P_Id, LastName, FirstName)

VALUES (5, 'Tjessem', 'Jakob')
What is normalization and Indexing

What is Normalization?
Normalization is the process of efficiently organizing data in a database. There are two goals of the
normalization process: eliminating redundant data (for example, storing the same data in more than one
table) and ensuring data dependencies make sense (only storing related data in a table). Both of these
are worthy goals as they reduce the amount of space a database consumes and ensure that data is
logically stored.
The Normal Forms

The database community has developed a series of guidelines for ensuring that databases are
normalized. These are referred to as normal forms and are numbered from one (the lowest form of
normalization, referred to as first normal form or 1NF) through five (fifth normal form or 5NF). In
practical applications, you'll often see 1NF, 2NF, and 3NF along with the occasional 4NF. Fifth normal
form is very rarely seen and won't be discussed in this article.
Before we begin our discussion of the normal forms, it's important to point out that they are guidelines
and guidelines only. Occasionally, it becomes necessary to stray from them to meet practical business
requirements. However, when variations take place, it's extremely important to evaluate any possible
ramifications they could have on your system and account for possible inconsistencies. That said, let's
explore the normal forms.
First Normal Form (1NF)

First normal form (1NF) sets the very basic rules for an organized database:
 Eliminate duplicative columns from the same table.

 Create separate tables for each group of related data and identify each row with a unique
column or set of columns (the primary key).
For more details, read Putting your Database in First Normal Form
Second Normal Form (2NF)

Second normal form (2NF) further addresses the concept of removing duplicative data:
 Meet all the requirements of the first normal form.

 Remove subsets of data that apply to multiple rows of a table and place them in separate tables.
 Create relationships between these new tables and their predecessors through the use of
foreign keys.
For more details, read Putting your Database in Second Normal Form
Third Normal Form (3NF)

Third normal form (3NF) goes one large step further:
 Meet all the requirements of the second normal form.

 Remove columns that are not dependent upon the primary key.
For more details, read Putting your Database in Third Normal Form
Boyce-Codd Normal Form (BCNF or 3.5NF)

The Boyce-Codd Normal Form, also referred to as the "third and half (3.5) normal form", adds one more
requirement:
 Meet all the requirements of the third normal form.

 Every determinant must be a candidate key.
For more details, read Putting your Database in Boyce Codd Normal Form
Fourth Normal Form (4NF)

Finally, fourth normal form (4NF) has one additional requirement:
 Meet all the requirements of the third normal form.
 A relation is in 4NF if it has no multi-valued dependencies.
Remember, these normalization guidelines are cumulative. For a database to be in 2NF, it must first
fulfill all the criteria of a 1NF database.
The CREATE INDEX statement is used to create indexes in

tables.
Indexes allow the database application to find data fast;

without reading the whole table.
Indexes
An index can be created in a table to find data more quickly and efficiently.
The users cannot see the indexes, they are just used to speed up searches/queries.
Note: Updating a table with indexes takes more time than updating a table without (because the
indexes also need an update). So you should only create indexes on columns (and tables) that
will be frequently searched against.
SQL CREATE INDEX Syntax
Creates an index on a table. Duplicate values are allowed:
CREATE INDEX index_name

ON table_name (column_name)
SQL CREATE UNIQUE INDEX Syntax
Creates a unique index on a table. Duplicate values are not allowed:
CREATE UNIQUE INDEX index_name

ON table_name (column_name)
Note: The syntax for creating indexes varies amongst different databases. Therefore: Check the
syntax for creating indexes in your database.
CREATE INDEX Example
The SQL statement below creates an index named "PIndex" on the "LastName" column in the
"Persons" table:
CREATE INDEX PIndex

ON Persons (LastName)
If you want to create an index on a combination of columns, you can list the column names
within the parentheses, separated by commas:
CREATE INDEX PIndex

ON Persons (LastName, FirstName)
Indexing vs. Normalization of logs

Posted on November 23, 2009 | 2 Comments
Recently a friend asked me whether he should normalize or index logs for faster reporting. My
response was that it depends on who is interpreting the reports. I suggested he use indexing if
the logs are coming from a single application and his users understand the log message format.
However, if the logs come from many different applications or have complicated message
formats, then normalization is the quickest and easiest method. In most cases the best method is
to use both indexed and normalized log data if it is an option.
First, a review of what it means to index log data
An index of log data is similar to an index in the back of most books. A separate, smaller
collection of words(index) is created with pointers to the full text. In most cases the log data to
search can be very voluminous and repetitive, which allows for efficient indexes (few words
with lots of pointers is the most efficient index). To optimize search capabilities engineers are
using full-text indexing tools such as Lucene or IT search applications like Splunk to index the
data, especially when there are GBs and TBs of logs to search.
For a user to get what he/she wants when using an index search they must be very
knowledgeable on how the applications or devices creating the log data function and be able to
understand the contents of the log messages. If they are searching for a specific term or word,
then they need to know exactly the syntax of the term and how it is used in the application’s or
device’s log messages. For example, it is important to know the difference between login and
logon.
Another key for successfully using indexed log data is for users to understand what is “indexed”
and what is not. Users should know what are the delimiters in the indexed words and how are
they used and what is considered an index-able word. Is an email address a full word or two
separate words separated by the @ sign? Is a domain name one word or multiple words
separated by periods (or both)?
It also is important for users to know exactly what words are used in the messages they are
searching. For example, say you want to run a report for failed logins. It is fairly easy and
works great if the user has a homogeneous environment like all UNIX servers or all Web
application servers. All you have to do is search on ‘failed login’ in a search index and it gives
you all the messages that have both the words ‘failed’ and ‘login’ in them. However, when I
tried this on my lab systems (combination of UNIX and Windows devices), I didn’t get all the
records I expected. My indexed search showed nine failed logins. After looking at the raw log
data I found out that some of my failed login messages didn’t have the exact words ‘failed’ and
‘login’ in them. One of the messages I was looking for said “login failure“, and my Windows
logs said “Failed… Logon“. It became very obvious that a user has to know the log content very
clearly before they do the search of indexed data.
What does it mean to ‘normalize’ log data
Normalizing log data is the process of aggregating similar messages. This is typically done via
software writing rules that interpret and summarize similar log messages. For example, different
messages that contain the words ‘failed logins’, ‘authorization failures’, and ‘logon failures’ can
all be interpreted as failed logins and allow users to search or report on one key phrase rather
than knowing what specifically the log message context states.
One problem with normalized data is that someone has to write the software to normalize the
data. Organizations can do this themselves or use a 3rd party product like LogLogic or ArcSight
that have teams of developers constantly writing rules to normalize typical log messages from
various devices. The vendors will focus on the most common types of devices and provide a
development kit for end users to create their own normalization for in-house applications. This
also means that a 3rd party is making decisions about what the log messages mean so that it can
be easier for users to read reports. For example, does a ‘Denied’ message from a Cisco PIX
firewall mean the same thing as a ‘Rejected’ message from a CheckPoint firewall?
In a typical large enterprise configuration I can see a use for both types of log reports. The app
team could use an indexed search report because they are very familiar with the specific
application they are running and the exact message contents on which they want to report. The
IT Operations team is responsible for a much more diverse group of messages and is more reliant
on ‘normalization’ for their reports to be useful, and therefore should stick with a product that
normalizes the log data for all the tools that they need to manage.
There are good reasons to use both indexed and normalized log reports. Several of the vendors I
have worked with recently are working toward combining indexing and normalization to make it
easier for their customers to get to the data they are searching for and/or reporting on. For now,
users need to understand the difference and the details about when and why to index vs.
normalize their log data.
Full disclosure: While I was at LogLogic we developed both indexed and normalized search &
reporting so the customer could choose what they wanted to use. I have seen other vendors, like
Arcsight, provide this choice. But most log analysis tools will typically use one method or the
other.

Test Plan Overview: V Model and Waterfall Model

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Test Plan Overview: V Model and Waterfall Model

Enviado por

Direitos autorais:

Formatos disponíveis

http://www.h2database.com/html/grammar.

V Model and Waterfall Model

Sections of a Test Plan

Test plan overview

Test plan sections

Test plan templates

Test plan categories

Test plan work items

Test plans and their relationship with other test artifacts

Test plan tasks

TEST PLAN TYPES

One can have the following types of test plans:

TEST PLAN TEMPLATE

Test Plan Identifier:

 Provide an overview of the test plan.

 List the test items (software/products) and their versions.

 List the features of the software/product to be tested.

Features Not to Be Tested:

 List the features of the software/product which will not be tested.

 Mention the overall approach to testing.

Item Pass/Fail Criteria:

Suspension Criteria and Resumption Requirements:

 Specify criteria to be used to suspend the testing activity.

 Specify the properties of test environment: hardware, software, network etc.

Staffing and Training Needs:

 Specify staffing needs by role and required skills.

 List the responsibilities of each team/role/individual.

 List the risks that have been identified.

Assumptions and Dependencies:

TEST PLAN GUIDELINES

Defect Life Cycle

Nevertheless, the life cycle in general resembles the following:

Status Alternative Status

COMPLETED FIXED, RESOLVED, TEST

Defect Status Explanation

What is the difference between severity and priority?

Severity Value : S2 :Serious (Critical/Major) :

Severity Value : S3 : Normal

Severity Value : S4 : Small (Minor) :

High Severity & High Priority (S1/S2 & P1) :

Low Severity & High Priority(S4 & P1):

Low Severity & Low Priority(S4 & P4) :

Exit and Entry Criteria

1)All source codes are unit tested

2)All QA resource has enought functional knowledge

3)H/W and s/w are in place

2)Planned deliverable is ready

3)High severity defects are fixed

Use Cases and Test Scenarios

When to Start Testing and when to Stop

How to write test cases from requirements

1. Differentiate different Modules, then different forms in those modules

Test Set - is nothing but set of test data

Requirement Coverage and Test coverage

The aim of coverage based testing method is to 'cover'

Statement Coverage or Node Coverage

What is Boundary Value analysis and Equivalence Partitioning?

What is Boundary value analysis and

Equivalence partitioning uses fewest test cases to cover maximum requirements.

Boundary value analysis:

We Define a Equivalence classes

We will define the boundary of each class of Inputs

Difference between build and release and versioning?