nonfunctional-attributes

name	nonfunctional-attributes
description	非機能のうち「正しく・安全に・誰にでも動くか」を性質の充足(違反0件、契約破壊なし等) で確かめる品質保証系の観点を扱う。 test-catalog の手法カタログの一部。セキュリティテスト、ペネトレーションテスト、 DAST/SAST/IAST、SCA(依存脆弱性)、ユーザビリティ、アクセシビリティ(a11y/WCAG)、 クロスブラウザ互換性、i18n/l10n、信頼性(MTBF)、可用性フェイルオーバ、 カオスエンジニアリング、回復性、コントラクトテスト(Consumer-Driven Contract/Pact) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
disable-model-invocation	true

非機能テスト(品質保証系: 安全・到達性・堅牢性)

非機能のうち「正しく・安全に・誰にでも動くか」を確かめる観点を集める。 セキュリティ、a11y、互換、i18n、信頼性、可用性、カオス、コントラクト(互換性維持)など。 測定指標が数値レイテンシでなく「違反0件」「契約破壊なし」のような性質の充足で表れるのがこの群の特徴。

耐障害性(バルクヘッド/レートリミット/サーキットブレーカ)とデータ品質・マイグレーション整合は nonfunctional-resilience.md に分けた。 測定系の非機能(性能、負荷、ストレス、スパイク、ソーク、スケーラビリティ、キャパシティ)は nonfunctional-perf.md。 開発プロセスに組み込む戦術(BDD/ATDD/CI/カナリア)、静的テスト、その他の観点(冪等性/並行性)は process-static.md。

目次

• 品質保証系の非機能テスト(一覧)
• 遂行手順: アクセシビリティ(着手→完了)
• 完了チェック: アクセシビリティ(もれ確認)
• TypeScript example: アクセシビリティ
• コントラクトテスト(互換性維持の運用観点)
• 品質保証系の網羅の定義

品質保証系の非機能テスト(一覧)

ISO/IEC 25010 の信頼性、セキュリティ、使用性、互換性に対応する。

• セキュリティテスト：機密性、完全性、認証認可など、攻撃に対する防御が要件を満たすか検証する。
• ペネトレーションテスト：攻撃者の視点で実際に侵入を試み、悪用可能な脆弱性を発見する。
• DAST/SAST/IAST：DAST は動作中のアプリを外部から、SAST はソースを静的に、IAST は実行時の内部計装で脆弱性を検出する。目的は検出の層を分けて取りこぼしを減らすこと。
• SCA(依存脆弱性)：依存ライブラリの既知脆弱性(CVE)とライセンスを照合する。npm audit などで自前コード以外のリスクを把握する。
• ユーザビリティテスト：実利用者がタスクを達成できるか、操作のつまずきを観察して使いやすさを評価する。
• アクセシビリティテスト(a11y, WCAG)：支援技術の利用者を含め誰もが使えるかを WCAG 基準で検証する。
• 互換性テスト(クロスブラウザ)：複数のブラウザ、OS、デバイスで同等に動作するかを確認する。
• 国際化地域化テスト(i18n/l10n)：多言語、通貨、日付書式、文字方向などで表示と処理が破綻しないか検証する。
• 信頼性テスト(MTBF)：一定期間の故障発生間隔(平均故障間隔)を測り、要求された信頼性水準を満たすか評価する。
• 可用性フェイルオーバテスト：構成要素を意図的に落とし、冗長系へ切り替わってサービスが継続するか確認する。
• カオスエンジニアリング：本番に近い環境で障害を意図的に注入し、システム全体の回復力を実証的に確かめる。
• 回復性テスト(Recovery)：クラッシュや切断のあと、データを失わず正常状態へ復帰できるかを確認する。
• 設置構成テスト(Installation)：インストール、アップグレード、アンインストールが各環境で正しく完了するか検証する。
• 可観測性テスト：ログ、メトリクス、トレースが障害調査に足る情報を出しているかを確認する。
• 疑似ローカライズ(Pseudolocalization)：文字列を機械的に伸長変形し、未翻訳箇所やレイアウト崩れを翻訳前に炙り出す。

この一覧は「広く薄い」で足りる。実際に手を動かす a11y・コントラクト・耐障害性・データ品質には、以下に遂行手順と完了チェック(または不変条件と example)を厚く置く。

