Personal tools
You are here: Home 原稿・資料 ソフトウェア・テストPRESS Vol.9 (2009年10月) 原稿 転身・未経験からのテスト業務
Document Actions

転身・未経験からのテスト業務

花城 泉(HANASHIRO Izumi)

●●●●転身・未経験からのテスト業務

●●●「初めて」から学んだこと

●●はじめに
わたしはまったくの未経験でこの業界に飛び込んでしまいました。
詳しい経緯は省くとして、この章では未知の世界をどうにかこうにか1年間綱渡りしてきた体験談を元に、過去と現在と未来に抱えている問題とその解決法について考察してゆきたいと思います。
むしろ考察というよりは悟ったこと・解ったことのレポートのようなもの、個人的な所感やつぶやきかもしれません。
お茶・コーヒー片手に気楽にお読みくだされば幸いです。どうぞよろしくお付き合い下さい。


●●初心者時代

●運命のふしぎ
さて、"まったくの未経験"と冒頭に書きました。
前職はファストフード店です。無料の笑顔を振りまきつつ、ハンバーガーを作ったりポテトを揚げたりそれらをセットにして売ったりしていました。PCには趣味でそこそこ慣れ親しんではいたもののプログラミング経験は皆無です。「Webデザイナーになりたいな」というだけで職業訓練を受け、上京した当時、ソフトウェア開発に伴うテストに関わることになろうとは想像もしていませんでした。正直今でもふしぎでなりません。

●未知との遭遇
この仕事を始めたとき、一番最初にやらなくてはならなかったことは"聞き取り調査"でした。

<初出勤>(うろ覚えですが記憶の限り…)
1.割り当てられたデスクに案内され、これから使うPCのセッティングをする
2.「これをインストールしてね。」「ここにアクセスしてね。」何に使うのか解らないまま、促されるままに謎のソフトその他をセッティング
3.「朝来たらこれを立ち上げて、こういう操作をしてね。」どうしてそういう操作が必要なのか解らないまま、促されるままに操作
4.「あなたはこれからこの製品のテストに携わります。まずはこれを適当にいじってみて、使いにくいところや気になることを教えてね。」どこをどういじるのか解らないまま、とりあえずでたらめにいじってみる
5.数十分後「どうですか?使用感などは。」ともちろん訊かれるが、使用感以前に使い方が解らない、のでなにをどう説明したらいいかも解らない
…初日はだいたいこんな感じ。

<次の日>
1.「ここを見て、このファイルのテストを行って下さい」
ちんぷんかんぷん。

初日から思っていたのですが、まず開発者には常識であろう用語が、特に横文字がまったく理解できません。そういった解らない用語は書き留めておき、片っ端からWebで検索をかければいいです。
しかし

<テストケースより>
 操作 :ユーザー一覧からユーザーの詳細を表示させ、詳細ツールバーの削除ボタンを押下する

一覧?詳細?その詳細ツールバーとやらはどこをさしているのですか…?といきなり詰まってしまいました。(慣れた今ならどうってことない説明なのですが、当時は悩んだものです。)
もちろんこうなったら誰かに訊くしかないです。
でも開発者の皆さん黙々と仕事してらっしゃるし、お邪魔したら悪いし…、という葛藤と共に実は恐怖もありました。

●なかなか話しかけられない理由
当時は、プログラマは無口で偏屈で頭が良くて頑固で…という偏見に凝り固まっていたので、ちょっと話しかけるだけでも相当勇気を振り絞らなくてはなりませんでした。また、頭の良い人へのコンプレックスなのか、「物を知らないことが恥ずかしく、そんなことも知らないのと笑われるのが怖い」というしょうもないプライドも邪魔をします。
実際質問しようものなら(これは人によりますが)宇宙言語で答えが返ってきたり。しかも何度訊いてもどうしてもその意味が解らなかったり。
必死で聞き取りをした後は、その言語の解析作業をしなくてはならないこともしばしば。
なけなしの推理力を駆使して出した結論(操作やテストケースの意味など)が間違っていることも多々あり、結局はまた質問しに行くことになります。するとだんだんわたしも開き直ってきました。
未経験でよかったのかもと思うことは、完全な一般ユーザーの視点から製品を見られることと、解らないのが当たり前なのでどんな基本的な質問をしても恥ずかしくないことです。うん、恥ずかしくない恥ずかしくない大丈夫、と、自分に言い聞かせているような部分もないわけではなかったですが…。
初心者の強みで「教えてちゃん」でもどんどん交流していけたのは幸運でした。できるだけ自分で調べてからどうしても解らないことを質問する癖もつきました。

