第8話 テストエンジニアは最後の砦

スキル

» 2009/08/13

　ソフトウェア開発の最終工程は「テスト（試験）」です。ここをパスすれば、製品またはお客様に納品出来る品質だと一般的にはいわれます。

　ところで、テストエンジニア（以下、TE）って、いつごろ派生したエンジニアなんでしょうか？

　というのは、わたしがエンジニアになったころは、そういう担当？はなかったと記憶しているからです。せいぜい「テスター」と呼ばれる人たちがテスト仕様書を元にチェックするぐらい。初めて聞いたのは組み込みソフトの開発現場からそういう要求があった時かな。今から10数年前です（この話は後から出てきます）。

　テストは、「単体テスト」「結合テスト」「総合テスト」と段階を踏んで実施します。会社によっては多少言葉が違うかもしれませんが（結合テストと総合テストを一緒にしてしているところもあります）だいたいこんな感じでしょうか。

　誰が実施するかも会社によって考え方は異なります。一番多いのは「単体テスト」はPGで、「結合テスト」「総合テスト」はSE主導で、PGや他のグループから少し人を借りてやることが多いようです。組み込み機器はある程度動作してからTEを導入するケースが多い。TEがいても通常PGもテストしていると思います。テストはある意味「責任の担保」なので作った人（主にPG）に責任を持ってもらうという考え方もあるようです。

　ただ、最近はシステムが複雑化しており、例えば携帯電話では機能は増えるわ納期はないわといった事情だと、どうしても予定がずれ込んで、最終工程のテストがおろそかになりがちです。結局、ある程度デバッグできた所からテストしてもらいバグ出ししながら進める方が効率が良くなります。本当はこのような考えは品質保証の点から言うと良くないのですが、第三者（開発担当者以外）にテストしてもらうこと自体は個人的に賛成です。

■本当のテストができないエンジニア

　わたしは、基本的に単体テストの仕様書はPGに、結合テストや総合テストの仕様書はSEに担当させます。最近、レビューして感じるのはテストに対する認識が甘いことです。前にも書きましたが、とにかく「動くこと」が頭の中では最優先なので、テスト仕様書も動くことしか考慮していません。

　ひどい仕様書になると、わたしはそれを見るだけでプログラムの構造が理解できます。そう、あくまでもプログラムに沿って正しい動作の検証しか書かれていないのです。わたしから見れば、そんな仕様書作るだけムダだと考えているので、レビューの時にはかなり厳しく意見します。

　テストの基本は正しい操作で正しく動作することを確認することだけではありません。逆をいえばそれは当たり前の話で、単体テストの段階でデバッグレベルのバグがあっては正直困ります。イレギュラーな状況、例えば不正な入力データ、サーバーの停止、ネットワーク障害、非常識に大きいファイル入力、めちゃめちゃなキー操作……など、挙げればキリがありません。こういう時にシステムがどのように動作するのかを検証するのが、テストの目的だといえます。

　あくまでもユーザーが利用することを前提に、システム（機器）が異常終了やフリーズすることを避けるために行うのであって、間違ってもプログラムが正しく動作することを確認するためではありません。マニュアルに沿って正しく動作することは当たり前です。

■複雑化するシステム、潜在化するバグ

　業務システムは多種多用なミドルウェアが、組み込み機器も汎用的なOSの派生であるWindows MobileやLinux、最近ではiPhoneやAndroid等も出てきてシェア争いを繰り広げています。一昔前（今でもだと思いますが･･･）は組み込みOSはリアルタイムOSとひとくくりで呼ばれていた気がします。今ではWebアプリだろうがデスクトップアプりだろうが組み込み機器だろうが同じような開発環境、同じような手法で開発が可能になっています。

　どのシステムも一昔前のような「シングルタスク」のOSではないので、高速、高機能な反面、プロセスの実行順序（優先順位）やメモリ配置・配分などすべて時々の状況に合わせてOSが調節してくれます。

　これはソフトウェアを作るという意味においては大変ありがたいのですが、逆をいえば、個々のプログラムがどの様に動作するかを決められないと言うことになり、コードの書き方によっては自分達が意図しない動作をします。時には再現性が低いバグもあります。何回か実行するとバグが出るが、その回数も条件もまちまちなケースです。

　最近の携帯電話でも発売直後に不具合が発生することは決してまれではありません。昔は回収しましたが、今は端末が自分自身のファームウェアを書き換える機能を持っているので回収しなくても済みますが、これも複雑化するシステムや機能の副作用だといえます。

■テストエンジニアに向いている人は？

　一般にソフトウェアテスト呼ばれる物は「ホワイトボックステスト」と「ブラックボックステスト」に分類されると思います。わたしは、ホワイトボックステスト（カバレッジ）は、PGが責任を持ってやるべきで、「ブラックボックステスト」はTEが行うものだと考えています（あくまでもわたし個人の考えです）。

　エンジニアは知識と経験をバランス良く積んでいくことが理想だと思います。知識に偏ると頭でっかちなエンジニアになり、応用が利かなくなります。経験だけではアーキテクチャーが古くなり、設計時に支障が出ます。

　しかし、TEは以下の項目については他のエンジニアよりも長けている必要があると思います。逆にプログラミング技術は基本的なものだけ理解していれば良いと思います。

• システム全体を正しく把握できること
• ドキュメントの行間が読めること
• 恣意的にKY（空気読まない）なこと

　例えば、携帯電話で考えてみます。携帯電話の基本的な動作はキャリアによって決められています。電話がメインなのでメールを入力している途中など、着信があればどんな操作よりも着信動作が一番優先になります。メール着信はおそらくその次ぐらいでしょうか。

