Written By Nishikant Banchhor

Software Engineer Introduction Use cases are a popular way to express software requirements. They are popular because they are practical. A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction. Use cases are simple enough that almost anyone can read them. Even customers or users can read use cases without any special training. However, writing use cases takes some practice. It is not difficult to start writing use cases, but really mastering them takes training, practice, and insight. No single use case specifies the entire requirements of the system. Each use case merely explains one particular interaction. An organized suite of use cases and other specification techniques are needed to fully specify the software requirements. The figure below illustrates where a use case document fits into the overall software requirements specification (SRS) and how it relates to other documents. This white paper focuses on the yellow "Use Cases" box. Ideally, your use case document is just one part of an overall set of project documents. But, don't worry if you just want to jump straight into writing use cases: this white paper focuses on them. Project Proposal Business Need Market Opportunity Software Requirements Spec → Use Cases Use Case Suite Use Cases Feature Specifications Feature Set → Feature Specifications Non-Functional Requirements Environmental Requirements User Needs Classes of Users User Stories → → Quality Assurance QA Plan Design Structural Design Behavioral Design → User Interface Build System Architecture Persistence Security

Target & Benefits Target Market Segment Claimed Customer Benefits

Feature specifications describe the same system from a different perspective: a feature spec abstractly describes everything about one software feature and all it's possible uses. Likewise. when working through a use case. so you would note that in the feature spec. correct. Long before you reach these goals. use cases and feature specs provide checks and balances that help you write requirements that are more complete. Use cases concretely explain how a user accomplishes a goal using one or more features of the system. (You may notice that this is very similar to the test case writing steps. Beside those steps. Together. you might realize that a feature needs a particular input value to work properly. you will find that the process of writing use cases is itself a very useful way to clarify your own thinking about the system requirements: by writing step-by-step descriptions. The rest of this white paper works through the six steps shown in yellow in the diagram below. you might realize that a particular feature needs an additional option.Interview Notes Requests from Customers → Test Suite Test Cases Test Runs One goal of writing use cases is to specify the system to be built. and consistent.) . when making a pass over the feature specifications. we show the corresponding steps for writing feature specifications. you force yourself to think through the details of the system's features. It is a good idea to write the use cases and the feature specs in parallel. For example. Use cases and feature specifications complement each other. so you might need to add a step to all use cases for that feature. Another important goal is to allow potential customers to read the use cases and validate them. so that the resulting specification can be handed off to someone else for implementation.

However. This concept is key to getting the most value out of the limited time that you have to write specifications. After the SRS is written. we recommend that you only specify the most important use cases in detail. Step One: Identify Classes of Users . feature specifications can affect the design more directly. then fill in details incrementally as needed.Use Case Writing Steps 1: Identify Classes of Users Feature Spec Writing Steps 1: Identify Functional Areas ↓ ↓ 2: Outline the Use Case Suite 2: Outline the Feature Set ↓ ↓ 3: List Use Case Names 3: List Feature Names ↓ ↓ 4: Write Some Use Case Descriptions 4: Write Some Feature Descriptions ↓ ↓ 5: Write Steps for Selected Use Cases 5: Write Specs for Selected Features ↓ ↓ 6: Evaluate Use Cases 6: Evaluate Features Note that in steps 4 and 5. Both use cases and feature specs affect both the design and quality assurance of the system. In any complex system. each part is used in later work on the system. It is usually best to take a breadth-first approach: map out your use case suite first. and the use case suite can provide a stronger starting point for the system test suite. there will be a large number of potential use cases.

