Over the years, the QA process at our company has been polished to perfection. That allows us to deliver only high-quality web pages and websites regardless of the technology they are based on. If you're curious about what happens under our QA hood, read this interview with one of our leading Quality Assurance experts.
GetDevDone is a tight-knit group of highly skilled and experienced frontend and backend developers. They are capable of getting done any project our clients request. However, simply building a website or converting a design into HTML markup is not enough.
We know how important bug-free software is for businesses. A slow-loading website with pages that suddenly fall apart can scare off customers and affect the bottom line. That’s why our company is focused on delivering only high-quality websites and web pages.
Over the years, the QA process at GetDevDone has been polished almost to perfection. It’s based on numerous test cases and time-tested best practices that we constantly improve and adjust to our clients’ current needs and quality standards. Not only do we perform cross-browser testing on desktop computers, but we also test projects on multiple devices and in an array of mobile browsers.
Why is Quality Assurance so important, and what stages do our QA experts go through in their work? We’ve met with one of our leading QA engineers for the answers.
When does the testing stage begin, and what’s the QA department’s primary objective?
We get down to business as soon as a client gives us their approval to start working on their project.
At the project estimation stage, we review the project specifications (if available), test them for contradictory requirements and feasibility, and suggest the best ways to implement certain modules and features. We also draw a test plan.
If we have received no project specs from the client, a QA writes the project specifications and summary jointly with the developers. Thus, the testing process gets underway already at the project estimation stage.
We must anticipate problems that our clients may encounter. We also ensure that everything looks and functions exactly as the client has specified by referring to the final quality assurance website checklist.
What main stages does the testing process include?
Here is the typical sequence of steps we go through while testing every project:
This is what the functional testing phase includes:
✘A page isn’t displayed correctly
✘A developer hasn’t implemented some of the features
✘Certain code in the project fails to work
At this stage, we apply two testing techniques:
We can also test a project in earlier browser versions for an extra fee.
If the project is a multilingual resource, our website quality assurance checklist also includes localization testing. We verify the correct translation of every available field both on the back-end and front-end.
If the client chooses the “optimized for load speed” option, we conduct performance testing as well by checking how fast web pages can load.
Finally, after we’ve completed the regression testing and our developers have fixed all the bugs, we perform smoke testing to make sure the main features work as they should. Only when all is perfect are we ready to deliver the end product to the client.
Do you perform testing on real gadgets? Why is device testing so important?
Yes, we perform testing on a multitude of real devices. That’s what distinguishes GetDevDone from freelance developers who have limited capabilities and can test projects on one or two gadgets most of the time.
Here are the key benefits of real-device testing:
When do you fix bugs?
To exceed our clients’ expectations and deliver their projects as promptly as possible, testing and bugfixing at GetDevDone are simultaneous processes. Regardless of the project’s deadline, our website quality assurance experts always perform testing. Therefore, the more time we have, the deeper and broader test coverage we can provide.
Do you perform automated testing?
Our QA engineers test each project based on our clients’ specific requirements. That’s why we perform manual testing at every stage of the QA process. That being said, the larger the project is and the more time we need to spend getting it done, the more acute is the need for automated testing. Whenever necessary, we write automated tests to cover all the functionality.
We hope that you now have a good idea about how we test projects at GetDevDone. Our website quality assurance specialists are trained to maintain the highest quality standards. Each page is manually tested on a variety of real devices and in multiple browsers, while bugs are fixed the moment they have been discovered. Do you have any suggestions or ideas for our QA professionals? Get in touch with us.
In case you don’t know it yet, QA stands for Quality Assurance. Why is Quality Assurance important? QA’s main purpose is to ensure that a specific software product works in accordance with the requirements that its creators defined when they were designing it.
Under its umbrella, QA gathers people, tools, standards, and processes, i.e., everything that can impact building high-quality software. A QA engineer’s mission is to ascertain that an application or a website is reliable.
QA is much broader than just testing. QA experts come into play even before programmers write a single line of code. They can help speed up the development process in general and the testing process in particular by making a list of standard and unusual inputs beforehand.
QA should start before development begins, ideally during estimation and specification review. If QA only begins after the build is almost finished, the team can miss contradictory requirements, unclear acceptance criteria, or features that are technically possible but risky within the available scope.
In a practical website project, early QA usually means reviewing the brief, checking whether the requirements are complete, identifying possible edge cases, and preparing a test plan. If the specs are missing or incomplete, QA and developers help clarify the expected behavior before the work moves too far.
For agencies, this matters because unclear requirements usually become delivery risk later: extra review rounds, delayed approval, or bugs that are actually scope gaps.
A standard website QA checklist should cover both how the site works and how it behaves across real usage conditions. It should not be limited to visual checks.
A practical checklist usually includes:
The exact checklist should still depend on the project. A small landing page does not need the same coverage as a multilingual CMS build, ecommerce site, or complex integration-heavy project.
Yes, manual QA is still necessary because automated tests can confirm expected behavior, but they do not replace human judgment. Automation is useful for repeated checks, regression testing, and larger projects with stable functionality that needs to be verified many times.
Manual QA is better for things that are harder to reduce to scripted checks: visual accuracy, mobile interaction, confusing admin workflows, unexpected user behavior, layout issues, and whether the site feels usable in real conditions.
GetDevDone uses manual testing throughout the QA process and adds automated tests when project size, functionality, and available time justify it. That balance is usually more realistic than trying to automate everything. For small or fast-moving website projects, excessive automation can cost more time than it saves. For larger builds, not automating repeatable checks can make regression testing slow and fragile.
Real-device testing checks the website on actual phones, tablets, and browsers, while emulator testing simulates those environments on another machine. Emulators are useful for quick checks, layout previews, and broader coverage when the team cannot physically test every device.
Real devices are better for catching issues tied to actual hardware, operating system behavior, mobile browsers, touch interaction, orientation changes, scrolling, animations, and virtual keyboards. These details often look fine in an emulator but fail or feel awkward on a real phone.
The practical choice is not either/or. Emulators help widen coverage, but real-device testing is safer for final checks, mobile-heavy layouts, interactive pages, and projects where the mobile experience directly affects conversions or client approval.
QA affects timelines in two opposite ways: it takes time, but it also reduces late rework. If testing starts early, bugs can be found module by module while developers are still close to the work. That is usually faster than discovering a large set of issues during final review.
In the GetDevDone process, testing and bug fixing happen in parallel. A finished module can be tested, fixed, retested, and then later checked again during regression and smoke testing. This keeps QA from becoming one large bottleneck at the end.
The main timeline trade-off is coverage depth. With more time, QA can test more devices, browsers, edge cases, flows, and project-specific scenarios. With a tight deadline, the team still needs core checks, but lower-risk or optional coverage may need to be scoped separately.
QA should catch bugs that stop the website from matching the approved design, requirements, and expected user behavior. The most obvious issues are broken layouts, missing features, failed scripts, broken buttons, forms that do not submit correctly, and galleries or interactive elements that do not work.
Good QA should also catch less obvious delivery risks: invalid form input handling, confusing user flows, admin editing issues, mobile keyboard problems, browser-specific layout shifts, localization mistakes, and regressions introduced after bug fixes.
For agency-delivered work, these bugs are not only technical defects. They can turn into client-facing problems during review: a stakeholder cannot approve the page, a marketer cannot edit content, or a campaign launch is delayed because a critical flow was never tested end to end.
A QA team needs enough project information to know what correct behavior looks like. At minimum, this usually includes approved designs, project specifications, functional requirements, target browsers and devices, CMS/admin expectations, integrations, form behavior, content rules, languages, hosting or staging details, and acceptance criteria.
The most useful information is not always long documentation. A short, clear explanation of expected user flows can be more valuable than a vague feature list. For example: what happens after a form is submitted, which fields are required, who receives notifications, what error states should appear, and what the admin user must be able to edit.
If that information is missing, QA and developers can help reconstruct it, but this usually adds friction. A documented website development process makes QA easier because the team has clearer checkpoints before testing begins.
Agencies should use both: the development partner’s QA for implementation quality and their own acceptance testing for business, brand, and client-specific judgment. These are related, but they are not the same job.
A development partner should catch technical and implementation issues: broken layouts, form errors, missed requirements, browser problems, device issues, regressions, and obvious usability problems. The agency or client still needs to confirm whether the final result matches campaign goals, brand expectations, legal wording, content accuracy, tracking requirements, and stakeholder preferences.
This is especially important when an agency uses external front-end development services. Partner QA can reduce delivery risk, but it should not replace final acceptance from the team that owns the client relationship.
Project-specific QA checks are the ones that depend on the site’s complexity, audience, technology, or commercial risk. They should be agreed before testing starts, not discovered after the client review.
Common project-specific checks include multilingual and localization testing, performance testing, older browser support, complex form logic, custom integrations, ecommerce checkout flows, CMS editing workflows, migration checks, security checks for custom modules, and automated regression testing for larger functionality.
The key question is: what would be expensive or embarrassing if it failed after delivery? For a multilingual site, that may be untranslated fields. For a campaign landing page, it may be tracking or mobile form submission. For a CMS build, it may be whether marketers can actually edit the modules without developer help.
Treating QA as a final pre-launch task increases the risk of late surprises, rushed fixes, and unclear responsibility. By the end of a project, small defects can become larger delivery problems because they are tied to already-approved layouts, dependencies, or client expectations.
The biggest risk is that QA starts finding issues that should have been caught earlier: contradictory specs, incomplete features, weak edge-case handling, broken module behavior, or regressions caused by last-minute fixes. Developers then have to switch back into parts of the project they considered finished.
For agencies, final-only QA also compresses the review window. Instead of using acceptance testing to confirm the build, the agency may end up sorting defects, clarifying requirements, and managing client anxiety right before launch. Early QA is less dramatic and usually cheaper to absorb.
On October 5, 2023, the World Wide Web Consortium (W3C) unveiled the much-anticipated WCAG 2.2, marking the culmination of five years of dedication and innovation. In this post, we're diving deep into the latest updates to the key web accessibility guidelines and sharing our unique approach to putting them into practice.
Discover how we implement web accessibility standards, aligning with WCAG recommendations to make websites more user-friendly for individuals with disabilities.
How do you build an eCommerce site that doesn’t just look good on launch day, but keeps selling and scaling for years? Getting there means following a clear eCommerce website development process and making the right calls early, choosing the right platform, modeling data flows, integrating the stack, and shipping with QA discipline.