●蚊帳の外から輪の中へ
そうして開発者と異文化交流する中で、だんだんと「無口で偏屈で頑固」というわたしの開発者のイメージは払拭されて、恐怖はほどなく消えました。質問しに行くとみなさんとても優しく丁寧に説明してくださいます。例えわたしの理解できない言語だろうと、根気強く教えてくださるので、自分の偏見を恥じました。仕事に対する姿勢もです。よりよい製品をつくるために、みんなやることをやっているだけなのです。そのために必要なことはきちんとシェアしなくてはならないと感じました。
おそらく、異文化が異文化ではなくなってきたのだと思います。


●●新人さん来襲

●慣れてないから解ること、慣れてきて見えるもの
テスト作業に慣れてきた1ヶ月目あたりで、報告した不具合が修正されたのを確認するベリファイ作業をやるようになります。また、リリース前のスモークテストを行ったり、分割して割り振ったりということもやり始めます。
2ヶ月目に突入すると、テストに使用するサーバーの更新なども手順を教わり、テストケースを削除したり足したりという整備、テストを割り振る仕事も任されるようになりました。
そして迎えた3ヶ月目、テストチームにアルバイトの新人さんがやってくることに。
新人さんを迎えるにあたり、自分が苦労した経験から、なるべく解りやすくスムースにテストを実施できるような環境づくりを始めようと思いました。

<問題点>
・テストを初めて行う人への導入プロセスが調っていない
・資料が蓄積されていなかった、もしくはあっても見つけにくく解りにくい
・質問しにくい雰囲気

<解決するためのアプローチ>
・テストする製品に早く慣れてもらう
・誰が見ても操作を間違えようがない、書式などにばらつきのないテストケースづくり
・解らないことがあったら素早くアクセスできる資料集づくり
・それでも解らないことを誰かに気軽に訊きやすい雰囲気づくり

目指したのはこんなところです。

●実践と結果
まず、製品に慣れてもらうためにスモークテストを実施してもらうことにしました。
これは上司のアイディアです。基本操作ばかりを集めたスモークテストに沿って、製品のつくりを覚えてもらおうという狙いです。これは成果を収めました。スモークを終了した後、通常のテストへの移行がとてもスムースになりました。
次にテストケースのばらつきについて。
テストケースは機能を実装した開発者が作成することになっています。あらかじめ「こういう記述をする」「文言を統一する」という決め事がなかったのか、あっても浸透しなかったのかは謎ですが、とにかく開発者によって・ファイルによって書き方が見事にバラバラです。似たような操作なのにまったく違う操作のように感じて戸惑うことも多々ありました。また、テストケース自体の粒度もまちまちでした。
「この機能はこんなに細かく見るのに、あちらの機能はこれだけでいいの?」
…この問題はわたしが来るずっと以前から指摘されていたことだそうで、誰もが認識していて誰もが何とかしなくてはと思っていて誰もが修正できなかったのです。結論から言うと今も修正できていません。ただ、テストを実施しながらちょこちょこと修正するスタイルがテストチーム内に定着しつつあるので、やがては綺麗に粒のそろったテストケースに生まれ変わる…のかもしれません。
資料集づくりは現在進行形で少しずつ充実してきています。
わたしがテストを実施する中で覚えていった、新しく入ってきた人に役立ちそうな、でも誰でも見られる状態になっていない情報。テストに必要なサーバ情報。どのようにテストを進めるか、どのように不具合を報告するか。などなどざっくりとテキストにまとめて社内システム(製品のテストも兼ねています)に置いたことから始まりました。やがてテストチームのメンバーが協力してくれるようになり、資料はぐっと増えました。ただし、増えれば増えるだけ資料の保守などが必要になってくるはずです。これは今後の課題として頭の片隅にとどめておきます。
質問しづらい雰囲気については、これは慣れるしかないだろう、と思います。
慣れてくればどうってことはないので、慣れるまではなるべくお互い(開発者とテスター、テスター同士)に親しんでもらおうと画策しました。これも上司が始めたことですが、テストチームは全員あだ名で呼び合います。"仲間"として打ち解けることで、まずはチーム内で気軽に質問しやすい空気が生まれます。チームの誰かが解っていることならそこで完結するので、開発者の手間を取らせません。また、質問されることによって、実は自分自身もあんまり理解していなかったことに気づけたりして、とても勉強になりました。
全社に向けて「テストチームレポート」を書き始めたのもこの頃です。テストの進捗と日々のちょっとした出来事を書き綴ることで、全社に「こんなメンバーがいますよ」と知ってもらおうとしたのでした。


