Self-Assessment Tools

This chapter defines the tools and usage methods that project teams can use to independently verify compliance with TQS standards before requesting a certification audit. It includes an overview of automated verification tools, tool-specific configuration guides, CI integration checks, and comprehensive report generation methods.

---

33.2.1. Automated Verification Tool Overview

The key verification items required for TQS certification can be quantitatively measured using automated tools. The following table summarizes the core tools used for TQS self-assessment and their pass criteria.

Tool	Verification Area	Execution Command	Pass Criteria
Spotless	Java code formatting	mvn spotless:check	0 format violations
ESLint	JS/TS code quality	yarn lint	0 errors
Prettier	Code formatting	yarn format:check	0 format violations
JaCoCo	Backend test coverage	mvn test jacoco:report	Line 80%, Branch 70%
Vitest	Frontend testing	yarn test:coverage	Line 80%, Branch 70%
Lighthouse	Web performance/accessibility	npx lighthouse <URL>	Performance 90, Accessibility 90
OWASP Dependency-Check	Dependency security	mvn dependency-check:check	0 vulnerabilities with CVSS 7.0+

All tools must be executable in a CLI environment and must be configured to run automatically in the CI/CD pipeline.

---

33.2.2. Tool-Specific Configuration Guide

This section describes the installation and basic configuration methods for each tool.

33.2.2.1. Spotless (Backend Code Formatting)

Spotless is integrated into Maven projects through the spotless-maven-plugin. The plugin must be added to the <build> > <plugins> section of pom.xml.

The key configuration items are as follows.

Configuration Item	Value	Description
Formatter	Google Java Format	TQS mandatory formatter
Target scope	src/**/*.java	All Java sources
Exclusion scope	Auto-generated code	jOOQ generated code, etc.

• Format check: mvn spotless:check (build fails on violations)
• Format apply: mvn spotless:apply (auto-fix)

33.2.2.2. ESLint (Frontend Code Quality)

ESLint must be configured using the Flat Config format. Create an eslint.config.js file in the project root.

The key configuration items are as follows.

Configuration Item	Value	Description
Config format	Flat Config	TQS mandatory format
Parser	@typescript-eslint/parser	TypeScript support
Vue plugin	eslint-plugin-vue	Vue 3 SFC linting
TypeScript plugin	@typescript-eslint/eslint-plugin	Type safety rules

• The any type prohibition rule (@typescript-eslint/no-explicit-any) must be set to error.
• Enabling the Vue Composition API enforcement rule is recommended.

33.2.2.3. Prettier (Code Formatting)

Prettier is configured through the .prettierrc file in the project root.

The default configuration values recommended by TQS are as follows.

Configuration Item	Recommended Value	Description
printWidth	100	Maximum line length
tabWidth	2	Indentation size
useTabs	false	Use spaces
semi	true	Use semicolons
singleQuote	true	Use single quotes
trailingComma	all	Use trailing commas

• Format check: yarn format:check or npx prettier --check .
• Format apply: yarn format or npx prettier --write .

33.2.2.4. JaCoCo (Backend Test Coverage)

JaCoCo is integrated into Maven projects through the jacoco-maven-plugin. The plugin must be added to pom.xml and coverage thresholds must be configured.

The TQS mandatory coverage criteria are as follows.

Coverage Type	Minimum Threshold	Notes
Line coverage	80%	Mandatory
Branch coverage	70%	Mandatory

The following targets may be excluded from coverage measurement.

• jOOQ auto-generated code
• Configuration classes (@Configuration)
• DTO and Record classes
• Application entry points containing the main method

33.2.2.5. Vitest (Frontend Testing)

Vitest manages test configuration in vite.config.ts. A separate vitest.config.ts file may also be used.

The key configuration items are as follows.

Configuration Item	Value	Description
Test environment	jsdom or happy-dom	DOM simulation
Coverage provider	v8 or istanbul	Coverage measurement engine
Coverage reporters	text, html, lcov	Report output formats

• Run tests: yarn test
• Measure coverage: yarn test:coverage
• Coverage criteria must meet the same thresholds as the backend: line 80%, branch 70%.

33.2.2.6. Lighthouse (Web Performance/Accessibility)

Lighthouse can be executed through Chrome DevTools or CLI. The CLI method is used in CI environments.

The TQS mandatory score criteria are as follows.

Category	Minimum Score	Notes
Performance	90	Mandatory
Accessibility	90	Mandatory
Best Practices	80	Recommended
SEO	80	Recommended

• CLI installation: npm install -g lighthouse
• Execution: npx lighthouse <URL> --output=json --output-path=./lighthouse-report.json

33.2.2.7. OWASP Dependency-Check (Dependency Security)

OWASP Dependency-Check is integrated into Maven projects through the dependency-check-maven plugin.

The key configuration items are as follows.

Configuration Item	Value	Description
Failure threshold	CVSS 7.0	Build fails when vulnerabilities at or above this score are found
Report format	HTML, JSON	Result report output format
Auto-update	Enabled	Automatic NVD database refresh

• Run scan: mvn dependency-check:check
• The build fails if even one vulnerability with a CVSS score of 7.0 or higher is found.
• Frontend dependencies should be checked separately using yarn audit or npm audit.

---

33.2.3. CI Integration Check

All automated verification tools must be integrated into the CircleCI pipeline to run automatically on every commit.

33.2.3.1. Pipeline Configuration Order

The CI pipeline must execute verification stages in the following order.

Order	Stage	Execution Tool	Behavior on Failure
1	Code format check	Spotless, Prettier	Pipeline abort
2	Lint check	ESLint	Pipeline abort
3	Unit tests	JUnit 5, Vitest	Pipeline abort
4	Coverage verification	JaCoCo, Vitest Coverage	Pipeline abort
5	Build	Maven, Vite	Pipeline abort
6	Security scan	OWASP Dependency-Check	Pipeline abort

Each stage executes only if the previous stage succeeds. When a stage fails, subsequent stages are not executed and the pipeline is immediately aborted.

33.2.3.2. CI Check Checklist

The following items must be verified to ensure CI integration is properly configured.

• Verify that all verification tools execute successfully in the CI environment.
• Verify that the pipeline aborts when verification fails.
• Verify that coverage reports are saved as CI artifacts.
• Verify that security scan results are output as reports.
• Verify that build success/failure notifications are delivered to the team.

---

33.2.4. Comprehensive Report Generation

A TQS self-assessment report must be prepared by consolidating the execution results of each tool. This report is used as reference material when requesting an audit.

33.2.4.1. Report Contents

The comprehensive report must include the following items.

Item	Content	Source
Project information	Project name, version, technology stack	Manual entry
Code format results	Spotless, Prettier execution results	Tool execution logs
Lint results	ESLint execution results, warning/error counts	ESLint report
Backend coverage	Line/branch coverage figures	JaCoCo report
Frontend coverage	Line/branch coverage figures	Vitest report
Performance/accessibility scores	Lighthouse scores by category	Lighthouse report
Security scan results	Number of vulnerabilities, highest CVSS score	OWASP report
CI pipeline status	Recent build success rate, consecutive success count	CircleCI dashboard

33.2.4.2. Report Preparation Standards

• All figures must be extracted directly from tool execution results. Figures must not be manually adjusted.
• The date of report preparation and the execution environment (OS, tool versions) must be specified.
• If there are non-compliant items, a remediation plan and expected completion date must be stated for those items.
• The report is submitted together with the audit request form. Requesting an audit without a report is possible, but attaching a report can shorten the audit period.