Introduction
Testing is a nonnegotiable part of the software development cycle. But what does it entail, exactly? In this blog post, we’ll take a look at Syberry’s testing processes, discuss some of the most common types of testing our team implements, and show how our testing protocols contribute to our projects’ success—and our clients’.
Syberry’s Testing Process: Where Do We Start?
Before testing begins, it important to establish why we’re testing, reviewing the key goals and aspects of our testing plan with other team members, including the business analyst, project manager, and development team. Here are some of the main talking points for that discussion:
- Goal(s) of testing, from the respective parties’ perspectives
- Types of testing required
- Distinguishing characteristics of the product and its target audience
- Types of devices that testing needs to be carried out on
- Browsers and operating systems that should be tested, and at which screen resolutions
- Requirements for various types of forms and style guides, as well as software requirements specification
- Any required documentation on the results of testing, such as reports, checklists, test cases, etc.
Gathering as much information as possible in advance means the team is well prepared for the job ahead and can plan their work thoroughly.
Types of Software Tests
The kind of tests we conduct depend in part on the needs of the project; but let’s take a look at some of the most commonly used types of testing, which are relevant on most projects.
Backend Testing
What would happen if a large number of requests hit the server all at once? That depends on how stable the product is, and this is precisely what is tested during backend testing, otherwise known as “load testing.” Using specialized tools, QA engineers simulate a scenario in which the number of users rises dramatically, which leads to a sharp increase in requests sent to the server. Testers then monitor at what point the server crashes, meaning it stops responding to requests. If the critical threshold is too low, developers suggest ways to optimize the server.
The process of load testing is led by the QA team, but it involves other parties, as well. The development team determines exactly what to test, as they are able to establish what kinds of requests are sent to the server most frequently, which requests transmit the most data, and which generate the highest loads. The ordering client or product owner determines exactly how to handle test, as these stakeholders know the business aspect best, including the target audience and user metrics, the most frequent behavior scenarios, time periods of increased and decreased activity, types of activities, and periods and nature of peak traffic. Without this input, load testing might not produce the real picture.
The results of load testing depict the size of the load the system can withstand. It is also possible to emulate a scenario where the system crashes and then study its behavior afterwards. Can it recover on its own, or is manual intervention needed? This work will help prepare for similar situations in production.
For example, consider a large commercial product that works with different types of contracts. One day the company released a highly anticipated new type of contract, but the following day the system ceased working completely, and their contact center was overwhelmed with inquiries. The reason was a miscalculation during testing: the team was testing simultaneous work with a certain number of contracts, but in reality, the load was 100 times that number. This case goes to show just how important testing—and all the planning that goes into it—is.
Functional Testing
As you may guess from the name, functional testing is designed to check the functionality of the product as defined by the software requirements specifications. The task of the developer is to bring the outlined functionality to life, and the task of the QA engineer is to prepare test documentation (e.g., test cases and checklists) to be sure the developer has succeeded.
When a product component is ready for functional testing, QA engineers inspect it for operability and adherence to specifications. If the component passes inspection, the task is marked “done” and closed. If it does not pass, any bugs are entered into bug tracking system, the component task is sent back to the developers, and the information on the problems found is entered into the system. The task is not accepted as complete until the bugs are fixed.
Usability Testing
Before a product is released, it’s important to conduct usability testing to reveal any weak points in the interface or overall usability of the product. To do this, designers hand over the interactive prototype to a group of users and collect feedback. Most importantly, designers want to know how easy the users find it to reach their goal within the product. QA engineers compose a questionnaire for the users that helps understand their experience, and the responses are used to guide any changes that may be required.
Regression Testing
Regression testing is one of the most important and labor-intensive parts of QA engineers’ work. This type of testing is similar to functional testing, though in addition to checking new functionality, it also ensures that any new functionalities do not interfere with previously tested and completed components.
Regression testing also includes testing different versions of a product that is already being used by real users. Before launching any new version upgrades, it is essential to make sure that they work without breaking the current version.
The further along the development is, the more functionality needs to be tested, and the more time-consuming regression testing becomes.
Integration Testing
Integration testing occurs when the development team finishes and connects two big parts of the system, such as the admin panel and the web service. After such a substantial integration, it is imperative to be sure the two parts work together like they should.
The Importance of Testing Cannot Be Overstated
Finally, it is important to emphasize that, as the number of new technologies is growing, so is the number of potential bugs that can occur in any software product. Development without testing along the way can be compared to painting while blindfolded, as different elements of the project may not behave according to initial expectations. If you wait until development is “complete” to find that out—or worse, let users find out for you after the software is live—you’re creating much more trouble and expense for yourself than if you conduct this complex and diverse series of tests at key intervals throughout the development process.
