Tester's dictionary [I-R]

Random Testing 

It is a black-box software testing process where the application is tested by inputting random values. The outputs are compared with software requirement to verify pass or fail.

Recovery Testing 

Recovery testing is the method of testing which will find how the system is able to recover from crashes and hardware failures.

It is the forced failure in a variety of ways to verify that system recovers is properly or not.

Regression Testing 

Retesting application for unchanged parts is called Regression testing. Test cases are re-executed in order to verify whether previous functionality of application is working fine or new changes have not introduced any new bugs in the system. This test can be performed on new builds so when there is significant change in original functionality.

Release Candidate 

A release candidate also known as an RC has few identified glitches that must be addressed before the program can be marked for testing. A beta version of application typically has more bugs that need to be fixed out before being released to consumers for more thorough testing.

Release Note 

Release notes is a set of document which is released as part of the final build that contains new enhancements or bug fixes that went in as part of the release and also the known issues of that build.

Reliability Testing 

Reliability Testing is about testing applications so that failures are discovered and removed before the system is deployed. The purpose of reliability testing is to determine product reliability and check weather software meets the customer’s reliability requirements.

Requirements 

Requirements are descriptions of the services that software systems must provide and the constraints under which it must operate. It also has high-level abstract statements of services or system constraints to detailed mathematical functional specifications.

The Different Type of Requirements:-

User requirements

• Statements in natural language and diagrams of the services that the systems provide and its operational constraints.
• Written for customers

System requirements

• A structured document setting out detailed descriptions of the system services.
• Written as a contract between contractor and client

Software specification

• A detailed software description which can serve as a basis for an implementation or design
• Written for developers

Requirements Based Testing 

The requirements-based testing (RBT) process is comprised of two phases:

• Ambiguity reviews
• Cause-effect graphing

An ambiguity review is a technique for identifying ambiguities in functional requirements to improve the quality of those requirements. Cause-effect graphing is a test-case design technique that derives the minimum number of test cases to cover100 percent of the functional requirements. This divided into following activities:

• Define test completion criteria.
• Design test cases.
• Build test cases.
• Execute tests.
• Verify test results.
• Verify test coverage.
• Manage the test library.

Requirements Traceability Matrix 

The purpose of the Requirements Traceability Matrix is to verify that all requirements defined for systems are tested in the test protocols. The traceability matrix is a tool both for the validation team to ensure that requirements are not lost during the validation project and for auditors to review the validation documentations.

Retesting 

Retesting is the execution of one or a set of test cases which previously failed due to a suspected defect in the software’s.

Review 

A review is a systematic examination of documents by more or one people with the main aim of finding and removing errors early in the software development life cycle. Reviews are used to verify documents such as requirements, code, system designs, test plans and test cases.

Risk 

Risks are future uncertain event with a probability of occurrence and a potential for loss. It is a factor that could result in negative consequences and usually expressed as the product of impact and likelihood.

Risk = Probability of the event occurring x Impact if it did happen 

Different categories of risks are:-

• Schedule risk
• Budget risk
• Operational risk

Risk Management 

Risk management is a series of steps whose objectives are to address, identify and eliminate software risk items before they become either threats to successful software operation or a major source of expensive rework.

Root Cause 

Root Cause is the process of identifying the contributing factors for the underlying variations in performance associated with adverse events or close calls.