●●●テストは面白いかい?

●●テストをたのしくする工夫

●テスト以外の仕事
初めてだらけの時、試行錯誤しながら夢中でやるテストは楽しいものでした。知らないことを知るのが面白かったし、不具合を見つけるのは宝探しのようでわくわくしました。
ここまで注記しませんでしたが、この章全体で"テスト"と記述したものはだいたいリグレッションテストを指しています。リグレッションテストは繰り返しのテストです。最初は楽しかったテストも、繰り返すうちにやがて飽きてきてしまいました。飽きるとモチベーションも能率も下がります。そこで、なんらかの気分転換が必要になってきます。
テストを始めて1ヶ月目くらいから、リグレッションテスト以外の仕事もするようになりました。リファレンス修正や不具合の修正の確認(ベリファイと呼んでいます)、Webデザイナー希望だったこともあり製品に使うアイコン制作もやらせてもらいました。飽きっぽい性格を見抜かれていたのでしょうか、早い段階からそんな別な仕事を任せてもらえたので結構モチベーションは維持できていたように思います(ただし当人比)。

●テスターさんたちと分かち合う
そんな経験があるので、テストチームの全員がそんなに飽きっぽいわけではないのですが、テスターさんたちのモチベーションがなるべく下がらないように工夫をしているつもりです。ひたすら長くてつまらなくて根気のいるテストと、気分転換用に短くさらっと気分良くこなせる面白いテストを組み合わせて振ったり、別のいろんな仕事を振ったり。リファレンスの修正やスモークテスト、ベリファイやテストケースの整備、前述した資料集づくりなど。
そうしているうちにだんだんと各自の得意分野・不得意分野が見えてきたりして興味深いです。
例えばわたしは決まった繰り返しのテストよりも自由にバグを探せる探索テストが大好きなのですが、逆にきっちりとテストケースがある方が安心できる人や、むしろテスト自体があんまり好きではなく、リファレンスやドキュメントの整備にやりがいを見出す人など様々です。

●ちょっと無理?でもいけるかも?
気分転換以外にも、テストそのものに目標を設定するのも有効なようです。テストチームレポートに全体のテスト量と終了したテスト量の割合を記述してみたことがありました。
「全体はこれだけあって、今何%終了しています。このペースだと期日までに終了させるのは厳しいかもしれませんが、毎日このくらいのテストをこなせばいけそうです。一緒にがんばりましょう!」
これは効果てきめんでした。だんだんテストに慣れてくるということを差し引いても、ものすごい加速度でテストが片付いてゆきました。
ちょっと厳しいけれどがんばれば手が届く、そのくらいが丁度いい目標なのだなと実感しました。がんばると勢いがついてきて、その勢いのままの流れに乗ることは、宝探しと同じくらいわくわくするたのしいことなのです。