As you will see below. you would write another. whereas another class of user may need more guidance in making choices. which other types of users do they interact with to accomplish specific business goals? The ReadySET Pro templates are simply templates: they do not force you to follow a predefined process and they are not a magic bullet that does your work for you. Too often. Next. one class of user may simply need a speedy transaction. So. an entire class of users are initially overlooked. ReadySET Pro can improve the quality of your project documents by helping with both the breadth and details of your work. Others may be power users who will master every option and shortcut over time. It is important to identify and list classes of users so that none of them are forgotten. When you specify additional classes of users. and their key needs. This leads to a frustrating series of requirements changes when their requirements must be added later. and so on. How ReadySET Pro Helps ReadySET Pro helps you identify classes of users and take advantage of that information while planning your use case suite. Some users will expect to walk up to the system and accomplish one goal as quickly as possible. Not all users are alike. but it gives you a big head start on this step. In addition to saving time. their goals. which business objects are of primary concern to these users? And. For example. That process would be like coding your application without outlining the design first. The ReadySET Pro user needs template and use case suite template come prepopulated with reusable sample text describing classes of users that are found in many applications. At the detailed level. and still end up with a well written result. ReadySET Pro provides a broad and remarkably complete set of project document templates that ask the right questions. You would never really know how much further you need to go before you are done. Step Two: Outline the Use Case Suite It is tempting to skip this step and jump directly into writing a use case. make sure that you know the key needs of each class of user. For this first step. For example. The sample text will not fit your application exactly. For example. you can adapt it to fit your project.g. e.The first step in writing use cases is understanding the users. the reusable sample text is well written and to-the-point. if you were .. administrators. these time savings add up in each step. ReadySET Pro guides you in describing their key needs. the reusable sample text gives you a head start can be expected to save you up to an hour. So. After writing one use case. and a third class of user may expect to reuse their knowledge of competing products. you are less likely to overlook important areas of development. some banking ATM customers just want "fast cash".

For example. Try our ROI Calculator to see for yourself how incremental improvements in quality can save substantial time and money. The advantage of using an organized list or grid is that it gives you the big picture. These lists and grids help you. you can list all the classes of users. the templates guide your thinking toward a more complete specification that will lead to a better quality product in the end. Having an organized use case suite makes it easier to name use cases because the task is broken down into much smaller subtasks. in the e-commerce grid. A use case suite is an organized table of contents for your use cases: it simply lists the names of all use cases that you intend to write. product releases. One particularly good use case suite organization is to use a grid where the rows are classes of users and the columns are business objects. there will be a clearly visible blank space in the use case suite. but it is easy to overlook the use cases for administrators who must create coupons. for example. you can expect to save some time on the actual writing. Put your finger. there might be a business object "Coupon". For example. there will be a list item or grid cell that really should be empty. on each list item or grid cell in your use case suite. Step Three: List Use Case Names If you did step two. For example.spending too much time in one area. The second step in our breadth-first approach to writing use cases is to outline the use case suite. starting with the ReadySET Pro templates can definitely save some time. administrators might have some very different use cases. Each cell in the grid will list use case names that are done by that class of user on that type of object. in an e-commerce system. How ReadySET Pro Helps The ReadySET Pro use case suite template is pre-populated with reusable sample lists and grids that help you organize your use cases around classes of users. The suite can be organized several different ways. For example. this step will be much easier to do well. you will think of two to five use cases fairly easily. In contrast. It is obvious that shoppers use coupons. or if you had forgotten other important areas altogether. If it is overlooked. ask yourself about the relevant goals of users. Most of the time. Sometimes. make sure that you cover every class of user that your system must support. and helps you put your finger on any area that needs more work. the administrator . These clear indications of missing requirements allow you to improve the requirements sooner rather than get bogged down in too many frustrating requirements changes later. As stated above. priority. for example. business objects. But more importantly. shoppers would have use cases for adding and removing products from their shopping carts. or cursor. Then. each of which is more specific and concrete. and other meaningful criteria. and then list use cases under each. In this particular step. calculating the percentage of abandoned shopping carts. for each one.

