As software quality assurance engineers, it is our responsibility to ensure that the applications, websites, mobile apps, etc., we work on are built to the best possible standard.
How do we accomplish this? What are those standards?
This article will explore the reasons we test, types of testing practices, and tools to ensure the testing is done successfully.
Get to Know the Different Types of Software QA
The most basic approach to testing is done through manual testing, but there are different techniques.
Exploratory testing is more of a free-form testing strategy. As a user, you are freely exploring the application, similar to how an end-user would. You are looking to identify anything out of the ordinary or any unexpected results you come across.
We are not looking at any requirements or specific functionality; we are looking to find issues more organically. The benefit to this approach is that you are not focused on a specific feature and are more likely to notice oddities within the application.
Functional testing is accomplished by testing different areas of the application against a subset of requirements on how the application should be developed. Functional testing usually describes what the system does.
Within the scope of functional testing, there is a term known as black-box testing.
This is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. For example, if we are testing the requirements around account creation, we are looking to ensure that users are able to create a username and password based on the following:
- The user’s account name must be 8 characters.
- The user’s password must be 8 characters containing: 1 uppercase, 1 lowercase, 1 number, and 1 special character.
During our testing, we find that the user can complete this process without having a special character in their password, failing the requirements above.
Since this is black-box testing, we assume that we have no knowledge of how that validation is being done within the application. We would then document our findings and return this item back to the development team for them to fix.
Opposite to black-box, we have white-box testing.
This is a method of software testing that tests the internal structures or workings of an application, as opposed to just its functionality. In white-box testing, an internal perspective of the system and programming skills are used to design test cases.
As a tester, we choose inputs to exercise paths through the code and determine the expected outputs. Taking the same example above, instead of just testing the UI during the account creation process, we are also going to test the associated API that handles the request from the UI to the back-end. Through this test, we are able to determine that the API is not handling the password validation and that the username is also not being stored in the database correctly.
There are benefits to both of these approaches:
- With black-box QA, we are focused more on the visual experiences that our end-user would experience and require less knowledge of the system itself.
- White-box testing allows us to test this process from the UI back to how the code handles the data it is requesting from the user. However, it does require more knowledge of the system. White-box can’t always be completed by a QA engineer, though, as they may not have access to the database where the data is being stored or knowledge of how to access and navigate that system. It is also important to note that functional testing tests a slice of the functionality of the whole system.
Let’s move onto Acceptance/Usability testing, a technique used to determine whether or not the application has met the requirement specifications (different from the slice we tested during functional).
The primary purposes of this test are to evaluate whether the application is compliant with the business requirements and verify that it has met the required criteria for delivery to end-users. Let’s expand on the previous example and assume that to meet the business requirements, we need to ensure the user can:
- Create a new account (including password reset and username lookup).
- Access the ‘My Account’ homepage.
- Update their personal information.
These are much broader requirements that would each have been tested separately at the functional level. For the acceptance testing, we are now going to test this full workflow from beginning to end, ensuring that it meets all of the business requirements.
From here, we move into Compatibility testing, and this is a pretty basic concept. We are looking to ensure compatibility across multiple devices, browsers, and operating systems depending on the application that is being developed.
This ensures that the user experience is the same regardless of the browser (Chrome, Edge, Safari) or operating system (Mac, Windows).
Accessibility testing is a newer topic for software QA, but it has already proven very important. This is the practice of making your applications usable by as many people as possible including those with disabilities such as vision or hearing impairment and other physical or cognitive conditions. For accessibility, there are strict guidelines:
Web Content Accessibility Guidelines
- Level A – This is the most basic level of accessibility.
- Level AA -This deals with the most common barriers for users with accessibility constraints.
- Level AAA – This is the highest and most complex level of web accessibility.
These guidelines can be found in extensive detail here: Web Content Accessibility Guidelines (WCAG) 2.1 (w3.org). They are designed to ensure that your application is developed in a way that all people can access and use your website and enjoy the same experience.
Using Automation to Improve Software QA Speed & Scale
Testing is a crucial aspect of the development process and can take a lot of time and resources, depending on the size of the application. Automating some testing functions and processes can improve the speed at which an application is tested.
As we build out our application, it is important to test the newest features being developed. However, what if a new feature breaks existing functionality? It can be difficult to test each new feature along with the existing ones. Creating automated tests to cover your existing functionality enables you to focus more time on testing the new features.
Regression testing is commonly done throughout the development cycle. This is the process of re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change.
Creating an automated regression suite allows you to run a subset of tests through a tool that will mimic the same steps you would do manually but in a fraction of the time. This can be done for both the UI and your back-end API calls.
If we recall the example from above, creating a new account is something that will likely take place often within your application. We can write automated tests to cover this workflow by creating generic usernames/passwords, test the login process, etc.
The work of a software QA engineer is a critical step in the development lifecycle. Through these practices, we can ensure the application provides the best possible experience for the end-user.
Without it, software development can be unreliable, with products potentially requiring complete do-overs if flaws proved too widespread or intrinsic.
Even so, it’s important to find opportunities to automate repetitive tasks where possible, saving your time and resources for more creative pursuits.
Happy testing!
Want to learn more?