Just like Alice’s Wonderland, testing has many paths or, as we call it, “testing techniques” that you can use to get to your desired outcome i.e., ensuring that the quality of your system is top-notch. That sounds pretty simple, right? And it is, but there’s a bit more to it than just that.
When it comes to effective quality assurance in software testing and the different types of systems, you can use various types of testing techniques. This blog takes a look at the different types of techniques and why they are useful, nay, important for testing software thoroughly:
- Choosing the Right Test for Your Needs
- Exploring Happy-Case Testing
- Regression Testing: Ensure Your System Is Robust and Compatible
- So What Is Exploratory Testing?
- Our Own Tried-and-Tested Rain Dance Testing
- The Final One … Load Testing
- Final Thoughts
Choosing the Right Test for Your Needs
It’s important to know that it’s not always necessary to use ALL the types of testing when QA’ing a system or product. The outcome you want will determine the type of testing you need to use. For example, if you are busy testing a new feature that was just built and that needs to be integrated with your existing product, then you will use the following techniques:
- happy-case testing;
- negative-case testing; and
- some regression testing.
But if you want to see how much user traffic a system can handle before it crashes or falls over, then you will make use of load testing.
Before it seems like I’m just saying some random words, let’s go through each of these types of testing techniques as well as give a breakdown of a scenario of what to do.
Exploring Happy-Case Testing
First, let’s take a look at happy-case testing. Happy-case testing uses a known input and produces an expected output. For example, if I’m testing the sign-up process of a new website, I expect that when I enter all the required information on the sign-up page and click the sign-up button (a known input), then I will be successfully signed up (expected output). Basically, you’re testing to ensure the system is doing what it’s expected to do.
So, let’s use the example mentioned above and work through the QA testing process from beginning to end. To test a feature, you will first need to determine if there are any preconditions needed. A precondition refers to something that needs to be in place or established before the testing can commence. In this case, we will need a stable internet connection and the required URL for this sign-up web page. It makes sense because we can’t proceed with our test if we don’t have these 2 conditions.
Second, we need to write out our test steps that describe the typical steps a website user would take to make use of a certain function on your website e.g. sign up, download something or contact us. These are the steps that we’ll test. So, for example:
- Enter the sign-up URL into the browser and hit enter
- URL loads correctly, and user should see the sign-up page
- Enter a first name in the “First name” field
- Enter a last name in the “Last name” field
- Enter a valid email address in the “Email address” field
- Enter a valid password that meets all the requirements in the “Password” field
- Click the ‘Recaptcha’ checkbox
- Click the Sign-up button
- User sees a ‘Verify Email’ screen.
By following these steps and getting to that end result, you will know that your test has passed and it is working as expected based on the expected output condition that you mentioned in your testing scenario.
It can also happen that your test fails. Let’s say your test fails as you were never directed to the “Verify Email” screen (expected output), then you will either:
- directly communicate with the developer who built the feature about the issue you found’ or
- you will log a defect ticket; or
- you’ll do both.
Sidenote: A defect ticket refers to a ticket that houses all the information with regard to describing and reproducing a defect in a system. But we won’t be delving into that process in this article.
Once the defect has been fixed, you as the QA will repeat the steps mentioned above until you are happy to sign off that the feature works as expected. These are the basic steps of creating and executing a test scenario.
Together with happy-case testing, we get our second method of testing: negative-case testing.
With negative-case testing, we are searching for the vulnerabilities of the system. We want to see where the system is failing. Let’s use the same example as above. If I click the sign-up button without entering any of the required information and successfully sign up, that is a big problem. We have identified an issue in the system. In this case, we expect to see some sort of validation message or a blocker that won’t allow us to sign up until we have entered the correct and required information.
Next up, we have smoke testing and regression testing. With “smoke” testing, you want to ensure that all the core features of your custom software/system are still working as expected. It’s basically a high-level version of regression testing. You would usually do this type of testing after a new feature has been released to ensure that nothing went wrong during the release/deployment process.
On a broader scope level, regression testing refers to testing where the QA verifies that any change or update made to a system works as expected when integrated with the system as a whole. You want to ensure that the new feature hasn’t broken any of the existing functionality.
Regression Testing: Ensure Your System Is Robust and Compatible
Regression testing is also a great avenue to take when software or plugin upgrades have been done, to ensure that everything is still working as it should. This type of testing can take quite a bit of time, especially if you have a big platform/system. So this is where automation comes in handy.
You will save a lot of time when you can automate the testing scenarios as per the regression test cases. These tests will look and function the same as ‘normal’ tests, with each automation test having its own preconditions and steps to test a specific scenario. Then, while the computer runs your regression tests, you can tackle some exploratory testing.
So What Is Exploratory Testing?
It’s exactly what the name implies. You explore the system. This can be a great way of testing for individuals who are new to a system and who need to understand it. It can also be a very useful technique when searching for bugs and vulnerabilities in a system. You have no set of testing instructions or scenarios; you basically click and see if the system is doing what it needs to do; this is more of an informal testing technique.
Another useful tip when doing exploratory testing is to keep in mind how an end user would use the product and not necessarily how a product developer would use it. It often happens that customers don’t use a product as intended and find ways to deviate from the intended use — these are the vulnerabilities we want to find.
Our Own Tried-and-Tested Rain Dance Testing
Another testing technique that links well with exploratory testing is called ‘rain dance’ testing. This is not an industry-known technique, though. It’s one a previous colleague and myself coined. With rain dance testing, you are intentionally trying to break the system. For example, let’s say you’re working on a retail site, and you want to test that the online purchase process works as expected.
Your preconditions in this case will be having the correct system URL, a valid user account, as well as the item you want to add to your cart. Given all your preconditions have been met, let’s define your testing steps:
- Select item you want to ‘purchase’ and click “add to cart”
- Click the browser refresh button
- Add another item to your cart
- Remove the first item from your cart
- Click the browser refresh button again
- Click the “check out” button
- Click the back button in your browser
We expect to be directed back to our cart where the item we added is still showing. If this is not the case, then we have found a defect in the ‘check-out’ process.
We do this kind of testing because this also mimics what users in the real world would do. An end user is a very special kind of species in their own right, and they can be very unpredictable, so it’s important for us, as QAs, to ensure that we catch all the system glitches before they do.
The Final One … Load Testing
One more testing technique that companies use is load testing — a testing type that is part of performance testing. Load testing and stress testing a system is used to determine how many users a system can or cannot comfortably handle before it crashes.
Companies with high user traffic at specific points in time, such as gaming or betting companies, would use this type of testing. This type of testing definitely has its challenges. As you can imagine, trying to replicate 10 users at one time, not to mention 100 + users, can be difficult and time-consuming. Luckily, you get third-party software tools that can help with this type of testing, like Load Ninja.
Final Thoughts
When you embark on a journey of QA testing, you’ll quickly learn that there are a wide variety of QA testing techniques and types. The techniques you decide to use, often more than one, will rely on the outcome you want. If you want to test that a new feature is working as expected, then use happy-case testing. If you want to ensure that a newly released feature is working properly within the system as a whole, then a regression test is the way to go.
So, as you embark on your own testing odyssey, remember that the tools and techniques at your disposal are as varied as the landscapes of Wonderland. Choose wisely and adapt as needed.
