test case

A legal action whose outcome is likely to set a precedent or test the constitutionality of a statute.

A test case has usually been thought of as one in which an individual, but more likely an interest group, initiates a case in order to challenge the constitutionality, or perhaps a particular disliked interpretation, of a statute. There are other situations that, although somewhat different from this traditional sense of “test case,” can also be loosely called “test cases.” Some people challenge laws, not necessarily with the thought of “going to the Supreme Court,” but simply because the laws are thought improper, but their cases end up in the Supreme Court; examples are provided by civil rights demonstrators who sat in at restaurants in the South in the 1950s and 1960s. Their convictions on a variety of misdemeanor charges provided convenient opportunities for the federal courts to speak out against racial discrimination. Others might specifically provoke arrest under a statute, with the intention that the case reach the high court, as occurred after Congress in 1989 passed a statute against flag burning. In still other situations, when individuals run afoul of a law they did not specifically seek to break, a lawyer taking their case may challenge the statute's validity rather than try to avoid a conviction.

The examples just noted are relatively recent civil liberties or civil rights situations. Instances of test cases are also found in economic regulation: many challenges to New Deal regulatory legislation were intentionally brought by businesses, their trade associations, or conservative interest groups like the Liberty Lobby. Test cases can be found much earlier as well. One example is the famous “separate but equal” case, Plessy v. Ferguson (1896), which resulted from a concerted effort by some lawyers, joined by railroads, to invalidate Jim Crow statutes; another was an effort by conservatives to challenge the federal income tax through action masked in a collusive suit, Pollock v. Farmers' Loan and Trust Company (1895).

Interest groups engaging in litigation are now more likely to undertake immediate focused challenges to objectionable laws almost before the ink is dry, rather than waiting for individual cases to arise when the laws are implemented and someone is adversely affected by them.

There are several reasons for frequent contemporary use of test cases. The Supreme Court has broadened access to the courts by those seeking to challenge laws. Judges are also more willing to entertain actions for declaratory judgments, that is, declarations of a party's rights before the person is charged with violation of a law; to entertain attacks on a statute “on its face,” that is, on the statute as written, not as applied; to issue injunctions against enforcement of a law; and to grant summary judgments, that is, to rule on the basis of affidavits rather than waiting until extensive testimony has been taken about contested facts. As a result, few new controversial statutes last long before being tested.

Test cases serve to move political issues quickly into a legal setting and to accelerate their arrival at the Supreme Court. Because the Supreme Court is a major political actor likely to confront any major current controversy in due course, test cases are to be expected and are consonant with this view of the Court's role. However, some test cases leave the justices without the benefit of seeing how a statute is applied and, however it may appear “on its face,” whether it might have been applied in a constitutional manner. To the extent our adversary legal system is associated with cases heavily anchored in particular facts, the greater use of facial statutory challenges is a departure from that tradition. The Court itself could make it harder to bring test cases lacking a thorough factual development. One way would be to alter rulings on procedure, as the Burger Court did by tightening rules on access to the courts, for example, limiting who had standing to challenge zoning rules (Warth v. Selden, 1975). Another would be simply not to grant review in cases where a thorough factual record had not been developed.

— Stephen L. Wasby

A test case is one in which an individual or a group intentionally violates a law in order to bring a case to court. The purpose is to test the constitutionality of the law. For example, in 1989 Congress passed a law against flag burning. Soon afterward, protesters broke this law because they wanted to bring a test case to the courts. Thus, the case of United States v. Eichman (1990) was tried and eventually taken to the U.S. Supreme Court. The Court decided that the federal flag-burning law was unconstitutional and overturned it–-exactly the outcome desired by those who initiated the test case.

A suit brought specifically for the establishment of an important legal right or principle.

The term test case describes a case that tests the validity of a particular law. Test cases are useful because they establish legal rights or principles and thereby serve as precedent for future similar cases. Test cases save the judicial system the time and expense of conducting proceedings for each and every case that involves the same issue or issues.

To illustrate, assume that Congress passes a law that makes using a cellular phone while driving a misdemeanor punishable by up to one year in jail and a fine of $10,000. Such a law would likely be challenged by a large number of cell phone owners, all of whom are in essentially identical circumstances and all of whom have the same arguments against the law. In such a situation, attorneys representing the plaintiffs might look for a case with a sympathetic set of facts with which to challenge the law. For example, they might select a case involving a driver who was charged with violating the law when she used her cell phone to request medical assistance for a family member. Other observant law firms would postpone or otherwise delay their own similar cases to wait for the outcome of the test case.

