Beruflich Dokumente
Kultur Dokumente
html
'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.
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.
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.
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.
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.
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
/////////////////////////////////////////////////////////////////////////////
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.
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.
Provide a unique identifier for the document. (Adhere to the Configuration Management
System if you have one.)
Introduction:
References:
List the related documents, with links to them if available, including the following:
o Project Plan
o Configuration Management Plan
Test Items:
Features to be Tested:
Specify the criteria that will be used to determine whether each test item
(software/product) has passed or failed testing.
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:
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.
Risks:
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.)
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
NEW
ASSIGNED OPEN
DEFERRED
DROPPED REJECTED
REASSIGNED REOPENED
CLOSED VERIFIED
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
Priority Value : P1 :
FIX the bug ASAP
Priority Value : P2 :
Bug can be fixed before current itteration/minor release.
Priority Value : P3 :
The bug is very minor. A fix for this defect is not expected during the current itteration/minor release.
Priority Value : P4 :
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.
* 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:
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.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.
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
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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)
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.
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:
Budget Risk:
Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events
risks.
Causes of Operational risks:
Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
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:
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 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.
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.<br>1)Data validity testing.<br>2)Data Integritity
testing<br>3)Performance related to data base.<br>4)Testing of Procedure,triggers and
functions.<br>for doing data validity testing you should be good in SQL queries<br>For data integrity
testing you should know about referintial integrity and different constraint.<br>For performance
related things you should have idea about the table structure and design.<br>for testing Procedure
triggers and functions you should be able to understand the same.<br>
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)
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
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:
Query 3: to start limiting, or filtering, the data we fetch from the database
resulting in
Query 4: for the employees who do not live in London, you would write
Query 5: For Employees who, where hired on or after a given date, you would write
Resulting rows
Query 6: To know which employees were hired between two given dates, we could
write
resulting in
Query 7: special BETWEEN operator that checks to see if a value is between two values
The DISTINCT keyword can be used to return only distinct (different) values.
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
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
SELECT *
FROM Employee E1
WHERE (N-1) = (
SELECT COUNT(DISTINCT(E2.Salary))
FROM Employee E2
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
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”
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.
Use the below query to get 1st, 2nd, 3rd, 4th, 5th ….etc highest salary of employee
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
Salary
14000
To get 3rd highest salary of employee then we need replace “n” with 3 our query like will
be this
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.
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))
FROM EmployeeDetails e2
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 *
FROM EmployeeDetails e1
WHERE (1) = (
SELECT COUNT(DISTINCT(e2.Salary))
FROM EmployeeDetails e2
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 *
FROM EmployeeDetails e1
WHERE (2) = (
SELECT COUNT(DISTINCT(e2.Salary))
FROM EmployeeDetails e2
7 Sanjay 13000
In this way we can get required employee details with particular highest salary.
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:
Order By
Let's see the following query:
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:
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:
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:
item SUM(total_price)
apple 7
balloon 1
pillow 25
plastic bag 1
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.
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.
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.
Table dropped.
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.
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.
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,
To delete all the rows from the employee table, the query would be like,
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.
For Example: To drop the table employee, the query would be like
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.
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:
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.
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).
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.
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.
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:
Other Versions
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
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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
2 44678 3
3 22456 1
4 24562 1
5 34764 15
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.
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.
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).
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.
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).
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.
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 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,
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,
but, if you do not know their names, then to get their id's you need to write the query in this
manner,
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'.
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.
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.
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.
The TOP clause can be very useful on large tables with thousands of records. Returning a large number of records can impact on
performance.
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.
The first form doesn't specify the column names where the data will be inserted, only their
values:
The second form specifies both the column names and the values to be inserted:
The first form doesn't specify the column names where the data will be inserted, only their values:
The second form specifies both the column names and the values to be inserted:
The following SQL statement will add a new row, but only add data in the "P_Id", "LastName" and the "FirstName" columns:
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.
For more details, read Putting your Database in First Normal Form
For more details, read Putting your Database in Second Normal Form
For more details, read Putting your Database in Third Normal Form
For more details, read Putting your Database in Boyce Codd Normal Form
Remember, these normalization guidelines are cumulative. For a database to be in 2NF, it must first
fulfill all the criteria of a 1NF database.
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.
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:
If you want to create an index on a combination of columns, you can list the column names
within the parentheses, separated by commas:
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.
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.
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.