概要

テストの戦略を考えるのは大変（手抜きしている事が多い）ですし、なんとかしたいけど、どうしたらいいかわからないという時に取れそうな手段について考えてみました。ちなみに、テスト戦略を立て始めるのは早ければ早いほどいいです。つまり、プロジェクトスタート時から考え始めるくらいでもいい。

リスクベースドなテスト戦略

リスクベースドなテスト戦略とは、ざっくりと言うと、いろんなテストのアプローチを考えた上で、リスクの重み付けをして、優先度の高いものからうまく回避するようにテストを組み立てる。という感じです。

これにおいて僕の感覚で大雑把に「最低限テスト戦略で組み込みたいこと」は次の4つです。

出来る人をチームに入れる。
データの明示的、暗黙的変換部分に着目してテストする。
エンドユーザーが苦情を言うシーンをテストする。
システム運用が面倒になるシーンをテストする。

逆に言うと、「なんでたかだかこれくらいのことを考慮しないでテストをやっているんですか？」と叱ることがある4つ。（もちろん、考慮した結果、必要ないと判断する事はよくありますよ。）

最初の1つ以外は順不同です。

出来る人をチームに入れる。

まず初めに考える事は、対象のプロジェクトにおいて最適な知見を持つエンジニアを探す事です。それは開発チームが埋め込みやすいバグを知っている人だったり、対象の技術について詳しい人だったり、エンドユーザーや運用について詳しい人だったり。プロジェクトのメンバーが弱い部分を補える人をチームに入れる事を考えましょう。

入れる事が難しかったら、自分たちでどうやってその部分を補えるか考えましょう。勉強すればいいのか、インタビューする事でスキルが得られるのか、テスト対象外にするか、など。

データの明示的、暗黙的部分に着目してテストする。

テストをするときにはデータの変換に着目するのが一般的です。明示的、暗黙的変換は僕が呼んでいるだけです。それぞれ次のような意味になります。

明示的変換 : アプリケーションのロジックとして認識して実装している変換 (ex. プロダクトコード起因)
暗黙的変換 : ミドルウェアやインフラによって実装している変換 (ex. HTML、RDBにおける文字列のエンコーディング)

暗黙的変換に関しては知らないとテストできないわけですが、逆に言えば「使っている技術をリストアップしてそれぞれで暗黙的変換が行われていないかを机上で確認する」というミーティングを持つだけでもテスト戦略としては有効な場面があります。

エンドユーザーが苦情を言うシーンをテストする。

「エンドユーザーに触ってほしい手順」のようなテストをすることは当然に近い物があるのですが、もっといいのはどういったときに苦情がでるかを考えてテストに組み入れる事です。もし自分たちが使っている似ているソフトウェアがあるなら、どういったときにゲンナリしてちょっと距離を起きたくなるかを考える感じでしょうか。もしくは痛烈にTwitterとかで批判するようなことを書き込むときですかね？

システム運用が面倒になるシーンをテストする。

そのシステムを運用しているときに何をやろうとしたら面倒になるかを考えて、テストに組み入れてみます。例えば、特定ユーザーの処理だけがエラーになってしまうときにログと実際のデータをひもづけた上で正しく修正するための情報と確認をするプロセスを考えて、テストしてみるとかですね。それが出来ないといったことになったら、あとでものすごい時間をかけることになるので。

手離れのよい開発をするためにはどうするか。といった感じでしょうか。

まとめ

いかに早くテスト戦略を立てて実行に移すかは重要だということは認識しているけれど、何から考えていいかわからない場合に考える4つの手段について記しました。リスクベースドで真っ先にでてくるこの4つは人によっては「それってレビューでする事だよね」と思われるかもしれません。まぁそれは状況によりけりなので「そうですねー」とも言えますし「作ってからじゃないとわからないこともありますよねー」もあります。

テストすべき事には「最初に決定可能な事」と「つくりながら決定可能な事」があり、後者3つの手段全てにおいて両方のテストが含まれます。どれくらいかはプロジェクトによるので、そのときの最適解を探すのがメンバーのスキル次第といったところでしょうか。