Skip to main content

Automate Quality Tests

Learning Objectives

After completing this unit, you’ll be able to:

  • List the set of standards you use for the software quality assurance (SQA) process.
  • List the types of tests you should use during the software development process.
  • Describe important code quality metrics.
  • List important test automation tools.
  • Describe the standard unit test structure.

Assure Quality

You must build quality in at the start of a project for a robust storefront application in production, with fewer disruptions along the way. To ensure a project’s quality, implement software quality assurance (SQA). This is the process of determining the quality of a software project based on a defined set of standards. It’s important that you document standards at the beginning of the development stage and use them as guidelines before the site goes live. Here are some important standards.

  • Test guidelines: Information to advise the development team on what and how to test. They outline general principles or ideas that developers and testers can follow for the best course of action.
  • Style guides: A set of standards for the writing, formatting, and design of documents, code, and other digital assets. They provide a concrete and applicable set of rules. In some cases, they derive from guidelines, for example, design style guides.
  • Quality key performance indicators (KPIs): Code and testing quality metrics. They define the metrics that measure the level of achievement against existing style guides or other objectives.
  • KPI test and monitoring tools: Tools that measure the software quality KPIs and provide instructions if the KPIs are not met.

Assuring quality means paying close attention to test KPIs and test coverage during the project’s development phase. Let’s take a look.

Test KPIs

Test KPIs demonstrate the maturity and production readiness of software. They also demonstrate a QA team’s productivity in minimizing software bugs and contributing to high-quality software releases.

Test Coverage

Test coverage is a software testing metric that measures the amount of testing against a code base, typically as the percentage of the code base that’s covered by the tests. Test coverage software collects information about which parts of a program are executed when running the test suite to determine which branches of conditional statements have been taken.

Test coverage tools help determine test coverage relative to the software requirements. Maintaining high test coverage improves the compliance of software with specifications and the overall software quality. Use automated tests as much as possible. The more automation, the lower the risk of problems due to human error.

Which Tests?

Let’s take a look at the different types of tests that need to happen during software development.

Quality assurance testing includes unit, smoke, functional, integration, and regression tests.

Test

Description

Unit

Tests the individual components/units of an application. It’s typically written by developers or automation testers. Run during the development phase, it’s the first level of application testing.

Smoke

Determines if the deployed build is stable. It verifies the working process of essential features so that testers can proceed with further testing.

Functional

Analyzes if the application functions work as expected. This can include the user interface, APIs, database, security, client/server applications, and overall functionality of the application.

Integration

Integrates the application modules logically and then tests them as a group. It focuses on verifying data communication between the different application modules.

Regression

Verifies that a recent code change doesn’t affect the existing application features. It verifies that the old code works the same way as before the change.

Let’s take a look at the metrics.

Code Quality Metrics

Code quality metrics assess software health through automated code reviews. Developers use them to understand which types or methods they should rework or test more thoroughly. Development teams use them to identify potential risks, understand the current state of a project, and track progress. Low KPI values for code quality means that the code is too complex and likely to have problems when the merchant wants to extend functionality or run support activities.

Testing Quality Metrics

Testing quality metrics gauge the maturity of the code and a project’s production readiness. They also provide feedback on a QA team’s ability to minimize bugs. These metrics track the following.

  • Test coverage: The percentage of software requirements that are covered by unit tests.
  • User acceptance test (UAT): Defects found during UAT reflect on software quality preproduction launch. The number of bugs discovered in this metric should be lower than the equivalent in previous stages.
  • Production defects: Bugs that slip through into production can cause revenue loss. All blocker bugs should be addressed before the implementation goes live.

Bugs usually are categorized as blocker, critical, major, minor, or trivial. Each customer defines their own metrics for a production-ready solution. For example, in Japanese culture, merchants expect a 0-bug release, while in Europe or the United States, a certain number of major or critical bugs might be acceptable.

In the end, if the shopper can register an account, finish checkout, and pay for products; and the merchant can ship them the products, it’s a valid go-live case no matter how many bugs exist.

Test Automation

It’s important to automate the areas that are most critical to the business and where there’s repeatable manual effort. For example, regression and smoke tests are some of the best candidates for automation. This is where you create an account, add products to the cart, then navigate via checkout as a registered shopper and a guest. Scenarios like these are always tested by the QA team.

Test automation can happen at any phase of software development. It’s the application of tools and technology to reduce the testing effort, delivering capability faster and more affordably. You can run these types of automated tests on a frequent basis with little to no manual effort.

  • Unit tests: Tests small but vital functional blocks.
  • Integration tests: Combines functional blocks to bigger blocks (domains), and can use specific runtimes (use XLT or Selenium).
  • Regression tests: Tests at the application level before the result rolls out to a productive environment.

Don’t forget manual testing. Its purpose is to catch bugs and feature issues before the software goes live. While automated testing saves time by running a large number of surface-level tests in a short time, manual testing helps developers understand the entire problem and explore other angles of tests with flexibility. Great manual testing results in better automated test cases.

Which Test Tools to Use?

Automated test tools execute a test case suite with predefined actions on a software application. They compare actual outcomes and with expected results to generate detailed reports. Here are some benefits.

  • Higher software quality built in early
  • 24/7 testing
  • Easy regression testing
  • Test script reusability
  • The ability to analyze hundreds of test cases with ease
  • The ability to test on multiple platforms at once
  • Time saved from not having repeat monotonous test cases every day
  • Reduced business costs

B2C Commerce development projects typically use lint or the linter tool and SFRA test tools, such as Frameworks in SFRA, mocks, and dw-api-mock. Let’s take a look.

Linters

Lint is a static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs. It’s great at finding certain classes of bugs, such as:

  • Assignment to undeclared variables (they leak into the global scope, contaminating it and causing difficult-to-find bugs)
  • The use of undefined variables

Using lint tools can help accelerate development and reduce costs by finding errors early.

SFRA Test Tools

SFRA uses the model–view–controller (MVC) architecture, which divides an application into three parts.

  • Model: The business logic, data, and rules underlying the application.
  • View: What the shopper sees on the storefront.
  • Controller: Code that takes shopper input from entry fields, button clicks, and the like, and converts them into actions or data that’s consumed by the model or view.

Use these tools based on the architecture.

Element

Test Type

Tools to Use

Models

Unit

mocha, chai, sinon.js, and proxyquire

Views

Functional

mocha, chai, and webdriver.io

Controllers

Integration

mocha, chai, and request-promise

The ISML Linter npm tool can also help with a project.

Unit Test Structure

The standard unit test structure has three phases: arrange, act, and assert (called the AAA pattern). For a unit test to be successful, the resulting behavior in all three phases must meet expectations. Once you get used to the pattern, you can easily read and understand any test, which reduces maintenance costs for the entire test suite. Here’s the structure.

Section

Purpose

Arrange

Brings the system under test (SUT) and its dependencies to a desired state.

Act

Calls methods on the SUT, passes the prepared dependencies, and captures the output value (if any).

Assert

Verifies the outcome. The outcome can be represented by the return value, the final state of the SUT and its collaborators, or the methods the SUT called on those collaborators.

Next Steps

In this unit, you learned about quality assurance during the software development part of an implementation. Next, learn about the integration, delivery, and deployment phases.

Resources

Teilen Sie Ihr Trailhead-Feedback über die Salesforce-Hilfe.

Wir würden uns sehr freuen, von Ihren Erfahrungen mit Trailhead zu hören: Sie können jetzt jederzeit über die Salesforce-Hilfe auf das neue Feedback-Formular zugreifen.

Weitere Infos Weiter zu "Feedback teilen"