テストの段階が名前で並んでいる資料を見ても、違いが分かりませんでした。単体、結合、システム、運用。単語からは規模が違うことしか読み取れない。
分かるようになったのは、それぞれ誰が担当するかを知ってからでした。担当が違うということは、見ている観点が違うということです。
4段階を「確認する対象」で並べる
まず名前ではなく対象で並べます。
単体テストは部品ひとつ。 プログラムを構成する小さな部品を1個ずつ動かし、何かを渡したときに期待した結果が返るかを確かめます。書いた本人が確認する段階です。
結合テストは部品同士のつなぎ目。 組み合わせたときに、渡すはずのものが渡っているか。単体では全部通るのにつなぐと落ちるのは、たいてい渡し方の認識が食い違っているからです。
システムテストはシステム全体。 端から端まで通して、要件どおりに動くか。ここは業務の流れに沿って確認します。
運用テストは業務として使えるか。 実際に使う人が触って、これで仕事が回るかを判断します。ここだけ判断の基準が「仕様どおりか」ではなく「業務が回るか」に変わります。
範囲が広がっていくのと同時に、判断の基準も技術寄りから業務寄りに移っていく。ここが4段階に分かれている理由です。
経費精算のシステムで揃えると、こうなります。単体は金額の計算だけを確かめる。結合は申請が承認者に渡るかを確かめる。システムテストは申請から経理の確認まで通して流す。運用テストは経理の人が実際に月末を回せるか見る。同じ機能を、見る範囲を変えて4回確認しています。
担当が変わる場所が2つある
上の並びで、担当が切り替わる境目が2箇所あります。
1つめが単体と結合の間ではなく、結合とシステムテストの間です。ここまでは作った側が確認しますが、システムテストからは業務を知っている人が入ります。
2つめがシステムテストと運用テストの間。ここで判断する人が、作る側から使う側へ移りきります。
この2箇所の引き継ぎで揉めた現場を何度か見ています。よくあるのが、システムテストの段階で使う側が「そもそもこの流れがおかしい」と言い出すこと。仕様どおりに動いているので開発側は困る。使う側は業務が回らないと言う。
どちらも正しいんです。仕様が業務と合っていなかったという話なので、本当は要件定義に戻る問題でした。
テスト項目は思いつきで書かない
ここが実務でいちばん効く部分です。
テストの各段階には、対応する設計の段階があります。
要件定義 ── システムテスト / 運用テスト
基本設計 ── 結合テスト
詳細設計 ── 単体テスト
設計側の3つを説明しておきます。要件定義は何を作るかを決める工程。基本設計は画面に何が出るか、ボタンを押すと何が起きるかを決める工程。詳細設計はそれをどういう仕組みで実現するかを決める工程です。
上の表の左に書いてあることを、右で確認する。そういう対応関係になっています。
テスト項目は対応する設計文書から作れます。逆に言うと、設計文書に書いていないことはテストできません。
私が見た例で困ったのが、承認の上限金額まわりのテスト項目が「上限を超えた申請が登録できること」だけになっていたケースです。上限を超えたら部長決裁に回るという要件だったのに、そこは項目に入っていなかった。設計に承認者の切り替えが書かれていなかったので、テストを書く人も気づけません。
登録はできるので通ります。通ったのに要件を満たしていないという状態です。
動くことの確認と、正しいことの確認は別です。 前者しか書けていないテスト項目を見たら、対応する設計を疑ってください。
飛ばされやすいのは結合テスト
工程表を見ると、単体とシステムテストはあるのに結合テストが無いことがあります。
理由は分かります。単体で全部通り、システムテストでも通れば、間は要らないように見える。小さいシステムなら省いても回ることがあります。
問題は、落ちたときに原因の切り分けができなくなることです。システムテストで落ちた場合、原因が部品の中なのかつなぎ目なのかが分かりません。単体は通っているので部品は正しいはずですが、組み合わせ方が悪いのか、組み合わせる前提が違うのかは切り分けが要ります。
段階を踏むのは品質のためだと思われがちですが、切り分けを早くするためという面のほうが実務では大きいと感じています。
自動化できる段階とできない段階
テストを自動で回す話が出てきますが、段階によって向き不向きがはっきりしています。
単体テストは自動化に向きます。部品ひとつに何かを渡して結果を見るだけなので、そのまま機械にやらせられます。結合テストも、範囲を決めれば自動化できます。
運用テストにも自動化できる部分はあります。バックアップから戻せるか、障害から復旧できるかといった確認は、むしろ自動で繰り返すべきものです。ただし**「業務として使えるか」という判断そのものは人にしかできません。** ここが残ります。
システムテストは中間で、決まった流れをなぞる部分は自動化できますが、使い勝手の判断は残ります。
つまり下の段ほど自動化しやすく、上の段ほど人の判断が残る。テストを効率化したいときに、まず下から手を付けるのはこの理由です。
自動化そのものの手順は別記事で扱いました。
AIに書かせると量が増える
最近ここが変わりました。
実装をAIに任せると、テストコード(確認作業を機械に代行させる小さなプログラムのこと)も一緒に出てきます。私が自分のツールで記録を取ったときは、以前なら「時間が無いので後回し」にしていた単体テストが、書く手間が下がったことで最初から付くようになりました。
ただし増えたのは下の段だけです。運用テストは相変わらず人が触っています。触る時間は縮みません。
私はこれで一度、配分を読み違えました。単体テストが自動で付くので、テスト全体が軽くなったつもりで工程を引いた。実際には上の段が丸ごと残っていて、後半で足りなくなっています。軽くなったのは4段のうち下2段だけでした。
テストの用語や資格の体系については、JSTQBが日本語で整理しています。
工程表で最初に見る箇所
テストの工程表を渡されたら、私は段階の数を数えます。
4段あれば、どこで落ちたかの切り分けができる設計になっています。2段しかない場合は、抜けている段の確認を誰がいつやるのかを聞く。省くこと自体が悪いのではなく、省いたことを分かって省いているかが知りたいところです。
自分で作る側なら、最初から4段そろえる必要はありません。私は単体と運用の2段から始めています。部品ごとの確認と、業務として回るかの確認。真ん中の2段は、部品の数が増えて切り分けに困り始めてからで間に合います。
工程全体の並びと呼び方は、こちらにまとめました。
