Is it so that each step in a test case must be specific and contain only one expected result? The context is for combine UI and functionality testing.

For example, when clicked button X user should be redirected to login page and the button X must be verify the blue color of button login.

Is it possible to combine with functionality test case?

  • The question here is, after you are redirected to login page, how does the button x from previous page verify the color for login button? Commented Jan 4, 2022 at 6:20
  • The button x from previous page shown grey color as for default and its changed when there's click action on button Commented Jan 4, 2022 at 6:34
  • Okay. So if I'm understanding right, the button x is grey. You click > Go to Login page > button x turns blue. Next question; Does it change label to Login or Login is a separate button here? Commented Jan 4, 2022 at 6:37
  • Login is a separate button. Commented Jan 4, 2022 at 6:45

8 Answers 8


It's totally okay to write a combined expected result for all the steps of a test case.

It's also normal to write single expected result for each individual step.

Taking your example, your case can look like,

enter image description here


enter image description here

Either of them would be right as per my understanding.

The documentation rules/styles/formats can be customized based on the mutual understanding of the team. The actual point is a successful communication of work done and issues found (if any).

As long as your team understands what you're trying to convey, it's perfectly fine even if you write single line/paragraph test cases.


A test case is just a document regarding your testing. If it communicates the necessary information for the target audience, then it is fulfilling its goal.


It depends on who is the audience.

For which purpose you are writing the test cases and who is going to read and use your test cases.

If it's only for documentation purposes for manual testing - it's fine.

If it's primary purpose is to be used for test automation then it has to be very specific and step by step with expected results for each step separately.

If it's going to be used for both, then better to write with expected results for each step.

  • The OP's question is whether it is okay to have more than one expected results clubbed into one for a test step? Or each step should have only 1 expected result? Commented Jan 7, 2022 at 10:08
  • Yes I understand. My point is , the structure of the test case very well depends on the purpose and audience of the document. If it's going to be used for automation then it's preferred to have very clear expected result for each step separately. Commented Jan 9, 2022 at 18:59

This question is cool, thanks for posting it.

I've been working in BDD (behavior driven development) for a while now and this question goes to the heart of the breakdown of BDD as both requirements and test.

BDD Test in Gherkin might be something like:

When I open page http://whatever.com
Then the page contains button X
When I click on button X
Then button X is blue

As you see, there are several individual requirements and behaviors within that single sentence. There are many ways of expressing those requirements but the functional breakdown / specs of the user story flow there is key to understanding what to test.


The multiple expected result approach(w.r.t to a single test step) is usually preferred by software/security testing services at the initial level when we start building the product.

The steps-wise test case and multiple expected result format helps QA team to ensure the workflows/product is thoroughly tested and it further reduce the chances of missing any validation from QA's end.

However, preferring the multiple or single expected result layout is one's own choice and an engineer's comfort with the level of communication required in a project. Once the product gets stable over the years and workflows remain the same, we can refactor the test cases to be more generalized with a single expected.


It can, but better to do it separate test case because what if one of result is pass and other is not. For your above example, you can have separate test cases for functionality and the design.



Really good question to clear doubt of many who specially new to field.

Now, straight answer is yes you can for each step. But it is always advisable that you have single expected result so write your test step in such a manner that it is separate it out. The main reason for this is, if we have combine of multiple result set with single step then there is a possibility that few may pass and few may fail so we can justify whether entire step is pass or fail.

Lets consider your example only.

Test Step: Verify click on button X Expected Result: Should redirect to login page and should change button color to blue (there can be multiple functional test result as well, its not limit to UI) Actual Result: Redirected to Login page (PASS) but button color didn't change (FAIL)

So, now if we finally see the result of test step then its partially pass and partially Fail.

Rather, if you have done as below and it can be easily identified end result.

Test Step: Verify click on button X should redirect to login Expected Result: Should redirect to login page Actual Result: Redirected to Login page (PASS)

Test Step: Verify click on button X should change color to blue Expected Result: Should change button color to blue Actual Result: Button color didn't change (FAIL)

Hope, it will give you better idea of thought process and clear your doubt.



Yes, one step on test case can contain more than one expected result. I am currently using TestGear and it is very beneficial tool for testing. In TestGear , one step at a time in a test case may result in more than one expected result. It break specs of the user story to understand what to test. So TestGear is best option for you.

Your Answer

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

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