NaITE#18の発表資料です。

1. 提案：QAももっと
実装に踏み込んでみよう
藤沢 耕助

2. 本発表の趣旨
• より実装レベルに近い品質保証に関する話を、
実体験ベースでします
2

3. 問題提起
• システムリプレースの中〜⼤規模SIプロジェク
トのシステムテストレベルで、単体テストレベ
ルの不具合が摘出される
• ⽴場：プロジェクトのQAチーム担当者
error
3

4. 摘出される不具合の例
• アプリのロジックの考慮漏れ
• 業務の詳細な場合分け、例外ケースが漏れる
• （システムリプレースの場合）現⾏システムと
の不整合
• 現⾏システムの動作と異なる動作をする（考
慮漏れ）
4

5. 摘出される不具合の例
• 条件分岐、ループ条件誤り
• 分岐処理やループ処理の条件式に誤りがある
• ログ出⼒などの処理抜け
• 必要な箇所に処理が記述されていない
• 処理の記述の有無が不統⼀
5

6. 摘出される不具合の例
• メッセージIDなどのコード誤り
• 現⾏システムのコード体系をそのまま引き継
いだ結果、不整合となってしまうこともある
6

7. これらの不具合を摘出する
⼯程
• 実装（コードレビュー）
• 単体テスト
• 今回は特に「コードレビュー」でどう取り組む
かについて発表します
7

8. コードレビューではなくテストで
摘出してしまうことによるデメリット
• 不具合の摘出でテストが⽌まる
• たび重なる修正による確認範囲の増加
• コードレビューで単体テスト前に摘出した⽅が良い
のではないか？
8

9. QAが第三者的に
コードレビューを⾏うことについて
• 客観的なレビューができる
• ソースコードレベルからの品質保証が⾏える
• 全量が無理なら、サンプリングで確認する
9

10. 閑話休題
• QAはコードを⾒ない？
• コードを「書く」役割ではないが、「読む」
役割は必要ではないか
• 参考：「tohoku again by seki at ruby.org」
• https://speakerdeck.com/m_seki/
tohoku-again
10

11. QAがコードレビューを
しない理由
• コードレビューがQAの役割と認識していない／されてい
ない
• コードを読めない
• コードレビューの観点に⾃信がない
• 開発者と（⼼理的に）距離がある
• 実際にどう実装しているか、内部のロジックに興味がな
さそうだと思われている
11

12. コードレビューをするために
• 「QAがコードレビューをする」という認識を作る
• コードレビューをします、と宣⾔する
• 使⽤されている⾔語を理解できることをアピール
する
• 最低限、プロジェクトで使われている⾔語は読
めるように学習する
12

13. コードレビューをするために
• コーディング規約に沿ったチェックを⾏う
• コーディング規約に基づくチェックなら、実装に
関する知識がなくても可能
• レビューよりもさらに前に、コーディング規約を
⾒ながら実装するようになるとさらに良い
• 「コーディング規約ではどうなってる？」→コー
ディング規約を⾒る癖をつける
13

14. コードレビューをするために
• 静的解析ツールの導⼊⽀援から始める
• コードレビューよりは「QAの仕事」と認知さ
れやすい
• コーディング規約の⾃動チェックは⽐較的導
⼊しやすい
• チェック内容は開発者とのすり合わせを⾏う
14

15. コードレビューをするために
• 開発者と仲良くなる
• 物理的、⼼理的距離は重要
• ソースコードの修正確認など、コードを参照で
きる機会を有効活⽤する
• ソースコードを⾒ながら質問し、内部のロジッ
クについても理解する
15

16. コードレビューの観点例
• レビューの観点は不具合の傾向分析の結果を反映する
• 業務的に正しい処理になっているか
• 現⾏システムとの整合性が取れているか
• ループ処理や分岐処理における条件式誤りがないか
• ログ出⼒など、必要な処理が抜けていないか
• 出⼒するメッセージIDなどのコードに誤りがないか
16

17. その他気をつけること
• コードレビューとはいえ、はじめに取り掛かる
ことはそこまで技術的なレベルではない
• 観点を設定して客観的にチェックを⾏えば摘出
できるレベルのものも多い
• 必要なレビューアを揃える、出た指摘を横展開
するなどのポイントは他のレビューと同様
17

18. その他気をつけること
• レビュー全般に⾔えることだが、議事録を残す
のが重要
• 他の⼈がどんな指摘を受けているか知る
• 「あの⼈のコードはわかりやすい」という話を
する
18

19. まとめ
• ⼀般に開発プロセスの早期に不具合を摘出した⽅
が修正コストを抑制できることは知られている
• もっとコードレビューなど実装レベルに近い検証
を⾏えるようにすることで、QAとしての活躍の
幅が広がるのではないか
• コードを読むスキルは、そのまま設計書の読み解
き（テスト分析）のスキルにつながる
19

20. ご意⾒募集
• それは違うと思う、そこはこうした⽅がいいな
ど忌憚ないご意⾒をお寄せください
20

21. 参考⽂献
• 【改訂版】組込みソフトウェア開発向け コーディ
ング作法ガイド［C⾔語版］Ver.2.0
• リファクタリング プログラミングの体質改善
テクニック
• 俺のコードのどこが悪い？ コードレビューを
攻略する40のルール
21