テストリーダへの足がかり,最初の一歩

第9回 テスト実装(後編)

この記事を読むのに必要な時間:およそ 4 分

【今回の登場人物】

大塚先輩:
入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で,暇さえあれば写真を撮りに出かける。

中山君:
入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。

小川君:
入社2年目。新人研修後,その有望さから半年間顧客先に常駐。テスト業務の他,設計作業も経験を積んできた。趣味はベースで,定期的に仲間とライブを行うなど仕事と趣味を両立している。

千秋ちゃん:
入社2年目。小川君の同期で,開発部門所属。今までコーディングと単体テストは経験があるが,システムテストに関わるのは初めての経験。趣味は自分磨き。

前回までの状況

新しくチームに合流した千秋ちゃんに資料を渡し,一言「テストケース作っておいて」といい残し会議室を後にした中山君。作業場所すら指示されなかった千秋ちゃんですが,だまっていてもしょうがないと直前までいた現場で使っていた席に戻り作業を開始しました。

元のプロジェクトの席に戻っている千秋ちゃんを見て心配になった大塚先輩は,メンバに会議室に集まるように指示を出しました。現状を確認するとチームがチームとして成り立っていない状況でした。大塚先輩の指示もあり,チームの建て直しが図られ,ようやくメンバはそれぞれの役目を意識することができました。

その会議のその場で小川君から作業レベルでの問題点や疑問も共有しておこうという提案があり,トレーニングの件もあるのでまずは千秋ちゃんの作ったテストケースを見ていくこととすることになりました。

今回はリーダではなく担当レベルが知っておく事柄も多いですが,復習と思ってついてきてください。

大塚先輩:
ではみんな千秋ちゃんが作成したテストケースを見てほしい。

図1 千秋ちゃんが作成したテストケース

図1 千秋ちゃんが作成したテストケース

千秋の疑問 ~テストケースのフォーマット,ツール

千秋:
えっと,何から言えばいいかしら。そうね。これだわ。
千秋:
テストケースの書き方なんですけど,いまどきExcelで書くなんて古臭くありませんか?
千秋:
最近読んだ本にはテストケースはテストコードとして書くのが普通と書いてありました。
中山君:
えっ,そうなの?
千秋:
それに,こんなのいちいち手で書くの無駄よ。スクリプト書いちゃだめ?
千秋:
どうせツールで実行させるんでしょう。Excelで書いてその後スクリプトで書くなんて無駄じゃない。この程度だったらフリーのツールがどっかに転がってるでしょうし。
小川君:
ダメだよ。コードだと可視性が落ちてしまうから,使いどころを見極める必要があるね。今はその時じゃないよ。
千秋:
可読性? SEだったらコードぐらい読めるでしょう。それに動かしてみなくちゃ,どんな結果がでるのかわからないじゃない。
小川君:
動かしてみて考えるんじゃなくて,事前に期待結果を考えてやらないといけない。
千秋:
設計書に期待結果なんて書いていないじゃない。そんなもの,どうしたらわかるのよ。
中山君:
ちょっと待ってくれ。この案件はシステムテストなんだ。テストの一部分はツール化できるけれども,全部は無理だよ。
千秋:
え~,いちいち手で動かさないといけないわけ?
小川君:
中山先輩,すいません。つい,千秋ちゃんの話に引っ張られてしまって。そうなんだ。システムテストは手で行う部分も多いんだよ。

スクリプトによるテストは見極めを

千秋ちゃんはコンポーネントテストの経験があり,スクリプトでテストを行っていたということですから,推測するにxUnitなどを使ったTDDの手法の経験があったものと思われます。しかし,これから取り組もうとしているのはシステムテストです。そのまま使えるものではありません。

それから,小川君の指摘にもあるように,プログラムコードベースのテストスクリプトはどうしても可読性が落ちてしまいます。そもそもプログラムコードを書ける人じゃないと,作成もできないしメンテナンスもできなくなります。確かにツールを使えば効率は(習熟していれば)上がるでしょうが,メリットデメリットがあることを認識しておくべきです。

プロジェクトで認定されていないツールを使うときは注意

千秋ちゃんはフリーのツールを使えば良いと言いましたが,基本的にはプロジェクトが正式に認定しているツールを利用すべきです。たとえば,そのツールが持っているバグにより正しい結果が得られない場合もあります。また,フリーのツールは基本的に改修の義務もありませんから,報告しても改修してもらえないでしょう。それ以前に「保証がない」ものですから,それを使ったあとのテスト結果は保証がないことになります。

組織によってツールの取り扱い方は変わると思いますが,自分の判断だけでツールの導入をせず,関係者の合意を取り付けるのがリーダとしての振る舞いです。

規定の書式を尊重する

プロジェクトにはたいていの場合,テストケース一覧表のようなドキュメントがあり,規定の書式が存在します。千秋ちゃんはコードで書こうとしたので,このテンプレートから逸脱した書き方をしようとしたことになります。それ自体は必要に生じて行うべきことですが,注意すべきことがあります。この規定の書式に従ったドキュメントは顧客への納品物となることがあります。

今回のケースはシステムテストを案件として取り扱っています。顧客への納品の可能性は高いと言えます。テストケースの表現形式を変える場合にはプロジェクト内の合意をちゃんととっておくことが重要です。

著者プロフィール

鈴木三紀夫(すずき みきお)

1992年,(株)東洋情報システム(現TIS(株))に入社。複数のエンタープライズ系システムの開発に携わり,現在は社内のソフトウェアテストに関するコンサルタントとして活動中。ASTER理事,JaSST実行委員,JSTQB技術委員,SQiPステアリング委員 他。

著書


池田暁(いけだ あきら)

2002年日立通信システム(現日立情報通信エンジニアリング)に入社。設計,ソフトウェア品質保証業務を経て,現在は開発に関する設計/テストツールの導入や,プロセス改善に関する業務に従事。ASTER理事,JaSST実行委員,品質管理学会・ACM正会員。

著書

コメント

コメントの記入