適当に操作しているようにしか見えません

やみくもテストはテストじゃない！

先輩の仕事を背中越しに見ると、単に手を動かしているだけのように見えます。頭を使った作業には見えません。先輩からも「適当に動かしてバグを探しておいてよ」という指示が出ているかもしれません。

頭を使わずやみくもに手を動かすテストが必要な局面というのはあります。しかし、新人でその局面に遭遇するケースというのはあまり無いでしょう。やみくもなテストではなく、やらなくてはいけないテストを任されることが多いはずです。

第2回は、この「やみくもなテスト」の問題点と「やるべきテスト」との違いを説明します。

やみくもなテストとやるべきテストの違い

テストの経験がないA君には、先輩のやっているテストが適当に操作しているだけにしか見えませんでした。ところが、先輩は決して『適当に』テストしているわけではありません。A君が言うような、やみくもなテストを行っているのではないのです。

では、《やみくもなテスト》と《ちゃんとしたテスト》は何が違うのでしょうか？

やみくもなテストの問題点

具体的にやみくもなテストの問題点を考えてみましょう。主な問題点を3つほど挙げます。

1. バグが見つかるかどうかは運まかせ
2. 記録を残さない
3. 時間が来たらそこで終了

1．バグが見つかるかどうかは運まかせ

狙いやあたりをつけてテストをするわけではありませんから、言ってみればバグが見つけられるかどうかは運まかせということになります。強運な人がいればいいのですが、現実はそうではないので…。

2．記録を残さない

やみくもなテストでは、テストについての記録が行われません。どんなテストを実施したのか、そのときどんな操作をしたのか一切書き残しません。これでは、先輩に対してすら適切な報告ができません。また、バグを発見したときに、どのような操作を行ったかが記録されていませんので、再現手順を見つけ出すのに苦労します。

3．時間が来たらそこで終了

テストがどれだけ十分に実行されたのか、わかるはずもありません。十分なテストを実施したのかどうかの判断基準がありません。どこまでテストすべきかが明確でないということです。そのため、いつテストを終わればよいのか判断できません。したがって、「⁠定時時間が来たら終了」など、なんの根拠もないテスト終了判断となりがちです。新人さんの場合、先輩から「どう？」と声をかけられるまで、ダラダラとテストをしがちになります。

いかがでしょうか？

ベテランの方はもちろん、新人の方も「あちゃー、こりゃダメだよ」という感想を持ったのではないかと思います。自分に部下がいたとして、このようにテストを行っていたとしたら、きっと「ちゃんと頭使わないとダメだよ」と指導するのではないでしょうか？

やるべきテストには目的や狙いがある

やみくもテストとやるべきテスト。この2つのテストの決定的な違いは、テストそのものに明確な目的があるかどうかです。

やみくもなテストは「テストを行う」という漠然とした目的はあるかもしれません。しかし、それ以上の目的を見いだせないことがほとんどです。

やるべきテストは、たとえば「マニュアルの操作どおりに画面が遷移するか確認する」とか「サーバに負荷をかけても大丈夫か確認する」といったような目的があります。

A君は、M先輩から数枚の仕様書を渡されました。ということは、少なくともその仕様書に書かれていることを、なんらかの目的や狙いに沿って、テストする必要があるわけです。そして、その目的や狙いに沿ってテストを行うためには、さまざまな検討や資料の作成が必要となってきます。

つまり、やるべきテストは「明確な目的が存在し、その目的を達成するための事前準備や記録、報告がある」ということです。

宝探しに例えると

テストの大きな目的のひとつは「バグを発見すること」です。これは例えるならば『宝探し』と似ています。

やみくもなテストとは、地図も持たず道具も何も持たず、宝が何であるかも考えることなしに、いきなり宝探しに出かけてみるようなものです。そうそう見つかるわけがありませんし、宝を見つけたとしても、宝を宝と認識できずに見逃してしまうかもしれません。

宝探しを行うにあたって、事前準備や記録、報告といった作業をしっかり行うとどうなるでしょうか。きっと、宝を発見できる確率が向上し、また、効率的な探索が行えることでしょう。

やるべきテストとは、宝を探す前に、地図とコンパスを用意し、発掘するのに必要な機材と要員を手配し、必要ならば書類を役所に提出するというようなものです。宝を探すという直接的な作業の前に、手間のかかる作業がたくさんあるのです。

準備や記録、これらは手間がかかる大変な作業です。また、これらをきちんと効率的に行うために、テスト手法や技法、管理技術といったものが存在し、活用する必要があります。なにも考えず場当たり的にソフトを操作するだけのテストと比べると、面倒なことだらけです。

しかし、どちらの方法ができるかぎり効果的・効率的にバグを発見するという目的を達成するかは、自ずと分かると思います。

やみくもなテストから脱出するためには

やみくもなテストの問題点を説明しましたが、では、このやみくも状態からどうやって抜け出せばいいでしょうか？

新人の方は、まずは次の点をしっかりと抑えましょう。

テストの目的を定義する

今から行うテストは何のために行うのか、その目的を定義しましょう。その目的や狙い、戦略については自分でわからなければ、指示を出してくれた先輩に確実に確認しましょう。その確認は口頭で済ませてしまってはいけません。必ず何らかの文書として作成し、先輩に確認してもらいましょう。

テスト対象を定義する

プログラム、ソフトウェア、システム（ソフト＆ハード）など、どれをテストするのかによって、テストは変わります。また、外部とのインターフェイスも考慮すべきかどうかによっても変わります。テストを実施する前に、「⁠何を」テストするのか確認しましょう。

使用するテスト技術をリストアップする

テストする目的や対象によって、使うべきテスト技術は異なります。どのような技術を使うのかをリストアップします。どんな技術があるのか、何を使えば良いのか分からない場合は、恥ずかしがらずに先輩に聞きましょう。もし、「⁠知っている」のであれば、自分の理解で正しいかどうかを確認します。

テストに使えるリソースを確認する

テストのリソースには、代表的なものに「人、物、時間」があります。「⁠誰が、何を使って、どれだけの時間でテストを行う」という一文を書くだけでも、テストの計画を立てるための大切な情報となります。どんな形であれ計画をたてた時点でやみくもではなくなります。

テストの終了基準を決める

新人さんは特に忘れがちですが、テストの終了基準を決めておかなかったばっかりに、いつまでたってもテストを終了できないということがおきます。この基準には、テストケースを100項目実行するとか、致命的なバグが見つかったらその時点で終了とか、様々なものが考えられます。 もし、これらのような基準がない場合でも、最低5時間行う、といった終了基準だけでも決めておくべきです。

この他にもポイントはありますが、まずはこれらをしっかりと抑えるところから始めましょう。これらを押さえるだけでも、やみくも状態からかなり脱出することができます。

また、テストがやみくもでなくなるだけでなく、自分の作業も明確になり、仕事としてきちんと計画だてることができます。

終わりに

やみくもなテストとやるべきテストの基本的な違いを解説しました。この時点で、「⁠テストは事前準備から含めてたくさんの作業がある」ということが認識できれば、ひとつレベルが上がっています。与えられた仕事をこなしているだけでは、あまり成長は望めません。ひとつ上の技術者を目指すのであれば、準備を怠ってはいけません。

次回以降はやるべきテストにおける、テストの実行までの事前準備について解説を行います。