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.
Tuesday, March 5, 2013
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.
Thursday, February 28, 2013
L
LCSAJ: A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements, the end of the linear sequence, and the target line to which control flow is transferred at the end of the linear sequence.
LCSAJ Coverage: The percentage of LCSAJs of a component which are exercised by a test case suite.
LCSAJ Testing: A test case design technique for a component in which test cases are designed to execute LCSAJs.
Logic-Coverage Testing: Sometimes referred to as Path Testing, logic-coverage testing attempts to expose software defects by exercising a unique combination of the program's statements known as a Path.
Load Testing: The process of creating demand on a system or device and measuring its response. Load testing generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the program's services concurrently. As such, this testing is most relevant for multi-user systems, often one built using a client/server model, such as web servers. However, other types of software systems can be load tested also. For example, a word processor or graphics editor can be forced to read an extremely large document; or a financial package can be forced to generate a report based on several years' worth of data. The most accurate load testing occurs with actual, rather than theoretical, results. See also Concurrent Testing, Performance Testing, Reliability Testing, and Volume Testing.
Localization Testing: This term refers to making software specifically designed for a specific locality. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product.
The test effort during localization testing focuses on:
Loop Testing: Loop testing is the testing of a resource or resources multiple times under program control.
LCSAJ Coverage: The percentage of LCSAJs of a component which are exercised by a test case suite.
LCSAJ Testing: A test case design technique for a component in which test cases are designed to execute LCSAJs.
Logic-Coverage Testing: Sometimes referred to as Path Testing, logic-coverage testing attempts to expose software defects by exercising a unique combination of the program's statements known as a Path.
Load Testing: The process of creating demand on a system or device and measuring its response. Load testing generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the program's services concurrently. As such, this testing is most relevant for multi-user systems, often one built using a client/server model, such as web servers. However, other types of software systems can be load tested also. For example, a word processor or graphics editor can be forced to read an extremely large document; or a financial package can be forced to generate a report based on several years' worth of data. The most accurate load testing occurs with actual, rather than theoretical, results. See also Concurrent Testing, Performance Testing, Reliability Testing, and Volume Testing.
Localization Testing: This term refers to making software specifically designed for a specific locality. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product.
The test effort during localization testing focuses on:
- Areas affected by localization, such as UI and content
- Culture/locale-specific, language-specific, and region-specific areas.
- Basic functionality tests
- Setup and upgrade tests run in the localized environment
- Plan application and hardware compatibility tests according to the product's target region.
Loop Testing: Loop testing is the testing of a resource or resources multiple times under program control.
K
KBS (Knowledge Based System): A domain specific knowledge base combined with an inference engine that processes knowledge encoded in the knowledge base to respond to a user's request for advice.
Key Performance Indicator: Quantifiable measurements against which specific performance criteria can be set.
Keyword Driven Testing: An approach to test script writing aimed at code based automation tools that separated much of the programming work from the actual test steps. The results is the test steps can be designed earlier and the code base if often easier to read and maintain.
Knowledge Engineering: The process of codifying an expert's knowledge in a form that can be accessed through an expert system.
Known Error: An incident or problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified.
Key Performance Indicator: Quantifiable measurements against which specific performance criteria can be set.
Keyword Driven Testing: An approach to test script writing aimed at code based automation tools that separated much of the programming work from the actual test steps. The results is the test steps can be designed earlier and the code base if often easier to read and maintain.
Knowledge Engineering: The process of codifying an expert's knowledge in a form that can be accessed through an expert system.
Known Error: An incident or problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified.
Subscribe to:
Posts (Atom)