テストエンジニアの胸騒ぎ
こんにちは、第3バイオリンです。
突然ですが、今とっても忙しいです！
わたしがリーダーを務める案件ではないのですが、依頼されたテスト作業の締め切りが近いのです。しかも、評価部署内で改善活動をしているグループのリーダーが休暇中で、わたしがリーダーに代わってグループの取りまとめをしています。留守を預かる以上、リーダーが戻ってきたときに困ることがあってはいけません。テスト作業の合間を縫ってグループのメンバーに仕事を振っています。
こんな風に仕事に追われて忙しいときにテストをしていると、ふいに胸騒ぎにおそわれることがあります。そんなときに思いついたことをやってみると、かなりの確率で変なバグを見つけてしまいます。
今回は、そんな少し不思議な体験についてお話します。
■これ以上バグが見つかると困る、そんな時
3か月ほど前のことでした。その日わたしは、あるアプリケーションのリリースチェックを行っていました。そこで前回のテストで発見されたバグの修正確認を引き受けました。開発チームのリーダーからは、「障害票に記載されている設定以外にもいろいろ試してみて」と言われました。締め切りまであまり時間がないのが気になりましたが、とにかく修正確認から始めることにしました。
まずは障害票に記載された、バグの再現手順と同じ設定を試してみました。これはきちんと修正されてみました。他にユーザーがやりそうな設定をいくつか試してみましたが、どれも問題ありません。どうやら大丈夫そうだなと思ったその時、ちょっと変わった設定を思いつきました。
いつもなら「わっはっは、こんな設定だれも思いつくまい」とひそかに愉快な気分になったりするものですが……なぜかその時、妙な胸騒ぎがしました。
■使命と本音のはざまで
これはもしかしたらバグを見つけてしまうかもしれない、と直感しました。でも締め切りは間近です。開発チームにしても、再リリースを行う時間はありません。
わたしは迷いました。ここでバグを見つけてしまったら開発チームは大騒ぎ。それに、自分の仕事も増やすことになる。テストエンジニアとしてはあるまじきことですが、一瞬そんな考えが浮かびました。しかしわたしは胸騒ぎを無視してしまうことはできませんでした。もしバグが後から発見されたら、きっと後悔する。そう思い、気になった設定を実行しました。
結果は……クロでした。バグは完全に修正されていなかったのです。すぐにテストリーダーに報告し、開発チームにも伝えられました。しばらくして開発チームから、次回のリリースで対応するという返事がありました。
■便利な能力？
この胸騒ぎが起こるのは決まって、締め切りまで時間がなく、これ以上バグが見つかったらまずいという状況であることがほとんどです。ある種の特殊能力かもしれませんが、正直いって精神的にキツイです。もう少し余裕があるときにこの能力を発揮できるといいんですけれど……火事場の馬鹿力みたいなものでしょうか。
そして今、まさに仕事に追われて余裕がない状況です。今のところ胸騒ぎを感じることはありません。今のところは。
コメント
ひでみ
こんばんわです。コラムニストのひでみです。いつぞやはコメントありがとうございました。
その胸騒ぎな感じ、わかります！
以前、ディスプレイドライバのテストにかりだされたことがあったんですが、これはなんとなく動かなそう、と思いながら試すとかなりな高確率で異常動作を起こしました。
ドライバ屋さんたちと「なんでこんな順序でコマンド出すんだよ」「なんとなく思いついたんですよ」「こんなのテスト項目にないし」「でも、ありえない組み合わせじゃないですよね」「それはそうだけどさぁ」といった会話をしたことを覚えています。
しかもそれを数回繰り返して、「なんでこんなにバグを発掘できるんだよ」と言われ「勘です」と答えたら、「女の勘ってこええ」って言われました（笑）。
ほんとにあの胸騒ぎはなんなんですかねえ。
男連中はなんでもかんでも「女の勘はこわい」で終わらせちゃうんですけど（苦笑）。
第3バイオリン
ひでみさん
こちらこそ、コメントありがとうございます。
>しかもそれを数回繰り返して、「なんでこんなにバグを発掘できるんだよ」と
>言われ「勘です」と答えたら、「女の勘ってこええ」って言われました（笑）。
似たようなエピソードをコラムニストのヨギさんが「女性の直感力が生きるIT分野 －テストエンジニア－」で書いています。
http://el.jibun.atmarkit.co.jp/yogi/2009/02/post-46af.html
（私がコラムニストに応募するきっかけになったコラムでもあります）
たしかに、勘というか「ほんの出来心だったんです～」みたいなノリでやってみたことがバグを見つけ出すことはありますね。
チェックリストに載っているテスト項目は開発が出してきた仕様書をもとにしているので、
すでに開発側の実装テストでたいていのバグは潰されているんですよね。
（潰れていないようであれば品質的に大問題です）
むしろチェックリストから離れて変なことをしてみると思わぬバグを発見してしまうことが多いです。
ということは私の場合、「締め切りまで時間がないけど変なことをするだけの心の余裕はある」という状況が一番バグを発見しやすいのかもしれません。
うーむ、真面目なのか不真面目なのかよくわからない・・・（悩）
saki1208
saki1208と申します。
なかなか便利な?能力ですね。
うちにはテスト専門のエンジニアはおらず、基本的に自分たちで作って、
自分たちでテストします。
私自身は昔からテストが苦手でテストして結果も残ってるはずなのにな
ぜそこにバグがっ!?てのがよくあります。orz
大抵の場合は仰る通り、チェックリストからちょこっと外れたところな
んですけどね。
# 危険な香りのするプロジェクトはほぼ嗅ぎ分けられるんですけどねぇ…
# でも、間違いなくそこにアサインされるので意味がない。
インドリ
それよく分かります。
私もバグに対する嗅覚があり、煙たがられたりします（笑）
この能力はシミュレーション能力だと思います。
私は頭の中でロジックが動き、バグをかぎつける事が出来ます。
ですので、おそらく第3バイオリンさんもその様な能力だと思います。
人間の直感は無から生じるものではなく、経験の積み重ねにより生じるものだそうです。
なので、第3バイオリンさんの経験が胸騒ぎというアラームを鳴らすのだと思います。
アロン
テスト項目の抽出が中途半端なだけですね。
開発者に限らず、対象物に染まっている者ほど無意識に危険な道を通らない作用が働きます。無意識を意識すること、それが答えです。
第3バイオリン
saki1208さん
はじめまして、コメントありがとうございます。
>私自身は昔からテストが苦手でテストして結果も残ってるはずなのになぜそこにバグがっ!?てのがよくあります。orz
>大抵の場合は仰る通り、チェックリストからちょこっと外れたところなんですけどね。
自分で作って自分でテスト、となるとどうしても「ここはきちんと動くはず」
「仕様はこうだからユーザはこう使うはず」という先入観があって見落としをしてしまうことがあると思います。
私も昔は開発をやっていたのでそのへんはよくわかります。
評価部門に移ってはじめてチェックリストを見たときには「こんな使い方する人いないでしょ！？」と驚いたものです。
第3バイオリン
インドリさん
コメントありがとうございます。
>私もバグに対する嗅覚があり、煙たがられたりします（笑）
ありゃりゃ（汗）。
本当は出荷前にバグを見つけたんだからもう少し感謝されてもいいはずなのに・・・テストエンジニアはそういう意味で割りの合わなさを感じる仕事です。
「感謝されるテストエンジニア」への道は遠いです。
>この能力はシミュレーション能力だと思います。
>私は頭の中でロジックが動き、バグをかぎつける事が出来ます。
>ですので、おそらく第3バイオリンさんもその様な能力だと思います。
>人間の直感は無から生じるものではなく、経験の積み重ねにより生じるものだそうです。
私の場合はそんなに計算してやっているつもりはないのですが、
ある程度テスト対象の機能を知らないとこの手の直感はうまく働かないかも、と思っています。
さすがにテスト対象をまったく知らないまま当てずっぽうにやってもバグは出ないと思います。
第3バイオリン
アロンさん
はじめまして、コメントありがとうございます。
>テスト項目の抽出が中途半端なだけですね。
わおっ、痛いところをつかれてしまいました（大汗）。ここは改善の余地があるところです。
>開発者に限らず、対象物に染まっている者ほど無意識に危険な道を通らない作用が働きます。
>無意識を意識すること、それが答えです。
なんだか哲学的ですね。
インドリさんのコメントへのお返事には「ある程度対象物を知らなくてはいけない」と書きましたが、逆に知りすぎると「ここは今までバグ出なかったし」と変なフィルターがかかって見逃しをしてしまうこともあります（恥ずかしながら経験あり）。
たまにですが、新しくアサインされてきたテスターが、ベテランのテスターが今まで気がつかなかったバグを発見することがあります。
対象物に染まっていない分、隠れた道をうまく探し当ててしまうわけですね。
私もいつまでも新鮮な気持ちでいたいものです。
saki1208
saki1208です。
>>テスト項目の抽出が中途半端なだけですね。
>わおっ、痛いところをつかれてしまいました（大汗）。ここは改善の余地があると>ころです。
これは、手厳しい。w
しかし、仰る通りですね。
あずK
> 無意識を意識すること
ちょうど今、勉強しているユング心理学の中で
意識・無意識の話が出てきていたのもあり、思わず納得してしまいました。
ユング心理学のタイプ論という話の中に「直観タイプ」というのがありまして、
それは、「全く別の発想をしやすい、別の可能性を見出しやすい」タイプだそうです。
直観タイプを強く持つ方はテストエンジニアに向いていて、
女性エンジニアは直観タイプが強い方が多いのかなあと思いました。
第3バイオリン
saki1208さん
>しかし、仰る通りですね。
うーむ・・・
テストのチェックリストの作り方については、いつも頭を悩ませているところです。
基本的には仕様書に載っていることを落とすわけですが、
仕様書には載らない非機能（パフォーマンス、使い勝手）をどう落とすかが難しいところです。
余談ですが、開発者の間で「暗黙の了解」になっている仕様がわかっていなくて
うっかり障害票を起票して文句を言われたときにはちょっとキレそうになりました。
そりゃ確認もせずに起票した私も悪かったでしょうが・・・だったら仕様書に書いてほしいです。
一応依頼しましたが、「仕様書に書くほどのことではないから」と断られてしまいました。
今は仕様もわかるようになり、その文句つけた人とも一応はうまくやっているのでいいんですけどね。
第3バイオリン
あずKさん
コメントありがとうございます。
>ちょうど今、勉強しているユング心理学の中で
>意識・無意識の話が出てきていたのもあり、思わず納得してしまいました。
メンタルヘルスのお勉強を続けていらっしゃるのですね。
私も一時期、心の調子を崩したうえ、R.シュトラウス(19世紀末にドイツで活躍した作曲家)の「死と変容」という曲の練習をしていたのでユングやフロイトに興味を持ったことがあります。（実際に本は読みませんでしたが）
まあ、このあたりのことはそのうちコラムに書いてみますよ。
>直観タイプを強く持つ方はテストエンジニアに向いていて、
>女性エンジニアは直観タイプが強い方が多いのかなあと思いました。
私は普段、根拠のないことはあまり信用しない主義なのですが、
このときばかりは信用せざるを得ないと思いますね。
普段は理詰めで対象物に立ち向かっていますが、たまに降って来る直感力も無視できないと思うようになってきました。
saki1208
第3バイオリンさん、おはようございます。
saki1208です。
>開発者の間で「暗黙の了解」になっている仕様がわかっていなくて
>うっかり障害票を起票して文句を言われたときにはちょっとキレそうになりました。
>そりゃ確認もせずに起票した私も悪かったでしょうが・・・だったら仕様書に書いてほしいです。
>一応依頼しましたが、「仕様書に書くほどのことではないから」と断られてしまいました。
まぁ、少し気が利いていれば「共通仕様」、「標準仕様」などの名目で仕様書、チェックリストを作るのです。すべてに共通するもの/画面に共通するもの/帳票に共通するもの/バッチに共通するものとかで。
で、そのプログラムに関係する物をチョイスして個別の仕様書にくっ付けると、「ウマー」でしょうか。
それでも選択漏れがあると結局同じなんですけどね。
saki1208
saki1208です。
ごめんなさい。
業務系システム前提で書いてしまってます。orz
業務系でなければ、括りが違うかもしれないですよね。
経験がないのでどんな括りになるかはわかりませんが...
第3バイオリン
saki1208さん
>業務系でなければ、括りが違うかもしれないですよね。
私の場合は、おもにプリンタドライバとそのインストーラ、自社で作成するバンドルアプリのテストをしています。
>まぁ、少し気が利いていれば「共通仕様」、「標準仕様」などの名目で仕様書、チェックリストを作るのです。
まさにそういうことです。
プリンタドライバというのはプリンタの機種によって微妙に仕様が異なるものですが、機種に依存する仕様というのは細かく仕様書に書くときりがないので開発側も書くのを嫌がるみたいです。
（逆の立場ならやっぱり書きたくないです。元開発者より）
今、チェックリストも機種に依存しない共通仕様と、機種に依存する仕様を
分けて、必要なところだけ組み合わせて使えるようにしている最中です。
ちょっとオブジェクト指向的ですね。