Common Failure Cases

This chapter compiles the most frequently occurring reasons for rejection in TQS certification audits and their solutions. It includes the top failure reasons, root cause analysis by case, and frequently asked questions (FAQ). Project teams should refer to this chapter before requesting an audit to proactively prevent repeating the same mistakes.

---

33.3.1. Top 10 Most Frequent Failure Reasons

The following is a list of the most frequently identified failure reasons in TQS certification audits, ordered by frequency.

Rank	Failure Reason	Frequency	Affected Area
1	Test coverage below threshold (line < 80% or branch < 70%)	Very High	Testing
2	System.out.println usage	High	Code convention
3	TypeScript any type usage	High	Frontend
4	CI/CD pipeline not configured or incomplete	High	Operations
5	Hardcoded secrets (API keys, passwords, tokens)	High	Security
6	JPA/Hibernate usage (not using jOOQ)	Medium	Data
7	Vue Options API usage	Medium	Frontend
8	Flyway migration not applied	Medium	Data
9	.gitignore missing or incomplete	Medium	Configuration management
10	Global exception handling not implemented	Medium	Backend

All items listed above are TQS mandatory items. Failure to meet even one of them results in certification denial.

---

33.3.2. Root Cause Analysis by Case

This section provides detailed explanations of the cause, solution, and prevention methods for each failure reason.

33.3.2.1. Test Coverage Below Threshold

Cause: This occurs when a test-writing culture is not established or when time for writing tests is not allocated. Testing complex business logic is often deprioritized because it is perceived as difficult.

Solution:

• Prioritize writing tests for core business logic (service layer) first.
• Exclude code that does not require testing (configuration classes, DTOs, jOOQ auto-generated code) from coverage measurement.
• Specify exclusion targets using JaCoCo's <exclude> configuration.

Prevention:

• Establish a practice of writing test code alongside new feature development.
• Add coverage threshold verification to the CI pipeline so that the build fails when coverage decreases.

33.3.2.2. System.out.println Usage

Cause: System.out.println statements inserted for debugging purposes remain unremoved. This also occurs when there is insufficient awareness of logging frameworks.

Solution:

• Replace all System.out.println with logging based on SLF4J + Logback.
• Use log.debug() for debugging output and disable the DEBUG level in production environments.

Prevention:

• Configure ESLint or static analysis tools to detect System.out.println usage as an error.
• Include console output usage as a mandatory review item during code reviews.

33.3.2.3. TypeScript any Type Usage

Cause: any is used for convenience when type definitions are complex or when external library types are unclear.

Solution:

• If an external library does not provide types, declare types using declare module.
• Write flexible yet type-safe code by leveraging generics.
• In unavoidable cases, use unknown and narrow the type with type guards.

Prevention:

• Set the @typescript-eslint/no-explicit-any rule to error in ESLint.
• Include and manage type definition files (.d.ts) in the project.

33.3.2.4. CI/CD Pipeline Not Configured

Cause: This occurs when the necessity of CI/CD is not recognized, or when configuration is deferred due to its complexity. It is common in projects where the practice of performing builds and tests only in local environments has become entrenched.

Solution:

• Configure a CircleCI-based pipeline. Create the .circleci/config.yml file and define stages in the order of lint, test, build, and security scan.
• Integrate all verification tools required by TQS (Spotless, ESLint, Prettier, JaCoCo, Vitest, OWASP) into the pipeline.

Prevention:

• Configure the CI/CD pipeline as a priority during the early stages of the project.
• Include the pipeline configuration file in version control.

33.3.2.5. Hardcoded Secrets

Cause: API keys, database passwords, and external service tokens are written directly in the source code for development convenience. Incidents where secrets written for local environments are included in commits are frequent.

Solution:

• Separate all secrets into environment variables. For Spring Boot, reference them in application.yml using the ${ENV_VAR} format.
• Add .env files to .gitignore to exclude them from version control.
• If secrets have already been committed to Git history, immediately rotate the secrets.

Prevention:

• Add secret detection tools to pre-commit hooks.
• Include secret inclusion as a mandatory review item during code reviews.

33.3.2.6. JPA/Hibernate Usage

Cause: Although TQS standards designate jOOQ as the standard technology for the data access layer, existing projects using JPA/Hibernate have not made the transition.

Solution:

• New projects must use jOOQ from the start.
• Existing projects should apply jOOQ to new features first, then gradually migrate existing JPA code.
• Configure the jOOQ code generator to write type-safe queries based on the database schema.

Prevention:

• Configure jOOQ dependencies and the code generator during initial project setup.
• Share the TQS data access layer standards with the team.

33.3.2.7. Vue Options API Usage

Cause: Projects developed since the Vue 2 era continue using the Options API as-is. Transition is sometimes deferred due to the learning cost of the Composition API.

Solution:

• Migrate all Vue components to <script setup> based Composition API.
• Extract common logic into Composable functions.
• Define Pinia stores using the Setup Store pattern.

Prevention:

• Establish a team rule that all new components must use the Composition API.
• Enable ESLint rules that detect Options API usage.

33.3.2.8. Flyway Migration Not Applied

Cause: Database schema changes are managed manually, or the need for a migration tool is not recognized.

Solution:

• Integrate Flyway into the project and manage all schema changes through migration scripts.
• Migration files must follow the V{version}__{description}.sql naming convention.
• Generate an initial migration file (Baseline) based on the existing schema.

