Results for category "Testing"

Setting up your Storyboards for best results when Generating Test Cases

When using PowerStory to generate test cases it is important how you use “keywords” within your steps to indicate if the step is a user action or an expected result.  

When you first try to generate test cases from your storyboard the default keywords are <user> and <system>.

If a storyboard step has the keyword <user> within it,  then it will be translated to a “user action” within the test case step generated.

if a storyboard step has the keyword <system>  within it, then that step will be translated to an “expected result” within the test cases step.

For example if you have a storyboard such as this…

  1. <user> types a url into the browser
  2. <system> loads the page associated with the url into the browser window
  3. <user> clicks on the login button
  4. <system> presents the login dialog
  5. <user> provides valid credentials and clicks on the login button
  6. <system> logs the user in and presents the home page

Then the resulting test cases would be as follows

User Action  -> Expected Result

1. types a url into the browser

-> Loads the page associated with the url into the browser

2. clicks on the login dialog

-> presents the login dialog

3. provides valid credentials an clicks on the login button

-> logs the user in and presents the home page

Closed

Reducing Rework – using powerSTORYBOARD

What are some sources of “REWORK”

  • Misunderstanding of Requirements => Translation Errors
  • Test Cases that are inconsistent with the Requirements
  • Changes to Requirements
    • Updating the user interaction flow and step details that are duplicated across your Use Cases and Storyboards and Test Cases
    • Updating your Wireframes, which are duplicated across multiple storyboards and test cases
    • etc

sources of rework

How do “Use Case Storyboards” eliminate this REWORK

“Use Case Storyboards” COMBINE your “use cases”, “wireframes” and “storyboards” into one integrated deliverable

A “Use Case Storyboard” as shown below, is simply a “Use Case” where each step in the use case is associated with a UI Wireframe/Mockup. This of course includes the main flow and alternate flow steps of the use case which is very different than traditional “Storyboards”, which are only a series of linear steps. This sounds simple, but the benefits are profound.

This approach allows you to walk through, or essentially simulate your “use case”.

Sample Use Case Storyboard where you associate Wireframes with each step  in a use case.

So what are the benefits of this approach and how does it reduce REWORK

  • Communicates Requirements more clearly resulting in less software development iterations
    • No longer does the reader have to review a use case and then manually correlate the steps in the use case to a storyboard or even worse just a collection of wireframes not put into a storyboard.
    • Instead the reader has the context of the details outlined in the use case step right beside and in context of the Wireframe associated with that step.
    • In addition it strongly encourages the collaborative and combined review of use cases and UI/UX design by your BA and UI/UX teams, which will result in more accurately defined and understood requirements.
  • The “user interaction flow” is shared between the use case and the storyboard eliminating duplication
    • As the flow changes you no longer have to update the flow definition in multiple places (ie. Use Case, Storyboard, Test Cases), reducing rework.
    • It also ensures your storyboards cover all of the alternate flows defined within the use case helping ensure requirements are not overlooked
    • Your storyboards will have less duplicate UI Wireframes, because common wireframes that used to be duplicated across multiple storyboards are now defined in the mainflow or parent flows of nested alternate flows.
  • You could even generate your test cases from your Use Case Storyboards
    • The interaction flow and wireframes defined in the Use Case Storybaord are identical to what you will want for functional test cases. So using some creative algorithms you can actually automatically generate your functional test cases and they will be 100% in sync with your requirements.
  • STORYBOARD allows you to create Use Case Storyboards in something you are already familiar with -> PowerPoint

    Create “Use Case Storyboards” in PowerPoint with powerSTORYBOARD

    Learn more about powerSTORYBOARD

    Closed

Are you tired of REWORK to requirement and test cases when requirements change?

Current approach – too many hand-offs and deliverables

Many organizations approach to defining software requirements involve too many hand-offs and deliverables. This can lead to requirements translations errors between the different hand-offs and deliverables. In addition, the collective details of the requirements are spread across so many different deliverables it makes it harder for the developers and testers to properly interpret and understand the requirements.

