Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Using Feature-Driven Testing for More Strategic Test Coverage

DZone's Guide to

Using Feature-Driven Testing for More Strategic Test Coverage

Get better test coverage without bloating your base of QA tests by implementing feature-driven testing, as explained in this article.

· DevOps Zone ·
Free Resource

Read why times series is the fastest growing database category.

Anyone who has built out a suite of QA tests knows that your database of test cases can get bloated fast. In the 2017-18 World Quality Report, 55% of teams stated that they have challenges managing the size of their test data sets.

For teams trying to move fast and use their development resources efficiently, this challenge is a major cause for concern. The larger your test suite, the more maintenance it requires and the more time QA will take away from your team. What's more, testing "all the things" often creates more noise in your quality metrics and can create confusion around whether or not a feature is ready to ship.

By shifting testing focus from total coverage to strategic feature coverage, teams can drive more effective, impactful QA processes.

Implementing Feature-Driven Testing With the 5/10/15 Rule

To alleviate the confusion and frustration of writing the wrong tests, we recommend that our users take a feature-driven approach to testing. Feature-driven testing is a pragmatic, feature-based approach for front-end testing. It can also be applied to other types of testing, such as unit testing.

The goal of feature-driven testing is to create a structured test suite that focuses test coverage where it is most critical. To build these strategic test suites, we use the 5/10/15 Rule to write the first 30 tests for any given feature or application.

Smoke Tests

Every test suite should include five smoke tests that test the most-done user activities. These tests should be focused around core feature flows that are essential to your application staying up and running.

Happy Path Tests

Beyond the core feature flows covered by your smoke tests, you should also write ten tests that cover the most common user paths. Again, these are central to most users' experience of your product.

Regression Tests

Bugs happen, and your regression coverage should ensure that they don't happen where they will matter the most. For regression coverage, select the fifteen tactical breaking points in the feature to make sure that they always work.

Once you've defined those test cases, you will have a strong foundation for QA that you can have confidence in. By building out coverage in sets of thirty strategic tests at a time, you'll be able to ensure that test coverage stays focused and concise.

Note that you should stay away from testing edge cases, as they tend to provide the least value for the effort they require.

Learn More about Optimizing Test Coverage

Finding the right amount of coverage that gives you the confidence to ship without slowing your team down with excessive test execution and management. To learn more about the 5/10/15 Rule and how to create a customized testing strategy, check out our webinar on How Much Do I Need to Test? Creating a Custom QA Strategy and this blogpost on how we designed our own testing strategy, Optimizing Rainforest for Rainforest.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
qa testing ,devops ,qa ,software testing ,test coverage

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}