遂行手順: アクセシビリティ(着手→完了)

a11y テストの本体は「自動走査で機械的に取れる違反を0件で固定し、自動では取れない観点を手動で補う」ことだ。自動だけで WCAG 準拠は名乗れないが、回帰を止める底面は自動で張る。

1. 準拠レベルを決める：WCAG 2.1 の A / AA / AAA のどれを満たすかを先に決める(多くは AA)。withTags(["wcag2a", "wcag2aa"]) のように走査対象タグへ落とす。
2. 走査対象ページ/状態を列挙する:トップだけでなく、モーダル開閉後・フォーム入力エラー時・ログイン後など、DOM が変わる主要状態を洗い出す。状態ごとに走査しないと、初期表示だけ緑で動的 UI の違反が漏れる。
3. 自動走査で違反0件を固定する:@axe-core/playwright 等で各状態を走査し、violations が空配列であることをアサートする。新規違反が入ったら CI を落とす底面になる。
4. 自動で取れない観点を手動チェックへ回す:キーボードのみで全操作到達できるか(フォーカス順序・トラップ)、スクリーンリーダーで読み上げが意味を成すか、色だけに依存しない情報伝達か、コントラスト比。これらは axe が部分的にしか見ないので、観点リストで人手確認する。
5. 既知の違反を握り潰さない:今すぐ直せない違反を除外する場合は、除外理由と修正期限を残す(恒久的な除外にしない)。

完了チェック: アクセシビリティ(もれ確認)

• 主要状態を走査したか:初期表示だけでなく、モーダル/エラー表示/ログイン後など DOM が変化する状態を走査対象に入れたか。
• 違反0件がアサートされているか:violations を出力するだけでなく空配列で固定し、新規違反で CI が落ちるか。
• キーボード操作を確認したか:マウス無しで全機能に到達・操作できるか(自動走査では取りこぼす)。フォーカストラップやスキップリンクを見たか。
• 色・コントラストを見たか:情報が色だけに依存していないか、コントラスト比が基準を満たすか。
• 除外に理由と期限があるか:走査から除外した違反に、理由と修正期限が残っているか(恒久除外になっていないか)。

TypeScript example: アクセシビリティ

@axe-core/playwright で実ページを走査し、WCAG 違反をゼロ件で固定する。

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("トップページに a11y 違反がない", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});

コントラクトテスト(互換性維持の運用観点)

粒度としてのコントラクトテスト(いつ unit/integration の代わりに契約を固めるか)は levels.md のコントラクトテスト節が扱う。ここでは ISO/IEC 25010 の互換性(相互運用性)を非機能の観点として読み、API 境界の互換性を継続的に壊さないかを運用に組み込む側面を扱う。

概要

サービス間 API の契約を消費側が期待として定義し、提供側 CI でその期待を検証する(Consumer-Driven Contract、実装ツールは Pact)。提供側が独立にデプロイされても、消費側が依存する形を壊していないことを相手を立ち上げずに保証する。

目的/いつ使う

チーム分割やマイクロサービスで提供側が独立に変わるとき、後方互換性の破壊(必須フィールド削除、型変更、ステータス変更)を統合前に検出したいときに使う。単一プロセス内の呼び出しや、めったに変わらない安定 API には過剰(YAGNI)。

TypeScript example

消費側が pact として期待を宣言し、提供側はその pact ファイルを CI で検証する。下は消費側の期待定義(vitest 風の擬似)。

import { PactV3, MatchersV3 } from "@pact-foundation/pact";
import { describe, it, expect } from "vitest";
import { fetchUser } from "./user-client";

const { like } = MatchersV3;

describe("user-client が user-api に期待する契約", () => {
  it("GET /users/:id は id と name を必ず返す", async () => {
    const provider = new PactV3({ consumer: "web", provider: "user-api", dir: "./pacts" });
    provider
      .uponReceiving("a request for user 1")
      .withRequest({ method: "GET", path: "/users/1" })
      // 消費側が依存する必須フィールドを宣言。提供側が消すと検証が落ちる
      .willRespondWith({ status: 200, body: { id: like(1), name: like("alice") } });

    await provider.executeTest(async (mock) => {
      expect((await fetchUser(mock.url, 1)).name).toBe("alice");
    });
  });
});

落とし穴

