※本記事は登録会員限定記事ですが、限定全文公開中です。
テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。
登場人物
- プロ之 … プログラマー
- テス緒 … テスター
テストはテスターの仕事かもしれませんが、テスターの役割はテストすることだけではありません。テストを通じてプロダクトの品質を知ることや、品質を良くするのに役立つ情報を集めることもテスターの仕事です。そうした情報を生かすには、テスターと開発者が一緒になって、良い品質のプロダクトを送り出すため懸命に働くしかありません。ひとつの仕事にそれぞれ異なる視点を持って取り組むのが、開発者とテスターです。仕事は開発者だけでも、テスターだけでも成し遂げられません。
本連載では、テスターと開発者がどのような仕事をしながら、どんな関わり合いを持ち、それぞれの独自の視点と強みを組み合わせていくのか、テスターのテス緒さんとプログラマーのプロ之さん2人の様子を追いながら紹介していきます。
気になる！さて、どうしよう
テス緒さんはあるプロダクトに関わるテスターです。小規模ながら3名からなるテストチームの一員として、今日も割り当てられたテストケースを実行しています。そろそろお昼休みになろうかというとき、ちょっと目のすみに引っかかるものを感じました。実行したテストケース自体は手順通りに完了したのですが、画面上で隣の行に表示されている数字に違和感をおぼえたのです。
テス緒(以下、T)「あれ、この49.9ていう数字、さっき50.0じゃなかったかな…見間違いかな。似てるだけで別のデータなのかな。でも、このテリー・ギリアムていう名前※1も見覚えがある気が…」
T「どこで見たんだろう。5つくらい前のテストケースだったから、あ、別システムの画面だね。ほらテリー・ギリアム、50.0。キリがよくて記憶に残ってたんだね」
T「どうしよう、担当のテストケースに影響ない項目だし、いまテストしてる機能とも関係ない気がする。でもちょっとだけ気になるから、あとでちょっとだけ調べておこう」
テス緒さんはいま、同じデータなのに表示が異なっているという現象を見つけました。これは、もしかしたらプロダクトの故障※2かもしれませんが、実は問題のない、仕様通りの挙動なのかもしれません。テストデータがおかしい可能性もあります。問題だとしても、すでに対処済みということもあります。プログラムに何かしらの問題があると判断するには、まずそうした可能性を排除していく必要があります。
テス緒さんは同時にこうも考えます。もしもプログラムの欠陥(バグ)が原因だとしたら、どうなるだろう？ 同じような数字のズレが、他の人のデータにもあるかもしれないし、他の項目にあるかもしれない。この項目に関するテストケースを見つけ、自分でテストを再実行したら、同じ現象を起こせるかもしれない。なんらかの証拠を見つければ、欠陥が確かにあると示せます。
こんないろいろなことをすべて、テス緒さんがひとりで調べたり考えなければいけないのでしょうか。さすがに手に余るし、自分が詳しくない領域は見落としや勘違いもしてしまいそうです。明らかに、他人の手が必要です。※3
ポイント:
- テスターは問題かもしれない現象を見つけるためにテストする。テストケースをこなすだけではない
- 問題かどうか判断するため、テスターは他の人を巻き込んでいく
※1 テスト用データの中には、本番データから固有名詞を置き換えて匿名化したデータが含まれています。この名前も、匿名化されたダミーの名前です。
※2 故障(failure)とはシステムやプロダクトの間違った動作や、期待と異なる結果です。故障は表面に現れた、目に見える現象で、故障の原因を探っていくとプログラムの欠陥(バグ)に行き当たる場合があります。
(参考: 『JSTQBテスト技術者資格制度 Foundation Levelシラバス Version 2018.J01』の「1.2.3 エラー、欠陥、および故障」 https://jstqb.jp/syllabus.html#syllabus_foundation )
※3 どうやって人の手を借りるかは、組織のプロセスや文化によっていろいろです。開発した人に直接聞きに行く、問い合わせ担当の人に連絡する、チケットを登録して担当をアサインする、リーダーやマネージャーが優先度や担当者を判断するなど、それぞれのやり方があります。
教えたり教えられたりする話
テス緒さんは昼休みをつぶして、さっと自分にできる範囲で調査しました。まだ確信は持てないものの、本番データでも同じ現象があることと、仕様上は同じ数字が出るものらしいことがわかり、やはり問題なのではないかと考えています。また、関連するテストケースを探し出して自分で実行してみましたが、すべて正しい結果でした。ということは、未知の新しい問題がある可能性があります。
そこで、同じプロダクトの開発チームにいるプログラマーのプロ之さんにメッセージしてみることにしました。
T「ちょっとだけ相談があって、チケットにも書いてあるんだけど、かくかくしかじかで…気になるのだけど、一緒に調べてもらえる？」
プロ之(以下、P)「いいですよ。30分だけでいいですか？ ハドルでやりましょう」
2人はオンラインミーティングに入りました。テス緒は画面共有して問題の数字を見せ、説明しました。
P「時間合計の項目か、total_hoursですね。これは…DBから取得した値を、summarize_group_reportで計算しています。ロジックは、えーと…わりとややこしそうです。別システムの方は別のコードで計算して…違った、こっちはフロント側にロジックが書いてあります」
T「それって問題？」
P「まったく同じロジックだったら共通にしたいですが、表示項目も違うし、たぶん違うみたいです。ですが、時間合計については同じ仕様だとしたら、本当は一本化すべきだな…でもなにか理由があるかも分からないです。それに、今の問題とは関係ないかもしれません」
テス緒さんとしては、プロ之さんが現象について把握してくれ、関係するコードを見つけてくれたのをありがたく思いました。同時に、いま調べている問題について一緒に考えてもらうには、話が噛み合ってないもどかしさも感じました。テス緒さんは具体的なアクションを持ちかけてみることにしました。
T「ありがとう。開発のことはよくわからないのだけど…この問題を調べるには、いくつかやりかたがあって、再現方法を見つけるか、DB上のデータに問題がないか調べるか、コードを仕様と付き合わせてレビューするか、データフローを網羅したテストケースを見直すか、かな、とりあえず。テストケース見直し以外は、ひとりでやるのは難しくて、手伝ってもらえそうなところはない？」
P「来週までは余裕がないと思います。チャットの質問くらいなら大丈夫ですけれど。再来週ならもっと時間が取れるかもしれません。気にはなるんですが、すみません」
T「ううん、ぜんぜん。ありがとう。いま教えてくれた情報だけでも、調べる役に立つし、もう少し調べてみるから…また質問させてもらうかもしれないけど、よろしくお願いします」
テス緒さんはミーティングを終了しました。プロ之さんに提供できる十分な情報がなかったことは残念に思いつつ、現象について認識してくれた点、調べるヒントが手に入った点、社交辞令だとしてもまた質問や相談ができそうな点から、期待以上の結果だったなと思いました。
ポイント:
- 他の人を巻き込むために、テスター自身が納得するまで情報収集する
- 期待するような協力が得られなくても、相手に感謝し、得られた情報を吟味する
それは自分の問題？
今回のお話は、ここまでになります。テス緒さんは問題かもしれない現象に遭遇し、まずは自分が納得して自信が持てるように、その現象を調査しました。そして、別のチームにいるプログラマーのプロ之さんに情報を共有し、助けを求めました。ひとつの問題に対して、一緒に向き合う構図が作れたわけです。とはいえ、まだ2人の協力関係は脆弱です。
言うまでもなく、プロダクトは1人では作れません。すなわち誰でも、プロダクトを作るため他の人と働く場面が必ずあります。テス緒さんは見つけた問題に対処するため、プロ之さんと働く場面を自分で作り出しました。
誰と誰がどういうとき一緒に働くのか、それはプロセスや文化や組織によって様々です。テスターは先にもっとしっかり調べておくべきというやり方もあります。もっと早く、すぐに開発者に声をかけるのが当たり前の組織もあります。相手の時間を奪うのは申し訳ないので自分でよくよく調べるという考え方もあれば、人に聞けばすむことに自分の時間を使うのはムダという考えもあります。
大事なのは、一緒に立ち向かう構図を作るために必要な準備をし、そのために時間を使うという意識です。仕事の中に「わたしの問題」も「ひとの問題」もありません。すべてプロダクトの問題であり、チームが共有する問題です。テスターは見つけた問題を開発者に「お願い」し、開発者は「頼まれる」ことが多いので、なんとなく立場の上下があるように思いがちですが、それは錯覚です。違う専門性の人が一緒に問題に立ち向かうという強靱な構図を作ってください。
ポイント:
- 同じ目標のため同じ仕事を一緒にしているという大前提を心に持つ
- 相手を尊重しつつ、協力したり協力してもらったりする
次回は、テス緒さんとプロ之さんがそれぞれのアプローチを取り、その働きが噛み合っていく様子を紹介します。
連載一覧
第1回：引っかかりを感じたら相談しよう
第2回：それぞれの得意をつなぎ合わせよう
第3回：大事(だいじ)なことが本当に大事か確かめよう
第4回：立場を越えて問題を追及しよう
第5回：テストを通じてチームとプロダクトとに貢献しよう