●●テスト管理

●Excelで
テストを割り振るためには全体を把握しておかなくてはなりません。
当時のテストケースはおおまかに製品の機能ごとのテキストファイルにまとまって、専用ディレクトリに置いてあるだけでした(※)。
いつ誰にどのテストを振ってどれくらい終了したか、などを記憶しておく能力がない自分は、とりあえずはExcelファイルに今あるテストのざっくりした情報を記録してゆくことにしました。
テストの統廃合作業なども並行して行い、最終的にテストファイルは150を超えるくらい。これをひとつひとつ確認しながら、テストファイル名、概要、ボリュームと難易度を独断と偏見で付け加えたりして、開始日と終了日と所要時間を書き込みます。
結論としてはこれは6割程度成功しました。
割り振る時点で記録をしてゆけば、まだ実施していないテストファイルが一目で解ります。大体の所要時間を計算し、おおよその見積もりが出しやすくなりました。
自分を褒めたいくらい大成功だ、とそのときは思ったのですが…テストを何度も繰り返すにつれて、問題点が浮き彫りになってきます。

●やっぱりあった落とし穴
まずは、ずぼらで飽きっぽい性格が災いして、だんだんと記録が面倒になりました。割り振るときにはExcelファイルを開いて確認するため、そのときに実施者を書き込むことができますが、終了時には別作業をしていたりして必ずしもファイルを開いていないので記録が後回しになってゆきました。後でまとめて…が2日分になり、1週間分になり、その面倒さにさらに間隔は開き…と負のスパイラルです。
所要時間もいいアイディアと思ったのですが、"実施する人間によってばらつきが出てきてしまう"ことにだんだん気づき始めました。(最初に思い至らなかったのです…。)そうなると、所要時間そのものの正確性がまず揺らぎます。
また、テストは開発期間に合わせて1回通すのが精一杯といった現状も加味し損ねていました。新機能追加や仕様変更があったら、その分のテストを実施しなければなりません。つまり毎回どんどんテストは増えるのに、前回のテストの合計所要時間では正確に見積もれません。
それに「今回やるテスト」「やらなくてもいいテスト」の見極めもできません。機能ごとのテストファイルとなると、そのファイルの中身のテストケースをすべて実施することになります。テストケースをピンポイントで選択して割り振りすることや、不具合の出たケースをピックアップすることが難しいのです。

※…つい最近、はるか昔に同じような狙いで作成したというExcelファイルが発見されました。
しかもまとまっていて見映えも良くて高機能。あの頃にこれを見つけていれば…と脱力しました…。

<学んだこと>
・面倒くさいことはやらなくなる
・所要時間は目安程度に考えておく

<未だ解決策の見つからない課題>
・新機能や仕様変更時の見積もり

●TestLinkはどうだ
「あーめんどくさい!もうExcelはやだ!」
難しい計算式を使っているわけでもない、ごくごくシンプルな管理表でも音をあげてしまったわたしに、上司が「こんなものはどうですか?」と教えてくれたのがTestLinkでした。
TestLink?便利になるのは嬉しいけど、それまでが面倒そう、立ち上げるのが難しそう…と尻込みしているとさらに「メーリングリストで質問してみたらどうですか?」と追い討ちをかけられます。
この頃になってようやく、テストはリグレッションテストだけじゃないということを理解し、"開発におけるテストの種類と役割"がいくつもあると気づき始めました。そしてそれらがまたもやちんぷんかんぷんなことにひるんでもいました。実際、TestLinkの説明や手引きを読んでもなかなか理解できません。
上司の勧めに従ってメーリングリストで質問をしてみたものの(だいぶ噛み砕いて説明してくださったにも関わらず)やっぱりよく解らず、お礼を言うだけで精一杯でした。

