Test Planning

When starting an automated testing project (or evolving an existing project), I like to start by asking myself the following questions:

1. "What is the main functionality of the application, the one that if it doesn't work, it doesn't meet the users' needs?"
2. "Which test cases will be implemented?"
3. "Which tests are most important and should be prioritized?"
4. "Which tests can be left for later?"
5. "What types of tests will be written? End-to-end? A11y?"

By answering these questions, I gain valuable insights to start what I call the creative process in writing automated tests.

Then, I begin an exploratory process of the application (or functionality) that will be tested.

At this moment, besides discovering how the application currently behaves, I also discover edge cases, which can sometimes be forgotten during the development of the application.

So, without further ado, I open the code editor and start writing a "skeleton" 💀 of the test suite. Just the descriptions of the test cases, without implementation details.

Structuring test suites with Cypress

In Cypress, test cases are organized in a test suite.

The most common way to define a test suite is using two different functions.

They are the mocha's describe() and it() functions.

They receive a string as their first argument and a callback function as their second argument.

The describe's first argument is the test suite description (e.g., 'Authentication', 'Products Search', 'Users List', etc.)

The test cases are defined inside the callback function (its second argument).

The it() function defines a test case.

The it's first argument is the test case description (e.g., 'successfully logs in,' 'searches for a nonexistent product,' 'lists the first ten users,' etc.)

The test implementation details are inside the callback function (its second argument).

Below is an example of the skeleton of a test suite with a couple of test cases.

describe('Authentication', () => {
  it('successfully logs in', () => {
    // test implementation here.
  })

  it('successfully logs out', () => {
    // test implementation here.
  })
})

Exercise 🎯

Based on the process suggested above, create a "skeleton" of the tests you consider essential to ensure that the Cypress Simulator application works as expected, thus giving the team confidence that if all tests are green, it can be delivered to production for use.

Show the world what you learned 🌎

To show your professional network what you learned in this lesson, post the following on LinkedIn.

I am taking the Cypress Simulator course by @Walmyr Lima e Silva Filho at the @Talking About Testing school, where I learned a practical automated test planning process that helps me prioritize the most important tests and have something concrete to work on. #TalkingAboutTesting #TATSchool #CypressSimulator #Cypress

👨‍🏫 Remember to tag me in your post. Here is my LinkedIn profile.