TEF道メンバーが毎回一人ずつ自分の気になるネタを発表する、
TEF道勉強会の2015年6回目を開催しました！！
今回はTEF道のグッズ担当で、ソフトウェアテスト界の「シルバースプーン」こと
中岫さんの番です。
お題は「Pair Testing」。
＜狙い＞
ペアテスティングの紹介
ペアテスティングを体験してみる
・・・ということで、実際に手を動かして実践してみるところも
みんなで取り組んでみました。
＜PairTestingとは？＞
ざっくりいうとペアプロのテスト版
定義は特にないが、2人で一つのモノをテストすることを指すことが多い
二人一組でプログラミングを実践する「ペアプログラミング」の
テスト版ですね。
ちなみに、「組合せテスト」のペアテストとは言葉は似ていますが
別モノです。
ただ、このペアテスティング、事例や情報があまりないですね。
そんな中、実際に中岫さんは実務で取り組んでいるようです。
＜期待する効果＞
※ペアプログラミングの効果と同じであると仮定して
１、規範意識の増大。個人の作業よりもサボりにくい。
２、よりよいコード（テスト）。相乗効果により設計（テスト設計）の質が向上することの期待
３、作業効率の向上。考え込むといったことが少なくなる。
４、割り込みに対して一方が応対している間に、もう一方が作業を進められる。
５、ペアを頻繁に入れ替えれば、複数の人間が１つの機能の開発（テスト）に関われる。
６、勤労意欲の向上。1人で作業するよりも楽しい場合がある
７、頻繁にペアを組みかえる場合、そのコード（テスト）全体について全員がそれなりの知識を共有できる。
８、教育的側面。知識の共有の促進。
９、チームワーク。結束力を生み出しやすい。
＜相性の良い手法＞
ペアテスティングは、以下と相性が良い
・アジャイル
・探索的テスト
・ユーザビリティテスト
たとえば、「探索的テスト×アジャイル×ペアテスティング」であれば、、、、たとえば
【前提】
開発者同士、または、開発者とテスターがペアを組む。
【やりかた】
・一人が操作しているところを見ながら、もう一人がさらにどんなテストできるかを考える。
⇒知見者の操作をみることで、無知見者がテストするための予備知識を得ることができる。
⇒良くバグを見つける人のノウハウ、暗黙知、特殊操作などのノウハウが得られる。
・こんな操作をしたらどうか？と提案する。
⇒提案する側は、チャーター、テストの観点表、仕様書を参照する場合もある。
・ログを取り、振り返る事によって知見を得る。
⇒ログから、この操作はどういう意図でやったの？などを確認。
⇒足りないモノや似たような操作が無いか考えて、再度ペアを入れ替えてテストする。
・・・一人では得られない「気づき」が得られるってことですね。
さらに、異なる能力や立場の人がペアを組むことで、互いに影響し合えると。
＜探索的テストってナーニ？＞
非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果かも予測せず、毎回、テスト方法が変わる。（JSTQBシラバスより）
昨今話題の探索的テストですね。
中岫さんによると。。。
非公式なテスト設計技法のひとつ。テストを実施する仮定で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。
です。
ちなみに・・・・
＜似ているテスト＞
モンキーテスト
ランダムテスト
ゲリラテスト
アドリブテスト
意地悪テスト
一つ一つの意味は割愛しますが、よく混同されますよね。
ちなみに、中岫さんは「探索」の意味を深堀していました。
似たような言葉の比較をまとめていたのが面白かったので
掲載させていただきます。
これにより、「探索的テスト」の中岫さんによる個人見解は以下。
１、目的が必要
→見つけたい欠陥を狙う、観点が必要
２、何かを明らかにしなければならない
→欠陥を見つけなくても、なかったことを証明することも大事なこと
３．危険を冒す必要はない
→無謀な馬鹿げたテストは必要ない
４、ある領域を調べる行為
→まったく関係ない領域までテストする必要はない
「徘徊テスト」や「散策的テスト」には目的はないですし、
「探検テスト」や「冒険テスト」は危険（リスク／コスト）が大きすぎ！！！
というわけで、実際にやってみましょう！
＜今回の定義＞
・チームメンバー２人によるソフトウェアのテスト。
・一人は実際に操作し、もう一人は、議論しながらテストシナリオを作成する。
・２人のうち一人はテスターで、もう一人は、開発者またはビジネスアナリスト。
・正式なテストケースを用いず、探索的テストとして行う。
・ペアはチームメンバーが同等でなければいけない。
＜メリット＞
・開発者やビジネスアナリストは、別のビューからソフトウェアにアプローチ。
・ビジネス・アナリストとテスターの間で自動的に知識の共有。
・担当者と開発者で衝突することがあるが、ペアテスティングによって協力的になる。
・ペアで作業することによって緊張感を保つ。
・発見したバグはすぐに直される。
・ランダムに発生するようなバグの原因特定をしやすくなる。
・最も重要なこと。一緒に仕事することは楽しいです。
実際には以下で行いました。
１、参加者同士でペアを組む
２、ペア同士でどう進めるか考える（何をどうやってテストする？）
３、1セット30分交代で、交互にテスト
お題：中岫さん作の「FreeMindのデータをExcelで入出力する」ツール
・・・ここからは実践です。
ワイワイガヤガヤと、これぞ勉強会の醍醐味ですね～
今回は４チームで行いまして、それぞれのやり方で実施しました。
以下、チームごとの感想です。
--------
★ペア①
【やり方】
機能ごとにテスト担当を入れ替え
【感想】
・普段仕事している仲間なら良いと思うけど、上司とはちょっと・・・
・ただ、「偉い人」にも相応の観点があるので、いままでにない観点が得られるかも（やりづらいけど）
--------
--------
★ペア②
【やり方】
一人がやって、周りがガヤる
【感想】
・やりたいけど順番待ち、もどかしいことも
・方針や観点が次々浮かんでくるメンバーがいると心強い、周りから観点がもらえる
・テスト方針だけは最初に決める必要がある。ただ、方針変更は自在にできるのが良い。
・バグの切り分けなどの分析作業は一人でやった方が良いかも
--------
--------
★ペア③
【やり方】
仕様に沿ってやる
10分ごとに交代
操作に特化
目的をもって実施
【感想】
・アイデアだしが良かった、楽しかった
・相談できる人がいると心強い
・相談してやることで一体感がでる
・一人で考えるよりは複数人でやると観点が膨らむ
・それぞれの仕様を知っているかでアイデアの出方が変わる
・バグが多いとこのテストは成り立たないかも
・考えたり、分析するときは一人の方がよい
・３人で実施するのもありかなあ
--------
--------
★ペア④
【やり方】
どういうアプローチを考える
①仕様ベースと②利用者を決めてやる
ルールを決める（宣言とツッコミ）
ターゲットを絞る
【感想】
・思い込みで「流す」ことがなくなる
・バグが沢山でてきたときにデータを取りまとめるのにもう一人いると良いかも
・仕様の理解がたりないときとやバグが多いときにはもったいない。ある程度動くときに効果がある
・ペアなのでそのばで相談して解決するので、モヤモヤ感が減る
・やる人と記録係が分かれるので集中する
--------
・・・というわけで、ざっくりまとめると
「発想が膨らむことに効果大」
「効果が出ない状況もある」
「まずは楽しい」
だと思いました。
実際私はペア②に所属しましたが、考えていることを「口に出す」という事は
自身の考えを整理する意味でも、非常に有用だと思いました。
普段振り返ると、結構「ぼんやり」と手を動かしている時間ってあるものだなあと感じました。
あと、当然ながら自分にないモノを外部吸収できる作用は大きいです。
もっと違う立場の人と組むと、もっと違うのかもしれないですね！
（たとえば製品自体に精通した人とか、製品の運用／使い方のスペシャリストとか）
まあ、あとは費用対効果の面もあるので、そこは気になりますけど。。。。
誰かが言ってましたが・・・・
「今回のメンツでペアテストしたら、どんだけコストかかるんだろう？」
って（笑）
ただ、テストの一手段として採用したい方法だなと感じました。
特に、「教育」的側面だったり、発想をふくらますフェーズでは
有効だなあと感じました！
中岫さん、ありがとうとざいました！
次回は・・・・根本さんによる
「ゲーミフィケーション」です！！
by上田