6

I am beginner in writing test cases. I am working on a live mobile testing project.

Consider a test case to login to a Mobile application:

Test case Description:

To verify that user is able to sign into the account successfully.

Test case steps:

  1. Launch the application.
  2. Enter valid email address and password into the 'email' and 'password' input fields respectively.
  3. Observe that user is able to sign into the account successfully.

Expected Result:

User must be able to sign into the account successfully.

What is the correct , generally accepted way to write test cases steps. Should we write the line 'Observe' in the 3rd step.

Please give some good examples of complete test case and the words used by professional testers?

2
  • 1
    What about pre-requisites? Or the test data required for being able to login (ie, valid credentials)? For 'proper' test cases, you'd need an expected result for each step... so even at Step 1, the expected result for Launching the application would be that the application launches - and what happens if it doesn't?
    – dvniel
    Aug 25, 2015 at 7:46
  • Rule of the thumb is that the next person must be able to reproduce the exact same steps and result. It will vary per environment if that will be 'just any person' or your equally trained colleague.
    – Bookeater
    Aug 25, 2015 at 8:13

4 Answers 4

6

I am working as QA and also to write a test cases of mobile application and web application. In Both Application required in writing the test cases are :

  • Test case id

  • Test case(unit to test)

  • Preconditions

  • Input test data

  • Priority

  • Steps to be executed

  • Expected result

  • Actual result

  • Pass/Fail

  • Comments

and for more information see below of reference link in which all Negative and positive test cases of login page is displayed.

http://www.9lessons.info/2011/02/how-to-write-test-cases-for-login.html

http://w3lessons.info/2014/08/23/a-lesson-on-testing-login-page-example/

4

Testcase format

I like one of the following formats:

These give a clear separation between test phases and steps.

  • How is the test situation setup
  • What is the action under test (try to keep action steps under 10, preferable less)
  • What is verified

Details

How to write the step details of test-cases greatly depends on who the target audience is. You could give more or less details, some examples:

  • Very detailed: Manual testers without application knowledge, steps need to be 100% exact.
  • A bit detailed: Client acceptance testing, guidelines to trigger client into testing their personal workflows.
  • Less detailed: Automated tests, high level steps might be sufficient in the test-case descriptions. Just enough to be able to understand what needs to be automated. Details are later defined in the tests it self.

Language

You ask about which words to use. This often depends of the domain of the applications. Different industries might use different terminology.

If you want to be sure others understand your test-cases try to use a bit of Hallway testing with them. Let someone else execute the testcase while you watch what they are doing without giving them any assistance. Improve the testcase and try again with someone else until the testcase is self explanatory.

Be sure to prevent ambiguous language, set a shared language between teams and tests.

2

There is simply too much variation between different teams of testers and business contexts to provide a one-size-fits-all answer here. There are good and valid reasons that different teams around the world use very different test documentation approaches when it comes to test case writing styles.

You and your colleagues should familiarize yourself with several different approaches that other teams use. Think about the pro's and con's of using formalized and detailed script structures as opposed to the pro's and con's of other "documentation-light" approaches. Once you're aware of the options available, you should consciously adopt approach that works best for your context.

These 3 sources are directly on point and provide more examples for your consideration than I can get into here:

  1. Dr. Cem Kaner's excellent piece "What's a Good Test Case?"

  2. A presentation I gave at an STP conference called "Documenting Software Testing Instructions - A Survey of Successful Approaches"

  3. This other similar question on StackExchange: "When writing manual test cases and scripts, how much detail is too much detail when documenting the steps?"

Image - "Topics" slide from these presentation slides: http://www.slideshare.net/JustinHunter/documenting-software-testing-instructions-a-survey-of-successful-approaches

1

Test Case Format for mobile application and web application.

  1. Test case Id (it's unique)
  2. Module Name
  3. Sub-Module Name
  4. Test Case Steps (Numbers or alphabetic like, 1,2,3 or a,b,c)
  5. Test Case Description
  6. Input Data
  7. Validation ( check (*) mandatory fields validation and mention it)
  8. Expected Results
  9. Actual Results
  10. Test Priority (High, Medium, Low)
  11. Test Case Status (Pass or Fail)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.