For example, many organizations will take this approach…

  • BA / Product Manager
    • The BA or Product owner elicits requirements from a customer…
    • …and writes them down perhaps as a high level feature list…
    • …then further elicits and documents requirements details using use cases and/or user stories and perhaps
  • UI / UX Team
    • These use cases or stories are then interpreted by the UI/UX team…
    • …to develop UI Mockups
    • …and perhaps UI Storyboards
    • …or even full blow interactive UI Prototypes to bring these use cases to life.
  • QA and Development
    • Then the development team and the testing team need to interpret these UI Storyboards, UI Mockups and Use Cases to develop the code and Test Cases.

The result of this approach includes a lot of re-work and project costs due combinations of the following. Perhaps some of this sounds familiar to you.

  • Use Cases, UI Mockups, UI Storyboards and test cases often get out of sync with each other, which makes it difficult for the developers and testers to know what real requirements are.
    • For example the use case steps may now communicate something different than steps outlined in the ui storyboard or test cases.
  • UI Storyboards and/or prototypes forget to implement all of the flows outlined in the use cases, leading to a scenario where features get missed.
  • Test cases are incorrect, causing false bugs to be found, wasting further time and budget.
  • Missed test cases, causing bugs not to be uncovered, leading to costly production issues.
  • Developers building features that are different than what the customer is looking for, leading to unsatisfied customers or additional rework.
  • Another related issue is that often during the UI Storyboarding phase new requirements come up that are added to the UI Storyboard but also should be in the original use case. A lot of good intentioned teams will not spend the time to update the use cases and feature lists, furthering the confusion for the developers and testers.

What can we do to reduce this confusion and rework

 

The good news is that there are some reasonably simple changes we can make in our processes and deliverables that will decrease the “broken telephone effect”. The theme shared by these ideas is to reduce the hand-offs and translations.

Get the Entire Team Involved in the Requirements Early

 

One technique is to involve the BA, UI/UX and QA resources directly in the elicitation process with the customer. Some may even argue to include the lead developer for that domain as well. By having all disciplines represented during the interviewing process, they will all hear requirements directly from the customer, helping reduce the reliance on just what the BA documents. Another equally important side benefit is that each discipline brings a different perspective which can lead the interview process down different paths of conversation and requirements gathering.

For example the QA resource may tend to ask more questions about the requirements that related to edge conditions, or error conditions, than perhaps the BA or UI/UX resource would. In addition putting the UI/UX resource in front of the customer, will give them a chance to better understand what kinds of features are more frequently used, which is important when trying to manage the cognitive load of the end user, by ensuring the more frequently used functionality is more easily found through good UI/UX design.

This may seem like a waste of time and budget, but at least considering the benefits of doing this on the more complex portions of your application could be a good start.

My personal approach is to include the developers and QA team during the requirements walkthroughs early and well before they are done, so that they have the opportunity to provide feedback and also gain a deeper semantic understanding of the requirements and what is driving them.

Combine and evolve your Use Cases, UI Mockups and UI Storyboards into the same physical deliverable

 

One approach to addressing this is to combine your Use Cases, UI mockups and UI storyboards into one integrated deliverable called a “Use Case Storyboard”. A “Use Case Storyboard” is simply a use case where each step in the use case is associated with a UI Mockup.

This approach has the benefit of automatically keeping what you traditionally would have documented as a separate use case, UI mockups and UI storyboards in sync. In addition to keeping everything in sync, it turns out to be far easier to communicate the requirements during walkthroughs of “use case storyboards”, because they combine the details of a use case text along with the informative UI Mockups into one deliverable that is easy to walk through from the end user point of view. This not only helps your end customer confirm the requirements are correct, but also importantly helps reduce confusion with the developers and testers

In addition it strongly encourages the collaborative and combined review of use cases and UI/UX design by your BA and UI/UX teams, which will result in more accurately defined and understood requirements.

Adopting this approach would involve starting as we normally do by having the BA define the use case without any mention of UI specific requirements, just to capture the objective of the user in the use case and any key steps and alternate flows (or exception flows, depending on which terminology you use). Then the UI/UX team would start to attach UI Mockups to each of the steps in the Use Case to start to bring to life the UI/UX design.

Since the “Use Case Storyboard” is expressed in terms of a main flow and alternate it has the additional benefit of reducing the number of traditional storyboards, which are linear and don’t include alternate flows. For example if we took the sample “use case storyboard” above and represented it as two separate linear storyboards, the first and last steps and their UI mockups would be duplicated, leading to requirements maintenance and rework costs.

