Business test types

These tests verify that the application will deliver to the users the value they are expecting. It is not just a matter of verifying the application meets its specifications, it is also about checking that specifications are correct. There is no application that is specified perfectly in advance.

Agile teams perform showcases to stakeholders the functionality during development and at the end of every iteration the functionality to be delivered, to ensure that any misunderstandings or specification problems are caught as early as possible. This causes to arise many improvements, stakeholders need to decide how much they want to take.

Acceptance / End to End

Recreates all the user flow. They are executed in a production-like environment. They can be developed with Cypress or Jest. We can get what they should do from the Definition of Done or Acceptance Criteria of our tasks. Another approximation is get the flow of a real user (through logs and events) and reproduce that behaviour in a controlled environment.

Acceptance tests are critical because they answer:

• "How do I know when I am done?" for developers
• "Did I get what I wanted?" for users

When both pass, requirement is completed.

Properties of automated acceptance tests:

• Provide faster feedback to developers in order to know if all requirements are met.
• When running in large teams with many modules, they detect if changes to one part of the application affect another module that has not been modified.
• Using human-readable tests it is possible to generate documentation from your tests. Given-when-then model can be transformed into documentation every time a requirement is deployed.
• the acceptance criteria they are based on meet INVEST
• tests must me run through a GUI in order to simulate accurately user behaviour.

It is important to remember that not everything needs to be automated. There are many aspects such usability or UI that people test better. A good rule is to automate once you have repeated the same test a couple of times and when you are confident that you won't end up spending a lot of time maintaining the test.

Most of the times acceptance tests involve putting the application in a particular state, performing actions, and verifying the results. These tests should use the API to put the test in the correct state to start it.

atomic

Being atomic imply that:

• the order in which they are executed does not matter.
• can be run in parallel for running faster.
• create all it needs to execute and then clean up everything except if it succeed or failed

performance

Acceptance tests affect the whole application, so they take a long time to be executed. In order to improve them we must take some actions:

• refactor common tasks: keep a list of the slowest tests and improve them
• share expensive resources: create a standard blank instance of the application at the start of the test and discard it at the end.
• parallel testing: with atomic tests, you can parallelize them in powerful servers or compute grids.

Happy path

In general, for each requirement there is a single path through the application that the user will perform. This is known as happy path. This is often expressed the with given-when-then model:

Feature: Global Use Case

    Scenario: concrete Acceptance criteria
    Given [state of system when testing beings]
    And [another state]
    When [the user performs an action]
    And [another action]
    Then [new state of the system]

Every requirement should have at least one automated happy path test. These tests should be used by developers as smoke tests to provide rapid feedback on whether they have broken some functionality.

Sometimes requirements constitute different use cases, which are known as alternative paths. There are many possible tests that can be performed, we have to pick the most relevant cases.

Regression

They serve to ensure that when you make a change you don't break an existing functionality and verifying that you haven't changed any behaviour. When writing acceptance tests (focused on testing user requirements) we should keep in mind that they will form part of the regression test suite.

Smoke

Check the minimum requisites for the application. Does it load? Is there a login button?

Exploratory

We define a user flow to test. We test and analyze it thoroughly. We generate a report of the process, which could result on creation of new documentation, bug finding or improve current tests and functionalities.

Appropriation

We execute a battery of tests and we validate manually that results are correct. Having that base, we will use that results as base to compare with future executions.

Usability

It is a method of testing the functionality of a website, app, or other digital product by observing real users as they attempt to complete tasks on it. We have SaaS like Hotjar that allow us recording user screen during their visit.