ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方
- 作者:高橋 寿一
- 発売日: 2021/03/17
- メディア: 単行本（ソフトカバー）
「知識ゼロから学ぶソフトウェアテスト」の著者である高橋さんの本です。 「そうそう」「わかるわかる」と頷きながら読み進めて、あっという間に読み切ってしまいました。 私が気になったところと共感できたところを書き出していきます。
上流品質を向上させる
そもそも私は、「上流品質」という言葉、知りませんでした。 個人的には上流/下流工程とかいう響きがあまり好きではないのですが、開発初期でも品質向上を上げる努力をしましょうってことなんですかね。
プロジェクトのしわ寄せは大体コーディングの後のテストフェーズで起こります。 それまでは順調と報告を受けていたプロジェクトもだんだんと暗雲立ち込めてきます。 下手をすると保守フェーズになってもバグが見つかり、システム利用者に迷惑をかけ、信頼貯金がなくなっていく...。
ほんと日本のソフトウェア開発現場はヤバい。
この一言に尽きると思います。わざわざリリース期日に近付いてから手戻りリスクの高い作業をする、というのはリスクヘッジできてない開発組織だと思います。
上流品質を向上させるには
本書では
- 要求仕様の明確化
- クラスや関数構造をシンプルに保つ
- 単体・統合テストの実行
- レビューの実施
を実行すれば良いと書かれています。 当たり前のようにやっている開発組織もあると思いますが、私もこれである程度の品質は担保できると思っています。 間違っても「システムテストをちゃんとやる」みたいなことではないみたいです。
開発初期でもテストをしなければ、多くのバグを後半で潰すことになり、(間に合わない為)納期を優先することで、潰し切れないバグを残してしまうことになります。 バグを0にするのは難しいですが、システムを利用する上で致命的なバグを出さない為にはこの作業をしておいた方が良いと私も思います。
単体テストで大事なのは網羅率でなく期待値の確認
これは本当にそう思います。 テスト対象のメソッド呼び出しで Exception が起きなければ OK としているテストコードのなんと多いことか。 なんかよく分からんけど正常終了している確認にはなりますし、Exception を throw するような振る舞いに変わった時にデグレに気づくことができるので全く意味がないとは言いませんが、「これでテストはバッチリです！」とは言いたくないなぁと思います。
カバレッジはわかりやすいので目標値として設定しやすいですけど、カバレッジ100%だからと言って品質が高いかというと全然そんなことないです。 境界値や状態遷移で起こりうる入力値のパターンを100%網羅し、その期待値を確認する方が高品質に繋がると私も思っています。
最近のシステムは外部サービス呼び出しも多くあって、単体テスト実行のたびに API 叩くわけにも行かないこともあるでしょうから、その辺りの単体テストは mock することが多いのではないでしょうか。 その時の期待値として、「mock を呼び出したこと」だけでなく、「mock の引数に正しく値を渡しているか」も確認する必要があると思っています。 Java で言うと、Mockitoをよく使うのですが、ArgumentCaptor でテスト対象メソッドから mock に渡したパラメータも確認する必要があると言うことです。 外部サービス呼び出しとか RDBMS に永続化処理があるテストは mock に置き換えて引数をチェックするってことをよくやります。
レビューしよう
しましょう。 レビューは「本人が気づくことに重点をおくもの」だそうです。なので、指摘より「なぜこういうふうになっているの？」という問いかけ形式にすると気づきに繋がるようです。理由によってはコメントした人も気付けるかもしれませんしね。
システムテストの自動化
SIer あるあるですけど、システムテストを自動化するのは夢物語だと思っています。 キャプチャー・リプレイの自動化テストなんか...悪夢でしかないです。 仮にうまくいったとしても、スクリプトのメンテナンスコストがバカにならないと思います。 ちょっとの変更でテストが壊れて、それを放置して自動化しなくなる未来が見えます。
やっぱり単体テストで多くのバグを見つけることが重要
重大なバグをシステムテストで見つける方式はリスクしかないです。それですり抜ける奴があったら...大騒ぎになります。 システムテストはやはり今の時点では手動でやるしかなく、それを毎回人の手でやるってのは苦痛です。 単体テストは自動化しやすく、内部的な状態を再現させやすいので、それに対するテストケースの追加が容易にできます。 バグが出てその修正とテストをセットにしておけば、他の修正でデグレが起きても早い段階で気づけます。 デグレ検知の為に毎回手動でシステムテストをやるとしたら...私はその現場から抜けようと思いますね。
あとがき
薄くて高い！
と読者の方に怒られるみたいですが、そういう方はもっと難しそうな文献を私たちにわかりやすく教えて欲しいものです。 ここまでわかりやすく要約してくれる本、そうそうないと思うんですよね。
まとめ
品質を上げるには特効薬はないんですよね。 要求仕様だって具体的に書かなければテストに落とせないし、テストに落とせないってことは開発完了にならないってことです。それだけでリスクです。 開発したそばからテストも書いておけば、レビューの input にもなるし、デグレ検知もできるしカバレッジも見れるしで「進んでる感」を得られます。
自分の経験を押し付けているように受け取る人がいるようですが、私は解決パターンの引き出しとして良書だと思いました。 他人が経験したものを知ることで同じような失敗しなかったり、成功への近道ができるなんて最高じゃないですか。
あと、まだ売っているらしい。(最近は amazon と中古で売ってるのくらいしか見てないな)