So to summarize, the “use case storyboard” reduces rework by helping you communicate requirements more clearly. In addition this approach also reduces requirements translation errors typically caused by hand-offs between deliverables and teams.

 

Generate Your Test Cases Automatically from Use Case Storyboards.

 

Instead of having your QA team manually create test cases, why not Generating test cases directly from your “Use Case Storyboards”. This has the following major benefits.

  • Dramatically reduce the time it takes to create your functional test case set.
  • Your test cases are 100% consistent with your requirements
  • You have complete functional test case coverage
  • As requirements change, you can update your test case set quickly

For example if we were to take the “Use Case Storyboard” outlined above, it would generate the following two test cases, including the UI Mockups.

Test Cases are typically written in a format of a “user action” followed by an “expected” result. If you spend a little more time up front when creating “Use Case Storyboards”, defining which steps are “user actions” and which steps are “expected results” this can used in the test case generation engine to determine which steps should be assembled into test cases as “user actions” or “expected results”.

 

Summary

 

As an industry we are always evolving how we do things. In this article I present an approach that helps reduce project costs and increase the likelihood that you will develop what your customers need. I talked about how to get your collective team involved earlier in the requirements definition process which is not really a new idea, but certainly a valuable one. However I do present the concept of a “Use Case Storyboard” that combines Use Cases, UI Mockups and UI Storyboards, into one integrated deliverable that promotes collaboration and also makes it easier to communicate requirements to your customer, developers and testers. Lastly I talked about the idea of generating your functional test cases directly from these “Use Case Storyboards” which generates some significant project savings.

0

Avoiding conflicting requirements across your different requirements artifacts?

One issue I hear from developers, testers and stakeholders when reviewing requirements specs, is that sometimes the different requirements artifacts such as use cases, stories, wireframes and storyboards will often have “conflicting information” about the requirements, leading to confusion.

For example:
You might start with a user story, which is then expanded into a one or more use cases, which define the flow of steps between the system and the end user. Then there might be a number of wireframes defined and put together in the form of a storyboard to essentially bring the use case to life. I have often seen the situation where as the storyboard evolves and by its nature uncovers incremental requirements, the storyboard may have some steps in it that are not defined in the use case or worse in fact contradict what is in the use case. Then the test cases get created which again define a series of steps between the system and the end user.

The key thing being duplicated here across use cases, storyboards and test cases, is the series of steps between the system and the end user. This leads to confusion as to what the requirements are. 

Essentially what is happening here is that as we add more details about the requirements by adding new requirements artifacts, even with full traceability, we run the risk of duplicating requirements information which can get out of sync, or providing new conflicting requirements information.

Traceability to the rescue? Kind-of, but not fully!

One strategy to help reduce this issue, is to not to duplicate specific requirements details across the different requirements artifact types, and use traceability to link everything together. This traceability strategy is good to a point but does not fully address the issues I raised above. With this traceability strategy you still won’t avoid the duplication of the steps / flow describing how the user interacts with the system across your use cases, storyboards and test cases. 

We also need to combine artifact types! 

By combining the concepts of use cases, wireframes, storyboards and test cases into one integrated requirements artifact type that only defines the flow of steps between the user and the system once, you will avoid this duplication.

I refer to the combining of these different deliverable types as a “Use Case Storyboard“. The concept is to start with a use case and then as you create your wireframes, you associate them with each step in the use case, so that you can easily see the step information and the wireframe together. When you “walk through” the steps you are essentially seeing something similar to a storyboard, but this storyboard is not linear like traditional storyboards. In other words this storyboard supports main flows and alternate flows.

This notion of having storyboards that support main flow and alternate flows just like use cases do, further reduces duplication beyond just what was stated above. For example if you were to translate a use case with just one alternate flow into a storyboard you would need to create two storyboards, and these two storyboards would need to duplicate the steps in the main flow that are common. 

Now let’s talk about testing! 

You could perhaps just use the “use case storyboards” as your test scripts, or you could have some software automate the creation of your test cases by scanning the “use case storyboard” and creating a test case for each unique path through the combination of main flow and alternate flow steps. This does create a duplicate of the steps information, but it can always be re-generated when the “use case storyboard” needs to reflect a change in requirements.

0