はじめに
ソフトウェアテストとレビューに関して個人的に有益だと感じた知見を蓄えていきます。随時追記します。
本記事に記載したことは、「聞いたこと」、「聞いたことの私の解釈」、「聞いて私が思ったこと」などが混在していますので、ご注意ください。
知見
にしさんの講演（2010年くらい）
- テストとは「パネルクイズアタック25」のようなものだ。
- うまくパネルを開け、テスト対象のソフトの状態を見えるようにするのが、テスト。
- 少ない数のパネルで状態を見えるようにする。そのために、開けるパネルを選ぶ行為がポイントになる。
にしさんの研修（2016年）
- Wモデルで大切なのは、テスト要求分析やテスト設計で、作り込み工程の問題が見つかるという実感。問題が見つけられる活動や技術を前倒しで使う。
- テスト観点もレビュー観点も、全部一緒に構造化して、検証活動の戦略を立てる。やる/やらないの判断結果と理由を見えるようにする。
- 整理整頓をする(軸や構造を考える)前に、その対象を全部洗い出しておくべき。
- 同じ工程でもフェーズによって、目的や範囲、対象等が異なるなら、そのことを表現し説明できるようにする必要あり。
- 枯れた技術を組み合わせると、新しいものが生まれるかも。１つの技術じゃ弱くても、3つくらい重ねると強くなる。ある技術の成果を別の技術の入力として活かす。
- テストベース、テスト対象、テスト目的、テスト観点、工程の繋がりが見やすいように、検証戦略を表現したい。
にしさんとのお話（2016年）
※以下は「私が思ったこと」
- 観点は整理整頓する前に、まず全部洗い出す。
- 検証方法や検証環境ごとに、観点をグルーピングする。自動化や委託範囲の検討がしやすくなる。
- バリエーションのテストをする観点を明確にする。バリエーションのテストをしなくてよい部分を作る。
- 当たり前だが、テスト容易性を高める設計をする。
- WBS（作業の構造）だけでなく、QBS（品質の構造）を設計する。
- QC工程表、QFD（品質機能展開）は、ソフトウェア開発でも使いどころがあるかも。
松尾谷徹さんとのお話（2016年）
- 構造の保証は、仕様・設計ベースの動的テスト以外の方法で実施したほうが効果的。構造的な保証をした後に、動的テストを実施する。構造的な保証ができていることで、動的テストの項目が間引きできる。段階的に最適な方法で、保証を積み上げる。
- 構造化設計は、レビューをしやすくするために生まれた。どのような背景・目的で、生まれた技術・技法か知っておくこと大切。
- バグ成長曲線は、ダメな探索(ランダムな探索)をしているときのモデル。
- ループ処理がある機能は、データ構造とデータの状態に焦点を当ててテスト設計。
小川清さんとのお話（2016年）
- 機械化自動化できる作業やその作業に必要なデータを分離する。制約があって、機械化自動化できないと思っていた作業が、一部機械化自動化できるようになる。機械化自動化できる作業の範囲は少しずつ増やす。
- 技法・技術は、全範囲に対して適用する必要はない。適用しやすいところ、効果が高いところを選定して、一部に適用するだけでも、十分。
足立久美さんとのお話（2016）
- ソフトウェアプラットフォーム(部品)の開発者は、変更時に自分の部品内での影響をテストすることはもちろん、部品のユーザー(アプリ)が影響をテストするための情報を渡すべき。
- アプリと部品をくっつけてはじめて価値が生まれる。部品単独ではなく、システム全体の品質を、部品開発者も考える。
- アプリ開発者からしたら、変更された部品だけもらうと、『変更されたことはわかったけど、うちはどこを何を再テストすればいいんだよ！？』となる。
- アプリと部品で、協力して、無駄なく漏れなく、変更の影響を確認できるような仕組みを構築したい。
JaSST'16 Tokai（2016年）
- 欠陥の分析結果は、分析の目的により異なる。
目的が達成できた時点で、分析が止まる。
例えば、以下の目的毎に異なる。- 欠陥の再発防止策を決める(なぜなぜ分析)
- 欠陥を予見するために予兆を明らかにする(欠陥モデリング)
- 再現できない不具合を、再現させることができる力には、大きな価値がある。
ソフトウェア品質シンポジウム（2016年？）
- パネルディスカッションを聞いて思った保証のために重要なこと・もの
- ユースケースの定義
- 発生確率を考慮した設計する
- 評価の重みづけ
- ギブアップする(保証できないことをはっきり説明する)
- 場所を限定すれば(前提を置けば)、網羅性が説明できる
- 人は文字より動くものを見たほうが理解しやすい
- リアルワールドでの確認
森崎修司さんの研修（2017年）
- 製品やサービスの価値を考えることが大切。
- 価値から観点（レビューなど検証活動の観点）をトップダウンで繋げておく。
- 価値と観点を繋げておくことで、各観点の重要度がわかる、検出した各欠陥の重要度がわかる。
- 限られた期間、工数で開発をしなければならない状況において、重要度がわかることは価値がある。
- 複数のイテレーションで完成度を高めながら開発をする場合、リリース毎に求められる価値が違う。求められる価値に合わせて、必要な観点を絞りこめる（不要な観点を捨てられる）とよい。そのために、関係者で価値と観点を共有しておく。
- 価値は教えてもらい理解するものではない。自分で考え作り出すもの。
- 価値を考えるとき、製品・サービスのユーザーの広がり、利用環境・場面の変化、寿命を捉えておくことが必要。
- 価値は、さぁ考えようと言って時間を作って考えるものではない。日々考えるもの。
- レビュー計画立案時に、価値と検出すべき欠陥を特定・共有しておく。レビューは、目の前に見えるものに集中してしまい、ゴールを見失いやすい。
※以下は「私が思ったこと」
- テスト観点を抽出していると、保守性等のレビュー観点は出てきにくい。レビュー観点を抽出していると、テスト観点も出てくる。テスト観点ではなくレビュー観点を抽出し、レビューで検出すべき欠陥とレビュー以外の活動で検出すべき欠陥を分離し、テスト観点が特定されるほうがよいかも。
@kyon_mmさんの勉強会（2017年以前）
- レビューアは、ユーザー、顧客、後工程担当のつもりで確認する
- 指摘は、当たり前品質、一元品質、魅力品質で分類する
※以下は「私が思ったこと」
- レビューアは、自分が開発者のつもりで、自分だったらこう作ると考えて確認していることが多いかも。
清水吉男さんとのお話（2017年）
- 組込みだったら、まずは状態遷移設計を押さえる。
- テストの網羅性は、品質保証ではなく、開発中に担保する。そのために、必要があれば設計を変える。
JaSST'19 Tokai（2019年）
※以下は「私が思ったこと」
- 面白いと思った考え方
- テストすることを合意する だけじゃなくて、テストしないことを合意する。
- やることを提案する だけじゃなくて、やらないことを提案する。
昔家を建てたときに工務店の方から「2階にトイレって本当にいりますか？」「クローゼットの扉って本当に今いりますか？」「食洗機って本当に今いりますか？」等、”いらない”ほうに誘導する質問を受けたことを思い出した。儲からないほうに誘導する不思議な工務店だった。
CEST技術交流会（2020年）
- 機能性は品質特性の一部。非機能の品質特性もある。非機能要求を満たすことを早く検証することが大切。開発期間の終盤に非機能要求を満たさないことが発覚することで、プロジェクトが炎上する事例を見聞きしている。
- ソースコードを修正する行為だけでなく、品質を満たすか不確定なソースコードを検証する行為でも、価値を生み出す。ソースコードの修正を伴う要求を洗い出し優先順を決めるのではなく、確認したい品質（機能はその一部）を洗い出し優先順を決める。機能を積み上げるのではなく、品質を積み上げるという考え方が大切。
- 性能の計測は、必要な機能を全部入れないとできない。早く全部の機能要求を満たした状態を作ること大事。
- 非機能要求に対する計測がしやすい環境を整えておくこと大切。機能を追加したら、すぐに性能の計測ができる状態だとよい。
- 組み込みソフトは、機能要求に対応するフェーズ（試作するフェーズ）と、非機能要求に対応するフェーズ（仕上げるフェーズ）を、明確に分けてしまったほうが、開発がしやすそう。
- 後工程はお客様。前工程は神様。後工程となる量産フェーズの評価が楽になるように、前工程の先行開発で設計する。基本的には、前工程（前フェーズ）が高い立場で、後工程（後フェーズ）が低い立場ということはない。例えば、多くのものを手間をかけて量産し、最終的なコストへの影響が大きい、工場の意見は尊重される。