Glossary of Software QA/Testing

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  

Waterfall model
Waterfall is a model of the software development process in which the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase are performed in that order, probably with overlap, but with little or no iteration.

PDR
PDR is an acronym. In the world of software QA or testing, it stands for "peer design review", informally known as "peer review".

Exit criteria
The "exit criteria" is a checklist, sometimes known as the "PDR sign-off sheet". It is a list of peer design review related tasks that have to be done by the facilitator or attendees of the PDR, either during or near the conclusion of the PDR.
By having a checklist, and by going through the checklist, the facilitator can verify that A) all attendees have inspected all the relevant documents and reports, B) all suggestions and recommendations for each issue have been recorded, and C) all relevant facts of the meeting have been recorded.
The facilitator's checklist includes the following questions:
* Have we inspected all the relevant documents, code blocks, or products?
* Have we completed all the required checklists?
* Have I recorded all the facts relevant to this peer review?
* Does anyone have any additional suggestions, recommendations, or comments?
* What is the outcome of this peer review?
As the end of the PDR, the facilitator asks the attendees to make a decision as to the outcome of the PDR, i.e. "What is our consensus... are we accepting the design (or document or code)?" Or, "Are we accepting it with minor modifications?" Or, "Are we accepting it after it has been modified and approved through e-mails to the attendees?" Or, "Do we want another peer review?" This is a phase, during which the attendees work as a committee, and the committee's decision is final.

Data integrity
Data integrity is one of the six fundamental components of information security. Data integrity is the completeness, soundness, and wholeness of the data that also complies with the intention of the creators of the data.
In databases, important data - including customer information, order database, and pricing tables - may be stored. In databases, data integrity is achieved by preventing accidental, or deliberate, or unauthorized insertion, or modification, or destruction of data.

Data validity?
Data validity is the correctness and reasonablenesss of data. Reasonableness of data means that, for example, account numbers falling within a range, numeric data being all digits, dates having a valid month, day and year, and spelling of proper names. Data validity errors are probably the most common, and most difficult to detect (data-related) errors.
What causes data validity errors? Data validity errors are usually caused by incorrect data entries, when a large volume of data is entered in a short period of time. For example, a data entry operator enters 12/25/2010 as 13/25/2010, by mistake, and this data is therefore invalid. How can you reduce data validity errors? You can use one of the following two, simple field validation techniques.
Technique 1: If the date field in a database uses the MM/DD/YYYY format, then you can use a program with the following two data validation rules: "MM" should not exceed "12", and "DD" should not exceed "31".
Technique 2: If the original figures do not seem to match the ones in the database, then you can use a program to validate data fields. You can compare the sum of the numbers in the database data field to the original sum of numbers from the source. If there is a difference between the two figures, it is an indication of an error in at least one data element.

TestDirector
TestDirector®, also known as Mercury TestDirector®, is a software tool made for software QA professionals. Mercury TestDirector®, as the name implies, is a product made by Mercury Interactive Corporation, 379 North Whisman Road, Mountain View, California 94043 USA.
Mercury's other products include the Mercury QuickTest Professional™, Mercury WinRunner™, also known as WinRunner™, and Mercury Business Process Testing™.

Parameter?
In software QA or software testing, a parameter is an item of information - such as a name, number, or selected option - that is passed to a program, by a user or another program. By definition, in software, a parameter is a value on which something else depends. Any desired numerical value may be given as a parameter. In software development, we use parameters when we want to allow a specified range of variables. We use parameters when we want to differentiate behavior or pass input data to computer programs or their subprograms. Thus, when we are testing, the parameters of the test can be varied to produce different results, because parameters do affect the operation of the program receiving them.
Example 1: We use a parameter, such as temperature, that defines a system. In this definition, it is temperature that defines the system and determines its behavior.
Example 2: In the definition of function f(x) = x + 10, x is a parameter. In this definition, x defines the f(x) function and determines its behavior. Thus, when we are testing, x can be varied to make f(x) produce different values, because the value of x does affect the value of f(x).
When parameters are passed to a function subroutine, they are called arguments.

Constant
In software or software testing, a constant is a meaningful name that represents a number, or string, that does not change. Constants are variables that remain the same, i.e. constant, throughout the execution of a program.
Why do we, developers, use constants? Because if we have code that contains constant values that keep reappearing, or, if we have code that depends on certain numbers that are difficult to remember, we can improve both the readability and maintainability of our code, by using constants.
To give you an example, we declare a constant and we call it "Pi". We set it to 3.14159265, and use it throughout our code. Constants, such as Pi, as the name implies, store values that remain constant throughout the execution of our program.
Keep in mind that, unlike variables which can be read from and written to, constants are read-only. Although constants resemble variables, we cannot modify or assign new values to them, as we can to variables, but we can make constants public or private. We can also specify what data type they are.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34