ソフトウェアテストとレビューに関する知見の記録

# はじめに

ソフトウェアテストとレビューに関して個人的に有益だと感じた知見を蓄えていきます。随時追記します。
本記事に記載したことは、「聞いたこと」、「聞いたことの私の解釈」、「聞いて私が思ったこと」などが混在していますので、ご注意ください。

# 知見
## にしさんの講演（2010年くらい）

* テストとは「パネルクイズアタック25」のようなものだ。
  * うまくパネルを開け、テスト対象のソフトの状態を見えるようにするのが、テスト。
  * 少ない数のパネルで状態を見えるようにする。そのために、開けるパネルを選ぶ行為がポイントになる。

https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%8D%E3%83%AB%E3%82%AF%E3%82%A4%E3%82%BA_%E3%82%A2%E3%82%BF%E3%83%83%E3%82%AF25

## にしさんの研修（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年）
* 機能性は品質特性の一部。非機能の品質特性もある。非機能要求を満たすことを早く検証することが大切。開発期間の終盤に非機能要求を満たさないことが発覚することで、プロジェクトが炎上する事例を見聞きしている。
* ソースコードを修正する行為だけでなく、品質を満たすか不確定なソースコードを検証する行為でも、価値を生み出す。ソースコードの修正を伴う要求を洗い出し優先順を決めるのではなく、確認したい品質（機能はその一部）を洗い出し優先順を決める。機能を積み上げるのではなく、品質を積み上げるという考え方が大切。
* 性能の計測は、必要な機能を全部入れないとできない。早く全部の機能要求を満たした状態を作ること大事。
* 非機能要求に対する計測がしやすい環境を整えておくこと大切。機能を追加したら、すぐに性能の計測ができる状態だとよい。
* 組み込みソフトは、機能要求に対応するフェーズ（試作するフェーズ）と、非機能要求に対応するフェーズ（仕上げるフェーズ）を、明確に分けてしまったほうが、開発がしやすそう。
* 後工程はお客様。前工程は神様。後工程となる量産フェーズの評価が楽になるように、前工程の先行開発で設計する。基本的には、前工程（前フェーズ）が高い立場で、後工程（後フェーズ）が低い立場ということはない。例えば、多くのものを手間をかけて量産し、最終的なコストへの影響が大きい、工場の意見は尊重される。

# 関連記事
https://qiita.com/kazuo_reve/items/157423aff900ac3b9e16

https://qiita.com/kazuo_reve/items/492f3db1fbcff510b14a

https://qiita.com/kazuo_reve/items/50419ce788703746d14a