はじめに言葉ありき――テストエンジニアと国語力
こんにちは、第3バイオリンです。
日々の仕事をこなしていると、テストエンジニアというのは、技術力、テクニカルスキルだけではどうにもならないことがたくさんあるなあと実感します。なぜなら、テストエンジニアの仕事のうち、テストそのものに費やす時間というのは実はそれほど多くないからです。
ではそれ以外の時間は何をしているのかというと、だいたいは仕様書や関連資料を読んだり、チェックリストやテストの手順書、それに報告書を書いたりしています。さらにその合間にレビューや反省会で人の話を聞き、そして質問に答えたりテストの内容や結果を説明したりしています。
こういう生活をしているので、わたしは「テストエンジニアに必要なのは国語力」だと思っています。残念ながら今のわたしにとってまだまだ不足しているスキルのひとつです。
今回は、わたしが国語力の必要性を痛感したときのことを書きたいと思います。
■書く力……チェックリストの不備→テスト失敗
テストの前には必ずチェックリストを作成します。このチェックリストの出来ばえがそのままテストの成否を左右するといっても過言ではありません。特にテストの手順や、それによって期待される結果の記述があいまいで、読む人によって解釈が分かれてしまうようだとテストの失敗につながることがあります。
それはわたしがリーダーを務めるテストチームで、あるアプリケーションのテストをしたときのことでした。
テスト項目のひとつに、アプリケーションの画面上に並んだアイテムをマウスでポイントすると、そのアイテムの説明がバルーンヘルプに表示されることを確認する、というものがありました。
そのテスト項目について期待される結果として、チェックリストには「テキストが正しく表示される」と記載されていました。このアプリケーションは何度もバージョンアップを繰り返していることもあり、チェックリストは過去バージョンのものを流用しながら作成していました。問題の機能はずっと昔からあって仕様変更もない、いわゆる枯れた機能だったのでわたしはチェックリストの内容について特に見直しもかけず、そのまま流用することにしました。
画面上に表示されるアイテムの種類にも変更はなく、したがってバルーンヘルプに表示される説明文の内容にも変更はありません。そのためチェックリストに記載されている「テキストが正しく表示される」というのはテキストの一字一句を確認しなくてもいい、ただ文字の欠けや抜けがないかどうかだけを確認するということを意味していました。
このテストを担当するのはわたしと、同じチームのテスター1名でした。彼はわたしの前任のリーダーのときからこのチームに所属しているので、わたしは彼がチェックリストの記載の意味もわかっているものだと思い込んだまま、テストを開始しました。
テストが少し進んだところでふと隣で作業を進める彼をみると、なぜかグロッサリファイルを開いています。わたしは彼に「なんでグロッサリファイル開いているの？ 文言の変更はなかったはずだけど」と問いかけました。すると彼は答えました。「バルーンヘルプの文言チェックしているんです。ほら、ここに“正しく表示される”って書いてありますし」
つまり彼は「正しく表示される」というのを「グロッサリファイルと比較して、一字一句間違いがないこと」と解釈したわけですね。
わたしはすぐにチェックリストを修正しました。テスト全体に大きな影響はなかったものの、チームのテスターに余計な確認作業をさせて、時間をロスしてしまいました。
■読む力……仕様書に「書いていないこと」が読み取れない
チェックリストを作成するには、まず仕様書を読むことから始まります。仕様書に書いてあることを読み取り、チェックリストに反映することは簡単です。難しいのは、「書いていないこと」がないかどうかチェックすること、なぜそれが書かれていないのかを確かめることです。
書いていないことは仕様書に追記するか、訳あって仕様書に追記できない場合はテストチームのほうでノウハウとして残すかのどちらかの解決策を取る必要があります。
そうは言っても、実際には書いていない仕様をバグと誤認し、余計な障害票を起票してしまうことはしょっちゅうです。書いてあることだけから「書いていないこと」があるかどうか読み取ることは本当に難しいです。
■話す力と聞く力……開発チームとの攻防
書かれていない仕様を仕様書に追記するのは開発チームの仕事です。よってわたしから開発チームに追記の依頼をする必要があるのですが、ことがそう簡単に運ばない場合もあります。
わたしがまだ新米リーダーだったとき、「書いていない仕様」を読み取ることができずに、余計な障害票を起票してしまったことがありました。
わたしは今後このようなことを引き起こさないためにも、この仕様を仕様書に追記してほしいと開発チームに依頼したのですが、断られてしまいました。その仕様は特定の機種にのみ適用されるものだったので、開発チームとしては「いちいち書いていたらきりがない」というのが理由でした。
そこを何とか……と食い下がってみたのですが、開発チームのメンバーのひとりから「あなたはまだ仕様が分かっていないようですね。早く理解して下さいよ」と言われ、追い返されてしまいました。
後にそのメンバーが出した報告書には例の障害票について「チェックリスト作成者が不慣れだったので」といった意味合いのことが書かれていました。さすがにこのときは、なんでここまで言われなくてはいけないのか、しかも報告書というかたちで残すなんて……とかなり憤慨しました。
でも今から振り返ると、わたしの言い方にも問題があったのかもと思います。わたしがあのとき、一方的に食い下がるだけでなく開発チームのいい分も聞けていたら、お互い嫌な思いをせずにすんだのかもと反省しています。
ちなみにこの一件によって、わたしはその開発メンバーに対して「今に見てろ！ すぐに仕様を覚えてやる！」と思ったのですが、結局何も見せないうちに彼は派遣元に戻ってしまいました。そのことはいまだに心の奥でモヤモヤしていますが、でもそのおかげで話し方、聞き方について考えるようになったので結果的には良かったのかもしれません。そう思いたいです。思わせてほしいです。
■結局、国語力ってどうやったら身につくの？
ここまで国語力のなさが招いた失敗について書いてきました。それでは、国語力を身につけるために何かしているのかと聞かれますと……残念ながら、これといったことは何もしていないのが現状です。書くことは、コラムの執筆を通して少しは鍛えられているかもと思っていますが、本当にそのとおりなのかどうかは正直言ってわかりません。結局、経験を積むしかないのかなと思います。
何を言えば、どのように書けば自分の意図が相手に伝わるのか、そしてどのように聞けば、何を読めば相手が伝えたいことを受け止められるのか、いつも迷っています。
コメント
nantaro
こんばんは。IPネットワーク系のシステムをテストしています。そうですね、文章表現は難しいですね。私も障害票を起票するのですが、開発チームのリーダーから「あなたの障害票はわかりにくいとチーム内からクレームがあがっている」と言われたことがあります。そのときはカチンときましたが、冷静になって自身の起票した障害票を読み直すと、指摘の通りでした。
やはり数をこなしていくしかないかなと思っています。また、他の人の文章をマネするのも良いかなと思います。
仕様のグレーゾーンも悩ましい問題です。開発規模が大きくなってくると書かれていない仕様は暗黙の了解のようになっています。ただ私としてはもう少し白黒はっきりさせてほしいなと思っています。時には、書かれていないこと＝不具合だ！と感じてしまいます。
とりとめのないことばかりですみません。同じテスターなので気持ちがよくわかります。
それでは。
第3バイオリン
nantaroさん
こんばんは、コメントありがとうございます。
>私も障害票を起票するのですが、開発チームのリーダーから「あなたの障害票はわかりにくいとチーム内からクレームがあがっている」と言われたことがあります。
私もテストエンジニアとして駆け出しのころ、テストリーダーから
同じようなダメだしを受けて、何度も修正しました。
「このくらいは書かなくてもわかるだろう」と思っても意外とわからないことがあるんですよね。
障害票の書き方がまずいと最悪の場合、開発チームを迷宮へミスリードしてしまうこともありえます。そう考えるとけっこう恐ろしいです。
>やはり数をこなしていくしかないかなと思っています。また、他の人の文章をマネするのも良いかなと思います。
昔開発にいたころ、障害票に書いた対策の内容について
開発リーダーから「文章になってない」と叱られたことがありました。
そのリーダーから、同じようなことを言われたのを思い出しました。
>開発規模が大きくなってくると書かれていない仕様は暗黙の了解のようになっています。ただ私としてはもう少し白黒はっきりさせてほしいなと思っています。時には、書かれていないこと＝不具合だ！と感じてしまいます。
仕様書に仕様が書かれていないことは仕様書の不備であり、立派な不具合だと
思うのですが、なかなか改善されないんですよね。
これは私のチームに限らず、部署全体で問題視されていることです。
私も元開発なので、仕様書に書けない、できれば書きたくない事情があるのも
わかるのですが、それでもコラムに書いたような対応をされると
「勝手なこと言って！」と思ってしまいます。
インドリ
永遠の課題だと思います。
最近読書離れと呼ばれるだけあって、文章を読めない人が多く困ることもあります。
それと「当たり前」という言葉からバグが入り込むという点を未だに分かっていない人もいます。
さらに、分業化が進みすぎてテストを知らない開発者の場合があり得ます。
この記事のケースの場合、有無を言わさずテストコードで結果を示せばいいと思います。
私も何度言っても相手が分かってくれない場合、テストコードで言い逃れできないようにします。
コードは文章よりも雄弁に語る場合もあるのです。
仕様書をLISPで書けばいいと思う時すらあります。
第3バイオリン
インドリさん
こんばんは、コメントありがとうございます。
>それと「当たり前」という言葉からバグが入り込むという点を未だに分かっていない人もいます。
>さらに、分業化が進みすぎてテストを知らない開発者の場合があり得ます。
自分のチーム、自分の部署しか知らない人っていうのは確かに問題ですね。
同じチームの人なら「暗黙の了解」で通じることでもよその人が相手だとそうはいきません。
しかしどうもそれが理解できないらしく、「なんでわからないのかがわからない」となるわけです。
私自身も開発にいたころはそういう傾向があったのであんまり偉そうにはいえないのですが、
井の中の蛙はほんとうに恐ろしいです。
>この記事のケースの場合、有無を言わさずテストコードで結果を示せばいいと思います。
>私も何度言っても相手が分かってくれない場合、テストコードで言い逃れできないようにします。
言ってもわからない場合は実際に障害を出したり、困る状況を作り出して
「ほら言わんこっちゃない。みんなあなたのせいです！」とやってやるしかないと私も思っています。
あとは、私が言ってきかない場合は虎（うちの上長）の威を借ることもあります。
ただ、これはテストリーダーとしての役割を放棄したような気がするので好きなやり方ではありません。
このコラムで書いた一件については、優秀だった前任者と比較され、
どう考えても私をなめているとしか思えない口ぶりで言われました。
それ以外にもいろいろとあったので、少しだけ上長に手を回してもらいました。
しかし、そのおかげで上長からは「要注意プロジェクト」とマークされるようになってしまいました。
今は開発リーダーも変わり、嫌な言い方をする人もいないのでだいぶやりやすくなりましたが。
友ぞう
こんにちは、友ぞうです。
国語力、ものすごく同感します。
テストエンジニアだけでなく、どんな職種でも国語力って必要ですよね。
書けない、いい言い回しができない、以上に読めない人が
圧倒的に多いと感じます。
小さい頃に読書をたくさんしている人は国語力が高いとか。。。
国語力を上げるのはよい文書をとにかく読むことだと思います。
個人的にお勧めなのは、新聞なのですが、小説とかでもいいので
活字を読むってことが必要なんでしょうね。
（ネットのブログとかではなく・・・）
周りの人で、説明書を読まない人っていませんか？
取説でも大事なことは、小さな字で余白に書いてあったりして。
スミからスミまで読めとは言わないまでも、
説明書を読まない人は、国語力もない、などと勝手に思っています。
読む力、書く力、ともに使わなければ衰えます。
漢字も書かないと忘れるし。
だから、続けることは大切なんですよね。きっと。
第3バイオリン
友ぞうさん
こんばんは、コメントありがとうございます。
>国語力、ものすごく同感します。
>テストエンジニアだけでなく、どんな職種でも国語力って必要ですよね。
実はそうなんですよね。
「テストエンジニアと国語力」とは言ったものの、なにもテストエンジニアに限った問題ではありません。
>小さい頃に読書をたくさんしている人は国語力が高いとか。。。
>国語力を上げるのはよい文書をとにかく読むことだと思います。
文章上達の一番の近道は他の人が書いたドキュメントを読むこと、ってよく上司に言われていましたね。
>周りの人で、説明書を読まない人っていませんか？
>取説でも大事なことは、小さな字で余白に書いてあったりして。
>スミからスミまで読めとは言わないまでも、
>説明書を読まない人は、国語力もない、などと勝手に思っています。
説明書もろくに読まずに「わかんないから教えて」と聞かれたり、
うまく動かない、壊れたと文句を言われたりするとイラッとするのを通り越して、
「もう勘弁してよ・・・」と悲しくなってしまいます。
>読む力、書く力、ともに使わなければ衰えます。
>漢字も書かないと忘れるし。
>だから、続けることは大切なんですよね。きっと。
PCの漢字変換に慣れてしまうと、書くときに漢字が出てこないってことがありますね（汗）。
それで携帯電話のメールやメモ帳で慌てて調べる、と（本当に毒されてますね）。
PCや携帯電話のメールも便利ですが、やはり自分の手で書くということも忘れてはいけないと思います。
というわけで、今年も年賀状は手書きにします。