Glossary of the Lecture 5 «Test design. Test cases» for the «Fundamentals of Software Testing» course

Any professional field is not complete without a specific vocabulary, which is used by specialists in the work. The IT industry is not an exception. On the contrary, proficiency in professional speech is simply a must-have.

During the course you will gradually replenish your vocabulary with some new words. We are sure they will be helpful for you not only in doing your homework, but also in professional activities.

Specially for you, we have prepared a series of articles containing glossaries of terms for each lecture of the course «Fundamentals of Software Testing» that testers operate with every day.

Boundary Value – an input or output value that is on the edge of the equivalent region or on the smallest distance from the both sides of the edge, for example, the minimum or maximum value of the region.

(Border Condition, Boundary Condition)

Code Coverage – an assessment of the coverage of the executable code tests, performed by tracking some not verified software parts during testing.

Equivalence class – a data set that processes in the same way and produces the same result.

High Level Test Case – a test case without specific input values ​​and expected results. It uses logical operators; instances of the real values ​​are not yet defined and/or not available.

Low Level Test Case – a test case with specific input values ​​and expected results.

Negative Test Case – a case where the system validated against the valid and invalid input data. A negative test checks if an application behaves as expected with its negative inputs. Checks for exceptional situations (triggering of validators) and also checks that the function called by the application does not work when the validator is triggered.

Positive Test Case – tests only the valid inputs to verify that  the software is doing what it's supposed to do.

Requirements Coverage – an assessment of the test coverage of the functional and non-functional product requirements by constructing a traceability matrix.

Test Design – the stage of the software testing process when test cases are designed and created in accordance with the previously defined quality criteria and testing objectives.

Test Case – a set of steps, specific conditions and parameters necessary to verify the implementation of the tested function or its part.

Test Suite – a set of tests that implement the business task performed by the system under the tested system The test suite includes, in addition, to test scenarios, test data, or the rules for their generation.

Test Coverage – one of the metrics for assessing the quality of testing, which is represented by the density of the test coverage of the requirements or executable code.

Test Design Techniques:

Boundary Value Analysis – a technique for checking the behavior of the product at the boundary values ​​of the input data. Boundary testing may also include tests that verify the behavior of the system on input data that is outside the acceptable range of values. In this case, the system must in a certain (pre-agreed) way handle such situations. For example, using an exception or error message.

Cause/Effect – usually the combination input of conditions (reasons) to receive a response from the system (effects). For example, clicking the «Add» button to submit a customer add form is the «Cause». After clicking the «Add» button, the system adds the client to the database and displays its number on the screen and this is the «Effect».

Decision Table – a great tool to streamline the complex business requirements that need to be implemented in a product. The decision tables present a set of conditions, the simultaneous fulfillment of which should lead to a certain action.

Equivalence Partitioning – a technique that involves splitting the entire set of tests into equivalence classes with a subsequent reduction in the number of tests.

Error Guessing – when a tester uses his knowledge of the system and the ability to interpret the specification in order to «predict» under what input conditions the system may throw an error. For example, the specification says: «the user must enter the code». The tester thinks: «What if I do not enter the code?», «What if I enter the wrong code?» And so on.

Exhaustive Testing – an extreme case. Within this technique, you should check all possible combinations of input values and this should find all bugs. In practice, the application of this method is not possible due to the huge number of input values.

Pairwise Testing – the technique where instead of checking all possible combinations of values ​​of all parameters, only combinations of values ​​of each pair of parameters are checked. It consists of such data sets where each tested value of each of the checked parameters is at least once combined with other tested values of all the other checked parameters.