ソフトウェアテスト・QAの小ネタ Advent Calendar 9日目の記事です！（初参加…！）
小ネタということで日頃意識していること、ぼんやり考えていることをゆるく書きます。
前提：周辺環境
- 自社開発 BtoB Web ＆ iOS/Android アプリ
- アジャイル志向開発チーム
- 手動テスト多め・テストメンバーは入れ替わりが多い
やってること
原則リスクベースドで判断する
なんのため？
- 予算や期間の制約上十分なテストはできない前提で市場バグ・障害の可能性を最小にするため
- 開発項目あたりのQA工数やリードタイムを小さくして開発サイクルを早めるため
使いどころ：
- テスト環境：どれくらい実環境に近づけるか、バリエーションの程度
- テスト設計方針：テストの重みづけはどれくらいか、達成したい非機能要件、防ぎたいバグにフォーカス
- テストケースの優先度：先にやるもの、リリース後でも許容なもの
- テスト開始基準：早期着手のリスク（手戻りや見逃し、効率低下など）とリターン（実施と改修期間の確保）
- リグレッションテストの実施範囲：どこまでやるか
- バグの対処：テスト実施と起票どちらが優先か、切り分けや再現条件調査をするべきかなど
「ユーザー価値最大化」「最低限の品質確保」「コスト削減」みたいな相反する軸があって、かつ状況が流動的なときに いつどこで誰が何をするか・しないかを決める判断基準 は原則リスクベースでいいのかなぁと思っています。
このときの「リスク」は「こういうバグを見逃すかも」「このテストは間に合わないかも」とか具体的で小さいものが多いです。
テスト分析/テスト設計は仕様作成と並行してやる
シフトレフトテスティング、W字モデルの鉄板の取り組み。
なんのため？
- 準正常・異常系のパターンを洗い出し、仕様の考慮漏れや実装漏れを防ぎたい
- 機能要件はもちろん、非機能要件（例えば運用操作性や容量満足性など）も識別し、考慮した仕様にすることで後々の手戻りを防ぎたい
- 特殊なテストデータやテスト方法が必要そうな場合、開発に用意してもらう（用意の時間も考慮したスケジュールを立ててもらう）ため
- 単体テストで品質担保可能な部分を開発に責任委譲したい
難しいところ
- 前の開発項目のテスト実施に追われて分析/設計に入れないことがある！
- 仕様変更・追加に応じてテスト側も更新が必要
- 仕様変更・追加をキャッチアップするためにミーティングやチケット更新、チャットをウォッチしておくコストがかかる
- アジャイルの価値観的にそうなるので嫌とかではないが、「作業に集中できない＆作業が終わらない」と困る（残業になるとコスト増になってしまう）のと「その分テストやバグが減ったの？」の推計や可視化ができてないのがハードル。
- 自走力とか積極的なコミュニケーション力とかが必要
「すべての要修正バグを生まれる前に消し去りたい」 んですよ。
わけわからんバグを見つけるとテンション上がる＆ Checking全開のテストは退屈なんですが、バグでユーザーさんが困ったり、やりたかった機能追加ができないのは本当に困る。
色々足りてなくて「やろうとしてる」くらいのステータスなのでもっとつよつよになりたいです…！
やりたいこと
ここからは個人の思いつきレベルの試してみたい工夫です。
過去の類似機能の試験表を新たなテスト設計に活かす
「似たような観点を毎回考えている…」 というチームメンバーの気づきへのTry。
機能一覧と過去の試験表を紐づけておき、テスト設計時は類似機能の試験表から使えそうな観点をコピーする、という単純なアイディアです。
なんのため？
- 資産（過去試験表）活用
- 一部でもコピーできれば時短や漏れ防止・質の安定になるはず
- 無則の観点や外部環境の観点は機能によらず必要なことが多い
- 目的や機能構造が似ている機能の観点群は流用できそう
既存機能の仕様や構造を知っていることが前提にはなりますが、一覧表を作るだけというコスパの良さがあります。
（以前別のプロダクトで観点リストを作成したのですが、汎用化のために観点の抽象度を高めると結局具体化の手間がかかったり、観点リストのメンテが滞ったりしてしまったので省コストな別案という感じです）
有則のテストに無則の因子を入れて圧縮する
有則のテストに無則の因子も入れてテストケース減らす、って個人だとたまにやるんですけど、チームとしてやったらもっと効果出る？というアイディアです。
圧縮後だとレビューしづらいのでそこの対策は必要と思われる。
クラシフィケーションツリーとかで見やすく手軽に作れないかしら…3値以上のデシジョンテーブル型の方がいいかも？
テストケースと手順を分離する
似たような手順が多くてコピー＆ペースト＆モディファイ時にミスる のあるあるですよね！
アレをなくしたい！
アイディア1：既出の手順は書かない
- 冒頭のテストケース（大抵ハッピーパスなど基本的なもの）は普通に書く
- 以降は以下のいずれかの場合のみ書く
- テストケースのグループ（ハイレベルテストケース単位とか）ごとに1件だけ
- 手順が複雑で間違えるリスクがあるテストケース
メリット：
- 試験表の形式が変わらない（大事）
アイディア2：手順を別紙に切り出す
こちらも重複記載は基本的にしない。
- 基本的なユースケース（例：ユーザー登録、編集、削除とか）ごとの手順を書いておき、分からなかったら参照してもらう
- 社内ユーザーマニュアル（簡易版）みたいなイメージ
- 上記で十分と思われるテストケースは手順欄が空欄でもOKとする
- 「手順が複雑で間違えるリスクがあるテストケース」は試験表に手順を書く
- 「別紙の[xx]でooする」とかの補足型 or 手順を全部書いても許容かも
メリット：
- 手順がリッチに書ける
- 太字、色字、画像挿入、表、リンク等使いやすい
- 番号やブクマを使って試験表から直接参照も可能
- オンボーディングのマニュアルとしても使えそう
デメリット：
- 2つのドキュメントを行ったり来たりはつらそう
- 見ないで適当にやる人が増える…？（自分もやりかねない…）
- 短ければ事前に読み合わせするとかで対策できそう
とりあえずアイディア1を試すのが無難そう…？
おしまい！
ここまで読んでいただきありがとうございました！ひとつでも「へー」というものがあれば嬉しいです。
「やりたい」のところは実現できるように頑張ります…！
それでは皆様も良いテストライフを！🎄