料理を開発に例えて、テストについて考えてみる
※この記事は「ソフトウェアテスト Advent Calendar」12月25日の記事です。
家の壁に貼るホワイトボードを導入したなそです。好きなだけ書けるのはとても楽しいです。AdventCalenderの書くことをいろいろマインドマップで考えて今回はソフトウェア開発がよく例えられる料理の話を考えてみたいと思います！
何かに規模の小さなものに例えることで、大きなソフトウェア開発の全体を理解が進むと思っています。
きっかけ
さて、そもそもなぜこの話をするかというと、ソフトウェア開発におけるテストフェーズが料理における「味見」に当たるのが納得できていないということがきっかけです。ツィッターでは「味見」でした。「お毒見」とかもありました。
レシピを設計書、調理は実装となるっていうのはわかるけど、テストはどう考えればいいんだろう・・・。レシピを見ても具材わからんし、調味料とか無理だし・・・っていつも思う。
— なそ@さとうひろゆき (@hiroyuki3gou) 2017年12月17日
やっぱり味見がテストなのか？
料理と開発の工程を比べてみましょう。今回は夕食を作る場合を想定して開発に照らし合わせています。
工程(料理：開発)
- 食べたいもの：要求
- 作れるもの：要件
- 作るもの：設計
- 調理：製造
- 味見？：テスト
- 盛り付け：リリース
- 片付け：運用
こういう風に考えてみると確かに味見が該当します。そして、この味見はお惣菜(OSS)やコンビニ弁当(外部サービス)を買ってきたときには必要ないので、確かに味見がテストフェーズと言っても過言ではないでしょう。お惣菜をそのまま食べる場合は味見の必要がないですが(食べたらそれはつまみ食い)、ひと手間加えた場合、味見が必要になりますね。
QCD(料理：開発)
- おいしさ？：品質
- 夕食に使えるお金：予算
- 夕食の時間：納期
次はQCDを考えた場合、Qに当たる部分が人によって意見が分かれるような気がします。おいしさ度外視(言い過ぎ)で栄養のバランス、カロリー重視、手を汚さずに食べれる等々私が思いつく限りでも複数あるので、もっとありそうですね。予算、納期に関してはそんなに意見が分かれない気がします。
そもそもQが一つだけだとは限らないでしょう。複数の要素があるので、料理における品質特性(おいしさ、栄養のバランス、カロリー、彩り、温度等)を定義するべきでしょう。当然いま5つですが、ここに該当しないものもあるでしょう。家庭の夕食に厳格な栄養のバランスを求めていると予算と納期が大変なことになりますが、「1日30品目食べましょう」などはQCDを考える上で良いバランスに感じます。
結論？
料理におけるテストフェーズは「料理における品質特性」＋「家庭の伝統」を加味して家族が健康であることが担保できるような活動全般を指すのではないでしょうか？
その中の手法の一つが「味見」であるということです。味見は属人性を含んだテストにおける探索的テストですね。栄養のバランスとかカロリーは素材をカウントするので、テストケースで確認できるかもしれません。
余談１ 食べたいものがしっかり言えないと・・・
「今晩何食べたい？」とよく母親に聞かれたことがあり、何でもいいと答えていたのですが、よくよく考えると要求で「良しなに作ってくれ」といって丸投げしていたということですね。よくこのプロジェクトが失敗しなかったと改めて母親に感謝してますm(__)m
しかし、食べたいものが出てくる確率は低いことは確かでした。一緒に暮らしている母親でさえこうなるので、大人数がかかわるソフトウェアの開発では「ほしいもの」が完成することはまずないでしょう。「ほしいもの」を要求できなかったことでトラブルになった例はいくつもあります。この辺は有名ですね。京都市の場合は現在内容の確認中なので、何とも言えませんが可能性があると示唆されています。
余談２ 一汁三菜ってさ・・・
ご飯の基本は一汁三菜って、教えてもらいましたが、
- ご飯
- 汁物
- 主菜
- 副菜１
- 副菜２
ざっと見ただけでも、サブシステムが5つもあります。これを決められた予算と納期でしかも品質を担保しながらと考えると、無理な気がします・・・。っていうか普段料理する私も毎日は無理です。(せいぜい一汁一菜。茶色い・・・)
しかもこれらを考えながら、季節の食材や素材の数を横串で見ながら考えないといけないという。主婦はプロジェクトマネージャに向いているのではないかと本気で考えてます。
余談３ 作るもの・・・
料理のレシピは、材料と手順が書かれています。レシピがなかったら属人性を持った家庭の味になります。レシピ化することで人に教える、次に作る時にも同じ料理がつくれたりしますね。
「ぎゅーんとやって、スパッとひゅんとしてぐつぐつするとできるよ」じゃ伝わるものも伝わりませんよね。似たような話をテストラジオでも話をしています。
あとがき
余談のほうが長くなった気がしますが、ノルマ(テストラジオの広告)も達成したのでこのくらいにします！
料理の作業工程とソフトウェア開発の工程は例えとして優秀です。誰でも料理をしたことがあるので想像しやすいはず・・・。この例えは今後も使っていきたいと思います。
それでは、なそがお送りしました！
WACATE 2017 冬 ~すべてがTになる~ 参加レポート
どうも！なそです！！
ワカテーズハイという症状をご存知でしょうか？
WACATE2017 冬 ～すべてがTになる～ 開催概要 - WACATE （ソフトウェアテストワークショップ）
1泊2日で開催されるワークショップです。
ソフトウェアテストに関わる人たちが60名くらい集まる異色と言えば異色です。
そこでは２日間ずっとテストの話をし続けます。
その状態に慣れ、月曜日に会社に来ると周りよりもテンションが高くなっているのが「ワカテーズハイ」と呼ばれるハイテンション状態です！
テストラジオも今回のWACATEに触れてます。さらっと。
通常のセッションは、他の人に解説を任せて私はよりニッチな分科会をレポートします！
素晴らしく綺麗にまとめてくださっている人からリンクOKをもらったので、通常セッションを見たい方は、こちらをごらんください！！
WACATEは参加型ワークショップです。
参加者の自主性がかなり尊重されるワークショップでは、他では珍しい時間があります。
それは「夜の分科会」です。
語りたいテーマをぶら下げたオーナーの元に集まり、議論をするという形式です。ここにはWACATEの実行委員はあまり関与してません。オーナーを中心に議論をファシリテートしながら、意見をぶつけ合うのが分科会です。みんなで考える会です。
分科会のオーナーになるには、WACATE申込時に分科会のオーナーになりますと宣言するだけです！簡単！！
WACATEより引用
ディナーセッションが終わった後はその勢いのまま自分が語りたいテーマごとにグループにわかれ、フランクに議論をしていただきます。
恥ずかしがりやの方も人見知りの方も、遠慮なさらずテストについて思い切り語りあいましょう。
テーマはWACATEの参加申し込み時に募集しておりますので、語りたいテーマがある方はぜひテーマオーナーとして立候補していただければと思います！普段からの悩みや他のエンジニアに考えを聞きたいことなどを大胆に、かつ真剣に語ってみてください。きっと応えてくれる同士が見つかるはずです。
是非、想いのたけをぶつけてください！
参加者による分科会のため、WACATE毎にテーマが異なります。
その時に興味があることについて話をするので、その場限りになります。
そして、今回のテーマは5つでした。
- テストの妥当性
- 納得の提案
- BPPセッションの続き
- QAの立場
- テストの自動化についてなんでも答えます
そして、私は今回「テストの妥当性」のオーナーでした。
さて、今回なんだかんだで3回目のオーナーになりましたが、どうやってテーマを決めているかというとその時のトレンドを分科会のテーマにしています。
過去の分科会では、「教育」がテーマになってます。
今回とは別なテーマにしました。
テーマを決めた理由は、「テストの妥当性」について悩んでいる人がいたから。
そして、そのことに私自身が興味を持ったからですテーマにしました。
みんなどうやって折り合いをつけながら、テストしているのかなと。
分科会が始まると、気になるテーマごとに集まり議論スタートします。
今回はお悩み相談に近かったので、本人のヒアリングからスタートです。
ここでオーナーが注意しないと行けないことは大きく３つ
- 喋りすぎる人を止める
- 発言しない人に発言を促す
- タイムキーピング(時間は100分)
オーナーが最初の火をつけると周りから発言が出てきて、程よく火が大きくなります。
そうして、想像以上に思っていること、普段疑問に思っていること、疑問に思っていなかったけど人の意見を聞いて疑問に思ったことなどなど周りからいっぱい出てきます。
火がだんだんと大きくなってきた頃には、よく喋る人と全く喋らない人の２層に分かれます。この辺でオーナーがファシリテートしていきます。
が、今回はよく喋る人が喋らない人に発言を促してくれたおかげで、オーナーやることなくなりました。
それでも、議論を進めながらなので、届かないところもあります。
そこをフォローすれば良いだけなのです。
というわけで、議論がいい感じに進みました。
議論を進めていく中で、今回のお悩みは「テストの妥当性」「テストケースの妥当性」の２面があり、それぞれを切り分けて考えていく中で、取れる立場や状況。立ち回り方。失敗例。と教科書的な回答が出てこない！！ そこがとても面白い。
その中で、
- テストの妥当性では「テストケースによるテスト」と「探索的テスト」が必要
- テストケースの妥当性では「どこまでテストするべきか」を検討する必要
って話になったはず・・・（メモとか取ってないので思い出しながら書いてる。間違ったらフォローして！！）
テストケースだけのテストでは、カバーできる範囲が限られています。だからこそテストレベルを分けてテストすることでそれらをカバーする必要があります。
また、テストケースによるテストだけではカバーできないので、探索的テストを実施する必要がある。それもモンキーテストではなく画面の規模等で時間を割り振るタイムボックスの探索的テストとかをオススメしていました。
画面の規模等の話は何話したかを覚えていますが、ちょっとここでは割愛します。
いきなり「探索的テスト」をやりましょうでは、難しいのでまずはテストケースのテストを実施して、バグの傾向を掴む必要があります。（7原則の4：欠陥の偏在）その傾向に則って探索的テストを実施するのが理想ではと分科会メンバーでは落ち着きました。
そのためのメトリクスや情報を集めるのも重要です。的な話をして翌日のメトリクスのセッションにぶん投げた記憶があります。(ページ下部にリンクを貼っておきましたのでご覧ください。私も何やるかわかっていなかったので目的の情報が集まってなかったらごめんなさい。連絡くだされば一緒に悩みます(うぉい笑))
次にテストケースの妥当性では、どこまでテストすべきかは担当者やユーザー側にヒアリングを行い、その水準を満たすのをゴールに実施していくべきという話になりました。どこまでもテストケースは増やすことができます。（7原則の2：全数テストは不可）
その中で取捨選別を行うのは我らテストエンジニアでは決め切れません。経営判断やPMの意向等々が必要になります。100点の基準がわからないのであれば、決めるしかないです。その決め方は私たちから動いて決めてもらう。一緒に決めていく必要があります。
また、必要なケースを洗い出すためにはたくさんのテストケースをやるのではなく、効率の良いテストケースを用意する必要があります。テスト技法を使って効率を求める必要があります。ここは翌日の「直交表に触れてみよう（仮）」にぶん投げました。
（この仮はいつ取れるんだろう？これも下に貼っておきます）
他にもテスト技法があるので、ここは頑張って勉強してもらいましょう！！
オススメの本はこれ！
ただし、いきなり深く読もうとすると深淵を覗くことになるので（失礼なやつ笑）無理のない範囲で学習を進めるのが吉♪
という感じの100分を終え、どうだったんだろうな？
どこかで話を聞けたら嬉しいですね。
そんな分科会を開催しました。周りの人がどんな分科会をしたのか興味あるなぁ。
分科会のオーナーは、気になるテーマの話ができて、みんなの意見をまとめる練習がここではできます。
答えを持っている必要はないです。ニッチ過ぎても多少は大丈夫！！
飛び込んでみると世界が変わると思いますよ♪
実は、WACATEにはさらに分科会がありまして、深夜の分科会があります。
地方から来た人たちと話をする機会がないので、その集まりっぽくなりますがここでは、全国の猛者たちが暑すぎる議論を繰り広げたりします。お悩み相談もしてくれます。進路だったり、業務の悩みだったり。
（まぁ、夜の分科会の時点で0時近いので、そこから先は自己責任です笑 ただし、濃厚なテスト談話を聞けます。今回の深夜の分科会はワークショップがもう一個開催されていました）
ちなみに私はというと
いる人捕まえて、ラジオ放送をしていました。
そんな感じで夜が更けていきます。
なかなか夜の分科会のオーナーになった話というブログは見ないので、これをきっかけに分科会のオーナーが増えてくれると嬉しい限りです！
WACATEはレポートを書いてみんなでワイワイするのも一つのアウトプットになります。ワカテーズハイのうちにブログを書いて見ましょう！！
それでは、なそがお送りしました♪
WACATE セッションの資料はこちら
みんなのメトリクス 公開用 from kauji0522
テストデータの人名を「ああああ」とかにしてませんか？簡単にデータを作成してみませんか？
※この記事は「ソフトウェアテストの小ネタ Advent Calendar」12月4日の記事です。
Advent Calender 初投稿のなそです。
今回のお題は小ネタということで、知っていたら楽かもしれないテストデータを便利に作れるサイトを紹介したいと思います。
皆さんはテストデータで人の名前使うときにどうしてますか？
「テスト太郎」や「ああああ」とか使ってませんか？私は以前まで使ってました。
あとはドラマやアニメの登場人物を使ったり、自分の名前使ったり色々使っていたんですが一人二人ならさくっとできます。大量のデータになった時や住所や電話番号と入力項目が増えていくと毎回その場で作るのは難しくなります。
氏名や住所だけでなくメールアドレスや誕生日などのデータを作ることができます。
また、年齢比や男女比、居住の地区など細かく生成データを指定することでテストするアプリの対象ユーザーに合わせることができます。
ただ、問題としてはリアルすぎて本物だと思われる可能性があります(；ω；)
使用の際はその点だけご注意ください。
バグがあったときに、XXさんで障害出てますとか言いやすいです。
10件〜5000件のデータが作成できます。
いっぺんにデータを作成してくれるので、大量のデータを対象にしたテストデータも作りやすいです。
ぜひ、利用して素敵なソフトウェアテストライフをお過ごしください！
木テクにて突撃LTをさせてもらいました！！
こんにちは、なそです。
季節は一気に冬になり、体調はいかがでしょうか？
さて、ちょっと前ですが、下記でLTをさせてもらった話をします！
申し込んだのは10月25日(水)の前日でした。
直前に対応いただきありがとうございましたm(__)m
話の内容は「テスト観点」についてです。
私が伝えたかったのは、テスト観点一覧表をつくりましょうではなくテスト観点とは何者かということを再認識してもらいたかったということです。私自身がという再認識をするところがめっさ強いです。
＝私のイメージ＝
テスト観点＝テストするための観点。この辺にバグが居そうだなと思える「勘」だとおもっています。
(このテーマで話をしようと思った時に、テスト観点とは何者だということでJSTQBの用語集を見ましたが、テスト観点はなかったです)
よくあるのがそれを一覧化して、みんなで共有できればバグは漏れない！と。
でもよく考えてほしいのです。「勘」なので、何かしらの経験、知見、知識が必要になってきます。その一覧は失敗リストでもあるのである。
過去の失敗をリスト化したものをテスト中にバグが出たとしたら、その前の工程で対策できていないと過去の経験が活かされていないということに。
そのため、テスト観点はテストする人たちのみのものではないということだと私は思っています。プロダクトマネージャやプロジェクトマネージャ、開発者、テストエンジニアのみんなで共有できれば、早い段階から問題解決できて良い製品を作れるはず！！上流の工程からバグを作りこまない作業ができる！
では、すぐにテスト観点一覧を作るべきかというとそうではないのです。
作る前にチームの中で話をするべきです。特に最近入った人とベテランが対話すべきです。先ほども言った通りで「勘」なので、ベテランが持つ直観の場合もあります。まずはチーム内で共有することが重要です！
まずはドキュメント化しようぜ！って流れは私は好きじゃないです。
∵ドキュメントにすることでかかる時間ってすごい膨大なものだからです。
このテスト観点を一覧にするだけで作成コスト、メンテナンスコスト、内容の把握、使い方の説明、改善作業、等々・・・
誰がやるんでしょうね。重要性とコストを天秤にかけないままに実行に移すとそれこそとん挫します。1回作ればそれでOKってものでもないので、改善をしていかないといけないです。もし途中でできなくなるなら、それって結局やったことをどぶに捨ててるんですよね。もったいないですよね。
じゃ、どうしましょうって話になります。
テーマを決めた飲み会とか座談会とかを実施してみたらどうでしょうか？
その中で出てきた話をみんなで共有して、整理して、みんなの中の合言葉にする。
合言葉にすれば忘れにくいので、改善されてそれが起こらなくなったらそれは文化になったということなので、次の問題や課題が発生しているはずです。忘れる、漏れる、抜けるとかが問題になってくるのであれば、一覧化して共有していく。
みんなで整理しながら育てていく。そんな感じで現場がうまく回り始めればよいなぁと思っています。
すでにテスト観点をお持ちの場合は、一度整理してみるといいです。
これ毎回テストするけど、まったく障害を出さない場合は「殺虫剤のパラドックス」化している可能性が高いです。
この話の後に、テストのスーパーヒーロー達による会が開催されることになりました。
興味があればぜひ参加してみてください。
(ってすでに募集オーバーしているΣ(･ω･ﾉ)ﾉ！！)
それでは、少しでも現場を改善して1分でも早く帰りたい「なそ」がお送りしましたm(__)m
転職を振り返ってみる
こんばんは、なそです。
Twitterのタイムラインが転職、仕事辞めたいであふれかえっていたので、自分の時を思い出してみることにしました。
【転職迷い時期】
もともと北海道でSIerでほぼベンダーとしてシステム開発をしていたので、一気通貫の仕事が多かったです。そのため、顧客とかかわることができる要件定義から保守運用まで担当できたのはとても仕事をする上での土台を作ることができていました。
しかし、その中でどうしても開発の終盤からリリースまで荒れることが多く、いろんな人に迷惑をかけることがありました。
このころから勉強会に参加するようになり、いろんな方から社外の状況を聞くようになっていきます。それと合わせてプロジェクトマネージャーの勉強に加えて、開発プロセスの勉強も進め始めました。
【転職決断】
前職で炎上案件の渦中におり、うまいことマネジメントができない。開発も進まない。顧客との調整もしっくりこないという状況でした。(PMは別にいたんですが、ここでもうまいことコミュニケーションが取れていなかった気がします)
PMとは別の案件でもチームを組んだことがあったのですが、顧客への価値提供の部分でぶつかることが多く、ここでも同じことを発生させてしまいました。
そうこうしているうちに実践している開発プロセスに疑問を持つようになり、ほかの会社はどうやっているのか気になり始めました。また、品質の指針であるテスト計画書がコピペ製作だったため、品質に対しても気になり始めました。
そんな中、ふとした気の迷いから登録した転職サイトから一通のスカウトが届きました。それが今の会社です。上記で気になっていた「品質」「検証」「いろいろな会社」というキーワードがヒットし、ダメ元で受けてみることに。
【転職まで】
ダメ元で受けるといっても、いろいろとヒットする項目があったため数社から選ぶことはせずに1社受けてダメだったら、もうしばらく会社を続けることにしました。
(性格上、ふらふらと決めかねるくらいの時は実務も転職活動も何も身も入らないので)
エントリーからすぐに1次面接のメールが届き、東京本社を希望していたためSkypeで面談となりました。(一人しかいない部屋の中でスーツを着て椅子に座っているのはシュールでした)
その日は前歴、転職の理由、ちょっとした雑談をして終わりました。最初は緊張していましたが、話を進めていく中で緊張も程よく解けました。
そのままあれよあれよと決まり、無事に転職することができました。意思決定の速さには本当に感謝しています。9月下旬から10月中旬くらいのスピード決定でした。
【転職後】
さて、念願かなって品質を勉強できるとのことで、いろいろと飛び込ませてもらいました。そのおかげで今、悩みながらもテストを仕事にしてよかったと思えています。
なんだかんだでサクッと決まりましたが、いろんな人と話をしていくなかで感じたのは「転職の理由」が大きいのではないかと思いました。
私が自問自答したのは、3点だった気がします。
- 会社の事業に共感できるか？
- 業務の内容は理解できるか？
- その業務を通じて何をしたいか？
会社の事業に共感できて、業務内容が理解できて、得たいものが定義できなければ、ミスマッチが起きますので。。。相手もこの3点がミスマッチだと落としてくれるので、自分に合わなかったんだと納得もできます。
(多少の思い込みが入っても大丈夫だし、ぼんやりしててもいいと思います。そして、会社の全部を知るのは不可能です。漠然とでもよいのでここで働きたい。こういうことをしたいとイメージできるかどうかが鍵な気がします)
そして、これがしっかりしていると周りの人に止められることはないと思います。
(転職した人周りにいなかったし、誰にも相談しませんでした(笑) 社内では特に誰にも言ってません。一番仲が良かった先輩すら転職が決まった後に報告しました)
まぁ、ノリと勢いで転職しましたが、こうして言葉にしてみると何も考えずには転職はしていませんね(笑)
(スピード決定だったのですが、転職は3か月くらい待ってもらいました。わがままを聞いていただきありがとうございます)
自分はこうして東京で働くことになり、いろんな人出会うことができました。
転職や今の業務で悩んでいる人の少しでも助けになれば幸いです。
それでは、ノリと勢いを大切にする「なそ」がお送りしました♪
転職を振り返ってみる
こんばんは、なそです。
Twitterのタイムラインが転職、仕事辞めたいであふれかえっていたので、自分の時を思い出してみることにしました。
【転職迷い時期】
もともと北海道でSIerでほぼベンダーとしてシステム開発をしていたので、一気通貫の仕事が多かったです。そのため、顧客とかかわることができる要件定義から保守運用まで担当できたのはとても仕事をする上での土台を作ることができていました。
しかし、その中でどうしても開発の終盤からリリースまで荒れることが多く、いろんな人に迷惑をかけることがありました。
このころから勉強会に参加するようになり、いろんな方から社外の状況を聞くようになっていきます。それと合わせてプロジェクトマネージャーの勉強に加えて、開発プロセスの勉強も進め始めました。
【転職決断】
前職で炎上案件の渦中におり、うまいことマネジメントができない。開発も進まない。顧客との調整もしっくりこないという状況でした。(PMは別にいたんですが、ここでもうまいことコミュニケーションが取れていなかった気がします)
PMとは別の案件でもチームを組んだことがあったのですが、顧客への価値提供の部分でぶつかることが多く、ここでも同じことを発生させてしまいました。
そうこうしているうちに実践している開発プロセスに疑問を持つようになり、ほかの会社はどうやっているのか気になり始めました。また、品質の指針であるテスト計画書がコピペ製作だったため、品質に対しても気になり始めました。
そんな中、ふとした気の迷いから登録した転職サイトから一通のスカウトが届きました。それが今の会社です。上記で気になっていた「品質」「検証」「いろいろな会社」というキーワードがヒットし、ダメ元で受けてみることに。
【転職まで】
ダメ元で受けるといっても、いろいろとヒットする項目があったため数社から選ぶことはせずに1社受けてダメだったら、もうしばらく会社を続けることにしました。
(性格上、ふらふらと決めかねるくらいの時は実務も転職活動も何も身も入らないので)
エントリーからすぐに1次面接のメールが届き、東京本社を希望していたためSkypeで面談となりました。(一人しかいない部屋の中でスーツを着て椅子に座っているのはシュールでした)
その日は前歴、転職の理由、ちょっとした雑談をして終わりました。最初は緊張していましたが、話を進めていく中で緊張も程よく解けました。
そのままあれよあれよと決まり、無事に転職することができました。意思決定の速さには本当に感謝しています。9月下旬から10月中旬くらいのスピード決定でした。
【転職後】
さて、念願かなって品質を勉強できるとのことで、いろいろと飛び込ませてもらいました。そのおかげで今、悩みながらもテストを仕事にしてよかったと思えています。
なんだかんだでサクッと決まりましたが、いろんな人と話をしていくなかで感じたのは「転職の理由」が大きいのではないかと思いました。
私が自問自答したのは、3点だった気がします。
- 会社の事業に共感できるか？
- 業務の内容は理解できるか？
- その業務を通じて何をしたいか？
会社の事業に共感できて、業務内容が理解できて、得たいものが定義できなければ、ミスマッチが起きますので。。。相手もこの3点がミスマッチだと落としてくれるので、自分に合わなかったんだと納得もできます。
(多少の思い込みが入っても大丈夫だし、ぼんやりしててもいいと思います。そして、会社の全部を知るのは不可能です。漠然とでもよいのでここで働きたい。こういうことをしたいとイメージできるかどうかが鍵な気がします)
そして、これがしっかりしていると周りの人に止められることはないと思います。
(転職した人周りにいなかったし、誰にも相談しませんでした(笑) 社内では特に誰にも言ってません。一番仲が良かった先輩すら転職が決まった後に報告しました)
まぁ、ノリと勢いで転職しましたが、こうして言葉にしてみると何も考えずには転職はしていませんね(笑)
(スピード決定だったのですが、転職は3か月くらい待ってもらいました。わがままを聞いていただきありがとうございます)
自分はこうして東京で働くことになり、いろんな人出会うことができました。
転職や今の業務で悩んでいる人の少しでも助けになれば幸いです。
それでは、ノリと勢いを大切にする「なそ」がお送りしました♪
4か月ペアテストをやって思ったこと
どうも「なそ」です！
みんなアウトプットしてますか？
どうも最近の忙しさから勉強会になかなか参加できなくてアウトプットできていない気がする今日この頃です。
さて、今回のお題は「ペアテスト」についてです。
ペアテストについては何度かテストラジオでも話をしています。
なぜペアテストの話題を取り上げるかというと、4か月にわたって実施してきてた案件が8月末で終了しました。
BPPセッション 良いチームを作ろう from 佐藤 博之
ついでにWACATEでチームの話をしたので、その時のスライドです。いい機会なので棚卸を含めてここで実験結果報告を行うと思います。
1．きっかけ
ペアテストとの出会いは、4月に開催された「Agile Japan」で、和田さんから「アジャイル魂2015」をいただいたことがきっかけです。
和田さん本当にありがとうございます！！
その中で、ペアプログラミングについて書かれている記事を読みこれはテストにも応用できるのではと現在のプロジェクトで実施してみました！
アジャイルの魂 2015より抜粋
誤解されているのは、作業内容に関することです。プログラミングとは設計・コード作成・テストを全て含む創造的な作業を示しますが、詳細設計工程とテスト工程の間にある「PG工程」を2人で作業すると誤解している人が多く、ペアプロの理解を大きく阻害していると感じています。
創造的な作業ということはテスト設計にも当てはまる。ただし、テストエンジニアには「ペアプログラミング」は用語的に合わないので「ペアテスト」と置き換えてプロジェクトメンバーには説明しました。
また、プロジェクトのアサインの状況的にも実践しやすい環境が整っていました。1チームに2名のテスターずつ、3チームありました。私が参画した時点でペアが出来上がっていた。かつ、アジャイル開発を行っていたので、スプリントの開始時にはテスト実行できるものがない！！そのため、実行者にも教育を兼ねてテスト設計をしてもらうことになっていました。
どうせやるなら効率的にやりたい！！
ということで、メンバーと一緒にいろいろやってみることにしました。しかし、業務で成果をあげないといけないため、下記の制約をつけました。
制約①：ペアにしたのは、下記のスキルを持っている人達です。
- テスト設計をしたことがない（普段の業務はテスト実行がメイン）
- テスト設計・テスト実行はお手の物
制約②：ペアを組み替えたいけど、変えたことによる作業効率低下が怖いため、組み替えはあまり実施していない。（あまりということなので、0ではないです。組み替えは何度か発生しています）
制約③：ドライバー、オペレーターの交代は難しいため、各々のタスクを交互にレビューすることで役割を補う。
2．ペアテストの狙い
私はペアテストで狙いは
- テスト設計者はテスト実行者に説明することで、自身の設計スキルを見直す。
- テスト実行者はテスト設計者が何を考えて設計をしているか勘所を感じる
- お互いにコミュニケーションを取ることで仕事の進め方をブラシュアップ
でした。
チームメンバーにはこの意図を伝えた上で実践し、一人のテスト設計者に全てを任せる訳ではなく、チーム全体で解決していきました。
片方のペアが忙しいときは私が変わりに対応したり、別の人にお願いしたりと臨機応変に対応していきました。
ただ、手放しに良かったといえるかというといくつかの改善点ややらなきゃいけないことなどはありました。(業務をやりながらのチャレンジだったため、問題解決のための時間はあまり多くなかったです）
簡単ですが、振り返ってみます。
3．良かった点
- テスト実行者の設計力が上がった！
- テスト分析、テスト設計のフェーズを明確にしたことで手戻りが工数が減った
- 勉強会を企画して、違う人とペアを組んでもらってテスト設計をした
実行者の設計力は目を見張るものでした。参画当初は右も左もわからない。テスト設計ってどうすればいいんですか？という質問しかできなかったが、見様見真似でもテスト分析やテスト設計を作ってくるようになった。もちろん、知見が足りないのは重々に承知していることなので、そこはレビューや声かけのタイミングで補うようにしました。簡単な機能であれば、テストケースを独力で作成できるようになりました。
また、工夫した点としては、テスト分析とテスト設計のフェーズを分けたことです。基本的にテスト設計者は慌ただしく、声をかけづらい雰囲気だったこともあり実行者が気を使って(本来その気遣いは逆効果だけど、こちらもキャッチアップできる雰囲気を出せなかったのはあるのでお互いの反省点)テスト分析のレビュー完了前にテスト設計に入ることが何度かありました。そのせいで、テストケースに漏れや大きな手戻りがありました。
最後の勉強会はなかなか時間を作れなかったので、数回しか実施できていなかったですが、いつもと違う人と組んでもらいテスト設計の演習問題をやってもらいました。また、プログラムの挙動について、ゆもつよメソッドの「論理的機能構造」を使って説明をしたりといろいろな情報をメンバーに共有していきました。
4．改善点
- 実行者のフォローに時間がかかり、設計者の作業に遅延が発生することがあった。
- 実行者から設計者へのアクションが見えづらくOJTに近くなっていた
- レビューチェックリストやテスト観点を用意しておく
- 勉強会の課題のボリュームが大きすぎた
フォローをするための時間は確かに必要です。しかし、それが大きくなってしまうと相手の負担になってしまい、それが明らかになってくると自分が負担になっているのではないかと思い始めることになります。この辺のフォローは難しいですね。
実行者から設計者や私への要望は少なく、話を聞いてみるとテスト設計にいっぱいいっぱいになってしまってそれ以上のことを考えられないとのことでした。この辺は改善しなくちゃいけないですね。自分がどれだけレベルアップしているのかが見えないためにどうなっているかの変化を捉えられないってことですもんね。
あらかじめ、こういうところに気をつけてなどの観点を用意しておいてあげれば第一歩としてわかりやすかったのかな・・・
また、勉強会の課題の規模が大き過ぎてみんなダレてしまう結果になったのは残念でした。せいぜい2時間くらいのボリュームを考えておかないといけませんね。
5．次やるときに
当初の狙いである2番目は十分に達成できた。
しかし、1番目が不十分で、設計者の教育も必要なのが分かった。
例えば、現場では以下のようなことがチラホラありました。
- 1時間近く説明をしているが、伝わっていない
- 途中で説明をあきらめてキーボードを奪う
- 設計者が忙しくて、レビューがリアルタイムにできない
- レベルアップのチャンス
要点を絞った説明ができない、相手に考えさせる、タスク整理や時間の使い方がうまくできていない等の設計スキル以外の部分がネックになることが多かったです。開発者に求められるのは幅広い知識や経験が必要ですが、土台にはこういったスキルが必要になることが改めて実感しました。
相手のわからないことを組み取ったうえで、説明しようとするわがメンバーの理解力には尊敬します。私は全部を説明せずに、少しだけ説明して後はやってみな！ただし、わからなかったらすぐに質問すること！を徹底していたので、そんなに時間を使っていないかったです。
なんだかんだで、どれだけ説明したとしても本人にやる気がない場合はどうしようもないのだなというのを強く感じました。自分のやったことのない範囲をやるわけなのでいろんな感情を持つと思います。飛び込んで欲しくても飛び込めない場合は残念な結果になります。もっと飛び込んでも大丈夫という空気を作ってあげれなかったのは大きな反省点でした。
6．次なるペアテストの現場を求めて
現状テストエンジニアが不足してます。では、どうやって仲間を増やかのかを考えた時、一つの教育の形としてペアテストがあると思います。今後も続けて行きたいと思います！
テストエンジニアが増えてきた時にはモブテストとかもやってみたいです♪
それでは、今回はペアテストの結果レポートをお届けしました！
