Independent Testing Services · ITS

See the risks before release.
Decide with evidence.

For Hong Kong project partners and business system owners accepting or changing an important application. SMERP brings business risks, supplier follow-up and acceptance evidence into one agreed testing work package, so you can see what is verified, what remains open and who acts next.

Discuss your testing needsExplore the testing packages

Free initial discussion. Testing scope, deliverables, retest rounds and fees agreed before work starts.

For project delivery partners and business system owners

A system to accept.
A decision you need to support.

Choose the engagement around your responsibility and the decision ahead.

Main contractors and SI partners

A defined testing work package, clear development responsibilities and evidence ready for customer review.

Business and system owners

An evidence-based view of supplier delivery, an upgrade or a new application before acceptance.

Technical and project leads

A focused answer to a workflow, integration, release or performance question.

Unresolved issues and missing evidence can delay acceptance or leave important business risks unclear.

Why work with SMERP

Business risk, supplier follow-up
and acceptance evidence together.

One agreed work package connects the business question, actionable technical findings and the next acceptance decision. Your project lead receives a concise conclusion; the team handling each issue receives the evidence and follow-up responsibility.

Established in Hong Kong in 2005. Team members hold project-management and IT-audit qualifications including PMP, PMI-ACP and CISA. These are individual qualifications; the team page explains the background behind our planning and review approach.

See our experience and team credentials

What your team can act on

  • Business risks set the testing priorities.
  • Supplier responses remain separate from verified fixes.
  • A decision brief links remaining actions to the evidence.

Before an engagement, we agree the separation of testing and development responsibilities, reporting arrangements and any relevant relationships. The independence required by the customer or contract determines whether an engagement is suitable.

Three ways to engage

Choose the scope
that fits your decision.

Full ITS engagement

A practical fit when

An important acceptance or release needs a complete, agreed testing cycle.

Included work

  • Risk and coverage planning, test design and execution.
  • Defect follow-up, included retests and selected regression checks.
  • Progress updates and a final decision brief.

What you receive

The four deliverable groups below, with the evidence index and agreed handover materials.

Focused testing work package

A practical fit when

A specific workflow, interface, release or performance question needs an answer.

Included work

  • A defined objective, scope, conditions and expected results.
  • The selected checks and recorded findings.
  • Retesting only as expressly included in the quotation.

What you receive

A scoped test brief, relevant cases and evidence, findings and a conclusion addressing the question.

UAT support or evidence review

A practical fit when

Your team is running acceptance testing or assessing an existing evidence pack.

Included work

  • Selected UAT planning, scenarios, data or issue coordination.
  • Or review of supplied evidence against agreed requirements.
  • Recorded gaps, limitations and follow-up responsibilities.

What you receive

Agreed UAT records or review findings. The report identifies which material was reviewed and which tests, if any, we executed.

The initial discussion is free. Work is quoted by project or agreed testing cycle. The proposal defines the scope, build, environments, effort, deliverables, review points and included retest rounds. Software fixes and specialist assessments are separate unless explicitly included; additional scope or reruns are approved before the extra work starts.

Six steps from business risk to a useful conclusion

Start with the decision.
Follow the evidence.

Six steps connect the decision to the evidence. The proposal defines which activities and outputs apply to your package.

01

Define the decision

Confirm the acceptance or release decision, important workflows, criteria, decision date and responsibilities.

02

Prioritise business risks

Agree the consequences of failure and use them to prioritise the relevant requirements and checks.

03

Confirm testing readiness

Check the identified build, environment, access, test data, interfaces and expected results before execution.

04

Test and triage findings

Record expected and actual results, reproduction steps and evidence. Triage application, data, environment and interface issues; mark uncertain causes for analysis.

05

Verify fixes and related workflows

Retest fixes on the identified build and run the agreed regression checks for affected workflows.

06

Hand over the decision brief

Assess the agreed criteria and explain remaining risks, evidence gaps and actions for the customer’s decision.

What you receive and gain at each step

01 · Define the decision

  • What you receive: A test plan opening with the decision, agreed scope and criteria.
  • Value to your team: Know which question the testing must answer before effort is committed.

02 · Prioritise business risks

  • What you receive: A workflow and requirement-to-risk-to-test coverage map.
  • Value to your team: Put the available testing effort into the checks with the greatest business impact.

03 · Confirm testing readiness

  • What you receive: A readiness record with blockers, their impact and the next responsible person.
  • Value to your team: See what must be ready before testing time is used.

04 · Test and triage findings

  • What you receive: Execution records and prioritised findings with evidence and follow-up owners.
  • Value to your team: Give the responsible team enough information to investigate and act.

05 · Verify fixes and related workflows

  • What you receive: Fix-verification and regression records linked to the original findings.
  • Value to your team: Distinguish a reported fix from a verified result and see which related checks remain outstanding.

06 · Hand over the decision brief

  • What you receive: A one-page decision brief, evidence index and agreed test materials for handover.
  • Value to your team: Help management decide the next step and let the next team find and reuse the evidence.

The six steps are organised into four deliverable groups below. Review points, included retest effort, handover format and evidence access are agreed in the proposal.

Three checkpoints before the next acceptance decision

At each checkpoint, record the evidence available, gaps and next owner. The customer retains the final acceptance or release decision.

Before testing starts

Check that the build, environment, data and expected results meet the agreed entry conditions. Record any blocker, its effect on the planned checks and who must resolve it.

Before a fix is confirmed

Verify the relevant result on an identified build. Record separately: supplier reports fixed; fix verified; customer accepts residual risk. A supplier update alone does not establish a verified fix.

When testing concludes

Mark each agreed criterion as met, not met or insufficient evidence. Identify remaining risks, the next action and its owner. A high overall pass rate can still leave a critical workflow unresolved.

