1. はじめに
先日書いた「思考実験：AQUAフレームワークの品質保証兵站への応用」では品質や品質保証そのものにあまり触れていなかったので日ごろ考えていることをメモがてら書いてみます。
2. 品質
「品質」でググるとわかるようにいろいろな人がいろいろな定義をしていてSQuBOK Guide(ソフトウェア品質知識体系ガイド)ではアリストテレスまでさかのぼってさまざまな品質の定義を紹介しています。ソフトウェアエンジニアでSQuBOKを読んだことのない方は読まれることをお勧めします。
品質には多面性があり唯一の正解というものはないのですが筆者はワインバーグの「品質とは誰かにとっての価値である1」というのが好きです。
お金を出して商品を買ってくれたユーザや無料版を無料で使用しているユーザと比べると「誰か」というのはとっても広いですね。でも商品を買う前のまだユーザになっていない段階でレビューを見て良さそうだとかイマイチっぽいとか、品質、つまるところ対価を払って得られる価値が購入するという行為の判断材料の一つになっていることは誰しも経験があるかと思います。そして、何に価値を感じるかは人それぞれでもあります。
3. 品質が良いとは
「品質が良い」というのは以下の2つにブレークダウンできます。
- 価値がある、優れている
- 価値を損ねるものがない、少ない
ソフトウェアの品質が良いというとバグゼロやバグが少ないことを思い浮かべるかもしれませんが価値があること、優れていることも大事です。
4. 品質保証
品質保証はQA、Quality Assuranceとも呼ばれます。保証を意味する英語としてはassuranceのほかにwarranteeやguaranteeもありますが以下のassuranceの解説を読んでなるほどこれが品質保証、QAかと納得しました。
製品が品質基準に合致しているかを、設計・試作・製造・検査の全ての工程で確認する仕組みがあり、それを実行していることを保証する
出典：Limited warranty - 英借文ドットコム
ソフトウェアには製造工程がないため筆者は以下のようにアレンジしています。
製品が品質基準に合致しているかを、仕様設計・実装・テストの全ての工程で確認する仕組みがあり、それを実行していることを保証する
ここで「全ての工程」とあるように品質保証は全工程、全員参加の取り組みであり品質保証の担当者だけで行うものではありません。
4.1 品質基準
品質を満たしていること(価値を備えていることや、価値を損ねるものが少ないこと)を判断するためのさまざまな目標、基準があります。
- 品質にはお客様視点、設計視点、テスト視点、経営視点などがある
- 品質モデルとして例えばISO25000や狩野モデルがある
- 基準の作り方の一つにGQM(Goal, Question, Metric)がある
- ソフトウェアの品質には定量化の難しいものもある
4.2 工程
仕様設計の工程、プログラム実装の工程、テストの工程をいわゆるV字モデルで配置し、併せてそれぞれのスコープの一例を枠線で図示します。V字の左側で価値を作り右側で価値を損ねるものを除去します。3章で述べたようにソフトウェアの品質にとって左側、右側の両方とも大事な工程です。
4.3 確認する仕組み
確認する仕組みの例を以下に示します。
| 工程 | 例 |
|---|---|
| 仕様設計 | ・成果物のレビュー |
| 実装 | ・成果物のレビュー ・静的解析 ・動的解析 ・単体テスト |
| テスト | ・テスト内容(なにを)のレビュー ・テスト方法(どうやって)のレビュー ・テスト対象のチェックとテスト(結合テスト、システムテスト、受入れテスト) |
このほかにも例えばWindows Insider Programのプレビュー版やmacOSのパブリックベータ版といった正式リリース前のビルドを有志の方々にテストしてもらい価値の確認や不具合の検出を行う方法もあります。
4.4 実行
例えば不具合を見つけたら不具合票を起票し修正を行って再テストしてクローズしたり、出荷判定の判定会を開催して議事録を残したり、品質基準をクリアするよう日々さまざまな取り組みを実行します。
4.5 保証する
保証するにはその裏付け(エビデンス)が必要です。
設計部門と品質保証部門で組織が分かれている場合は品質保証部門が設計部門にエビデンスのデータを要求します。一方、設計部門に品質保証の機能を備える場合は設計担当、品証担当の誰もが生データ含めこれらのデータにアクセスでき、エビデンスを集めるのは品証担当が行います。
エビデンスを集約、整理し、しかるべき立場の人がリリース可能と判定すると晴れてリリースとなります。
5. SQAの役割
JaSST'17 Tokyoの招待講演で講師の奈良さんが「QAの役割はQMSを回すこと2」と説明されていたのがシンプルかつ深みがあり筆者は好きです。
QMSを回すとはプロセス警察(エビデンスを要求したりプロセス通りに実行しているかを監視する)のことではなく、価値を最大化し価値を損ねるものを最小化するためにソフトウェア開発の全工程に対してよりよく回るようにしたりうまく回っていないところにテコ入れすることといったほうがしっくりくると思います。
5.1 SQAのスコープ
前出のV字モデルにSQAのスコープをピンクの枠線で図示したものを以下に示します。見ての通りSQAのスコープはソフトウェア開発の全工程です。
5.2 SQAの活動
SQA担当の主な活動を以下に例示します。仕様設計担当、実装担当、テスト担当は主に目先のプロダクトにフォーカスしているのに対してSQA担当は目先だけでなく将来に備えた活動も行います。なお、レベルや粒度はばらばらで必ずしも筆者が行っているものとは限りません。
- 品質保証戦略の立案、見直し
- 品質のモニタリングとコントロール
- メトリクスの決定、見直し
- メトリクス集計技術の開発
- メトリクス集計
- プロダクト品質
- プロセス品質
- メトリクスに基づいたコントロール
- QMSの改善
- できていることをよりよくできるようにする(強みの強化)
- できていないことの阻害要因を除去する(弱みの克服)
- 品質保証技術の開発
- デバッグをやりやすい環境の構築
- 不具合摘出のフロントローディング
- ツールの内製
- ツールの試食、導入
- テックシェルフ(知識、ノウハウの蓄積と展開)
- 不具合管理
- 再発防止、未然防止
- 品質の評価(品質保証レベルのテスト)
- 品質保証活動のリソース計画と執行
このほか仕様設計、実装、テストで手薄なところのテコ入れとして以下のようなタスクを行うことがあります。
- レビュー
- デバッグのヘルプ(不具合の再現手順を探したり)
- テスト、修正された不具合の再テスト
5.3 SQA＝テスト？
SQAはテストをすることもありますがそれは上で挙げたように役割の一部でありSQA担当でテストされている方は以下のいずれかと思います。
- 品質保証レベルのテストを行っている
- いろいろなSQAのタスクを片っ端から自動化して捻出した工数をテストに充てている
- SQAチームの層が厚くてメンバーをテストにアサインできる
- テストすることをSQAと呼んでいる
5.4 参考書、資料など
5.4.1 書籍
前出のSQuBOK Guide(ソフトウェア品質知識体系ガイド)のほか、アマゾンで"ソフトウェア品質"で検索したり、「よく一緒に購入されている商品」「この商品をチェックした人はこんな商品もチェックしています」をたどるといろいろ見つかります。
また、コミックマーケットや技術書典などの同人誌即売会でソフトウェアテストやソフトウェア品質保証を扱っている同人誌が頒布されることがあります。
5.4.2 Web
Web上にもさまざまな資料がありますがここでは2018年9月～10月にかけてASTER(NPO法人ソフトウェアテスト技術振興協会)からリリースされたテストおよびテスト設計の資料を以下に示します。
- ASTER 技術セミナー:「ASTERセミナー標準テキスト」公開について
- テスト設計コンテスト'19 - U-30クラス チュートリアル
- テスト設計コンテスト'19 - OPENクラス チュートリアル
5.4.3 シンポジウム、カンファレンス
ソフトウェアテストやソフトウェア品質を冠した国内のシンポジウムとして以下の2つがあります。
上記のほかさまざまなシンポジウムやカンファレンス、勉強会などがあり貴重なナレッジを公開されている方々には感謝しかありません。
6. おわりに
こうして眺めてみるとSQAの活動は多岐にわたることがわかります。
なお、プロダクトやプロジェクト、SQAの規模、成熟度、優先することなどは各社各様で、優先度をつけてやることを絞ったりここに挙げていないこともやったりなど活動内容や活動方法は現場ごとにさまざまと思います。ここに書かれていることが必ずしも皆さんの環境に当てはまるとは限りませんが何かの参考になれば幸いです。