STQC's own published procedure for assessing systems and software opens with an unusually candid list of what goes wrong. The Procedure for Assessment of System and Software, issued by the STQC Directorate in 2014, names four recurring constraints. The complete and correct information about the system is not provided in time by the implementation agency. The system has not been thoroughly verified by the client or developer for readiness before it is offered for assessment. The project is already behind schedule by the time STQC is involved. And the assessors have limited exposure to the business domain. None of those four is a testing problem in the narrow sense. They are readiness problems, and they explain why assessments of government systems so often stall.
The procedure's remedy is just as revealing. It combines verification of the implementation agency's own testing process, a demonstration of the testing it carried out, and sample testing by STQC on the business-critical functions, which generally should not exceed 15% of the overall functionality. In other words, the quality of the implementer's test evidence largely determines how smoothly independent assessment goes. A system with a requirements document, a traceability mapping, a test plan, test cases, and test reports is assessed on the strength of that record. A system without them is assessed from scratch, under schedule pressure.
Functional correctness also now carries a constitutional dimension. On 30 April 2025, the Supreme Court held in Amar Jain v. Union of India that digital access is part of the right to life under Article 21, and issued twenty directions to make digital KYC accessible to persons with disabilities. The petitioners were an acid attack survivor who could not complete an e-KYC step that required a live, blinking photograph, and a visually impaired lawyer who could not use inaccessible applications. A flow that works for most users and fails for some is a functional defect with legal consequences.
This guide covers what functional testing means for government and enterprise applications judged against STQC's approach: what STQC covers, what an assessor needs to see, how defects are classified, what test documentation holds up, how to design tests for the risks these applications carry, how accessibility and GIGW fit in, and how to prepare. A note on scope applies throughout. STQC separately approves IT test laboratories under its own scheme, and this guide describes testing practice, not the approval status of any laboratory. Where a tender requires testing by STQC or by an STQC-approved laboratory, that status needs to be verified directly. The guide is written for project owners, implementation agencies, QA leads, and the compliance teams who sign off on go-live.
What STQC Is and What It Tests
The Standardisation Testing and Quality Certification Directorate sits under the Ministry of Electronics and Information Technology. In its own procedure, STQC describes its role on IT projects as an independent third-party conformity assessment agency, working through review, testing, and audit, at the pilot, pre-go-live, and post-go-live stages, in either staging or production. The attributes it evaluates include functionality, performance, security, usability, maintainability, and service quality.
STQC also runs an approval scheme for IT test laboratories, based on ISO/IEC 17025:2017 and ISO/IEC 17011, that covers both private and government laboratories testing software and systems for functional and non-functional characteristics. The scheme's scope shows the full range of testing that sits around functional testing.
| Test type in the approval scheme's scope | What it addresses |
|---|---|
| Functional testing | Whether the application does what the requirements say |
| Performance testing | Speed, capacity, and stability under load |
| Application security testing (web, mobile, and API) | Weaknesses in the application layer |
| Vulnerability analysis and penetration testing | Exploitable weaknesses in applications and infrastructure |
| Accessibility testing | Whether people with disabilities can use the system |
| Website testing as per GIGW | Conformance with the Guidelines for Indian Government Websites and Apps |
What Functional Testing Means Here
Functional testing checks that each requirement in the RFP, the contract, and the requirements document is implemented and works as specified. ISO/IEC/IEEE 29119, the international family of software testing standards, ties functional requirements to the functional suitability characteristic of ISO/IEC 25010, and describes testing at levels from unit and component through integration, system, and system integration to acceptance. STQC's procedure adds a practical expectation: the system should be fully developed, internally verified, and deployed on the required platform before it is offered for assessment, and end users should carry out user acceptance testing as well.
| Functional test type | What it confirms |
|---|---|
| Smoke and sanity | The build is stable enough to test further |
| System and end-to-end | Complete business workflows run correctly from start to finish |
| Integration and API | Components and external systems exchange data correctly |
| Business rule and data validation | Calculations, eligibility rules, and validations behave as specified, including invalid input |
| Role and permission | Each user role can do what it should and nothing more |
| Workflow and state transition | Approvals, delegations, and status changes follow the defined path |
| Negative and error handling | The system fails safely and tells the user what happened |
| Regression | Existing functions still work after changes |
| User acceptance | Intended users can complete their real tasks |
What the Assessor Needs to See
STQC's procedure lists the minimum inputs for an assessment, and the list works as a readiness checklist for any serious testing engagement.
| Required input | Why it matters |
|---|---|
| RFP and compliance criteria documents | The baseline against which the system is judged |
| Requirements document | The detailed statement of what was agreed to be built |
| Traceability between the RFP and the requirements document | Shows that every contractual requirement was carried into the specification |
| Test documentation, including test plan, test cases, and test reports | Evidence of what was tested and what was found |
The assessment itself follows a defined cycle.
| Step | What happens |
|---|---|
| Study and preparation | Assessors study the RFP, the requirements, and the documentation |
| Planning | The methodology, locations, environment, team, checklist, and schedule are fixed |
| Execution | Documents are reviewed, traceability is checked, the system is demonstrated, and critical business functions are tested in detail |
| Reporting | Observations are analyzed, severity is assigned, and an anomaly report is issued |
| Corrective action | The implementation agency fixes the anomalies and reports the corrective action |
| Verification and closure | Fixes are verified, the system is reassessed, and a final report is prepared |
The execution step includes a traceability check that maps RFP requirements to the system and software documents, a walkthrough to confirm the system is fully functional, and detailed verification of critical business functions, identified with the users. The outputs are an anomaly report, a closure report from the implementation agency, and a final report. The procedure dates from 2014, so the current approach for a specific project should be confirmed against the tender documents and with STQC, but the logic it describes, independent review resting on traceable evidence, is the pattern most conformity assessments still follow.
How Defects Are Classified
STQC's procedure uses a five-level scale for anomalies, which covers documents and processes as well as software behavior.
| Severity | What it means |
|---|---|
| Urgent | The failure causes a system crash, unrecoverable data loss, or jeopardizes personnel. A required document or process is absent entirely |
| High | The failure impairs critical system functions and no workaround exists. A critical requirement or critical document content is missing, wrong, or misleading |
| Medium | The failure impairs critical functions, though a workaround exists. A significant documentation or process deviation |
| Low | The failure causes inconvenience or annoyance. An isolated minor lapse |
| None | None of the above, or the item is an enhancement and not a failure |
The scale carries two lessons. Documentation gaps can rate as seriously as functional ones: a missing document is Urgent. And the difference between High and Medium is whether a workaround exists, so an honest assessment of workarounds affects both the severity rating and the schedule. Projects that argue severity case by case lose time. Projects that agree on the definitions before testing starts do not.
Test Documentation That Holds Up
ISO/IEC/IEEE 29119-3 defines templates and examples for test documentation, and STQC's procedure includes its own annexures for test scenarios, test logs, anomaly reports, and test reports. ISO/IEC 25051, which the procedure cites, lists the test documentation a third party expects to find: a test plan, a test description, test procedures, test results, and an anomaly report.
| Artifact | Purpose |
|---|---|
| Test plan and strategy | Scope, approach, test levels, environments, data, entry and exit criteria, and responsibilities |
| Test scenarios and test cases | Preconditions, steps, valid and invalid test data, expected output, actual output, and result, as in the STQC template |
| Traceability matrix | Links each requirement to the test cases that cover it, and to defects raised |
| Test log | A record of what was run, by whom, and when, with observations and screenshots |
| Anomaly or defect report | Each defect with severity, description, document reference, and evidence for repeatability |
| Test summary report | Results by module, defect counts by severity, and open items |
| Corrective action and closure report | Evidence that each reported defect was fixed and verified |
The STQC template asks that defect details be recorded completely enough to allow traceability and repeatability. In practice, that means a defect another tester can reproduce, with the exact data and steps, not a description of an impression.
Designing Tests for Government and Enterprise Risks
Generic test design techniques apply, including equivalence partitioning, boundary values, decision tables, state transitions, and use-case testing. The question for these applications is where the functional risk concentrates.
| Risk area | What to test |
|---|---|
| Eligibility and calculation logic | Boundary conditions, rounding, date handling, rule changes, and combinations of conditions |
| Multi-step workflows | Approval chains, delegation, rejection, resubmission, and what happens when a step is skipped or repeated |
| Roles and access | Every role against every function, including separation of duties and what happens after a role changes |
| Documents and uploads | File types, size limits, corrupted files, and retrieval of the right document for the right user |
| Notifications | Correct recipients, content, timing, and behavior when delivery fails |
| Integrations | Identity, payment, and document-exchange connections, including timeouts and partial failures |
| Reports and dashboards | Totals that reconcile with source data, filters, and exports |
| Audit trails | That every consequential action is recorded with who, what, and when |
| Data migration | Completeness and accuracy of records moved from legacy systems |
| Language and script handling | Input, display, sorting, and search in the languages the users actually use |
| Peak and failure conditions | Behavior under concurrent use and after interruptions |
Test data deserves its own attention. Production data copied into test environments is still personal data, and the DPDP Act's duty to implement reasonable security safeguards, which takes effect in May 2027, applies to it. Masking or synthesizing personal data for testing, restricting test environment access, and deleting data after use reduce exposure and are straightforward to evidence.
Accessibility and GIGW as Functional Requirements
For government websites and applications, accessibility is a requirement to be tested, not a courtesy. GIGW 3.0, the Guidelines for Indian Government Websites and Apps released in 2023, was formulated jointly with STQC and CERT-In. Government organizations are expected to assess their websites, web applications, and mobile apps against it and obtain Certified Quality Website certification from STQC. For cybersecurity aspects, the guidelines accept a "safe to host" certificate from auditors empanelled by CERT-In or STQC, or from STQC or NIC auditors. The guidelines are built on WCAG 2.1 Level AA and the Rights of Persons with Disabilities Act, 2016.
The Supreme Court's 2025 ruling gives the same expectation constitutional force for digital services. Accessibility testing therefore belongs inside functional testing, with checks that matter for real tasks.
| Accessibility check | Functional question |
|---|---|
| Keyboard-only operation | Can every function be completed without a mouse? |
| Screen reader behavior | Are labels, errors, and status messages announced so a blind user can finish the task? |
| Form and error design | Do errors identify the field and explain the fix in text? |
| Alternatives to capture steps | Is there another route when a photograph, blink, or face alignment step cannot be completed? |
| CAPTCHA and verification alternatives | Is there a non-visual way to pass verification? |
| Zoom, contrast, and mobile layout | Is the service usable at larger text sizes and on small screens? |
How Functional Testing Fits With the Other Test Types
| Test type | Question it answers | Typical sequence |
|---|---|---|
| Functional | Does it do what was specified? | First, once a stable build exists |
| Performance | Does it hold up under expected and peak load? | After functional stability |
| Application security | Can the application layer be attacked? | In parallel or after functional stability, and again after fixes |
| Accessibility | Can everyone intended to use it do so? | Alongside functional testing |
| Vulnerability assessment and penetration testing | Are there exploitable weaknesses in the deployed environment? | Before go-live and after significant change |
A functional pass does not imply security or performance acceptability, and the reverse is equally true. A "safe to host" certificate speaks to security, and a Certified Quality Website certificate speaks to the broader GIGW quality criteria. Neither replaces requirement-by-requirement functional verification.
What Carries Over to Enterprise Applications
Enterprise applications face no STQC requirement unless a government contract imposes one, but the discipline transfers well. A traceable chain from requirement to test case to defect to closure is useful in any acceptance dispute. Independent verification reduces the risk of a vendor grading its own work. A shared severity scale prevents argument over what blocks release.
| Government project practice | Enterprise equivalent |
|---|---|
| RFP-to-requirements traceability | Contract and statement-of-work traceability to acceptance criteria |
| Third-party assessment before go-live | Independent acceptance testing before payment milestones |
| Anomaly report and closure report | Defect reports and signed-off remediation evidence |
| User acceptance by end users | Business owner sign-off on real workflows |
| Sampling of critical functions | Risk-based test depth on the functions that matter most |
What Weak Functional Testing Costs
| Gap | Consequence |
|---|---|
| Documentation provided late or incomplete | Assessment delays, which STQC's own procedure lists as a recurring constraint |
| System offered before internal verification | Repeated rework cycles and a go-live that slips |
| No traceability between requirements and tests | Requirements go unverified and compliance with the RFP cannot be shown |
| Testing only the happy path | Defects surface in production, found by users |
| No accessibility testing | Exclusion of users and exposure under the RPwD Act and the Article 21 reasoning in Amar Jain |
| Severity and closure disputed case by case | Milestones and payments stall |
| No regression testing after fixes | Fixes introduce new defects |
A Maturity Model for Functional Testing
Level 1: Testing is informal, done by developers near release, with no documentation ↓ Level 2: A test plan and test cases exist, but traceability to requirements is partial and results are not formally reported ↓ Level 3: Requirements are traced to test cases, defects follow an agreed severity scale, and fixes are verified before closure ↓ Level 4: Independent testing, accessibility and integration checks, controlled test data, and a regression suite support each release ↓ Level 5: Testing is continuous, with automated regression in the delivery pipeline, evidence retained for audit, and results reported against acceptance criteria and service levels
The move from Level 2 to Level 3 matters most, since traceability and an agreed severity scale turn testing from effort into evidence.
A Readiness Plan Before Independent Assessment
- Freeze and baseline the requirements. Confirm the RFP, the requirements document, and the mapping between them.
- Build the traceability matrix early. Every requirement should point to at least one test case.
- Write the test plan with entry and exit criteria. Agree what counts as ready for assessment and what counts as done.
- Prepare test data and a stable environment. Mask personal data and match the target platform.
- Run internal testing to completion first. Offer the system for assessment only after the implementation agency has verified it.
- Agree the severity scale and closure evidence in advance. Use clear definitions, and decide how fixes will be demonstrated.
- Identify the critical business functions with the users. Plan deeper verification where the risk is highest.
- Include accessibility, integration, and user acceptance. Treat them as part of functional acceptance, and retest after every fix.
Common Mistakes and Edge Cases
Offering the system before it is ready. STQC's own procedure names this as a leading cause of delay.
Treating missing documents as a formality. Under the severity scale, an absent document rates as Urgent.
Testing against the developer's understanding, not the RFP. The baseline is what was contracted.
Skipping role-based testing. Permission errors are common and often serious in multi-department systems.
Using live personal data in test environments without safeguards. This creates privacy exposure that testing alone does not require.
Assuming accessibility can wait for a later release. Both the GIGW expectations and the Supreme Court's reasoning point the other way.
Confusing certificates. A security "safe to host" certificate, a Certified Quality Website certificate, and a functional acceptance sign-off address different questions.
When to Use What: A Few Decision Points
In-house versus independent testing. Internal testing is necessary and should come first. Independent testing adds objectivity and carries weight with clients and auditors, and it is often required by contract for government projects.
Manual versus automated regression. Automate stable, repeated checks so each release is verified quickly. Keep manual testing for new functions, exploratory work, and judgment calls about usability and accessibility.
Testing in staging versus production. Staging is safer and should be the default, and production checks are sometimes needed after go-live and should be limited and carefully controlled.
Depth of verification. Focusing detailed test cases on the critical business functions, which STQC's procedure suggests will generally be a minority of the overall functionality, balances effort against risk.
When STQC itself is required. Some tenders require testing by STQC or by an STQC-approved laboratory. Read the tender conditions, confirm the status of any agency before engaging it, and avoid assuming that equivalent testing will be accepted.
How SecNinjaz Fits Into This
STQC Services is one of SecNinjaz's practice areas. It covers functional, performance, and application security testing for web, mobile, and API applications, vulnerability assessment and penetration testing, accessibility testing, and GIGW compliance testing, the same categories that STQC's test laboratory scope describes. The work is testing aligned with STQC standards and documentation practice. Approval of laboratories and the issue of STQC certificates are matters for STQC, so where a tender requires testing by STQC or an STQC-approved laboratory, the status of the agency should be verified before engagement.
SecNinjaz holds ISO 9001:2015 for quality management, CMMI Level 3 for process maturity, and ISO/IEC 27001:2022 for information security, which matter here because a testing engagement handles requirements, test data, and defect details that need disciplined control. The security side connects to SecNinjaz's Cybersecurity practice, and data protection of test data connects to its GRC and DPDP practice. For project owners and implementation agencies that want test evidence an assessor can follow, from requirement to closure, that combination of testing practice and process discipline is the pairing worth looking for, whether the organization works with SecNinjaz or anyone else.
Frequently Asked Questions
What is STQC and what does it test?
STQC is the Standardisation Testing and Quality Certification Directorate under the Ministry of Electronics and Information Technology. It acts as an independent third-party assessor of IT projects, evaluating functionality, performance, security, usability, maintainability, and service quality, and it runs an approval scheme for IT test laboratories covering functional, performance, application security, accessibility, interoperability, and GIGW testing.
What documents are needed before an STQC assessment?
STQC's assessment procedure lists the RFP and compliance criteria documents, the requirements document, traceability between the RFP and the requirements document, and test documentation including the test plan, test cases, and test reports. Missing or late inputs are among the constraints the procedure itself identifies.
How does STQC classify defects?
The procedure uses five levels: Urgent, High, Medium, Low, and None. Urgent covers crashes, unrecoverable data loss, and missing required documents. High covers impairment of critical functions with no workaround. Medium covers impairment with a workaround, Low covers inconvenience, and None covers enhancements and items that are not failures.
What is GIGW 3.0?
GIGW 3.0 is the third version of the Guidelines for Indian Government Websites and Apps, released in 2023 and formulated jointly with STQC and CERT-In. It covers quality, accessibility, and security for websites, web applications, and mobile apps, builds on WCAG 2.1 Level AA, and forms the basis for STQC's Certified Quality Website certification.
Is accessibility testing part of functional testing?
It should be treated as part of functional acceptance for public-facing and government services. In Amar Jain v. Union of India, decided on 30 April 2025, the Supreme Court held that digital access is part of the right to life under Article 21 and directed changes to make e-KYC accessible, so a flow that some users cannot complete is a functional defect.
What is the difference between a safe to host certificate and a Certified Quality Website certificate?
A safe to host certificate addresses cybersecurity and is issued by auditors empanelled by CERT-In or STQC, or by STQC or NIC auditors. A Certified Quality Website certificate comes from STQC and addresses conformity with GIGW quality criteria, including accessibility. Neither replaces functional verification of each requirement.
Do enterprise applications need STQC testing?
Only where a government contract or tender requires it. Enterprises can still adopt the same discipline, including traceability from requirement to test case to defect, independent verification, and a shared severity scale, because it makes acceptance and payment milestones easier to settle.
Where should a project start when preparing for independent assessment?
Start by baselining the RFP and requirements and building the traceability matrix, then complete internal testing before offering the system for assessment. Agree the severity scale and closure evidence in advance, prepare masked test data and a stable environment, and include accessibility, integration, and user acceptance testing.
