От халепа... Ця сторінка ще не має українського перекладу, але ми вже над цим працюємо!
От халепа... Ця сторінка ще не має українського перекладу, але ми вже над цим працюємо!
9 min read
Having worked closely with dozens of startups, we heard many successful product development stories and even contributed to some. We also help clients overcome their bad experience with previous vendors. And when we ask them the main reason for their dissatisfaction, most responses concern the poor quality of their product.
Startup owners face various challenges related to the quality of their software products, primarily:
This article covers how professional QA services and an established process help business owners overcome these challenges to release products of high quality.
“Move fast and break things” is by no means our story. At NERDZ LAB we are aligned with the famous maxim, “Early testing saves time and money.”
Fortunately, paying particular attention to software QA services doesn’t necessarily mean slowing down product releases. Quite the opposite, testing is a cornerstone of the CI/CD paradigm—a key approach to picking up the speed of software development. All you need is a strategic approach to the test activities and tasks performed by your team.
Testing should be implemented from the earliest project stages and cover a range of test activities, helping to achieve the desired outcome of the project. Although releasing software of the highest quality is the top priority of any business, it’s not the only one. Startups should have enough resources to get off the ground and not get down to bedrock before finding investors. Let’s look at our own example of why the principle of early testing is critical to the success and cost-effectiveness of a project and how you, as a customer, can make use of it.
Actions. All the heavy lifting at this stage falls to the project test lead. The person who performs this role will be busy investigating the project specifications, product design requirements, and all other available project documentation.
Objectives. Creation of a document known as a test plan. We’ll use this for all software testing services related to our project.
Working with a test plan means covering the following:
Actions. The team of testers carries out an in-depth analysis of the business, system, and functional requirements, investigates user stories, experiences, use cases, and more. To perform this task, our team selects the most relevant of the following static test design techniques:
Objectives. We consider this stage one of the most pivotal in quality assurance engineering. Irrespective of which testing types are used, with their help, we’ll find the defects, issues, ambiguities, or discrepancies in the documents, such as requirements or design specifications. By finding the cause of failure initially, we prevent penetration of bugs into the forthcoming development stages.
Actions. At this stage, QA specialists will create high-level and low-level test cases, as well as a requirements traceability matrix (RTM). This RTM helps cover and check all the requirements with test cases, grouped into test suites, where the best sequence for each case is selected. This allows us to keep the best ratio between the execution terms and the number of requirements, features, and functionalities that have to be tested.
In contrast to the previous stage of test analysis, when our testers resort to static testing techniques, we rely on dynamic testing techniques which fall into two broad categories:
Objectives. Our principal aim in terms of test design is to cover all the documented requirements with test cases. We also use RTM to verify there are no requirements left without a corresponding test case and trace which test suite will be suitable to cover those requirements.
Actions. This stage of text execution is the first time the tester deals with the program build. But it can’t be classified as the only real testing during the software development process. There are vital stages before and after this part of the process.
All the identified bugs are added to the bug tracking system. Next, they’re assigned a ticket for the corresponding developer to fix them. After that, the ticket returns to the tester to perform:
As to our preferred tools, we rely on a blue-chip browser-based regression testing tool-Selenium-which is the most rational choice for frequent regression testing. We love it for its support of numerous testing frameworks, programming languages, and third-party libraries. As long as it’s perfectly compatible with many OS and browsers, some of the top browser vendors can make Selenium the native part of the browser someday.
Objectives. To release the software product of the highest quality, which is perfectly aligned with all the client’s requirements. Yet it’s easier said than done. Below, we continue with the next stage of QA testing services, which helps us to approach the desired objective.
Actions. With software testing services, it’s better to err on the side of caution. We double-check that all bug reports are closed, test plans satisfy exit criteria, and product programming has met all the objectives. To conclude, we compile a test summary report where we analyze all testing activities and rate their efficiency.
Objectives. To get the developed product ready for release.
Actions. This type of QA services can be applied to any software component at any testing stage and in parallel with any other testing activity. We work according to a test plan which can be revised regularly and may have various versions. So when, for instance, we receive new requirements, we try to quickly respond to the change without compromising entire testing and development tasks.
Objectives. Our task is to detect deviations in the agreed course of testing and make necessary amendments.
Today, you have to consider numerous form factors, OS version, resolutions, and device variations to ensure complete coverage of users’ devices. At NERDZ LAB, we address this matter with more than 25 real devices and about ten professional testing tools. On top of that, we follow our own approach to web and mobile testing and rely on automated testing as a key facilitator of many advanced development and deployment practices.
So let’s discuss what factors we should consider when dealing with mobile and web testing and why automation is a steady trend in software testing.
Mobile app testing relates to compatibility issues or bugs to be found across a wide range of mobile devices. That’s why we have to consider different parameters when compiling test plans for mobile and web testing procedures. Let’s look at mobile testing first, where we consider the following:
Besides that, we evaluate the following metrics in the course of mobile testing:
Now more details about our approach to web testing.
The main goal behind web testing is to verify whether web apps are adequately optimized to be viewed across multiple devices, including mobile phones, desktops, and tablets, with uninterrupted access from a web browser. We consider the following criteria when compiling the test plan for our web development services:
As to the analytics data, we use StatCounter GlobalStats to access the mobile and web analytics required for test execution. We rely only on industry-proven best practices — our decision is based on the suggestion of ISTQB Mobile Application Testing Foundation Level Syllabus.
Test automation is the use of testing tools and special programs to support teams in performing repetitive tasks, detecting bugs faster and more precisely, providing continuous feedback, and ensuring better test coverage. As a result, we save time and human resources. Other advantages of test automation include:
However, testing automation can’t and shouldn’t replace manual testing altogether. For instance, there’s no alternative for manual ad-hoc or exploratory tests, which often detect critical errors. To ensure the best quality, we suggest utilizing them hand-in-hand.
Learn more about our automation testing services and process here>
We try not to engage clients in the process of QA, even if they have experience as testers. The only thing we do need our client to do is carefully identify their requirements and never neglect their documentation. Let us explain why.
Take, for example, the explicit and implicit requirements buyers set when selecting a car. If the car salesperson immediately grasps that you need a four-wheel vehicle for driving in a city as well as further afield, that’s what we call the explicit requirements. Next, you’ll specify the car’s color, engine size, upholstery fabric, and similar—that will be implicit requirements. Some time later, when your custom-made product arrives, and you receive your white sedan with a 3.0L engine, you will be disappointed because you were expecting a hatchback instead of a sedan. How did that happen? Because a single but critical detail was omitted in the project documentation.
To avoid such mischief with software development, the client should receive demo builds of their products to ensure no implicit requirements are missed in the project documentation. It will help you guarantee at the initial development stage that your product isn’t a sedan when you’re expecting a hatchback.
At NERDZ LAB, software testing services cover the entire project starting from the test planning and estimation stage. Next, as we proceed with test analysis and design, we thoroughly apply testing based on test cases to cover all the requirements and perform testing efficiently.