MYレビュー観点 #QA

はじめに

業務で第三者レビューアとして色々なドキュメントをレビューさせていただいております。
その際に私が特に気をつけて見ているところを挙げたいと思います。

まずはどの工程のドキュメントについても気にしていることです。

まぁ、普通ですね。
ここらへんは、レビュー前に作成者ご自身でチェックして解決しておいて欲しいところです。

次に設計です。

No.	観点	ポイント
1	入出力先が明記されている	影響確認をするために必須
2	条件に該当しない場合の結果が明確になっている	ELSEの場合の処理が明確になってないと意図しない動きをする場合がある
3	変数やテーブルを使用する場合、初期化を考慮している	変数のクリア漏れなどあるあるです
4	論理名、物理名が記載されているか	どちらかしか記載されていない場合、正しく伝わらない場合がある
5	記載内容が処理単位でまとめられている	共通処理なのか個別処理なのかなど正しく伝わらない場合がある

設計に関しては、システム特有のルール等や癖？もあると思いますので、できれば有識者の確認をしてもらったほうが良いと思います。

さ、ついにテストに入ります。

No.	観点	ポイント
1	改修前後の比較をする場合、確認する項目や観点が明記されている	実際は更新日など差異が出ることが多い。差異が出てもいい項目はテスト設計時に明確にしておかないとテスターが混乱する
2	何のためのテストなのか明記されている	例えば「フラグ確認」だけなど、何（処理のどの部分）を担保するテストなのかわからない記載は避けるべき。テスト漏れにつながる
3	テスト環境が明記されている	本番環境とかけ離れた環境でテストを行っても意味がなかったり、明記されていないと環境が原因の不具合に気づけなかったりする
4	テスト実施の条件が明記されている	条件が明記されていないとテスターが間違った条件でテストを実施してしまう可能性がある
5	テスト実施の手順が明記されている	手順が明記されていないとテスターが間違った手順でテストを実施してしまう可能性がある
6	テスト実施の期待値が明記されている	例えば「正常に終了すること」だけでは、何をもって正常に終了したのか判断できない場合や間違った判断をしてしまう可能性がある

よし、テスト実施が終わった！
と油断しないでください。ただ実行しただけではダメです。
きちんとエビデンスを残しましょう。

No.	観点	ポイント
1	テストの終了条件を満たしている	たまにテストやり忘れてる人もいます・・・
2	エビデンスの不足がないか	テストの実施はしたがエビデンスは取ってない人もいます・・・
3	エビデンスのどこを確認して結果を判断したのかわかるようになっている	ただ画像を貼り付けてるだけだとわかりません（それでOKの場合はOKですが）

以上が私がレビュー時に見ている観点でした。
あくまで一例ですので、参画しているプロジェクトや対象のシステムによっては異なってくる部分もあるかと思います。

レビューアの人に参考にしてもらえると嬉しいですが、個人的にはレビューイの方に気にしていただいて貰えた方がレビューアとしても指摘が少なくなって楽になるので嬉しいなと。