In that situation. The sample text can also be helpful for application without login. Step Four: Write Some Use Case Descriptions In step three. If that happens. and it can reduce requirements changes later. just take a moment to note down the name of the feature. you might know that there should be some use cases listed. It already is enough for you to start doing some things that can help your overall project succeed. and level of detail. Before moving on to the next step.of an e-commerce site might not have any use cases for editing product descriptions. The name should be written in terms that a user might use themselves. And. write "TODO" as a reminder to come back to it later." It is never the user's goal to "Choose preferred language". You are already validating your definition of the classes of users. As you work through this step. That level completeness of the specification is very desirable because it gives more guidance in design and implementation planning. "Put product in shopping cart" is also fine. For example: "Select product for purchase". by itself. That gives you a big head start if you are building an application that requires login. phrase structure. The name of each use case should be an active verb phrase describing a goal. you may also think of a feature that should be specified in the feature set. Keep in mind that one of the goals of writing use cases is to allow potential customers and users to read and validate them. you can already get a better feeling for the scope of the release. Other times. if that is done by a "store manager" class of users instead. because the samples demonstrate the correct tone. So. that is simply a step imposed by the system on the user who is trying to get cash quickly. . but you cannot think of them at the moment. For example. you can already recognize some needed features that might have been overlooked if you had jumped down into detailed steps too soon. How ReadySET Pro Helps The use case suite template is pre-populated with the names of several common use cases. You can already roughly prioritize use cases. is major progress on the system specification. It is important to keep in mind that use cases focus on users' goals. This reusable sample text is centered around the process of user registration and login. you may have generated ten to fifty use case names on your first pass. Use case names should not be written in implementation terms: "Insert SKU into checkout phase one hash-table" is definitely wrong. At this point. In that situation. it is worth pointing out that the result of this step is itself very valuable. a banking ATM user's goal might be to "Get cash quickly. it can lead to more realistic schedules and release scoping decisions. That number will grow as you continue to formalize the software requirements specification. Having a fairly complete suite of use case names. write "N/A" for "Not Applicable".

You should not use programming constructs such as if-statements or loops. phrase structure. Step Five: Write Steps for Selected Use Cases Now it is time for the main event: actually writing the use case steps. if there are clearly too many use cases for one release. it is a good idea to split the use case into two distinct use cases. Focus on use cases that seem most likely to affect the success of the project. The description should provide a little more information on the user's goal and briefly outline the strategy that the user will follow. How ReadySET Pro Helps The use cases template is pre-populated with descriptions of several use cases focused on user registration and login. And. it's a good idea to just write descriptions rather than get into detailed steps for each use case. Each use case step has two parts: a user intention and system response: User Intention . For example. use an extension point to describe any type of failure or error condition. reschedule some of them for later releases. This is a task that you can expect to take ten to forty-five minutes for each use case. The solution is to be selective before moving to the next level of detail. you must be selective to get the most value in return for your limited available time. it needed at all. Again.The downside to mapping out the big picture is simply that it is too big. the resulting document could become too large. Write one to three sentence descriptions of each use case that you plan to implement in this release. select use cases that: • • • • • Enable users to achieve the key benefits claimed for your product Determine a user's first impression of the product Challenge the user's knowledge or abilities Affect workflows that involve multiple users Explain the usage of novel or difficult-to-use features Each use case should show a straightforward example of the user succeeding at a goal. That might average out to only about ten use cases in a typical work day. Going deep into the details of just a few use cases is enough to shake out uncertainties and identify areas for improvement. For example. that reusable text can give you a big head start. It could take a long time to fully specify every use case that you have mapped out. if at all possible. Sometimes there will be two or more ways to accomplish the same goal. and demonstrate the correct tone. The steps in a use case are almost always a linear sequence. The bulk of the use cases can be done later. If there are significant differences in strategy. making it harder to validate and maintain. Also. Rather than use conditional statements. As mentioned in the previous steps. and level of detail.

In general. The one-column format gives you more flexibility to skip system responses that are obvious. There are two main ways to evaluate use cases: • Potential customers and users can read the use cases and provide feedback. Step Six: Evaluate Use Cases An important goal of any requirements specification is to support validation of the requirements. it is not relevant to the use case. You can preview the Use Case Template or any other template through the Document Map. How ReadySET Pro Helps ReadySET Pro contains several high-quality. For example. or initiating commands. Possible values for these project management fields are also defined in the "use case format" document. • Software designers can review the use cases to find potential problems long before the system is implemented. and the proper handling of exceptions. "press Control-S" is not written in use cases. but unless that is something that the user can immediately see. The system response should not describe an internal action. If a use case step reminds you of a specific requirement in a system feature. For example. it may be true that the system will "Update database record". you should try not to mention specific UI details: they are too low-level and may change later. if I intend to save a file. Typical steps involve accessing information. However. make a note of it in the corresponding feature specification. As above. The two-column format forces every step to include an explicit user intention and system response. Capture your insights by writing notes and questions as you go. and direct actors. These use cases demonstrate the proper use of both formats. it is best not to mention specific details that may change later. A separate "use case format" document defines a notation for expressing user intentions using a small set of standard keywords. and to handle multiple actors interacting with the system in one use case. Use case steps can be written in either two-column or one-column format. For example. reusable sample use cases.The user intention is a phrase describing what the user intends to do in that step. . then I could probably press Control-S. providing input. Each use case template in ReadySET Pro also indicates its priority. preconditions. Usually the user intent clearly implies a UI action. System Response The system response is a phrase describing the user-visible part of the system's reaction to the user's action. the system's response to the user saving a file might be "Report filename that was saved". Recall that one of the advantages of writing use cases is that it forces you to clearly think through the details of the system. frequency.

