Functional Requirement A Functional Requirement is a description of what a system must be able to do.
A non-functional requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called
Non-Functional Requirement 'performance requirements' or 'quality of service requirements'.
The Project Plan is a document created for a project which contains specifc details regarding the methods, resources and tools being used to
create the deliverable software products. It is sometimes referred to as a Software Development Plan (SDP). The Project Plan should account for
the following planning key ideas:
1. Planning requires a (software) product or process development life cycle to provide a framework for considering the specific tasks to be
2. Planning needs to account for the interaction among management, development and product assurance disciplines throughout the project life
3. Planning is an an ongoing negotiation between the IT staff and their Business Partners.
4. Planning maps out the the envisioned technical approach, resources, schedule, and milestones for the transition from the current state to the
5. Planning should incorporate the need for change.
Project Plan 6. Planning needs to assess risk to determine the appropriate mix of management, product/process development and product assurance.
QA checks whether the software or software processes conform to established standards. It also identifies software or software processes that do
Quality Assurance (QA) not conform to standards.
Requirements Traceability Matrix The RTM maps the requirements with their respective test cases. By preparing a Traceability matrix, we can ensure that we have covered all
(RTM) functionalities in our test cases.
A requirement is a precise documented need of what a particular product or service should be or do. The two most common ways of documenting a
1. Shall Statements: The GW iBuy system shall allow a shopper to create a Punch-out cart that has a single GL distribution
Requirement 2. Use Cases: A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. It describes "who" (the
(in systems engineering) Actor) can do "what" (a sequence of actions) with the system in question.
The SRS document states in explicit language those functions and capabilities a software system (i.e., a software application, a website, etc.) must
provide. It also states any required assumptions, constraints, dependencies and interfaces by which the system must abide. The SRS also functions
as a blueprint for completing a project. The SRS is often referred to as the "parent" document because all subsequent project management
Software Requirements Specification documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and training or
(SRS) standard operating procedure documentation plans, are related to it.
Software Testing is the process used to measure the quality of developed computer software. Usually, quality is constrained to such topics as
correctness, completeness and security, but can also include more technical requirements as described under the ISO standard ISO 9126, such as
Software Testing capability, reliability, efficiency, portability, maintainability, compatibility, and usability.
A written set of steps that are used to test part of the functionality of a software system. It describes the input, Action/Event and expected response
Test Case to determine whether the particular functionality of the application is working fine.
A Test Plan & Procedures document provides the details of the strategy that will be used to verify and ensure that a product or system meets its
design specifications and other requirements. Some of the elements of a test plan can involve some or all of the following processes:
1. Identify the requirements to be tested.
2. Identify which particular test(s) you're going to use to test each module.
3. Review the test data and test cases to ensure that the unit has been thoroughly verified and that the test data and test cases are adequate to
verify proper operation of the unit.
4. Identify the expected results for each test.
5. Document the test case configuration, test data, and expected results.
6. Perform the test(s).
7. Document the test data, test cases, and test configuration used during the testing process.
8. Successful unit testing is required before the unit is eligible for component integration/system testing.
9. Unsuccessful testing requires a Trouble Ticket (e.g. PPM) to be generated. This document shall describe the test case, the problem
encountered, its possible cause, and the sequence of events that led to the problem. It shall be used as a basis for later technical analysis.
Test Plan & Procedures 10. Test Report Deliverables: Test Case Design, System/Unit Test Report, Problem Trouble Report (if any).
A description written in prose or a diagram that represents a hypothetical story to help a person think through a complex problem or system. It
entails a set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of
tests that follow each other, each dependent on the output of the previous one. Scenarios are useful to connect to documented software
Test Scenario requirements, especially requirements modeled with use cases.
A short program written in a programming language used to test part of the functionality of a software system. A written set of steps that should be
Test Script performed automatically is sometimes referred to as a test script; however this is more correctly called a test case.
The fundamental premise of acceptance testing is that the functional capabilities are testable. A testable requirement satisfies the following criteria:
1. The requirement is sufficiently defined to permit writing test cases that demonstrate whether or not the capability or capabilities defined by the
requirement are embodied in the software application.
2. The test cases are verifiable and measurable.
3. The test cases are executable in a cost-effective manner.
Example of a non-testable requirement: The GW iBuy system shall process a requisition quickly.
Testable Requirement Example of a testable requirement: The GW iBuy system shall process a requisition in 2 minutes.
Verification & Validation (V&V) V&V checks for any oversights or deviations from specified requirements and predecessor products and identifies them.
Build Verification Test
Data and database
Security and Access
User Interface Testing
Types of Testing
An initial testing effort to determine if a new software version is performing well enough to accept it for a major
Testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
To ensure that the Web service works properly with a number of simultaneous users.
Testing how well software performs in a particular hardware configuration etc.
To ensure that the Database gets and provides correct data.
Black-box testing geared to verify functional requirements of an application. Also see Positive Testing.
Testing of full, partial, or upgrade install/uninstall processes.
To determine if modules function together correctly
Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at
what point the systems’ response time degrades or fails.
This type of testing attempts to show that a given software application module does not do anything that it is not
supposed to do. The software application is tested for improper inputs and boundary limits. There is usually more
focus placed on positive testing but incorporating a balanced amount of negative test cases improves the overall
testing process and delivers a better quality system.
Example: Verifying that the GW iBuy system is not delivering an error when it should or delivering an error when
it should not. Refer to the following link for "The Top 10 Negative Test Cases" :
This testing is designed to ensure that the application will run in the amount of memory specified in the technical
documentation. This testing should also detect memory leaks associated with frequent starting and stopping of
Parallel testing involves testing 2 systems with the same data to make sure the results are the same. Examples
of the 2 systems are:
1. An old version and a new version of the same application
2. An existing version of an application and a newly designed version using a different architecture. Both systems
process the same functional requirements.
This type of functional testing attempts to show that a given module of an application does what it is supposed to
Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Re-testing of affected modules after fixes or modifications of the software or its environment. Regression testing
should be performed to a level determined by the tester to ensure that the problem being addressed was
corrected and did not inroduce any new defects.
Scalability is a measure of how easy it is to expand the infrastructure. These tests help to ensure that the
infrastructure is scalable under varying conditions and is designed to meet growth needs.
Testing how well the system protects against unauthorized internal or external access, willful damage, etc; may
require sophisticated testing techniques.
To test the system in a manner that demands resources in abnormal quantity, frequency or volume.
Tests particular functions or code modules conducted by the software developer prior to the start of any formal
User Acceptance Testing is often the final step before rolling out the application. Usually the end users who will
be using the applications test the application before ‘accepting’ the application.
This type of testing gives the end users the confidence that the application being delivered to them meets their
User Acceptance Testing – Prerequisites:
1. Before the User Acceptance testing can be done the application is fully developed.
2. Various levels of testing (Unit, Integration and System) are already completed before User Acceptance Testing
is done. As various levels of testing have been completed most of the technical bugs have already been fixed
Testing the UI of an application.
Involves verifying that the application/system successfully functions under high volume conditions.
Tested By Phase