After finishing coding a new module for a web app, the team leader told me to inform the QA team to log in the dev version of the app and test all the possible scenarios.

The obvious answer here, would have been to just pass the "user stories" which we used to write the code and should have been like this if there were any specific scenarios provided. Unfortunately, this is one of the cases that the developers team got poorly described specifications from the client.

Of course, we built the module based on some analysis of the client needs, but how the scenarios should be documented in order to make sure that the testers will try every one of them?

So the questions are:

  • Is there any kind of standard way of passing that kind of information to other teams?
  • Are UML diagrams a good choice for this tasks (or any other software)?
  • Should I just go on and write a tl;dr email listing all the scenarios?
  • Ask the QA team? – Niels van Reijmersdal Apr 25 '19 at 17:48
  • He is just one person :D and although he is an experienced tester, I just want to make sure to list all the scenarios without forgetting anything and also that I will do it in the most official way for the case there is an ISO audit. – user39266 Apr 25 '19 at 18:03
  • 1
    If he is an experienced tester in an environment that gets ISO audits. I would expect him to be able to tell you what he formally needs to be able to test all scenarios. :) – Niels van Reijmersdal Apr 25 '19 at 18:13
  • I will consult him, however Ι also wanted to see how other developers and testers handle this. – user39266 Apr 25 '19 at 18:39
  • +1 Understandable. My way of handling this was more a comment than a real answer. I think it is very context depended. But let's see how other people would handle this. – Niels van Reijmersdal Apr 25 '19 at 18:57

I don't think there is a standard way to do this. I don't know about a best way, but some ways i can think of the top of my head:

  • excel sheets/text files/tldr email with detailed instructions what and how to test, basically writing test cases for everything to manually reproduce.
  • userstories: just add in your stories what was actually implemented and pass that to the QA. if not in the user stories.. you would have to have some kind of documentation what you actually did written down somewhere, don't you?
  • uml diagrams: there is nothing wrong with this if they are concise and QA can figure out what to do.
  • other software: for overall management of testcases and such there are tools like HP ALM and many similar ones

Just pick whats most practical in your case. And as mentioned in the comments, ask what QA preferes. They may be used to text files or some expensive test management software.


I would consider documenting these in a TDD/BDD language/tool

For example in Cucumber (which now works in something like 50+, languages)

$ sudo apt-get install cucumber #(ubuntu)
$ mkdir some_test
$ cd some_test
$ cucumber init

Now create the file features/some_thing.feature

Feature: weekend check
  Everybody wants to know when it's the weekend

        Scenario: Sunday isn't Friday
          Given Sunday
          When I ask
          Then I am told "Nope"

Then you can run cucumber:

$ cucumber features/is_it_friday_yet.feature 
Feature: Is it Friday yet?
  Everybody wants to know when it's Friday

  Scenario: Sunday isn't Friday        # features/is_it_friday_yet.feature:4
    Given Sunday                       # features/is_it_friday_yet.feature:5
    When I ask whether it's Friday yet # features/is_it_friday_yet.feature:6
    Then I am told "Nope"              # features/is_it_friday_yet.feature:7

1 scenario (1 undefined)
3 steps (3 undefined)

You can implement step definitions for undefined steps with these snippets:

Given(/^Sunday$/) do
  pending # Write code here that turns the phrase above into concrete actions

When(/^I ask whether it's Friday yet$/) do
  pending # Write code here that turns the phrase above into concrete actions

Then(/^I am told "nope"$/) do |arg1|
  pending # Write code here that turns the phrase above into concrete actions

So you follow the instructions and create the above in a file in features/step_definitions/some_thing_steps.rb

Then you work on the code to get the specs passing

Another example, with ruby and rspec:

rspec has a really neat and short way of setting up the things to test:

Here are 4 tests that need to be implemented

require 'rspec'
describe "this is the basic tests" do
  it "logging in"
  it "going to member page"
  it "updating my profile"
  it "changing my email"

When you run this you'll get pending specs to implement

$ rspec pending_spec_exanple_spec.rb 

Pending: (Failures listed here are expected and do not affect your suite's status)

  1) This is the basic tests logging in
     # Not yet implemented
     # ./pending_spec_exanple_spec.rb:4

  2) This is the basic tests going to member page
     # Not yet implemented
     # ./pending_spec_exanple_spec.rb:5

  3) This is the basic tests updating my profile
     # Not yet implemented
     # ./pending_spec_exanple_spec.rb:6

  4) This is the basic tests changing my email
     # Not yet implemented
     # ./pending_spec_exanple_spec.rb:7

instead of the dreaded excel, email, text doc, etc. use real tests!

Note: rspec is free open source software

  • 1
    That is very interesting. Can it be used in a project written in a language other than Ruby? – user39266 Apr 28 '19 at 19:44
  • 1
    Added cucumber example which works in 50+, languages – Michael Durrant Apr 28 '19 at 20:56

This scenarios is encountered frequently in a software testing company where the requirements from the clients are not concise and complete.

One should follow the below process to overcome such issues

  • Dev team should contact Project Management team to get the exact requirements
  • Dev team should then create user stories containing the use case incorporated in the build
  • The referred user stories should be shared with QA team for them to create test cases for the given sprint
  • In case of any queries/issues related to the product requirement/functionality should be discussed with Project Management team

This way there can be a proper homework done for the referred product before it is built and tested.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy