Software testing
USECASE
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.
A use case (or set of use cases) has these characteristics:
Organizes functional requirements
Models the goals of system/actor (user) interactions
Records paths (called scenarios) from trigger events to goals
Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)
Is multi-level, so that one use case can use the functionality of another one.
Use cases can be employed during several stages of software development, such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.
etting started with use case methodology
To explore how use case is used in the enterprise, here are some additional resources for learning about use case methodology:
The pros and cons of use case diagrams: Putting too much into a use case diagram can often render the otherwise useful technique of use cases almost useless. Kevlin Henney recommends a more balanced and restrained approach in order to not lose readers in a myriad of bubbles and microscopic text.
From use case diagrams to context diagrams: It's tempting to consider use case diagrams as context diagrams because they do show context. But having one diagram for both will result in an unreadable cloud of bubbles.
Five use case traps to avoid: Employing use cases during software requirements analysis helps you improve your chances of developing software that truly meets their needs. But there are traps you should avoid, says expert Karl E. Wiegers.
RELATED GLOSSARY TERMS: HCI (human-computer interaction), user acceptance testing (UAT), use case diagram, pattern (design pattern)
Techopedia explains Use Case
Use cases define interactions between external actors and the system to attain particular goals. There are three basic elements that make up a use case:
Actors: Actors are the type of users that interact with the system.
System: Use cases capture functional requirements that specify the intended behavior of the system.
Goals: Use cases are typically initiated by a user to fulfill goals describing the activities and variants involved in attaining the goal.
Use cases are modeled using unified modeling language and are represented by ovals containing the names of the use case. Actors are represented using lines with the name of the actor written below the line. To represent an actor's participation in a system, a line is drawn between the actor and the use case. Boxes around the use case represent the system boundary.
Characteristics associated with use cases are:
Organizing functional requirements
Modeling the goals of system user interactions
Recording scenarios from trigger events to ultimate goals
Describing the basic course of actions and exceptional flow of events
Permitting a user to access the functionality of another event
The steps in designing use cases are:
Identify the users of the system
For each category of users, create a user profile. This includes all roles played by the users relevant to the system.
Identify significant goals associated with each role to support the system. The system’s value proposition identifies the significant role.
Create use cases for every goal associated with a use case template and maintain the same abstraction level throughout the use case. Higher level use case steps are treated as goals for the lower level.
Structure the use cases
Review and validate the users
TEST CASE
A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software systemor one of its features is working as it was originally established for it to do. 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 reqirement 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 considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written - when they are usually collected into test suites.
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. If a requirement has sub-requirements, 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.
A formal written test-case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a preconditionand 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 of the key.
Typical written test case format
A test case is usually a single step, or occasionally a sequence of steps, to test the correct behaviour/functionality, 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 can be or has been automated
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.
user case and test case
USECASE
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.
A use case (or set of use cases) has these characteristics:
Organizes functional requirements
Models the goals of system/actor (user) interactions
Records paths (called scenarios) from trigger events to goals
Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)
Is multi-level, so that one use case can use the functionality of another one.
Use cases can be employed during several stages of software development, such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.
etting started with use case methodology
To explore how use case is used in the enterprise, here are some additional resources for learning about use case methodology:
The pros and cons of use case diagrams: Putting too much into a use case diagram can often render the otherwise useful technique of use cases almost useless. Kevlin Henney recommends a more balanced and restrained approach in order to not lose readers in a myriad of bubbles and microscopic text.
From use case diagrams to context diagrams: It's tempting to consider use case diagrams as context diagrams because they do show context. But having one diagram for both will result in an unreadable cloud of bubbles.
Five use case traps to avoid: Employing use cases during software requirements analysis helps you improve your chances of developing software that truly meets their needs. But there are traps you should avoid, says expert Karl E. Wiegers.
RELATED GLOSSARY TERMS: HCI (human-computer interaction), user acceptance testing (UAT), use case diagram, pattern (design pattern)
Techopedia explains Use Case
Use cases define interactions between external actors and the system to attain particular goals. There are three basic elements that make up a use case:
Actors: Actors are the type of users that interact with the system.
System: Use cases capture functional requirements that specify the intended behavior of the system.
Goals: Use cases are typically initiated by a user to fulfill goals describing the activities and variants involved in attaining the goal.
Use cases are modeled using unified modeling language and are represented by ovals containing the names of the use case. Actors are represented using lines with the name of the actor written below the line. To represent an actor's participation in a system, a line is drawn between the actor and the use case. Boxes around the use case represent the system boundary.
Characteristics associated with use cases are:
Organizing functional requirements
Modeling the goals of system user interactions
Recording scenarios from trigger events to ultimate goals
Describing the basic course of actions and exceptional flow of events
Permitting a user to access the functionality of another event
The steps in designing use cases are:
Identify the users of the system
For each category of users, create a user profile. This includes all roles played by the users relevant to the system.
Identify significant goals associated with each role to support the system. The system’s value proposition identifies the significant role.
Create use cases for every goal associated with a use case template and maintain the same abstraction level throughout the use case. Higher level use case steps are treated as goals for the lower level.
Structure the use cases
Review and validate the users
TEST CASE
A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software systemor one of its features is working as it was originally established for it to do. 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 reqirement 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 considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written - when they are usually collected into test suites.
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. If a requirement has sub-requirements, 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.
A formal written test-case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a preconditionand 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 of the key.
Typical written test case format
A test case is usually a single step, or occasionally a sequence of steps, to test the correct behaviour/functionality, 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 can be or has been automated
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.