A step may be difficult for a user if it requires knowledge that the user does not have in mind at that time. reusable sample text that makes it easier to write use cases at the right level of detail. Also. claimed product benefits. you ask yourself these questions for each step: • • • • the Will the user realize that he/she should have the intention listed in this step? Will the user notice the relevant UI affordance? Will the user associate the intention with the affordance? Does the system response clearly indicate that progress is being made toward use case goal? How ReadySET Pro Helps ReadySET Pro's use case templates contain high-quality. Pretending to use the mockup to work through the use case can point out some use case problems. user needs. if you had included unneeded UI details such as "Scroll and control-click the name of each desired country in the list". what are the zip codes of your last three residences? User often have difficulty remembering to perform "post-completion" steps that do not seem relevant to their immediate goal. e. And.g. users have a bad habit of providing feedback on anything that is part of the use case. even if that is not the type of feedback you need. concrete.. will the user even know which countries are desired at this point in the interaction? When reviewing use cases. The light-weight. In the cognitive walk-through method. Keeping the right level of detail makes it easier to evaluate and improve your use cases without getting bogged down in UI details too soon. For example. A rough mockup of the system can simply list the contents of each screen. and at the right level of detail.To make customer or user validation more effective. because users may not be familiar with them. without getting into details of screen layout or particular UI widget selections.g. the system design.. children often do not remember to put away toys because their goal was simply to play with them. it is important to keep the steps simple. As recommended above. the comprehensive set of templates provided by ReadySET Pro helps you evaluate the use cases for consistency with project goals. in part. but then find that there is no good way for the system to present that response on the current screen.. then you are likely to get feedback on the way that standard list widgets work rather than insights into the actual task at hand. you should start by checking for too many steps or especially difficult steps. e. . For example. and the QA plan. web-based nature of ReadySET Pro makes it easy to share individual documents with a potential customer or user so that they can provide feedback. Phrasing the user intention as "Select desired counties" forces everyone to focus on the relevant issues. You can perform a more careful evaluation of your use cases and UI mockups with cognitive walk-throughs. Another very simple way to evaluate use cases is to try performing them yourself. e. you may have specified a particular system response for a step.g. you should avoid using programming constructs.

• Write use cases at the right level of abstraction. Conclusion This white paper presented six simple steps to writing effective use cases. ReadySET Pro provides valuable help for writing effective use cases by giving you templates that include reusable content and set good examples for you to follow. far too many UI designers immediately jump into UI screen layout. widget selection. Without this step in design. ReadySET Pro's unique contentrich templates help you write better test suites that can improve your product quality. Write Your Software Testing Plan Today Introduction All software needs to be tested. and careful wording of particular labels. While those design decisions need to be made eventually. ReadySET Pro users typically save at least three hours by using the use case suite and use case templates alone. • Evaluate use cases to help validate the system requirements before moving on to design and implementation. it is usually better to start by validating the overall interaction flow for the highest priority use cases. focusing on user intent and avoiding unneeded UI details. This white paper shows how ReadySET Pro can be used to quickly create a comprehensive system test suite with test cases. which means that you are more likely to be able to complete your plan. Part of the problem is that QA efforts often begin too late in the release cycle when there is too much pressure to take shortcuts. and the savings from other templates. These templates make the writing process much faster than starting from scratch. even under time pressure. Both of these advantages give you a big head start on your own software requirements specification. . see the ROI Calculator.The ReadySET Pro UI design template encourages designers to start with abstract descriptions of each screen that can be used to evaluate use cases. To estimate how these savings. most testing efforts are under-planned: some software testing professionals work in the field for years without ever seeing a really comprehensive QA plan and test suite. The keys to using use cases to effectively specify software requirements are to: • Take a breadth-first approach that maps out a fairly complete set of possible user interactions and provides full details on those use cases that are likely to give the best return on your efforts. Unfortunately. add up to days or weeks of project time. software testing is a major part of the overall software development process that involves many people and countless hours of detailed work. In fact.