●救世主なるか、TestLink
当社では開発部はふたつのチームに分かれています。それに対応するように、実はテストチームもふたつに分かれていました。もうひとつの開発チームとテストチームでもTestLinkを検討し、試し、最終的に導入に踏み切りました。
効能と感想はというと…前の章で佐藤さんが詳しく述べておられます。
導入に便乗してわたしも少しいじってみました。自分で解るところは自分で操作してみて、どうしても解らないことは質問して、先のメーリングリストでいただいたご回答の意味を理解すると同時に「これは最初が面倒でも導入したほうがいいぞ!」という考えに至りました。Excelとにらめっこで計算していた諸々が、ひとめで解るようになるだけでも万々歳です。それに前述したテストケースのばらつきも、移行時に見直すことで体裁など統一できるかもしれない、という期待もあります。
ばらついているゆえにエクスポートなどで一気に移行ができず、テストケース量が多いために膨大な時間がかかりそうなのが大変ですが、今期の開発のリグレッションテストに合わせて導入したいと考えています。


●●●まとめに変えて

●●進歩と堕落は紙一重
人間は飽きる生き物です。少なくともわたしはそうです。
テスターさんは好奇心が旺盛で新しいことが好きな人が向いているように思いますが、裏を返せばそれはとても飽きっぽいのだと言える場合もあるでしょう。飽きた、面倒くさい、そんなときにまたテストをする原動力になるのは、浅く広くでも深く狭くでも「勉強する」「新しい知識と技術を身につける」ことではないでしょうか。
至極当たり前な結論に落ち着いてしまいました。
ただ、新しいものを求めているだけでは従来の「古くてもいいもの」が蔑ろにされる恐れがあります。そこらへんのさじ加減と言いますか、バランス感覚はなかなか身につかないなと痛感しています。
全体を俯瞰する視点と、ひとつのことをじっくり見極める視点の切り替えも難儀だなあと感じます。
わたしはずぼらで面倒くさがりという欠点も併せ持っていますが、これにはいい面もあって、もっとぐうたらものぐさするためにはどうしたらいいか、考えることができます。進歩と見るか堕落と見るかは意見の分かれるところと思いますが、便利な今の時代の根っこにはぐうたら精神が息づいている、と言えないこともなさそうです。
テストをより早く、より正確に、より楽しくするヒントがまだまだそこに隠れている気がしています。


●●結びの蛇足
ここまでお付き合いくださってどうもありがとうございます。
この章を読んで、「なんて酷い会社なんだ」という感想を抱いた方もいらっしゃるかと思います。原稿を見せた上司にもそう指摘されました(笑)。
そのフォローや言い訳というわけではありませんが、いくつか。
わたしが来る前にも、この会社ではちゃんとテストは行われています。
開発者はわたしから見れば「玄人の集団」です。そのノウハウを、足突っ込んだばかりのずぶの素人が一朝一夕で理解できるはずもありません。なので、酷く見える部分はひとえにわたしの経験不足・知識不足から来ていると言っても過言ではありません。それまで会社で普通に行われてきたことを、わたしなりに噛み砕く必要があったというだけです。
最近ようやく「解らないということが解ってきた」のだと思います。「何が解らないのか解らない」状態で闇雲にもがいていたところに、薄く明かりが灯って周囲を見渡せるようになって…途方に暮れるほど奥が深くて膨大なテストの世界に愕然としているところです。
ここまでたどり着くのに1年。
客観的に見て、亀の歩みかもしれません。生き馬の目を抜くような業界で、これでいいのかと自問自答することもあります。
でも、わたしにとっては大切な一歩一歩です。ゆっくりでものろくても成長したのだと思います。そして会社はそれを我慢強く見守り、手助けしてくれました。この会社でテストをやってきて本当によかった。
今後このままテスターとして働くのか、念願のWebデザイナーになるのか、はたまたまったく違う職業に就くのか自分にも解りません。ただ、めぐりあわせに感謝し、今できることを精一杯、与えられた機会を無駄にせず成長するためにたゆまぬ勉強を続けてゆくだけです。
もうちょっとだけスピードアップして。


Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.