A test case in software engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. Software engineering is the application of a systematic disciplined quantifiable approach to the development operation and maintenance of Software. In Engineering, a requirement is a singular documented need of what a particular product or service should be or do A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system Application software is a subclass of Computer software that employs the capabilities of a computer directly and thoroughly to a task that the user wishes to perform It may take many test cases to determine that a requirement is fully satisfied.

Test cases are often incorrectly referred to as test scripts. A test script in Software Testing is a set of instructions that will be performed on the System Test scripts are lines of code used mainly in automation tools.

Written test cases are usually collected into test suites. In Software development, a test suite, less commonly known as a validation suite, is a collection of Test cases that are intended to be used to test

Formal requirement-based test cases

In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub-requirements. In that situation, each sub-requirement must have at least one test case. This is frequently done using a traceability matrix. A traceability matrix is a table that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship Some methodologies, like RUP, recommend creating at least two test cases for each requirement. The Rational Unified Process ( RUP) is an Iterative Software development process framework created by the Rational Software Corporation a division One of them should perform positive testing of requirement and other should perform negative testing. Written test cases should include a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted.

What characterizes a formal, written test case is that there is a known input and an expected output, which is worked out before the test is executed. The known input should test a precondition and the expected output should test a postcondition. In Logic a precondition is a condition that has to be met before a main argument can have any value In Computer programming, a postcondition is a condition or predicate that must always be true just after the execution of some section of code or after an operation

Informal requirement-based test cases

For application without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run.

Typical Test Cases format

Test Cases usually have the following components.

• Test Case Summary
• Configuration
• Initial Condition
• Steps to run the test case
• Expected behavior/outcome

Further reading

Under special circumstances, there could be a need to run the test, produce results, and then a team of experts would evaluate if the results can be considered as a pass. This happens often on new products' performance number determination. The first test is taken as the base line for subsequent test / product release cycles.

A variation of test cases are most commonly used in acceptance testing. In Engineering and its various subdisciplines, acceptance testing is Black-box testing performed on a System (e Acceptance testing is done by a group of end-users or clients of the system to ensure the developed system meets the requirements specified. Economics and Commerce define an end-user as the person who uses a product. User acceptance testing is usually differentiated by the inclusion of happy path or positive test case.

References

• Writing Software Security Test Cases - Putting security test cases into your test plan by Robert Auger