Shared steps

Shared steps

Today I want to tell you about two features, that should be done before test plans and test runs features. One of this features is shared steps for test cases.

Why are they important? Most of QA engineers use suites to group test cases in logical collections and often, all cases in such collections have very similar steps to reproduce. For example, user authorization with various social networks begins from visiting a sign-in page or purchasing some stuff in e-commerce projects starts with adding items into a shopping cart.

In, you are now able to add steps to reproduce in the test suite. All these steps are inherited by test cases and will appear on case preview page and will be included in a test run. If you successfully pass these steps during the test run for one test case, all further shared steps will be marked as passed.

Shared steps can be a mighty feature, that saves your time and decreasing time spent on a test run. What do you think? Share your thoughts in comments.

Another updates

“Shared steps” is not the only feature done during the last three weeks. There are plenty of small improvements and useful features.

Markdown editor

One of the most popular feature requests during the alpha test was a request to add some WYSIWYG-editor to test case creation page. Indeed, it is rather hard to describe the scenario, using only plain text.

Editor, for now, fully supports markdown syntax, except headings and added to the description, pre/post-conditions and steps to reproduce fields.

Test case type

A simple param, that was forgotten in the beginning. There are three values available to choose from (not two as usual):

  • Positive
  • Negative
  • Destructive

Positive test cases are used to check that the software is working the way, it supposed to. The positive test shows that the application or system under test meets the requirements and doesn’t throw any errors.

Negative test cases are used to check the system response to the scenarios the system doesn’t expect. For example when you are trying to add a restricted symbol to username field or use more characters than allowed.

Destructive test cases are used to test how long application can handle some negative actions before it breaks. For example, add too many elements on the page or perform stress load test.

Font size and colors

The second most popular request was to increase the font size and replace teal color for something more neutral. Default text font size is now 14px and button fill/stroke color is #55A4E7.

Create another test case

A small feature, that can save a few seconds and mouse clicks. If you check the checkbox and press save button, after successful test case creation, you’ll be redirected to test case creation page.

Flash notifications

A simple feature which helps you to understand what has happened after some action had been performed. Not rocket science, but makes an app more user-friendly.

Test case preview page redesign

To be honest, the current version of test case preview is ugly. It is hard to read information about case and page looks empty. I’ve decided to redesign it and here is a mockup of a new version. It is not ready in HTML yet, but in a few days, I want to implement it in production.

Please, tell in comments, how do you feel this design and ask questions about it.

What’s next?

At the beginning of the post, I’ve mentioned two big things, that should be done. The second thing is “Test Case VCS”. Subscribe to our telegram channel, twitter account, facebook page or this medium blog to get notified of next post.