生成した pact を提供側の CI で検証しなければ、契約はただのモック設定で互換性を何も守らない。like で型だけ緩めると必須フィールドの欠落を見逃すので、互換性の核になる値は具体例で固定する。pact broker でバージョン間の互換マトリクスを継続管理しないと、複数バージョン併存時の互換性が抜ける。

遂行手順(着手→完了)

コントラクトテストの本体は「消費側が実際に依存する形だけを期待として宣言し、提供側 CI でその期待を相手なしに検証し続ける」ことだ。

1. 消費側の依存を全て洗う:消費側コードが叩く全エンドポイント × メソッドと、レスポンスのうち実際に読むフィールドを列挙する。読まないフィールドまで宣言すると過剰結合で脆くなる。
2. 必須フィールドを具体例で固定する:互換性の核(欠けると消費側が壊れる値)は like で型を緩めず、具体値でアサートする。型だけ緩めると必須フィールドの欠落を見逃す。
3. pact を生成する:消費側テストを走らせて pact ファイル(契約)を出力する。この時点ではまだモック設定にすぎない。
4. 提供側 CI に検証を組み込む:生成した pact を提供側の CI で実際に検証する。ここを繋がないと契約は何も守らない(最頻の抜け)。
5. broker でバージョン互換を管理する:pact broker に契約を登録し、運用中の消費側/提供側バージョンの全組合せで互換が緑か(can-i-deploy)を継続確認する。

完了チェック(もれ確認)

• 提供側で実際に検証が回っているか:pact が提供側 CI で verify されているか。消費側で生成しただけ(モック設定のまま)になっていないか。
• 核フィールドを緩めすぎていないか:互換性の核が like の型緩めだけになっていないか。欠落で消費側が壊れる値は具体例で固定したか。
• 併存バージョンを取りこぼしていないか:運用中の全バージョン組で互換確認(can-i-deploy)しているか。最新同士だけ見て旧バージョン併存を見逃していないか。
• 消費側が読む形だけを宣言したか:消費側が実際には使わないフィールドまで契約に含めて過剰結合していないか。

網羅の定義

網羅基準: 消費側が利用する全エンドポイント × 期待レスポンス形(必須フィールド)を pact 化し、提供側 CI の検証が緑、かつ運用中の全バージョン組で互換が確認できたとき。網羅手順は levels.md のコントラクトテスト節と同じ(消費側の呼び出しを全て洗う→必須フィールドを具体例で固定→提供側 CI に組み込む)で、本節はそれを継続実行(CI ゲート + broker)に載せる運用面を足す。達成チェック: 提供側で検証が実際に回っているか、互換性の核フィールドを緩めすぎていないか、併存バージョンの組を取りこぼしていないか。

品質保証系の網羅の定義

非機能は「網羅率」でなく「品質特性 × 基準値」で網羅を定義する。 網羅基準: ISO/IEC 25010 の関係する品質特性ごとに「測定指標 + 合否しきい値」を定め、対象特性をすべて1つ以上のしきい値テストで覆ったとき網羅とみなす。 a11y なら WCAG 違反0件、セキュリティなら検出層(SAST/DAST/IAST/SCA)を分けて取りこぼしを減らす、互換なら対象ブラウザ/OS の組、データ品質なら4不変条件をしきい値にする。 網羅手順:

1. 対象に関係する品質特性を 25010 から選ぶ。
2. 各特性に測定指標としきい値を決める。
3. 各しきい値を超えたら CI を落とすテストにする(「走らせただけ」で終わらせない)。 達成チェック: しきい値の無い計測(走らせただけ)が残っていないか、セキュリティは複数層(静的 + 動的 + 依存)を当てているか。 ユーザビリティなど探索的で人手依存の一部は完全網羅できない。 その場合は観点リストの踏破か被験者数で停止する。

測定系(性能、負荷、ストレス、スパイク、ソーク、容量)の網羅の定義は nonfunctional-perf.md にある。

プロセス、静的、その他の観点は別ファイルへ

開発プロセスに組み込むテスト戦術(BDD/ATDD/CI 自動実行/CI ゲート/カナリア/ブルーグリーン)、実行せず欠陥を見つける静的テスト(静的解析/lint/型/レビュー/複雑度)、分類に収まりにくいその他の観点(冪等性/並行性/ネガティブ/境界外)は、process-static.md にまとめた。