Test case writing: Is it good to be thorough with steps, even though it's repetitive?

Question

For example, I have a website with users and articles. There are two types of users: Bronze and Silver. Further, there are two optional types of users: Employees and Executives. Each article has a visibility setting which is a combination of any of the above types.

Currently, my SAT test case looks something like this. (The SAT will be conducted at the client's environment).

Test Case #1: User views Bronze article
     1. Click "Log In/Register"
        a. Expected result: Terms and Conditions appear
     2. Scroll down to the terms and conditions
        a. Expected result: "Accept" button is enabled
     3. Click "Accept"
        a. Expected result: Login form appears
     4. Enter username "bronze.user@mail.com"
        a. Expected result: Populates the username field "bronze.user@mail.com"
     5. Enter password "Password123#"
        a. Expected result: Populates the password field with "Password123#"
     6. Click "Log In"
        a. Expected result: Takes user to the homepage with links to articles and profile management
     7. Click "List of Articles"
        a. Expected result: Shows user a list of available articles
     8. Search "arbitrary bronze article"
        a. Expected result: One article appears
     9. Click the article and confirm it is viewable
        a. Expected result: Shows the contents of the article
    10. Click "Log Out"
        a. Expected result: Ends the user's session
    11. Click "Log In/Register"
        a. Expected result: Terms and Conditions appear
    12. Scroll down to the terms and conditions
        a. Expected result: "Accept" button is enabled
    13. ...everything repeats itself for "silver.user@mail.com", "bronze.employee@mail.com", "bronze.executive@mail.com"

The result is hundreds of lines of steps which I feel is very unnecessary. Logging into the system is a no-brainer. I could shorten the test case by writing:

     1. Log into "bronze.user@mail.com"
     2. Search "arbitrary bronze article"
        a. Expected result: One clickable article
     3. Log into "silver.user@mail.com"
     4. Search "arbitrary bronze article"
        a. Expected result: "No articles found"
     5. ...repeat for each user type

However, I read that being thorough is a quality QAs should uphold. Should QAs be thorough when the test case is highly repetitive? Is it acceptable to shorten repetitive steps into generic ones? How about repetitive Expected Results - can those be shortened, or even ommited too?

Answer 1

This is very culture, personnel, and test dependent.

Culture: there may be a company or a national culture that points in one way or the other. At a company level, there may be a directive to be voluminous in documentation, under the assumption that someone else may need to execute the tests some day, or for some sort of quality reason, or standard reason, or whatever. At a national level, being very general, some cultures prize precision and following directions, others prize brevity and exploration. Their test cases tend to reflect this.

At a person level, it may depend on a lot of things. Who is writing the tests? Who is expected to execute them? How long are the tests going to be valid for? Personally, when I'm writing test cases I'm going to be executing once, in the near future, I'll shorten steps, usually by referring back to a prior testcase. However, when I'm writing test cases someone else is going to be executing, or that I know I'll be executing for years, I'll be more precise. Sometimes you'll have a single person writing testcases, and a host of possibly unskilled people executing them. In that case, you have to be very, very precise with everything.

And on a per-test level, it depends on what my goal is. Sometimes I'm doing system level validation, so I document what my general steps will be, what my target is, and what the success criteria are. But the individual pieces may not matter, or I may want to encourage variety. There are a variety of ways to generate CPU or I/O activity, for example; I may or may not specify how to do so, based on whether the type/pattern of activity matters. However, when I'm doing performance testing, where details really, really matter, and missing a step can mean a completely blown run, I document everything, and have a checklist so I can validate, as I go along, that I've done everything correctly.

What I've usually done when I had repetitive steps or whatever is use one of a variety of tools (TextExpander, often) to allow me to fill out templates and have the repetitive parts of the testcase automatically generated, and then only write the unique parts manually.

To answer your specific question, I'd ask the client what they wanted. Since, at least based on your example, they're testing a Web site, I'd probably also talk to them about how they were doing the testing. I'd hope they were using some sort of automation tool, and not doing everything manually. If they are automating, such as via selenium, I'd probably try to call out places that are the same/similar enough that they could be done via a macro call or something similar. And if they aren't automating, I might try to convince them to do so, so their testers can focus on things that humans are required for.

Answer 2

Test script is like code. If you want to reuse it later for manual regression testing, it needs to be maintained when tested application changes. All repetitive parts needs to be changed in the same way.

It might be only a small problem if your manual testers are smart/experienced enough to detect that situation and fix it/work around it.

If not, you are much better off to have a list of standard procedures, and reference them in manual test scripts (exactly like program's subroutine). Simplest way to implement it is something with hyperlinks, like a wiki.