so they must always rely on human judgment to evaluate test outputs. A test suite must be carefully designed with the coverage criteria in mind. This white paper focuses on the yellow "Quality Assurance" box. The following diagram illustrates the . and inconsistency. your testing documents are just part of an overall set of project documents. Testing Coordination Testing involves many people working together over time. Creating automated test scripts without outlining the test suite is like writing code without a design document. For the team to be effective. But even if you do not have the others. Test Automation Too often. QA teams hope to use automated testing.The figure below illustrates where your QA plan and test suite fit with other project documents. you will be able to follow the discussion of test planning documents. Test planning helps in the following specific areas: Requirements Validation Designing a system test suite forces you to deeply understand the requirements. As you understand the requirements more. A QA plan is needed to set coverage criteria and evaluate coverage. their efforts must be coordinated with a written plan. Test Coverage Testing only half of a large system is sure to allow thousands of defects into the shipping product. Correcting these problems early can speed up development and reduce the number of late requirements changes. This happens because they never really formalize the requirements. Project Proposal Business Need Market Opportunity → Software Requirements Spec Use Cases Use Case Suite → Use Cases Feature Specifications Feature Set Feature Specifications → Non-Functional Requirements Environmental Requirements Design Structural Design Behavioral Design → User Interface Build System Architecture Persistence Security Target & Benefits Target Market Segment Claimed Customer Benefits User Needs Classes of Users User Stories Interview Notes Requests from Customers → Quality Assurance QA Plan → Test Suite Test Cases Test Runs Software development projects that don't have enough test planning tend to bog down with defects that can put the entire project's success at risk. Ideally. you will notice incompleteness. but end up stuck with ad-hoc manual testing. ambiguity.

) Use Case Writing Steps 1: Overall QA Planning ↓ 2: Outline the Test Suite ↓ 3: List Test Case Names ↓ 4: Write Some Test Case Descriptions ↓ 5: Write Selected Test Cases ↓ 6: Evaluate Test Cases .gap between ad-hoc testing and automated testing. Ad-Hoc Testing Just see if you can break it Make up test cases "on the fly" Human interpretation of requirements Systematic Testing Driven by explicit QA goals → Test suite designed → for coverage → Tests specify expected output Automated Testing Driven by explicit QA goals → Test suite designed for → coverage → Scripts need no human judgment The rest of this white paper works through the steps shown in the diagram below. (You may notice that this is very similar to the use case writing steps. and how systematic testing with a test suite bridges that gap.

it is time to outline the system test suite. For example. system testing. This concept is key to getting the most value out of the limited time that you have for test planning. and field failure reports. The ReadySET Pro QA plan template is pre-populated with detailed goals. We encourage you to take a breadth-first approach: map out your test case suite first. How ReadySET Pro Helps ReadySET Pro helps with every part of the overall QA plan. Specific QA activities include: coding preconditions. then fill in details incrementally as needed. In any complex system. using analysis tools. The rest of this paper will focus in on just the system testing activity. Use the ROI Calculator to see how the savings for the QA plan. we recommend that you only specify the most important test cases in detail. beta testing. More importantly. test cases. you can list all the system . reviewing design and code. there will be a large number of potential test cases. Step One: Overall QA Planning Software quality is not one-size-fits-all: different software products need different types of testing because they have different QA goals. unit testing. see the Step-By-Step Demo. ReadySET Pro users have reported that the QA plan template alone saved them an average of three hours. among others. and a built-in checklist. activities. selecting the sample answers that fit best rather than writing new text. For example. Step Two: Outline the Test Suite Once you have prioritized your QA goals. The suite can be organized in several ways. The main parts of the overall QA plan are: • • • • Select and prioritize quality goals for this release Select QA activities to achieve those goals Evaluate how well the activities support the goals Plan the actions needed to carry out the activities The overall QA plan addresses all quality activities. a real-time system may place much more priority of performance than would a typical desktop business application. a plan of action.Note that in steps 4 and 5. The task of QA planning is discussed in detail in the "Quality Throughout the LifeCycle" white paper. and other documents really add up to save days or weeks of your project schedule. and by testing to find and remove defects. integration testing. a good QA plan can save many more hours later by reducing the number of defects. To see how fast and easy chipping away can be. A test suite document is an organized table of contents for your test cases: it simply lists the names of all test cases that you intend to write." That means. Quality can be achieved by building in better quality from the start. Adapting the QA plan to your project is largely a matter of "chipping away. evaluation.

an e-commerce application might not have any delete . the templates guide your thinking toward a more complete test suite that will lead to a better quality product in the end. which helps keep the project out of crisis-management-mode. For example. but it is easy to forget to test the ability for administrators to create coupons. One of the best test suite organizations is to use a grid where the rows are types of business objects and the columns are types of operations. this step becomes much easier to do well. For example. and calculating values related to the product such as shipping cost or days-untilshipment. diagnosing. operations. Step Three: List Test Case Names After you have outlined your test suite. on each list item or grid cell in your test suite. The next row an e-commerce test suite grid might focus on the Customer Order business object and have test cases for almost all the same operations. there will be a clearly visible blank space in the test suite document. in the e-commerce grid. for each one. repairing. Each cell in the grid lists test cases that test one type of operation on one type of object." It is obvious that shoppers use coupons. you can expect to save some time on the actual writing.components. Or. or cursor. you will often be able to turn each use case into one or more test cases. there might be a business object "Coupon. ask yourself about the relevant system requirements. Having an organized system test suite makes it easier to list test cases because the task is broken down into many small. If it is overlooked. As stated above. How ReadySET Pro Helps The ReadySET Pro test suite template is pre-populated with reusable sample lists and grids that help you organize your test cases around business objects. you could list major product features. Then. But more importantly. Put your finger. listing or browsing products. Since so much tine and effort in software development goes into tracking. improving quality saves a significant amount of time. The advantage of using an organized list or grid is that it gives you the big picture. it is very easy to see whether you cover every type of business object that your system uses. For example. a Product business object would have test cases for each of the following operations: adding a product to the system. searching products. or requirement priority. For example. These lists and grids help you achieve your desired specification-based coverage criteria. starting with the ReadySET Pro templates can definitely save some time. and it helps you put your finger on any area that needs more work. and then list test cases for each of those. and find more defects. If you have a written use case document. These clear indications of missing test cases allow you to improve the test suite sooner. editing products. make more realistic estimates of testing time needed. There may be some list items or grid cells that really should be empty. These advantages allow the found defects to be fixed sooner and help keep management expectations in sync with reality. in an e-commerce system. and retesting defects. In this particular step. deleting products. specific subtasks. and then list test cases under each.

operation for the Customer Order business object. Going deep . but are not there yet. you might prioritize the test cases based on the priorities of the features or use cases that they test. The disadvantage to creating a big test suite is simply that it is too big. making it harder to maintain. And. At this point. That number will go up as you continue to make your testing more systematic. This reusable sample text is centered around the process of user registration and login. The test suite outline is a useful asset that can help your project succeed. That gives you a big head start if you are building an application that requires login. login-2. it is worth highlighting the value of having a fairly complete test suite outline. phrase structure. you can already get a better feeling for the scope of the testing effort. it's a good idea to first write descriptions rather than get into detailed steps for each test case. Append a unique number to each test for the given test situation. you may have generated between ten and fifty test case names on your first pass. A good strategy is to be selective before drilling down to the next level of detail. One test case can be used when the steps are the same and different input values are needed. Before moving on to the next step. Use distinct test cases when different steps will be needed to test each situation. you may think of features or use cases that should be in the software requirements specification (SRS). Also. And. You are already starting to look at your requirements critically and you may have identified missing or unclear requirements. the resulting document could become too large. and level of detail. As you gradually fill in the test suite outline. The advantage of having a large number of tests is that it usually increases the coverage. The name of each test case should be a short phrase describing a general test situation. sales-tax-in-state-1 and sales-tax-out-of-state-1 for two different situations where collected sales taxes are reported to the government according to two different procedures. For example: login-1. explicitly mark it as "TODO". If you cannot think of any test cases for a part of the suite that logically should have some test cases. The sample text can also be helpful for applications without login. For example. How ReadySET Pro Helps The test suite template is pre-populated with the names of sample test cases for an e-commerce application. You can already roughly prioritize test cases. Quickly note any missing requirements in the SRS document as you go along. because the samples demonstrate the correct tone. Explicitly mark with "N/A" any cells that logically should not have test cases. login-3 for three alternative ways to test logging in. It could take a long time to fully specify every test case that you have mapped out. And. Step Four: Write Some Test Case Descriptions In step three. you can already estimate the level of specification-based test coverage that you will achieve.

verify the correctness of the system outputs. you cannot test anything that requires a logged in user) • Features that are needed for product demos or screenshots • Requirements that need to be made more clear Each test case should be simple enough to clearly succeed or fail.g. select system test cases that cover: • High priority use cases or features • Software components that are currently available for testing (rather than specifying tests on components that cannot actually be tested yet) • Features that must work properly before other features can be exercised (e. and level of detail. So. The remaining cases should all be specified eventually. or merged with another test case. Ideally. Focus on the test cases that seem most in need of additional detail. Step Five: Write Selected Test Cases Now it is time for the main event: actually writing the test case steps and specifying test data. the steps of a test case are a simple sequence: set up the test situation. exercise the system with specific test inputs. Later. When describing a test case. For example.into the details of just a few test cases may be enough to shake out ambiguity or incompleteness in the requirements. For each test case. You may use programming constructs such as if-statements or loops.. How ReadySET Pro Helps The test cases template is pre-populated with descriptions of several test cases focused on user registration and login. you will be able to expect any team member to carry out the test the same way that you intended. and demonstrate the correct tone. if needed. phrase structure. write one to three sentences describing its purpose. The description should provide enough information so that you could come back to it after several weeks and recall the same ad-hoc testing steps that you have in mind now. when you actually write detailed steps in the test case. you may realize that it should actually be split into two test cases. As mentioned in the previous steps. however you might choose to rely on ad-hoc testing for lower priority features in early releases. . make sure to note any requirements problems or questions that you uncover. you must be selective to get the most value in return for your limited available time. with little or no gray area in between. And again. if login does not work. This is a task that you can expect to take ten to forty-five minutes for each test case. that reusable text can give you a big head start. That might work out to approximately ten test cases in a typical work day. The act of writing the descriptions forces you to think a bit more about each test case.

If you have written use cases. or multiple outputs must be verified. "enter username. When carrying out the tests. not all test cases are so simple. some system test cases may be longer scenarios that exercise several requirements and verify correctness at each step. make sure to add enough detail to make the test reliably repeatable. while specifying as few implementation details as possible. Each variable is defined with a set of its selected values." If multiple inputs are needed. Use cases focus mainly on the user's tasks and how the system supports those tasks.Systems that are highly testable tend to have a large number of simple test cases that follow the set-up-exercise-verify pattern. and then it is used in test case steps just as you would use a variable in a programming language. For those test cases. If you only have one test input value for a given test case. However. test cases should more technical documents with enough implementation detail to allow any member of the development team to carry out a test exactly the same way. the tester should repeat each test case with each possible combination of test variable values. We encourage you to define and use test input variables. a twocolumn format can prove useful. You may notice that the two formats for test cases mirror the two formats for use cases. A major advantage of use cases is that they are simple enough to be read by actual users who can help validate requirements. each test case step has two parts: a test input. each step is a brief verb phrase that describes the action that the tester should take. then you could write that test data value directly into the step where it is used. For example. For those test cases. or as many as practical. Instead. When leveraging use cases in this way. The difference is that use cases are a form of requirements. one-column test cases will simply have more steps. a one-column format can clearly express the needed steps." "see Welcome page." "enter password. In the one-column format. Carefully selecting test data is as important as defining the steps of the test case." and "verify that greeting has correct username" are all steps. Expected Output The Expected Output is a noun phrase describing all the output that the tester should observe at that step. Try these steps to select test data: . The concepts of boundary conditions and equivalence partitions are key to good test data selection. they can be copied and pasted as a good starting point for test cases. many test cases will have a set of test data values which must all be used to adequately cover all possible inputs. whereas test cases deal with more details of the implemented system. Sometimes it is impractical to test one requirement at a time. However. In contrast. Verification of expected outputs are written using the verbs "see" and "verify." "click 'Login'. In the two-column format. and an expected output: Test Input The Test Input is a verb phrase describing what the tester should do in that step.

make sure that you have inputs that will force the system to generate each possible type of response to valid input. The preconditions of a test case describe conditions that must be true before the test can be carried out.. reusable sample test cases. an age entered as 200 is much more likely to be a typo than a user who is actually two-hundred years old. For example. 1. and 44). e. make sure to force the system to generate each relevant error message. 0 and 18). Double check the requirements to make sure that you have not missed a partition division.g. One clear way to guard against undetected defects is to increase the coverage of your test suite.• Determine the set of all input values that can possibly be entered for a given input parameter. but still leave many other critical defects undetected... • Choose one input value somewhere in the middle of each equivalence partition (e. for both functional and robustness testing. the system might treat minors differently than adults. Test data vales that are expected to cause errors (e. and one on each side of each boundary (e. -5.g. all minors are treated one way. And. and 19). • Review the requirements and find boundaries in the valid range that should cause the system to behave in different ways. make a note of it in the appropriate part of the system requirements specification. negative ages are nonsense. -5) should be tested in separate robustness test cases. and all adults are treated another way.g. . Writing preconditions helps to avoid writing redundant steps for setting up the needed testing situation. Recall that one of the advantages of writing test cases is that it forces you to clearly think through the requirements. 12. the age of a person might be entered as any integer. For example.g. You might also check for clearly unreasonable inputs. If a test case step exposes an unclear requirement. A separate "test case format" document defines a notation for expressing test case steps using a small set of standard keywords. so the boundary would be age 18. in robustness test cases. You can preview the Test Case Template or any other template through the Document Map. How ReadySET Pro Helps ReadySET Pro contains several high-quality. These test cases demonstrate the proper use of both formats. For example. not all adults are old enough to drink alcohol in the U.. one directly on each boundary (e.. 17.S. • Define the boundary between valid and invalid input values. For example. • Now you have a set of equivalence partitions: sets of values that the system should treat uniformly. For example.g. Step Six: Evaluate Test Cases A suite of system test cases can find many defects. Capture your insights by writing notes and questions as you go. • In functional correctness test cases. Each test case template in ReadySET Pro also indicates its preconditions.

. See how these savings. • Evaluate the system test suite and test cases to improve coverage of the system requirements. Conclusion This white paper laid out the steps needed to quickly create a system test suite and test cases using the ReadySET Pro templates. and design documents. the system requirements specification. The light-weight.While a suite of unit tests might be evaluated in terms of its implementation coverage. If there is a requirement that is not tested by any system test case. How ReadySET Pro Helps ReadySET Pro's system test suite template and test case templates contain highquality. And. then there could be an undetected defect on that line. and then prioritizing your work on specifying the test cases themselves. You can evaluate the coverage of your system tests on two levels. • Take a breadth-first approach by first mapping out a test suite with good coverage. a suite of system test cases should instead be evaluated in terms of specification coverage. Second. within an individual test case. ReadySET Pro provides valuable help for planning your system testing by giving you templates that include reusable content and set good examples for you to follow. ReadySET Pro users typically save at least three hours by using the test case suite and test case templates alone. the comprehensive set of templates provided by ReadySET Pro helps you keep the system test documents in sync with the overall QA plan. and choose test input values that cover all equivalence partitions. web-based nature of ReadySET Pro makes it easy for the entire development team to use and update the latest revisions of the system test suite. Implementation coverage measures the percentage of lines of code that are executed by the unit test cases. reusable sample text that helps you plan and write test cases that cover all requirements. The templates encourage you to use a format that makes it easier to evaluate your software testing plans. The keys to effectively system testing are to: • Set explicit quality goals that are appropriate for the current release and understand where your test plan fits in your overall QA plan. First. and the savings from other templates. If there is a line of code that is never executed. then you are not assured that the requirement has been satisfied. add up to days or weeks of project time by trying the ROI Calculator. Specification coverage measures the percentage of written requirements that the system test suite covers. Both of these advantages give you a big head start on your own test plans. the test suite itself is an organized table of contents for the test cases that can make it easy to notice parts of the system that are not being tested. the set of possible input values should cover all input value equivalence partitions for each parameter. • Write system test cases in enough detail that any member of the development team could carry out the testing to see the same results.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.