Before any app is released, it needs to be tested. How do you test an app? What needs to be done to ensure effective software testing?
When testing apps, there is not just one kind of test to perform. There are several, specific types of testing that should be conducted over a period of time. In this article, we outline the different types of testing. Here they are: unit, integration, functional, end-to-end, user acceptance, and performance testing. Most of these can be done manually and with automation.
To illustrate these different types of testing, let’s use the same test case: a time tracking app that integrates with a payroll system.
Unit Testing
As the name implies, unit testing checks a specific unit of code. This is a small chunk of code that performs a single function. For example, Let’s say you code the app on your phone to say “Record a time-stamp for the start time,” then to “record a time-stamp for the end time.” A unit test will say “Check to see if the start and end times are formatted in a numerical format: 202112231532. If it’s anything other than 12 digits, make the test fail.” Similarly, “Check to see if the end time is AFTER the start time. If it’s anything else, make the test fail.”
Here we are testing each individual part of the code, to make sure each part is able to perform its function, to help us to prepare to put it all together.
Integration Testing
The term “integration” is used a lot in software development to mean a few different things. Generally, integration refers to bringing together two different levels of architecture, e.g. front-end and back-end. To learn more about the application integration, read 5 Basics About Technology Every Software Entrepreneur Needs to Know.
With integration testing the code in your back-end is going to say to the database, “give me all the time entries for Lisa,” and after searching the database is going to return all the time entries for Lisa. The mobile app code says, “here is a new time entry for Lisa,” then the back-end says to the database, “here is a new time entry for Lisa,” where the database records the new time entry. So, we’re integrating the front end, back end, and database by passing data from one to the next, and to the next. The integration test says: “check to see if the new time entry from the front end was recorded in the database.” If it wasn’t, the test should fail.
Functional Testing
Here with functional testing, you have either Lisa, the real person, or Lisa, the testing bot, record a start time stamp and record an end time stamp. After Lisa hits the “submit” button, Lisa would then open her time entry log and see if the new time entry is listed there.
The emphasis of functional testing is on the experience of the user. From a business perspective, was the user able to record the two timestamps? It’s different from unit testing in that functional testing tests for business outcome from the user experience, whereas unit testing tests the code to make sure it works properly.
End-to-End Testing
End-to-end testing is about testing the entire flow of the app to make sure the process the app is designed to support can actually be run from start to finish. In an end-to-end test scenario, we have Lisa, who was just hired as a new employee under Sharon. Sharon enters Lisa’s new email address into the app to invite Lisa to create an account. After accepting the invitation, Lisa creates her account and logs in where she records her first time entry and submits it. Sharon then sees Lisa’s new time entry, approves it, and then Lisa is now able to see her approved time entry. When it comes time, Sharon sends all the new time entries to Payroll. Payroll pulls up the time entries and generates paychecks, and the payment is then recorded in Lisa’s check history. And finally, Lisa is now able to open her check history and see her payment.
User Acceptance Testing
User Acceptance Testing is when the customer or end user accepts the features built by the development team. In this scenario, Lisa (the real Lisa) is tasked with representing all the hiring managers to the development team. The development team sends each feature to Lisa, and soon after, she tests all the new employee and hiring manager features: inviting new employees to set up their accounts, recording time stamps, approving time stamps, and sending the time entries to Payroll. Most of the features end up looking great and Lisa approves those features, accepting them by saying they meet the business requirements. During the process, Lisa ends up finding one or two things that are not to her satisfaction. At that point, she would send them back to the development team and negotiate with them on any needed changes, and if the changes are agreed to, they are made, tested, and handed back to Lisa for retesting. When all the features pass UAT, the contract between the customer, Lisa, and the development team is closed as fulfilled. This happens in both client-vendor relationships and with teams internal to the same organization.
Performance Testing
Performance testing is about seeing how quickly an app can scale to serve a lot of people at the same time. Here’s an example performance test. The team sets up a bot that sends 5000 new time entries to the server at the same time. Then they measure to see how that load affects response time. It used to involve seeing when the server overloads. But some newer apps are built using what’s called “serverless architecture.” In that case, performance testing is more about seeing whether the app truly scales as needed without a decrease in performance. With performance test data, the team then works to optimize response time and scalability.
As you probably noticed, performance testing is focused mainly on the behind the scene functionality of the app. During app releases, the last thing you want is for your servers to go down because of too many users. The purpose of performance testing is to ensure fast response times and prevent downtime caused by high load.
Choosing How to Use Software Testing
Looking at the list of different types of testing, most of these types can be automated. The disadvantage, however, is that it costs money, up front, to write test cases. If you are a bootstrapping software entrepreneur (meaning you’re paying for your development out of pocket), it might push you beyond your budget.
But by NOT automating the test cases, it can prove problematic too. If you rely solely on manual functional testing and skip all the automated stuff, then every time you make a change to your code, you have to retest all – or at least part – of your app. That gets expensive and time consuming. Granted, automated testing isn’t guaranteed, and it will not solve all your problems. Sometimes you still need to go through your app by hand and make sure it’s working the way it’s supposed to.
All these different tests build on each other. Testing is a major key in developing your app. How well and thoroughly you test your app will show through your customer feedback and satisfaction. The money and time spent on testing will greatly improve the quality of your app and will be worth it in the long run. If you’d like to learn more, try reading this article, Understanding the App Development Timeline.
0 Comments