T.MURACHIの日記: テストの引継ぎ
品質管理というカテゴリは無いのね、そういえば。まぁ、いらんけど(w。
昨日は久しぶりの休日出勤。休日出勤なんて恥だと思っている私は極力休日出勤しなくて済むように仕事は整理しながらこなしてきたつもりなんだけどさすがに今回ばかりはそうも言っていられなくなってしまった。今、自分の周りに、自分自身の仕事のスケジューリングすらまともにできている人が一人もいなくなっている状態。そんな中で、おいらがどこまで仕事を進めておかなきゃいけないものなのかもいまいち見えてこなくて、金曜日の夜遅くになって、いや、それじゃあちょっと困るんですけどなんて話になっても、こっちが困っちゃうよ、ってな感じなわけで。。。
まさにデスマーチですな。。。今の職場ももうダメなのかもしれない。せめて共有型 TODO リストでも作って、全員の仕事の残量でもはっきりさせれば、上の連中も現状の深刻さが把握できるんだろうけど、おいらがそういう環境周りのことで一人わめいて見ても誰もそんなことのために時間も何も割いてくれるなんてことはなかったりするわけで。。。
現在開発が行われているバージョンで、おいらがそれのテスト運用チームに参加するようになったのが、昨年末 11 月ごろからだったかな。それまでおいらはこのバージョンでは GUI 部分だけを作ってくれる下請けが、恐らくは仕事内容の見積もりを目的として作ってくる UC 定義書とか言うムダ文書 (どのくらいムダなのかというと、内容的には 1 ファイルにまとめられていた外部仕様書とまったく同じ内容を無数の Word ファイルに切り分け、しかも操作内容を限定してしまっているために想定外のケースがすっかり抜け落ちた状態となってしまって開発用途にもテスト用途にもちっとも役に立たない上に、これ自体を作ってその内容の正確さのチェックのために物凄い工数を使ってしまったおかげで新バージョン固有の内容の外部仕様書への反映を遅らせてしまっている原因にさえなっちゃっているくらい) のチェックを延々とやっていました。前バージョンで時々ユーザーから報告される不具合のフォローなんかと掛け持ちでね。
そんな、極めてつまらない仕事からの移籍だったので、移った当初は少なくとも今までよりはマシな仕事ができると思ってちょっとだけ嬉しかったのですが、今ではむしろ関わらなければよかったと後悔すら思い始めてみたり。。。他人の作ったプログラムの引継ぎというのも厭なものですが、他人が途中まで運用していたテスト作業の引継ぎは、はっきり言ってそんなものの非ではないくらい厭なものです。
少なくとも、プログラムは読めばわからないことも無いし、動いてくれている部分については直す必要も無いし、上手く動いてないようなら関数ごと書き直しちゃえばいいだけだからね。
テスト作業自体は開発と平行して行われてきたらしいのですが、当初はどういうテストを実施するのかをまとめたもの - いわゆるテスト仕様なるもの - を作っていなかったようで、テストを走らせるためのツール (テストクライアント) と、テスト内容が記述されたスクリプトだけを、思いつく限り延々と作っていたようでした。初期の頃 (作業は 4 月頃から始まっていたはずなのですが、恐らくお盆休みぐらいまで) はテストクライアントの開発そのものにてこずっていたみたいで、実際にどういうテストを走らせるのか、ということにまでは気が回っていなかったようなのです。あの頃おいらは暇チンさんだったんだから、聞いてくれれば少しはこっそり手伝ったのに。。。(そして少し手伝うだけでも状況は相当変わっていたと思う…なんてのは自分を買いかぶりすぎですかね)
私に引き継がれる 1 ヶ月前ぐらいから、テスト部隊を手伝ってくれる派遣さんがお二人ばっかし入ってきた関係で、実際に作るテストの内容を伝える目的でテスト仕様の記述が始まったらしいのですが、それもなんだか、ちょこっと触って見て、あー動いてる動いてる、じゃあこれでいいや、レベルの素人じみた動作チェックをわざわざスクリプトに起こしてオートメーション化させているだけ、といった程度のもので、引継ぎのときにその、仕様とも、単なるメモ書き、コメントの寄せ集めともとれるような、しかもうどんのようにムダに長いテキストファイルを見せられたときには、正直びっくりしてしまいました。何しろ、使うデータの名前すら書いてないんだもん。当然、どう動くのが正しいのか、といった説明もなし。外部仕様書はここにあるから、これを読んでその通りに動いているかどうかチェックしてね、ってのが前提の運用で、しかもその外部仕様も内容が古くて参考にならなかったりして。。。
そんな感じだったので、引き継がれた当初は、あー、こんな程度の品質でいいのか、こりゃあ楽な仕事だなぁなどと高を括っていたのですが(w、その数日後には上司な人と one on one でレビューして叩かれまくって (と、言うよりは、おいらも一緒になってケチつけまくっていたのですがw)、さらには開発者とのレビューでもダメだしされまくって、結局おいらが全体的にもうちょっとマシな状態に品質を引き上げなきゃならないことになって、それに合わせてテストクライアントもいろいろと修正加えなきゃならないことになって、気がつけば作業量はダイナマイト、ダイナマイト、ダイナマイトエクスプロージョンワンスアゲーンな感じになってしまって。。。(壊
こういう話を、化学系の仕事をしているような人にしたりすると、めちゃめちゃ目を丸くさせて驚かれてしまいます。彼らにとって見れば仕事の本番はむしろ品質検査にある、ぐらいのいきおいだったりするわけで。ソフトウェアはバグが混入していても運用でカバーできる場合があるけど、物質の場合は純度が期待値よりも下回れば納品すらできなかったりしますからね。その辺に、品質に対する認識の差異が生じるのかもしれないけど、でも本当はソフトウェアだってそのくらいの意識で品質管理は行なわれるべきなんだと思う。
出だしの作業の進め方がいい加減だと、結局最後までいい加減な仕事で終わってしまうと思う。本当にいい加減な仕事のままで終わってくれればいいけど、おいらみたいに、問題を問題だとわめき散らしてしまう人間は、結局のところ帳尻あわせに遁走してしまうことになるわけで。。。ていうかそもそも今の職場についたのだって、元はといえば他人の仕事の尻拭いからだったんだよねぇ。。。ホント尻拭いばっかりだよおいらの人生・゜・(ノД`)・゜・
そんなわけで、テストは出だしからきっちり運用するべきだし、してもらいたいものです。ロジック的なことを無視して考えるなら、最低でも以下に挙げることぐらいは徹底して欲しいと思う。
- 動作内容の正当性を外部仕様書に頼るな。どう動けば正しいのかはテスト仕様として独自に明記するべき。理想的には入力値、テストデータも限定した方がよいと思う (特に、テスト実施者、自動実行型テストならテスト環境・テストスクリプト作成者が、開発している製品にまつわる専門分野に明るくない場合)。
- キモいケースを徹底的にリストアップする。コアの部分のテストの場合、外側が呼び出し方を間違えるケースについてはテストを省略してもよいかもしれないけど、それこそその場合の切り分けは却って難しくなる。限界値、イレギュラーケースは当然テストすべき。
- 確認事項単位でテストを作れ。 Coverage なんて便利ツールがあると、こいつが高得点をはじき出せば十分、なんて間違った考え方が蔓延してしまうもので、つくづくよろしくないよなぁなんて思ってしまう限りな訳ですが。あれをテストすればこれをテストしたことにもなるから、これは省略、なんてことをやっていると、次第にどこに漏れがあるのか分からなくなってしまいます。「網羅しているつもり」なんてのは、網羅しているとは言いません。どこを見渡しても「仕事しているつもり」な人ばっかりだけどね。
。。。どれも前バージョンのときに既に教訓として得たはずのことばかりだよなぁ。今回一つも徹底されてなかった。。。あーもうやだやだ、平日なんて来なければいいのに。平日じゃなくても仕事には借り出されるわけだけんども。
テストの引継ぎ More ログイン