A test case need not concern a new law. Suppose, for example, an attorney or client is dissatisfied with the current state of a particular law and has strong arguments in favor of changing it. If the facts of the case give the attorney or client a good chance of prevailing, the case may be called a test case because the outcome would change the law for future persons in similar circumstances.

In some cases, a person may choose to violate an existing law to provoke a lawsuit, prosecution, or penalty. The person may then challenge the lawsuit, prosecution, or penalty and use the case to try and change the law through a judicial opinion. In Druker v. Commissioner of Internal Revenue, 697 F.2d 46 (2d Cir. 1982), cert. den., 461 U.S. 957, 103 S. Ct. 2429, 77 L. Ed. 2d 1316 (1983), for example, James O. and Joan Druker, a married couple, intentionally used the lower tax rates for unmarried individuals in computing their 1975 and 1976 income tax because they believed the federal tax scheme was unconstitutional under the Equal Protection Clause of the Fourteenth Amendment. Before the Internal Revenue Service (IRS) could take action against the Drukers, the Drukers filed suit against the commissioner of the IRS. The Drukers were unsuccessful, but had they received a favorable disposition, they would have succeeded in changing the law on federal taxation of married couples.

See: case law; stare decisis.

This article is about the term in software engineering. For the use of the term in law, see Test case (law).

Software Testing portal

A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is functioning correctly. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.

Contents 1 Formal test cases 2 Informal test cases 3 Typical written test case format 4 References 5 External links

Formal test cases

In order to fully test that all the requirements of an application are met, there must be at least two test cases for each requirement: one positive test and one negative test; unless a requirement has sub-requirements. In that situation, each sub-requirement must have at least two test cases. Keeping track of the link between the requirement and the test is frequently done using a traceability matrix. 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.

Informal test cases

For applications or systems 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.

In scenario testing, hypothetical stories are used to help the tester think through a complex problem or system. These scenarios are usually not written down in any detail. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate. They are usually different from test cases in that test cases are single steps while scenarios cover a number of steps.

Typical written test case format

A test case is usually a single step, or occasionally a sequence of steps, to test the correct behaviour/functionalities, features of an application. An expected result or expected outcome is usually given.

Additional information that may be included:

• test case ID
• test case description
• test step or order of execution number
• related requirement(s)
• depth
• test category
• author
• check boxes for whether the test is automatable and has been automated.

Additional fields that may be included and completed when the tests are executed:

• pass/fail
• remarks

Larger test cases may also contain prerequisite states or steps, and descriptions.

A written test case should also contain a place for the actual result.

These steps can be stored in a word processor document, spreadsheet, database or other common repository.

In a database system, you may also be able to see past test results and who generated the results and the system configuration used to generate those results. These past results would usually be stored in a separate table.

Test suites often also contain

• Test summary
• Configuration

Besides a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted, the most time consuming part in the test case is creating the tests and modifying them when the system changes.

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.

Acceptance tests, which use a variation of a written test case, are commonly performed by a group of end-users or clients of the system to ensure the developed system meets the requirements specified or the contract. User acceptance tests are differentiated by the inclusion of happy path or positive test cases to the almost complete exclusion of negative test cases.

References

This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. (May 2009)

External links

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

v • d • e Software engineering Fields Requirements analysis • Software design • Computer programming • Formal methods • Software testing • Software deployment • Software maintenance Concepts Data modeling • Enterprise architecture • Functional specification • Modeling language • Programming paradigm • Software • Software architecture • Software development methodology • Software development process • Software quality • Software quality assurance • Structured analysis Orientations Agile • Aspect-oriented • Object orientation • Ontology • Service orientation • SDLC Models Development models: Agile • Iterative model • RUP • Scrum • Spiral model • Waterfall model • XP • V-Model Other models: CMMI • Data model • Function model • IDEF • Information model • Metamodeling • Object model • View model • UML Software engineers Kent Beck • Grady Booch • Fred Brooks • Barry Boehm • Ward Cunningham • Ole-Johan Dahl • Tom DeMarco • Edsger W. Dijkstra • Martin Fowler • C. A. R. Hoare • Watts Humphrey • Michael A. Jackson • Ivar Jacobson • Craig Larman • James Martin • Bertrand Meyer • David Parnas • Winston W. Royce • James Rumbaugh • Niklaus Wirth • Edward Yourdon Related fields Computer science • Computer engineering • Enterprise engineering • History • Management • Mathematics • Project management • Quality management • Software ergonomics • Systems engineering

This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)