　プログラム的には割込動作なのですが、テストではそんなもの目に見えないのでTEは「電話の着信は最優先」「メール着信はその次」と考えます。切断（終話）ボタンを押すと必ず待ち受け状態（画面）になり、長押しすると電源オン・オフします。これら全体の動作を把握することがまず第一歩です。PGは機能単位で切り出すので、全体動作（結合・総合テスト）でどうなるのかを考慮しません。逆を言えば、仕様書段階で考慮しなくても良いようにしてあるのが普通です。ですから、他の担当者の機能についてはあまり詳しくない（関知しない）のが普通でしょう。

　通常、マニュアルには正しい操作方法や、してはいけないことが書かれています。仕様書も処理方法やエラーなどが書かれていると思います。TEはここから「暗黙の了解」を読み取ることが必要になります。何故かと言えばユーザーは「マニュアル通りに操作するとは限らない」からです。例えば、携帯電話で、通話の最中に「メニューキー」を押すとどうなるか、切断（終話）キーを押すと通話が終了するが、長押ししたらどうなるかなどはあまり書いていないと思います（実際はキャリアの方でどのように動作させるか決めてある）でも、書いていないからとテストを怠ると、発売後にユーザーが通話中に何気なくメニューキーを押したら電源が落ちた……なんてことになりかねません（あくまでも例です）これがタイトルに書いた「最後の砦」の意味です。不具合が発生してから「やってなかった」ではその砦は何の役にも立ちません。

　本当にKY（空気読めない）では困りますが、テスト中はKY（空気読まない）がベストだと考えています。試験は製造工程とは別のラインで行うのが普通です。納期が迫ってくると現場の雰囲気もピリピリしてきてテストしてても「バグが出ないといいなぁ」と言う感じになってきますが、TEはこういう時こそどんどんバグを発見して欲しいと思います。バグなんてそういう時に出るものですし。バグが出て文句言うエンジニアは文句をいう前にバグを出さないソフトウェアを作るべきであって、バグを発見してもらったらむしろ感謝するべきです。

　先ほども書きましたが、「最後の砦」である以上、妥協も温情も許されません。品質保証のためには厳しすぎるぐらいがちょうど良く、それができないならテストエンジニアは務まりません。リリース後の不具合は「しょうがない」ではなく、人災だと考えるべきです。

■テストエンジニアを育ててみた

　わたしは、コラムの第3話で登場した上司にテストチームを作るからその連中を教育して欲しいといわれたことがあります（いまでもあるかはわかりませんが）。背景は組み込み機器（携帯やカーナビなど）の高機能化と開発期間の短縮があります。また、開発する側としても、ソフトウェアの開発とテスト専属チームによる品質保証で仕事を取りやすいと言ったメリットがあります。当時、この話をもらった時はすでに案件（携帯電話のテスト）があって、嫌でもやらなければならない状態でした。いつものことでしたが……。

　チームは女性ばかり3名で新人から5年程度のエンジニアでした。当然、テスト専属なんて経験はありません……って、わたしにもありませんでしたが。

　取りあえず、経験から方針と納品方法（テストをやった、だけではさすがにお金はくれないでしょうから）を決めました。テストはマニュアルを元にしたブラックボックステストで、ビルド別に最低3回行ないます。（それ以上は別契約）検査項目書（検査仕様書）はデータベース（この時はMicrosoft Access）で作成し、レポート印刷を可能としました。納品物はデータベースファイルと印刷したレポートです。

　わたしはデータベースの作成と検査項目の作り方をメンバーに教え、あとはリーダー予定の女性と2人で打ち合わせに行ったりしてました。あとはレビューなどで指導しました。自分では手探りでしたが、わたしが関わった最初と、その後2回検査を請け負った結果では発売後に不具合が出なかったのでまずは及第点かと思いますが、わたしのキャリアの中で唯一「良かったのだろうか？」と今でも考えることのある案件です。

　ちなみに携帯電話の場合、昔は地域によって会社が分かれていました。この場合「ローミング」があるのですが、社内でテストできないので、車でエリア外まで行ってテストしたこともありました。あと、困るのは「非常電話」です。いわいる「110」や「119」ですが、こればっかりは実際にテスト出来ないので、網シミュレーターを使いました。

■あなたは本物のエンジニアか？

　何回かに分けて今のエンジニアの問題点など書いてみました。PM、SE、PG、TE、他にもまだ役割はありますが、WindowsのクライアントOSですらかなり複雑なものになっており、作るソフトウェアの規模や種類によらず1人でプロジェクトを遂行するのは期間的にも難しくなっています。

　わたしは、エンジニアは自分の与えられた役割の中でベストパフォーマンスを発揮できる人だと考えています。SEだろうがPGだろうが関係ありません。スキルだけでも経験だけでもなく常に全体を考えて欲しいと思います。

　複雑化するシステムの中では大変だと思いますが、みんなが本物のエンジニアを目指せば、きっとデスマーチも失敗プロジェクトも減り、少しはこの業界を目指す人も増えるのではないのでしょうか。若いエンジニアが自由に活躍できる業界になることを期待したいです。

　次からはエンジニアを取り巻く環境をメインに進めようと思います。具体的にはビジネス、経営、職場や雇用、そしてお金です。エンジニアはこれらのことを、あまり自分に関係ないことのように捉えがちですが（フリーの人はそうでもないと思いますが）これからはそうも言ってられない状況になると思います。スキルだけでは生き残れる保証もありません。それにはまず、自分たちの取り巻く環境を知り、考えることから始めましょう。