Is automation testing a different type of testing from functional, performance, and security testing?
No, and the distinction is worth being clear about. Functional, performance, and security testing are types of testing, each asking a different question: is the behavior correct, does it hold up under load, and can it be misused. Automation is a delivery mechanism, meaning the way tests are executed. Functional and regression checks are the ones most commonly automated. Performance testing is inherently tool-driven, and security testing relies heavily on manual work that does not automate well.
Should we do functional testing before automating?
Usually yes. Functional testing establishes which checks matter and confirms they are stable and correctly specified, and those are exactly the checks worth automating. Automating first tends to lock in assumptions that have not been validated, producing a suite that runs reliably while testing the wrong things.
Can you automate all of our testing?
No, and a partner who says otherwise is selling something. Automation is good at repeating a known check and poor at noticing that something looks wrong. Exploratory testing, usability judgment, and most security assessment need a person. A realistic target is automating the stable, repetitive, high-value checks and keeping human effort for work requiring judgment.
When is test automation not worth it?
When the application or its requirements are changing rapidly, the tests would need rewriting each sprint and maintenance exceeds any saving. When a check runs rarely, the build cost is not recovered. When the outcome depends on human judgment, such as whether a layout looks right, automation cannot make the call. When the test environment is unstable, the suite will fail for reasons unrelated to the software. We will tell you when one of these applies rather than proceeding.
What tools do you use for test automation?
Selenium, Playwright, Cypress, and Appium for mobile. All are established open tools. Selection depends on your application, the browsers and platforms in scope, and what your team can maintain after handover, since a suite written in a language nobody in house uses becomes unmaintainable quickly.
We already have an automation suite that keeps failing. Can you help?
Yes, and this is a common situation. We assess what exists and identify whether the problem is framework structure, test environment stability, or the choice of what was automated. The recommendation may be to repair, to rebuild selectively, or to reduce the suite to the tests that earn their place. If the honest answer is that the existing suite is not worth saving, we will say so.
How does this relate to your DevOps services?
They meet at the pipeline. DevOps builds and operates the continuous integration and delivery pipeline itself: the build, the deployment, the environments. This service builds the tests that run inside it and integrates them so results appear where your team already looks. If you have a pipeline, we add the tests to it. If you do not, our DevOps services cover establishing one.
Do we own the automation framework and scripts?
Yes. The framework, scripts, documentation, and conventions are handed over and belong to you. There is no proprietary layer that requires continuing to engage us in order to extend the suite.
Is AgileTech Vietnam ISO certified for QA delivery?
Yes. Our quality management practices are verified by ISO 9001:2015 and our security management practices are supported by ISO 27001:2013. Both apply to automation engagements, which typically involve access to your codebase and build pipeline.