Practical deliverables for the next person and decision

Know what you will receive.
Know what it helps you decide.

A full ITS engagement brings these four outputs together. Focused testing, UAT support or evidence review specifies the applicable outputs, detail and review points in its proposal. Materials follow the agreed access and confidentiality arrangements.

PLAN

Test plan and risk coverage

The decision, criteria, scope, responsibilities and readiness conditions, with workflows and requirements mapped to risks and planned tests.

Value to your team: Check whether the plan addresses the business risks that matter.

EXECUTE

Test cases, results and evidence

Inputs, expected and actual results, execution status and evidence references tied to the tested build and environment.

Value to your team: Understand what was checked and give the next person a usable record.

FOLLOW UP

Findings and fix verification

Impact, reproduction steps, triage status, owner, supplier response and the outcome of included retests and regression checks.

Value to your team: Follow each issue through to evidence of resolution or a clearly recorded outstanding action.

CONCLUDE

Decision brief and evidence index

A one-page summary of criteria, results, remaining risks, limitations and next owners, linked to the detailed evidence and handover materials.

Value to your team: Review the next decision quickly and find the supporting detail when needed.

View an illustrative one-page decision brief

Illustration only: a fictional application in a test environment. The criteria, references and results below are examples, not customer results or a certification.

Decision brief · Approval application · DEMO-02

Conclusion: the agreed criteria are not all met. Two failed checks and two incomplete checks need follow-up before the next acceptance review. No fix verification or customer acceptance of residual risk is recorded in this example.

Execution: 12 planned cases — 8 passed, 2 failed, 1 blocked and 1 not run. The result applies to build DEMO-02 and the recorded test conditions.

MET · Routine workflow checks

TC-01–08 passed against their expected results. Evidence EV-01–08 supports these checks within the agreed scope.

NOT MET · Return and permission checks

TC-09 loses entered data when returned for correction (D-01, high priority). TC-10 fails an agreed role-permission check (D-02, medium priority). Evidence EV-09–10 records the findings.

INSUFFICIENT EVIDENCE · Interface

TC-11 is blocked because the test endpoint is unavailable. The expected interface behaviour has not been verified.

INSUFFICIENT EVIDENCE · Regression

TC-12 has not run. The planned regression criterion remains unverified and visible in the evidence index.

Next actions and responsible roles

  • Supplier: correct D-01 and D-02 and identify the build supplied for retesting.
  • Environment owner: restore the test endpoint for TC-11.
  • Testing team: verify the fixes, complete outstanding checks and update the evidence and criterion status within the agreed scope.
  • Business owner: review the updated brief, decide the next acceptance action and record any accepted residual risk.

Handover index: test plan TP-01 links agreed criteria to TC-01–12, execution records, EV-01–10 and D-01–02. Blocked and not-run checks retain their status and next action; they have no passing result. The detailed records support the brief and future reuse.

How to assess the value of the work

Coverage of important business risks

Compare the agreed workflows and risks with completed checks. See which important areas are verified, missing or blocked.

Visible progress on major findings

Track the important open issues, fixes verified on the identified build and actions still outstanding. A reported fix keeps its own status.

A decision with a clear next owner

Review each criterion as met, not met or insufficient evidence, with remaining risk, the next action and the responsible role.

Materials the next team can reuse

Find the case, conditions, result and supporting evidence in the agreed index. Use the handed-over materials for future review or agreed regression work.

Select the checks that matter to your decision

A test scope shaped around
your business and system.

Open a testing activity to see its scope. Your proposal confirms the selected checks and conditions.

Functional and workflow testing

Check business rules, permissions, normal use, exceptions and important end-to-end tasks against agreed expected results.

Integration and data checks

Check agreed interfaces, data exchange, error handling and the records passed between connected systems.

Performance, load and stress testing

Agree workloads and thresholds, then observe response, throughput, errors and resource use under the defined conditions.

Regression testing

Recheck selected existing workflows after a fix, upgrade or change, using the agreed build and regression scope.

UAT support

Help organise scenarios, test data, issue recording and follow-up. Business owners retain responsibility for acceptance.

Test evidence and deliverable review

Review supplied test material against agreed requirements and identify missing coverage, unclear results or follow-up needed.

Security, penetration, accessibility and AI-specific assessments require separately confirmed scope and specialist capability. They are not implied by a general functional or performance testing engagement.

Before we begin

Questions about independent testing.

Can you test a system built by another supplier?

Yes, subject to agreed access, requirements, environment, test data and working arrangements. We define how findings reach the development team and who is responsible for fixes.

How is independence handled?

We confirm development involvement, relationships, reporting lines and the separation required by the customer. Where SMERP developed or changed the system, we disclose that involvement. Our own delivery cannot be presented as an external independent assessment where one is required.

What do we need to prepare?

Bring the requirements or acceptance criteria available, an identified build, test environment and access arrangements, representative data and the decision date. We help identify any gaps before planning the work.

Does a passed test mean the whole system is ready?

A result applies to the tested scope, build, data and environment. The report identifies untested areas and remaining risks. Testing supports the decision; it does not guarantee defect-free software or replace the customer's approval.

Are fixes and unlimited retests included?

The proposal states who fixes defects and how many retest rounds or how much effort is included. Additional fixes, scope or reruns are assessed and agreed separately.

Will performance results apply to production?

Results describe the tested workload and environment. We record relevant differences from production and any limits on interpreting the results. Production testing requires a separately agreed plan and authorisation.

Start with the decision you need to make

Bring the system and the concern.
Find the checks that matter.

Share your role, important workflows, concern and decision date. We will discuss the suitable package, prerequisites and information needed for a scoped quotation.

Discuss your testing needs
[email protected]