Software testing, QA and application security
We build testing and security into delivery from the first sprint: automated and regression testing, code review, dependency scanning and vulnerability testing before go-live, with the evidence clients ask for in vendor security reviews.
Services in this pillar
Each service has its own page with scope, approach and buyer questions.
Software Testing & QA
Test strategy, automated regression tests and UAT support, for systems we build and systems other vendors delivered.
Application Security
Secure design and coding: sign-in and permissions, secret storage, dependency patching and security checks in the pipeline.
VA & Penetration Testing
Vulnerability scanning and controlled penetration testing of applications and infrastructure, with a remediation plan and a retest of fixes.
How testing and security fit into delivery
Defects and security weaknesses cost more to fix the later they are found, because more of the system has been built on top of them. So most of the effort goes into checks that run on every change: automated tests on the paths where failure is expensive, dependency scanning in the pipeline, code review before merge, and sign-in and permission rules designed at the start.
Point-in-time testing still has a place. A vulnerability assessment and penetration test before go-live, or once a year, shows what an outside attacker could reach on that day. MERCIL is not an accredited testing body. Where a regulator, auditor or tender requires a formal attestation, we work alongside an accredited firm, or you can engage one directly.
Common questions about quality and security work
Do you perform accredited penetration testing?
No. We run vulnerability assessments and controlled penetration tests and report the results, but MERCIL is not an accredited testing body and our report is not a formal attestation. Where one is required, we work alongside an accredited firm, or you can engage one directly.
How much test automation is enough?
Enough that the team can release without a long manual check. Start with the paths where failure is expensive and the areas that change most often. A coverage percentage on its own is a poor target, because tests end up written to reach the number.
Can you improve the security of a system already in production?
Yes. We assess it against the OWASP risk categories, rank the findings by how exposed each one is, and fix them in stages so feature work can continue while it happens.
How does this relate to PDPA?
Application security provides the technical controls that PDPA compliance depends on: access control, encryption, audit logs and breach detection. We build those controls. Interpreting your legal obligations is a matter for your legal advisers.
Next step
Start with a conversation
Tell us about the problem you are trying to solve. A senior person reads every inquiry and replies with our view of fit, scope and cost, including when another option would suit you better.