JaSST'16 Shikoku ソフトウェアテストシンポジウム2016四国 に行ってきました

こんにちは。中山です。
先日、香川大学教育学部キャンパス内で開催されました、
JaSST'16 Shikoku ソフトウェアテストシンポジウム2016四国

に参加してまいりました。

当日開催されていましたのは、高橋寿一氏の講演
「探索的テスト - 全機能テストできない、全部のバグを見つけられない時代の効率的なテストを考える」
と、安達賢二氏のワークショップ
「なんとなく実施するレビューからの脱却 ～目的・観点設定に基づくレビューの効果を体感してみよう！」
の2つ。
都合により私は、前半の「探索的テスト 〜」の講演だけしか受講できなかったのですが、ソフトウェアテストに関しての、私自身も普段から悩んでいる問題に対して、こんなアプローチがあるのか、といろいろと新鮮な気づきがありました。

「探索的テスト - 全機能テストできない、全部のバグを見つけられない時代の効率的なテストを考える」
の講演の講師である高橋さんは、書籍「知識ゼロから学ぶソフトウェアテスト」の著者の方でした。私も本屋さんで手に取ったことがあったかもしれません。

知識ゼロから学ぶソフトウェアテスト 【改訂版】

この高橋さんがまず最初に言われていたのが、
「プログラムのすべてをテストすることはできない」
ということ。
たぶん、プログラムを書いている人は、多かれ少なかれ、この点に関しては実感があるのではないかと思うのですが、一方で、業務においては、やはりテストコードの網羅率が重視されたりもします。
しかし、近年、OSS の活用の割合も大きくなっています。
純粋に自分たちで書いたコードに対してだけ、テストコードを設けていたりするパターンですと、プログラム全体に対するテストコードの網羅率は、見た目の上では小さくなったりします。

また通常、ソフトウェアテストは、プログラム開発側（またその発注側）が作成した要件定義を満たすかどうか、という観点で行われますが、一般的に、実際にそのプログラムを利用するエンドユーザは、開発側が思いもよらなかった使い方をすることが少なからずあります。
その意味で、プログラムの開発の時点では、すべてのパターンを網羅することはできない（利用パターンを想定しきれない）、とも考えられます。

実際に、Google や、Amazon、Facebook など、「今どきの」企業では、とにかくまずリリース、ということが優先であり、テストの網羅率、というのは、結果的にそれほど重視されていない、というお話もありました。

ここ最近、「DevOps」「アジャイル」「Scrum」など、開発手法自体の進化は目覚ましいのですが、ことテストになると、旧来の

• 網羅性を最優先する
• ケース作成、テスト実施などにコストがかかる
• 実施に時間もかかる

という形から、なかなか変われていないのではないか、というご指摘でした。（確かにそうかも。）

これを改善するために提案されていましたのが「探索的テスト」です。

探索的テストとは、ソフトウェアテストのひとつのスタイルであり、
端的に表すと、

• スキルのあるテスト担当者が
• テストケースは書かずに
• 対象のプログラムの目的、機能を明確にしたうえで、
• バグが潜在しやすいと思われる部分を重点的に検証する

という活動を、継続的に実行していく、というものになります。
とにかく、テストケース書くのって、いつもものすごく時間がかかるものなので、その時間もテスト実施にあててしまって、その分、バグを多く見つけましょう、というテスト手法のようです。
（ただ、全くドキュメントを作成しない、というわけではなく、タスクシートという、テスト合否基準を記載した資料は作成するようです。）

• すぐにテストに取り掛かることで、早くバグを見つけられる、
• バグが潜在しやすい部分（弱い部分）を重点的に検証することで、より多くのバグを見つけられる、

という特徴があり、アジャイルなどとも親和性の高いテスト手法だとのことでした。

しかしこの中の「スキルのあるテスト担当者が」テストを実施する、というのが最大のポイントです。
ここでいう「スキルがある」というのは、

• ソフトウェアテストの手法を理解していて、
• 利用しているプログラミング言語にも理解がある

というのを意味しているようです。
（そもそも、そんな優秀なメンバーがテストを担当するのであれば、探索テストに限らずとも、スムーズにテストを遂行していけそうな気もするんですが、）とにかく、スキルのあるメンバーが担当することで、最大限効果を発揮するテスト手法とのことです。
確かに、「勝手」がわかっていないと、表面をなぞっただけのような検証になってしまって、あまり効果が期待できないのかもしれませんね。

しかし一方で、パフォーマンスなど非機能要件を検証する場合ですと、探索的テストの手法では十分な検証が行えるとはいえず、従来の、テストケースベースのテスト手法が有効となります。
探索的テストに色々利点があるとはいっても、従来のテストケースベースのテストともうまく組み合わせて、進めていくのがよい、とのことでした。

講演の最後に、私はいつも気になっていた、「プログラム開発者が、テストをそのまま実施しても良いのか」という点を、講師の高橋さんに聞いてみました。
高橋さんによると、いつも、リソースに余裕があるというわけではないだろうから、開発者がテストも実施する（テスト専用のメンバーを用意できない）、というのはしかたないだろう、とのこと。ただし、自分の書いたコードは、必ず別のメンバーがテストする、というふうにしておけばよいでしょう、とのことでした。
また、10人くらいのチームで開発するのであれば、そのうちの1人は、品質管理専門のメンバーとして、コードレビューやテストなどを専門に担当する、という体制にするのがよいのではないか、とのことでした。

ソフトウェアテストに近道はないのかもしれませんが、今回の探索的テストも含めて、いろいろな手法を積極的に取り入れていくことで、結果的に、少しずつ効率・品質アップにつながっていくのかなと感じました。