品質管理

品質保証とは、製品が要求事項を満たし、正しく機能することを保証するための一連の取り組みであり、品質の有無を確認する活動だけでなく、品質を生み出すプロセス、基準、活動全般を包含するものです。完成品の検査である品質管理との区別は、単なる用語の違いにとどまりません。品質保証は欠陥の発生を未然に防ぐことを目的としており、品質管理は欠陥の検出を目的としています。

従来の方式では、リリース前に別のチームが完成した成果物を別の段階でテストするという方法が取られますが、これには多くの問題点が指摘されています。欠陥は発生からかなり時間が経ってから発見されるため、状況が忘れ去られ、修正コストが最も高くなります。また、開発とテストの間に時間差があるため、開発者は自身のエラーパターンについてタイムリーなフィードバックを得ることができません。さらに、品質に対する責任は、成果物の作成方法を管理できないグループに委ねられてしまいます。

現代の手法では、責任を集中させるのではなく分散させる。開発者は構築プロセスの一環として自動テストを作成し、コードレビューによって問題が環境に到達する前に発見され、継続的インテグレーションによって変更ごとに検証が実行され、品質スペシャリストはテスト戦略、探索的テスト、および自動化では対応できない領域に注力する。スペシャリストの役割は、検証のすべてを実行するのではなく、検証を可能にし、設計することへと変化する。

テストピラミッドは、自動検証の適切な配分を示しています。基底となるユニットテストは広範囲にわたり、迅速に実行され、障害を正確に特定します。統合テストはより小規模な層で、コンポーネントが連携して動作することを検証します。最上位のエンドツーエンドテストは、実際のシステムにおける完全な動作経路を検証します。これを逆にして、実行に時間がかかり、脆弱なエンドツーエンドテストに大きく依存すると、実行に何時間もかかり、予測不能な障害が発生し、最終的には無視されるようなテストスイートが生成されます。

探索的テストは依然として不可欠であり、自動化を重視する組織ではしばしば過小評価されています。自動テストは、指定された動作が依然として機能することを検証しますが、フローが分かりにくいこと、エラーメッセージが役に立たないこと、誰も想定していなかった組み合わせが意味不明な結果を生み出すこと、あるいは変更によってアサーションではカバーされない形で状況が悪化していることなどを検出することはできません。熟練した手動調査は、テストスイートでは見つけられない種類の問題を発見します。

品質に関する義務は、機能的な正確さだけにとどまりません。アクセシビリティ、現実的な条件下でのパフォーマンス、セキュリティ、ユーザーが実際に使用するデバイスや接続環境での動作、データ処理の正確性など、すべてが品質属性です。機能的な動作のみを検証する組織は、正しく動作する製品を出荷しても、ユーザーの大部分を失望させてしまうことになります。

テストデータ管理は、実務においてどの程度まで実現可能かを左右する、地味ながらも重要な制約事項です。現実的な欠陥を見つけるには現実的なデータが必要ですが、プライバシー保護の義務から本番データを直接使用できないことが多く、また、あまりにもクリーンな合成データは、まさに発見すべき問題を隠してしまう可能性があります。代表的で規格に準拠したテストデータの供給体制を確立することは、通常、単なる細かな事項ではなく、有意義な検証を行うための前提条件となります。

予防策の経済的メリットは十分に確立されている。欠陥の修正コストは、発見が遅れるほど急激に上昇する。開発段階で発見された場合はわずかなコストで済むが、生産段階で発見されると莫大なコストが発生し、運用コストや評判の低下といった損失も伴う。したがって、顧客体験に関する議論とは無関係に、コスト面だけでも早期発見への投資は正当化される。

品質は最終的な結果ではなく、どのように作業が行われたかによって決まるため、実践方法は納品後ではなく納品過程の中に位置づけられる。実際には、これは以下の段階で確立される。 製品開発 完了の定義の一部として、アクセシビリティとエクスペリエンスの基準は以下から抽出されます。 UX監査 基準と性能閾値 Webパフォーマンス 予算を精査し、検証された内容が製品に実際に求められる機能と一致するようにする。