In testing we have many different possibilities when testing a product – ranging from those that are more intensive, to those that are more lightweight tests or more localized.
In this article, we’ve put together a straight-forward overview of the different test approaches which we typically use within Moove It’s QA Studio.
Exploratory testing is the most lightweight we can do and usually is applied when we don’t have a complete overview of the product. Everyone can do exploratory testing, you’ll only need paper and pencil or a notes app on your phone or PC and a feature to test.
Here is an overview of how you can undertake exploratory testing:
- First, set a time frame in which we will be testing, let’s start with 10 minutes.
- Now, select a feature, for example, the login of the product.
- With the login page open, start clicking buttons, checking error messages, clicking links, do some successful logins and logouts, check the URLs, and basically play with every element you see on the screen.
- For each action you do, you’ll have to note what you do, for example, note: “Enter an invalid email. Click Login, the error message says “This email is not registered”.”, or “Clicked Login. The error message says “This is not a registered email”.”
- Continue to “explore” the feature, noting everything you do, and when the time you set (10 minutes in this example) ends, finish your session.
- Now it’s time to check your notes and see if any of the results you found may be a bug. After checking that, you can report your findings and add detailed “Steps to Reproduce” to your report.
Smoke testing refers to a medium-intensity testing technique focused on testing the core functionalities and flows of a product. It requires some previous work in creating a checklist with the most important flows and features.
We execute a smoke test when changes are made to the product in a specific environment to avoid retesting if a core feature is not working.
This approach can be used when the testing times are short and we need to check the stability of the core functionalities. We don’t recommend only running smoke testing because it just focuses on the most important aspects and not on the product as a whole.
Regression testing is one of the most important tests we do. It requires updated test cases (the smallest testing unit), and we apply it when a release to production is near to make sure the new features developed in the sprint didn’t cause any issues in the rest of the features.
For example, during the sprint, the features X and Y were developed and tested. When every change is pushed to the staging (or QA) environment, the QA team will select what test suites need to be executed. (test cases are arranged in test suites. For example, all the test cases regarding the login will be under the test suite “login”).
We select the core functionalities and the features that may be affected by the changes made for features X and Y. Now we execute all of those test cases to verify whether or not the product is stable enough and if no features were affected by the new changes. From the execution, we can report issues, if any, give the team a “passed vs failed test cases” report and see the importance of those issues, to assess whether we can deploy to production.
Full regression testing
Full regression testing is the most time-consuming and comprehensive testing approach we apply. This kind of testing refers to executing every single test case created for the product in a given environment.
We recommend executing at least 1 full regression every 2 or 3 sprints depending on the project. As this approach considers every test case, it takes more time than the rest of the approaches, but it’s the most beneficial for the product because we make sure that every part and flow of the application is working correctly.
As with the normal regression testing, we can provide the team with a “passed vs failed test cases” report and assess if we can deploy to production based on the severity of the issues found.
So, what type of testing should I use?
Well, this depends on the context of the particular project and the testing times we have. Here is a rough guide to when to use different types of testing in different circumstances.
- The tester doesn’t have a complete overview of the product. Here, use exploratory testing to better understand the product.
- A new hotfix is pushed to staging. Use the smoke test to make sure no core features were affected.
- The sprint is ending and no changes will be made. Use regression testing to make sure the new changes didn’t affect the previous developments.
- No full regression was executed in the last 3 sprints. Use full regression testing to verify the stability of the product.
- A large portion of the legacy code was refactored. Use a smoke test to ensure that the core features are working properly and then regression testing to check if the affected features are working correctly.