Prevention:

• Set up Flyway during the early stages of the project and create the first migration file.
• Prohibit manual DDL execution and ensure all schema changes are performed exclusively through migration files.

33.3.2.9. .gitignore Missing

Cause: The .gitignore file was not created, or IDE configuration files, build artifacts, and environment variable files are not properly excluded.

Solution:

• Create a .gitignore file in the project root.
• The following entries must be included: IDE configurations (.idea/, personal settings in .vscode/), build artifacts (target/, dist/, node_modules/), environment variable files (.env, .env.local), and OS files (.DS_Store, Thumbs.db).
• For files already committed, remove tracking using the git rm --cached command.

Prevention:

• Configure .gitignore immediately after project creation.
• Maintain a team-shared .gitignore template.

33.3.2.10. Global Exception Handling Not Implemented

Cause: Exceptions are handled individually in each controller, or stack traces are exposed directly to the client when exceptions occur.

Solution:

• Implement global exception handling using Spring Boot's @RestControllerAdvice.
• Define a standard error response format and apply it consistently to all exceptions.
• Configure appropriate HTTP status codes to be returned for each exception type.

Prevention:

• Create a global exception handling class during the early stages of the project.
• Share the standard error response format within the team and ensure compliance.

---

33.3.3. FAQ

This section compiles frequently asked questions and answers from the TQS certification preparation process.

Q1. Do we need to migrate an existing JPA project to jOOQ?

New projects must use jOOQ from the start. For existing JPA projects, a gradual migration rather than an immediate full transition is recommended. Apply jOOQ when developing new features and sequentially migrate existing JPA code during maintenance. However, new projects using JPA will be rejected at the initial audit.

Q2. Achieving 80% test coverage is difficult.

If achieving the coverage target is difficult, apply the following strategies. First, prioritize testing core business logic (service layer). Second, exclude code that does not require testing (configuration classes, DTOs, auto-generated code) from coverage measurement. Third, avoid writing meaningless tests solely to increase numbers. TQS technical audits verify test quality in addition to coverage figures.

Q3. There is not enough time to migrate a large-scale project from Options API.

It is not necessary to migrate all components at once. However, all components must use the Composition API at the time of TQS certification. For large-scale projects, it is recommended to secure sufficient time for the certification schedule and migrate in phases. Starting with simple components and expanding to complex components is an effective approach.

Q4. Must all verification tools be included in the CI/CD pipeline?

The mandatory verification tools required by TQS (Spotless, ESLint, Prettier, JaCoCo, Vitest, OWASP Dependency-Check) must be included in the CI pipeline. Lighthouse may be run separately after deployment, but integrating it into CI is recommended. Verification results from tools not included in the pipeline may not be recognized during the audit.

Q5. What should be done if OWASP scans produce false positives?

Vulnerabilities confirmed as false positives may be registered in a suppression file to exclude them from subsequent scans. However, when registering a suppression, evidence proving the vulnerability is a false positive must be recorded along with it. The validity of suppression files is also included in the audit scope.

Q6. Can feature development continue during the certification preparation period?

Running both in parallel is possible, but it is recommended to prioritize certification preparation tasks. By developing new features in compliance with TQS standards, certification preparation and feature development can proceed simultaneously. However, the project lead must manage the schedule to prevent delays in the certification preparation timeline.

Q7. What is the practical difference between Basic and Excellent certification?

Basic certification can be obtained by meeting 100% of mandatory items alone. Excellent certification requires 100% of mandatory items plus 80% or more of recommended items. Obtaining Excellent certification allows the "Excellent" grade to be displayed on the TQS Mark and may result in registration as an internal technical best practice. Projects preparing for certification for the first time are recommended to set Basic certification as their initial goal.

Q8. What happens if a conditional pass is received during the audit?

A conditional pass is granted when minor remediation is needed. The remediation period is a maximum of 2 weeks, after which a re-verification audit is conducted to make the final determination. The re-verification audit covers only the non-compliant items, making it less burdensome than a full re-audit.

Q9. Does applying Flyway migration affect existing data?

Using Flyway's Baseline feature allows migration management to begin while preserving the existing database schema. Only schema changes after the Baseline need to be managed through migration files, so existing data is not affected.

Q10. Is HikariCP connection pool configuration also subject to audit?

HikariCP is the connection pool library mandated by TQS. The appropriateness of connection pool configuration (maximum pool size, timeouts, etc.) is also included in the audit items. Since HikariCP is the default connection pool in Spring Boot 3.x, no separate library replacement is necessary, but the configuration values must be verified as suitable for the production environment.

Q11. Can a frontend-only project receive TQS certification?

Projects containing only a frontend can receive TQS-S/W certification. In this case, only the frontend-related checklist items apply. Backend-related items (Spotless, JaCoCo, jOOQ, Flyway, etc.) are excluded from the audit.

Q12. Can code be modified during the certification audit?

Code in the branch under audit must not be modified while the formal technical audit is in progress. Since verification is performed based on the commit hash submitted with the audit request, code changes during the audit may compromise the consistency of audit results. Code modifications must be made after the audit results are communicated.

Q13. Does a history of security incidents negatively affect certification?

A history of security incidents is not in itself a reason for rejection. However, whether appropriate response measures (root cause analysis, recurrence prevention measures, security configuration reinforcement) were taken after the incident is audited. If the response measures meet TQS standards, certification can be obtained.