こんにちは。ぜにです。
1月から色々ありすぎてすでに混乱気味ですが、今年もブログ更新継続していきます！
今回は、「ソフトウェアテストをカイゼンする50のアイデア」の
「Chapter2 適切なチェックの設計_ 入力と出力を明確に分離しよう」について感想を書いていこうと思います。
※電子書籍を購入しているため、引用に記載されているページ数が実際とずれている場合はご容赦ください。
受け入れ条件を構造化する
経験の浅いチームは、構造化せず情報を統合して受け入れ基準を台なしにすることがよくあるため、実際に何がチェックされているのかが不明確になります。
ソフトウェアテストをカイゼンする50のアイデア (p.110)
よくチームでテスト分析を行うときに、まず受け入れ条件（やデザイン）を眺め、必要そうなテスト観点を書き出します。
頭の中で「テストしなければいけなそう」な仕様、値を見つけてそれをマインドマップのブランチとしてさらにテスト観点を広げていくことをしています。
この章では、その「テストしなければいけなそう」をもう少し体系的に導き出す方法が記載されているのだと捉えました。
得られる利点
受け入れ条件の構造化を行う利点として、本書には下記のような項目が記載されていました。（一部意訳して抜粋）
- 仕様が理解しやすく、テストの完全性の確認が容易になる（抜け漏れの確認がしやすい）
- 構造化することによって条件と結果が明示的になるため、探索的テストや自動テスト化が進めやすくなる
どうやって受け入れ条件を構造化するか
受け入れ条件を「入力」と「出力」に分け、さらにGiven-When-Then で表す例が本書に記載されていました。
- Given (前提条件)：操作を実行する前の状態
- When (操作): 操作
- Then (結果) : 操作した結果
受け入れ条件を入力と出力で分けるところから考えてみた
厄介なシナリオをひもとく最良の方法の1つは、入力と出力を分離することです。
ソフトウェアテストをカイゼンする50のアイデア (p.112)
今回は上のGiven-When-Thenを用いず、入力と出力だけで分けて考えてみます。
架空の美容室予約アプリの受け入れ基準の一部として、「同じ日時に複数の予約しようとするとエラーが返る」があると仮定し、エラーが返る条件の入力/出力について考えてみました。
まず、「同じ日時」という言葉の中に複数の前提条件（入力）があると考え、「日時の重なり方」というブランチを作成しました。
分析の段階では、観点として「日時の重なり方」までで良さそうですが思いつくパターンを記載しました。
また、予約する施設を選択できると仮定して、施設についてのブランチも追加しました。
簡単な例にすぎませんが、一つの受け入れ基準で複数の観点を導き出すことができました。
これまでは、受け入れ条件に対して解像度が低い状態、またはどう整理したら良いか曖昧な状態でレビューやテスト分析を行いがちでしたが、
まず「入力」「出力」にまず分けて考えてみることで、受け入れ条件の解像度が上がるので、テスト分析が始めやすくなりそうだと感じました。
さいごに
前回、今回と「ソフトウェアテストをカイゼンする50のアイデア」の感想文を書きましたので、次回以降は一旦別の書籍について感想文を書いていこうと思います！
今のところ「Agile Testing Condensed」や「LEADING QUALITY」などを考えてます...
全然関係ない余談
最近バッティングセンターにハマって毎週行ってたのですが、何を間違ったのか120kmの球が右手人差し指にぶち当たり負傷してしまいました...🥲
当分バッティングセンターはおやすみになりました⚾️
