Quality Assurance: The activity of providing evidence needed to establish confidence among all concerned, that quality-related activities are being performed effectively. All those planned or systematic actions necessary to provide adequate confidence that a product or service will satisfy given requirements for quality.
For software development organizations, TMM (Testing Maturity Model) standards are widely used to measure the Quality Assurance. These standards can be divided in to 5 steps, which a software development company can achieve by performing different quality improvement activities within the organization.
Quality Attribute: A feature of characteristic that effects an item's quality.
Quality Audit: A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.
Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality to outputs of a process and to the correction of problems or to the improvement of quality.
Quality Control: The operational techniques and the activities used to fulfill and verify requirements of quality.
Quality Management: That aspect of the overall management function that determines and implements that quality policy. Direction and control with regard to quality generally includes the establishment of the quality policy and quality objectives, quality planning, quality control, quality assurance and quality improvement.
Quality Conundrum: Resource, risk and application time-to-market are often in conflict as IS teams strive to deliver quality applications within their budgetary constraints. This is quality conundrum.
Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed by top management.
Quality System: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.
Query: A question. Often associated with an SQL query of values in a database.
Queuing Time: Incurred when the device, which a program wishes to use, is already busy. The program therefore has to wait in a queue to obtain service from that device.
Tuesday, March 12, 2013
P
Page Fault: A program interruption that occurs when a page that is marked 'not in real memory' is referred to by an active page.
Pair Programming: A software development technique that requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: for example, while one types in unit tests, the other thinks about the class that will satisfy the test.
The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.
Pair Testing: In much the same way as Pair Programming, two testers work together to find defects. Typically, they share one computer and trade control of it while testing.
Pairwise Testing: A combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm) test all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameters pairs. The number of tests is typically O (nm), where n and m are the number of possibilities for each of the two parameters with the most choices.
The reasoning behind all-pairs testing is this: the simplest Bugs in a program are generally triggered by a single input parameter. The next simplest category of bugs consists of those dependent on interactions between pairs of parameters, which can be caught with all-pairs testing. Bugs involving interactions between three or more parameters are progressively less common, whilst at the same time being progressively more expensive to find by exhaustive testing, which has as its limit the exhaustive testing of all possible inputs.
Many testing methods regard all-pairs testing of a system or subsystem as a reasonable cost-benefit compromise between often computationally infeasible higher-order combinatorial testing methods, and less exhaustive methods which fail to exercise all possible pairs of parameters. Because no testing technique can find all bugs, all-pairs testing is typically used together with other quality assurance techniques such as Unit Testing. See TestDrive-Gold.
Partial Test Automation: The process of automating parts but not all of the software testing process. If, for example, an oracle cannot reasonably be created, or if fully automated tests would be too difficult to maintain, then a software tools engineer can instead create testing tools to help human testers perform their jobs more efficiently. Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging etc., without necessarily automating tests in an end-to-end fashion.
Pass: Software has deemed to have passed a test if the actual results of the test matched the expected results.
Pass/Fail Criteria: Decision rules used to determine whether an item under test has passed or failed a test.
Path: A sequence of executable statements of a component, from an entry point to an exit point.
Path Coverage: The percentage of paths in a component exercised by a test case suite.
Path Sensitizing: Choosing a set of input values to force the execution of a component to take a given path.
Path Testing: Used as either Black Box or White Box testing, the procedure itself is similar to a walk-through. First, a certain path through the program is chosen. Possible inputs and the correct results are written down. Then the program is executed by hand, and its results is compared to the predefined. Possible Faults have to be written down at once.
Performance: The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate.
Performance Testing: A test procedure that covers a broad range of engineering or functional evaluations where a material, product, or system is not specified by detailed material or component specifications: Rather, emphasis is on the final measurable performance characteristics. Also known as Load Testing.
Portability: The ease with which the system/software can be transferred from one hardware of software environment to another.
Portability Requirements: A specification of the required portability for the system/software.
Portability Testing: The process of testing the ease with which a software component can be moved from one environment to another. This is typically measured in terms of the maximum amount of effort permitted. Results are expressed in terms of the time required to move the software and complete data conversion and documentation updates.
Postcondition: Environmental and state conditions that must be fulfilled after the execution of a test or test procedure.
Positive Testing: Testing aimed at showing whether the software works in the way intended. See also Negative Testing.
Precondition: Environmental and state conditions which must be fulfilled before the component can be executed with a particular input value.
Predicate: A logical expression which evaluated to TRUE or FALSE, normally to direct the execution path in code.
Predication: The choice to execute or not to execute a given instruction.
Predicted Outcome: The behavior expected by the specification of an object under specified conditions.
Priority: The level of business importance assigned to an individual item or test.
Prediction: The choice to execute or not to execute a given instruction.
Predicted Outcome: The behavior expected by the specification of a n object under specified conditions.
Priority: The level of business importance assigned to an individual item or test.
Process: A course of action which turns inputs into outputs or results.
Process Cycle Test: A Black Box test design technique in which test cases are designed to execute business procedures and processes.
Progressive Testing: Testing of new features after Regression Testing of previous features.
Project: A planned undertaking for presentation of results at a specified time in the future.
Prototyping: A strategy in system development in which a scaled down system or portion of a system is constructed in a short time, then tested and improved upon over several iterations.
Pseudo-Random: A series which appears to be random but is in fact generated according to some prearranged sequence.
Pair Programming: A software development technique that requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: for example, while one types in unit tests, the other thinks about the class that will satisfy the test.
The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.
Pair Testing: In much the same way as Pair Programming, two testers work together to find defects. Typically, they share one computer and trade control of it while testing.
Pairwise Testing: A combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm) test all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameters pairs. The number of tests is typically O (nm), where n and m are the number of possibilities for each of the two parameters with the most choices.
The reasoning behind all-pairs testing is this: the simplest Bugs in a program are generally triggered by a single input parameter. The next simplest category of bugs consists of those dependent on interactions between pairs of parameters, which can be caught with all-pairs testing. Bugs involving interactions between three or more parameters are progressively less common, whilst at the same time being progressively more expensive to find by exhaustive testing, which has as its limit the exhaustive testing of all possible inputs.
Many testing methods regard all-pairs testing of a system or subsystem as a reasonable cost-benefit compromise between often computationally infeasible higher-order combinatorial testing methods, and less exhaustive methods which fail to exercise all possible pairs of parameters. Because no testing technique can find all bugs, all-pairs testing is typically used together with other quality assurance techniques such as Unit Testing. See TestDrive-Gold.
Partial Test Automation: The process of automating parts but not all of the software testing process. If, for example, an oracle cannot reasonably be created, or if fully automated tests would be too difficult to maintain, then a software tools engineer can instead create testing tools to help human testers perform their jobs more efficiently. Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging etc., without necessarily automating tests in an end-to-end fashion.
Pass: Software has deemed to have passed a test if the actual results of the test matched the expected results.
Pass/Fail Criteria: Decision rules used to determine whether an item under test has passed or failed a test.
Path: A sequence of executable statements of a component, from an entry point to an exit point.
Path Coverage: The percentage of paths in a component exercised by a test case suite.
Path Sensitizing: Choosing a set of input values to force the execution of a component to take a given path.
Path Testing: Used as either Black Box or White Box testing, the procedure itself is similar to a walk-through. First, a certain path through the program is chosen. Possible inputs and the correct results are written down. Then the program is executed by hand, and its results is compared to the predefined. Possible Faults have to be written down at once.
Performance: The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate.
Performance Testing: A test procedure that covers a broad range of engineering or functional evaluations where a material, product, or system is not specified by detailed material or component specifications: Rather, emphasis is on the final measurable performance characteristics. Also known as Load Testing.
Portability: The ease with which the system/software can be transferred from one hardware of software environment to another.
Portability Requirements: A specification of the required portability for the system/software.
Portability Testing: The process of testing the ease with which a software component can be moved from one environment to another. This is typically measured in terms of the maximum amount of effort permitted. Results are expressed in terms of the time required to move the software and complete data conversion and documentation updates.
Postcondition: Environmental and state conditions that must be fulfilled after the execution of a test or test procedure.
Positive Testing: Testing aimed at showing whether the software works in the way intended. See also Negative Testing.
Precondition: Environmental and state conditions which must be fulfilled before the component can be executed with a particular input value.
Predicate: A logical expression which evaluated to TRUE or FALSE, normally to direct the execution path in code.
Predication: The choice to execute or not to execute a given instruction.
Predicted Outcome: The behavior expected by the specification of an object under specified conditions.
Priority: The level of business importance assigned to an individual item or test.
Prediction: The choice to execute or not to execute a given instruction.
Predicted Outcome: The behavior expected by the specification of a n object under specified conditions.
Priority: The level of business importance assigned to an individual item or test.
Process: A course of action which turns inputs into outputs or results.
Process Cycle Test: A Black Box test design technique in which test cases are designed to execute business procedures and processes.
Progressive Testing: Testing of new features after Regression Testing of previous features.
Project: A planned undertaking for presentation of results at a specified time in the future.
Prototyping: A strategy in system development in which a scaled down system or portion of a system is constructed in a short time, then tested and improved upon over several iterations.
Pseudo-Random: A series which appears to be random but is in fact generated according to some prearranged sequence.
Tuesday, March 5, 2013
O
Object: A software structure which represents an identifiable item that has a well-defined role in a problem domain.
Object Orientated: An adjective applied to any system or language that supports that use of objects.
Objective: The purpose of the specific test being under taken.
Operational Testing: Testing [erformed by the end-user on the software in its normal operating environment.
Oracle: A mechanism to produce the predicted outcomes to compare with the actual outcomes of the software under test.
Outcome: The result or visible effect of a test.
Output: A variable (whether stored within a component or outside it) that is written to by the component.
Output Domain: The set of all possible outputs.
Output Value: An instance of an output.
Object Orientated: An adjective applied to any system or language that supports that use of objects.
Objective: The purpose of the specific test being under taken.
Operational Testing: Testing [erformed by the end-user on the software in its normal operating environment.
Oracle: A mechanism to produce the predicted outcomes to compare with the actual outcomes of the software under test.
Outcome: The result or visible effect of a test.
Output: A variable (whether stored within a component or outside it) that is written to by the component.
Output Domain: The set of all possible outputs.
Output Value: An instance of an output.
N
N-Switch Coverage: The percentage of sequences of N-transitions that have been tested.
N-Switch Testing: A form of state transition testing in which test cases are designed to execute all valid sequences of N-transitions.
N-Transitions: A sequence of N+transitions.
N+1 Testing: A variation of regression testing. Testing conducted with multiple cycles in which errors found in test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the solution reaches a steady state and there are no errors. See also Regression Testing.
Natural Language Processing (NLP): A computer system to analyze, understand and generate natural human languages.
Negative Testing: Testing a system or application using negative data. (For example testing a password field that requires a minimum of 9 characters by entering a password of 6).
Non-Functional Requirements Testing: Testing of those requirements that do not relate to functionality. i.e. performance, usability, etc.
Normalization: A technique for designing relational database tables to minimize duplication of information and, in so doing, to safeguard the database against certain types of logical or structural problems, namely data anomalies.
N-Switch Testing: A form of state transition testing in which test cases are designed to execute all valid sequences of N-transitions.
N-Transitions: A sequence of N+transitions.
N+1 Testing: A variation of regression testing. Testing conducted with multiple cycles in which errors found in test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the solution reaches a steady state and there are no errors. See also Regression Testing.
Natural Language Processing (NLP): A computer system to analyze, understand and generate natural human languages.
Negative Testing: Testing a system or application using negative data. (For example testing a password field that requires a minimum of 9 characters by entering a password of 6).
Non-Functional Requirements Testing: Testing of those requirements that do not relate to functionality. i.e. performance, usability, etc.
Normalization: A technique for designing relational database tables to minimize duplication of information and, in so doing, to safeguard the database against certain types of logical or structural problems, namely data anomalies.
M
Maintainability: The ease with which the system/software can be modified to correct faults, modified to meet new requirements, modified to make future maintenance easier, or adapted to a changed environment.
Maintenance Requirements: A specification of the required maintenance needed for the system/software. The released software often needs to be revised and/or upgraded throughout its lifecycle. Therefore it is essential that the software can be easily maintained, and any errors found during re-work and upgrading.
Within traditional software testing techniques, script maintenance is often a problem as it can be very complicated and time consuming to ensure correct maintenance of the software as the scripts these tools use need updating every time the application under test changes. See Code Free Testing and Self Healing Scripts.
Manual Testing: the oldest type of software testing. Manual testing requires a tester to perform manual test operations on the test software without the help of test automation. Manual testing is a laborious activity that requires the tester to possess a certain set of qualities; to be patient, observant, speculative, creative, innovative, open-minded, resourceful, un-opinionated, and skillful.
As a tester, it is always advisable to use manual white box testing and black-box testing techniques on the test software. Manual testing helps discover and record any software Bugs or discrepancies related to the functionality of the product.
Manual testing can be augmented by Test Automation. It is possible to record and playback manual steps and write automated test script(s) using test automation tools. Although, test automation tools will only help execute test scripts written primarily for executing a particular specification and functionality. Test automation tools lack the ability of decision-making and recording any unscripted discrepancies during program execution. It is recommended that one should perform manual testing of the entire product at least a couple of times before actually deciding to automate the ore mundane activities of the product.
Manual testing helps discover defects related to the usability testing and GUI testing area. While performing manual tests the software application can be validated whether it meets the various standards defined for effective and efficient usage and accessibility. For example, the standard location of the OK button on a screen is on the left and of CANCEL button on the right. During manual testing you might discover that one some screen, it is not. This is a new defect related tot he usability of the screen. In addition, there could be many cases where the GUI is not displayed correctly and the basic functionality of the program is correct. Such bugs are not detectable using test automation tools.
Repetitive manual testing can be difficult to perform on large software applications or applications having very large dataset coverage. This drawback is compensated for by using manual black-box testing techniques including equivalence partitioning and boundary value analysis. Using which, the vast dataset specifications can be divided and converted into a more manageable and achievable set of test suites.
There is no complete substitute for manual testing. Manual testing is crucial for testing software applications more thoroughly. See TestDrive-Assist.
Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.
Modified Condition/Decision Coverage: The percentage of all branch condition outcomes that independently affect a decision outcome that have been exercised by a test case suite.
Modified Condition/Decision Testing: A test case design technique in which test cases are designed to execute branch condition outcomes that independently affect a decision outcome.
Monkey Testing: Testing a system or an application on the fly, i.e. a unit test with no specific end result in mind.
Multiple Condition Coverage: See Branch Condition Combination Coverage.
Mutation Analysis: A method to determine test case suite thoroughness by measuring the extent to which a test case suite can discriminate the program from slight variants (mutants) of the program. See also Error Seeding.
Mutation Testing: Testing done on the application where bugs are purposely added to it. See Bebugging.
Maintenance Requirements: A specification of the required maintenance needed for the system/software. The released software often needs to be revised and/or upgraded throughout its lifecycle. Therefore it is essential that the software can be easily maintained, and any errors found during re-work and upgrading.
Within traditional software testing techniques, script maintenance is often a problem as it can be very complicated and time consuming to ensure correct maintenance of the software as the scripts these tools use need updating every time the application under test changes. See Code Free Testing and Self Healing Scripts.
Manual Testing: the oldest type of software testing. Manual testing requires a tester to perform manual test operations on the test software without the help of test automation. Manual testing is a laborious activity that requires the tester to possess a certain set of qualities; to be patient, observant, speculative, creative, innovative, open-minded, resourceful, un-opinionated, and skillful.
As a tester, it is always advisable to use manual white box testing and black-box testing techniques on the test software. Manual testing helps discover and record any software Bugs or discrepancies related to the functionality of the product.
Manual testing can be augmented by Test Automation. It is possible to record and playback manual steps and write automated test script(s) using test automation tools. Although, test automation tools will only help execute test scripts written primarily for executing a particular specification and functionality. Test automation tools lack the ability of decision-making and recording any unscripted discrepancies during program execution. It is recommended that one should perform manual testing of the entire product at least a couple of times before actually deciding to automate the ore mundane activities of the product.
Manual testing helps discover defects related to the usability testing and GUI testing area. While performing manual tests the software application can be validated whether it meets the various standards defined for effective and efficient usage and accessibility. For example, the standard location of the OK button on a screen is on the left and of CANCEL button on the right. During manual testing you might discover that one some screen, it is not. This is a new defect related tot he usability of the screen. In addition, there could be many cases where the GUI is not displayed correctly and the basic functionality of the program is correct. Such bugs are not detectable using test automation tools.
Repetitive manual testing can be difficult to perform on large software applications or applications having very large dataset coverage. This drawback is compensated for by using manual black-box testing techniques including equivalence partitioning and boundary value analysis. Using which, the vast dataset specifications can be divided and converted into a more manageable and achievable set of test suites.
There is no complete substitute for manual testing. Manual testing is crucial for testing software applications more thoroughly. See TestDrive-Assist.
Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.
Modified Condition/Decision Coverage: The percentage of all branch condition outcomes that independently affect a decision outcome that have been exercised by a test case suite.
Modified Condition/Decision Testing: A test case design technique in which test cases are designed to execute branch condition outcomes that independently affect a decision outcome.
Monkey Testing: Testing a system or an application on the fly, i.e. a unit test with no specific end result in mind.
Multiple Condition Coverage: See Branch Condition Combination Coverage.
Mutation Analysis: A method to determine test case suite thoroughness by measuring the extent to which a test case suite can discriminate the program from slight variants (mutants) of the program. See also Error Seeding.
Mutation Testing: Testing done on the application where bugs are purposely added to it. See Bebugging.
Subscribe to:
Posts (Atom)