QAおかもとです。
2013年1月30～31日に開催されたソフトウエアシンポジウムに参加させて頂きましたので、簡単なレポートをまとめたいと思います。
私は今年で3回目の参加になりますが、今年が一番人が多かった様な気がしますし、個人的にも興味のある講演が多かったです。
私の参加したセッションでは、主にテスト実装技術に纏わる講演がされました。
テストケースの問題箇所を特定する手法
テストであげられたBugは、あらかじめテストケースの評価項目や操作・結果に従って発見されたものなのか？または、そのBugを見つけたのは偶然だったのか・・？という事に論点をおいた講演でした。
確かに、テストケースには含まれていないけど沢山の条件やたまたまの偶然が重なり合ってBugを発見し、事なきを得る・・ということは無いですか？？
この場合、見つけたので良しとします！！とスルーするのは駄目で、本当はそういうBugにこそ学んで次回以降のテストケースの網羅範囲として生かすべき・・なのですが、次々と次回のリリースが控えている中で、リリース後に全てのBugを振り返って分析するという作業の時間を取るのはとても難しい事です。。
しかし講演者の方はそこに着目し、ある指標に基いて発見されたBugを分類・分析されたそうです。
結果、
偶然発見された、またはテストに不備がありながら(完全にはテストの確認内容や操作内容とは合致しないもの)発見されたBugは予想以上に多かったとの事でした。
つまりはテストエンジニアがまじめに書いているテストケースから、漏れているものが結構な数あったという残酷な結果です。
・・ちょっとぞっとしますが、何となく合点がいく部分があるのも事実です。
講演の内容はここで終わっていたので、ここからは恐縮ながら私の勝手な考察ですが、
全くテストケースには網羅されていない範囲のBugがどうして挙げられたか？
を考えてみますと、全ての機能を虱潰しに操作している以外で挙げられるのは、やはりテストエンジニアの経験による部分(影響範囲が分かっていることや過去にBugの出やすかった場所を知っている等)が大きいのではと思います。
例えば、偶然発見されたと言われるBugが10個あるとして、全くテスト経験の無いものが闇雲に操作を繰り返して同じように10個発見できるかと考えると、答えは・・？です。
そもそもBugだと気がついていたでしょうか？
「テストとは誰がやっても同じ・・」という言う話は、今回のシンポジウムでも何度か論議されていましたが、私もやはりそれは違うと思います。
確かにテストケースは、誰が操作しても同じような結果が返ってきて評価が出来るように書かれるべきですが、そこにどんな見地を加え、それを実行するかはテスト者に依存します。
では、更にここも考えてみます。
経験豊富なテスト者と新人のテスト者がいた場合、若しくは誰もが経験豊かなテストエンジニアと同じような成果を挙げるには何が必要か？
これは経験豊かなエンジニアによる過去に学んだ経験の共有、つまり具体的に重要になってくるのは「テストケースレビュー」なのではないか・・と思いました。
形式に則ってケースを作成することは出来ても、どこにボトルネックがあるか・どこに知られざる影響範囲があるか・・これは経験的に知っている、またはプログラムの構造を知っている者でしか知りえないところがあります。
これらを考えると、弊社QAではチーム内でのテストケースレビューや開発者によるテストケースレビューがありますが、とても理に適っている事だと思いました。
余談が長くなってしまったのですが、
上記の講演の他にもAWSを導入してテストを効率化した事例など興味深い内容のものはありましたが、jasstのサイトから近日資料が閲覧できるらしいので、詳細を確認したい方はそちらからどうぞ！
後は個人的に心に残った事を何点か。。
ベストプラクティスから学ぶことなんてない、ワーストプラクティスからこそ学べるのだ
これは基調講演をされていた岸田氏のセッションの中で出てきた言葉ですが、最近は成功事例に学ぼうという向きが強い傾向にありますが、実際は何の問題も起こらなかったベストプラクティスには学ぶところがあまりなく、むしろ失敗事例の中での学びは大きいとのことでした。
上記の 「テストケースの問題箇所を特定する手法」とも共通するところですが、
何故失敗したのか？
何故テストケースから漏れてしまっていたのか？
何故納期に間に合わなかったのか？
何故Bugは見逃されたのか？ ・・等々
そこを突き詰め、次には足りなかった部分・完全に抜けていた観点を補うような 一手を出さない限り次には繋がらない、学びにはならないという事を指していると言えます。
成長のサイクルを生み出すには、振り返りやフィードバックが大切ということでしょう。
テストエンジニアのやっていることは、開発者の頭の中の間違いを正すことだ
これは深い意味は無いですが、ほーーっと思いました。
じゃーQAの頭の中の間違いは誰が正してくれるのだ？と思ったのですが、多分それは仕様であり設計書であり、ポリシーなのでしょう。
今回の基調講演やクロージングセッションは、テストとは何ぞや？というかなり根本的なところだったり、社会的な側面であったり、ドストエフスキーが出てきたり・・と、哲学的な一面が多く個人的にはとても楽しかったのですが、色々と学びの多い機会で同時にもっと勉強しなくては！と奮起させられるものでもありました。
私もブラックジャック目指します・・
とまではいいませんが。。笑
