MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST15北海道(1)「基調講演：探索的テスト-アジャイル時代の効率的なテストを考える」

JaSST Hokkaido Conference exploratory testing

　9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
　私が参加したセッションは下記です。

セッション1　基調講演：

　「探索的テスト - アジャイル時代の効率的なテストを考える」

セッション3-3　探索的テストチュートリアル：

　「やってみよう！探索的テスト。テストの常識を変えませんか？」

セッション4-1-1　ライトニングトークス
セッション4-1-2　ビブリオバトル
セッション4-1-3　JaSST Hokkaidoセッション：

　「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」

　今回は、セッション1-1「探索的テスト - アジャイル時代の効率的なテストを考える」の内容で印象に残ったことをメモとしてまとめました。

セッション1　基調講演：「探索的テスト - アジャイル時代の効率的なテストを考える」 高橋 寿一

(1)講演資料

　下記、JaSST'15 Hokkaidoレポートに掲載されていますので、参照下さい。

http://jasst.jp/symposium/jasst15hokkaido/report.html#keynote

(2)網羅せずにどうやって品質を担保するか？

　デイリーリリースに対応するには？
→今までのテストのやり方で解決できない。

　そこで、探索的テスト。

(3)開発現場の状況

(3-1)アメリカ(90年代)
  • システムテスト
    • テクノロジーがあれば、システムテストで全部のバグ見つかると妄想していた時代。
  • Cem Kaner
    • 全数テストは無理なので、探索的テストを考案。
      →全数テストしきれないので、やり方を転換した。
(3-2)スクラム、アジャイル
  • スピードが要求される
    開発スタイルによって、テストのやり方を変える。
  • 自動化テスト
    Salesforce社などの企業で進んでいるが、日本は逆にあまり進んでいない。
(3-3)ゆっくり手動テストとかしていませんか？

　開発スピードが速い状況で、ゆっくり手動テストするやり方がよいのか？
→旧来のテスト。

(3-4)旧来のテスト
  • 徹夜したテストが実りあるものか？
  • 現在は、開発者がコード書く速度が速くなった
  • 網羅できているか？
    • しかし、網羅するにはコストがかかる
    • 自動車系：膨大なコードで、(網羅したテストが望ましいが)全部テストするのが難しいジレンマが...
(3-5)スキルのあるテスター

　テスターの給料は、開発者より安い。
→しかし、テストはスキルが必要。特に創造力が必要。

(4)探索的テストとは？

(4-1)ソフトウェアテストの1つのスタイル

　スタイルと手法は違う。

(4-2)テスト手法を駆使して探索的テストする

　境界値分析や状態遷移テストなど。
→細かいテストケースは書かない。書く暇があったら、テストしよう。

(4-3)同時実行

　短時間で分析～実行を行う。

(4-3-1)省くのは文章化

　時間がかかるのは、文章化である。

(4-3-2)省くのは文章化時間がかかるもの
  • 仕様の不明点を聞く
  • 無駄な会議

　上記は、テストしていない時間が多い。つまり、製品品質を上げる時間が少ないと言える。

(4-4)バグ発見
(4-4-1)テストケース10万件の0.5%しかバグ発見できない。

　テスト仕様を書く時間で予算が多く費やされる。

(4-4-2) テストケースからは見つからない
  • スキルのあるテスターが触りながらテスト。
    • バグが見つかる。
    • テストケース書かなくてもよくないか？
(4-4-3) 修士論文＠フロリダ工科大学大学院の話
  • 「自動化で繰り返しテスト」
    • Cem Kaner:
      「それでバグが見つかるか？意味があるか？」
    • 教訓:
      バグの原因を開発者と考えることが大切。
(4-5)テストケースベースドの限界

　要求が不明確で、変化するかもしれない。
→モノが出てから考える。

(4-6)要求仕様
(4-6-1)「要求仕様の抜けからバグが出てくるのでは？」 by 高橋寿一氏
(4-6-2)形式手法で書けば...

　前提は、ちゃんとできるならば。

(4-6-3)早い段階で要求仕様のバグを発見

　例えば、仕様追加部分でささっとテストして1～2日程度で済ませる。

(5)探索的テストのやり方

(5-1)情報源
(5-1-1)"General Functionality and Stability Test Procedure"

・James Bachの資料
　http://www.satisfice.com/tools/procedure.pdf

　「本資料をベースに探索的テストをやってみては？」 by 高橋寿一氏

(5-1-2)Cem Kanerのサイトに膨大ない資料がある

　http://kaner.com/

(5-2)探索的テストの定義

　人によってバラバラ。

※補足：
『ソフトウェアテスト標準用語集 日本語版 Ver.2.3.J02』では、下記で定義している。

非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。[After Bach]

　「Cem Kanerベースで定義を築きあげるとよい。」 by 高橋寿一氏

(5-3)探索的テストの成果
  • バグの数、市場バグの数
  • ウォータフォールのテストと比較してみる。
    探索的テストチーム vs スクリプトテストチーム
(5-4)探索的テストとランダムテストの違い
(5-4-1)ランダムテスト
  • 戦略が無い
  • モンキーテストと同義
  • 単位時間当たりのバグ発見件数は少ない。
(5-4-2)探索的テスト
  • 戦略がある。
  • 単位時間当たりのバグ発見件数は少ない。
(5-5)多くのテストケース
  • 殆どが無駄になる。
  • 一方、開発者の「嫌だな～」というところをテストケースを作ると、バグが出てくる。
(5-6)バグがどこに出てくるか？
(5-6-1)最近の傾向(研究)
  • ファイルが長い(サイズが大きい)
  • ファイルが頻繁に変更
(5-6-2)7%(hotspot)のファイル

　理論的には全てのバグが出る。

(5-6-3)80%のバグは全体の20%のモジュールから発見され、50%のモジュールにはバグは含まれていない。

　50%のモジュールから市場不具合としてインパクトは小さい。
→レアケース

(5-6-4)テスト実行前に何のコンポーネントがバグがあるか分からない。
(5-7)タスクシート
  • テストリーダが戦略を書くべき。
  • ノウハウを共有するという意味でで書いておくとよい。
  • テストケース(状態遷移とか)を考えるようなスキルセットが必要。
    • 何かニオイを感じる人。
    • 戯れているだけの人。
(5-8)探索的テストで大切なこと

　ユーザにとって嫌な思いをさせないテスト。

(5-8-1)ユーザにとってそのソフトウェアをユーザの権利を奪わずにテストを担保できるか？
  • 例：Excelの90%は使われていない機能。
    • どこが必要な機能か？
  • 頭を使う
    • 要求仕様
    • ユーザクレームから、製品のあるべき姿を考える。
    • ユーザ視点を考える。
(5-8-2)バグの出るポイントでちゃんとテスト
(5-9)ドキュメント
  • 最低限、戦略は書く
    • Pass/Fail基準
  • １つ１つのテストケースは書かない

(6)探索的テストの注意点

(6-1)非機能テスト(セキュリティなど)は探索的テストをあまりやらない
  • 理由:
    • 大変なため
(6-2)ユーザビリティテストは有効
  • 理由:
    ユーザ視点なため。
  • BTSに登録しにくい内容だが、テスターをユーザビリティテストに参入させるとよい。
(6-3)探索的テストのみに頼らない。
(6-4)終了判定

　基準を決めておくとよい。

「"テストケース99.7%Passしたら出荷する"や"信頼成長曲線が寝たら..."は、違和感がある」 by 高橋寿一氏

(7)探索的テストの人材の問題

　どういうスキルが必要か？
→プログラミングのスキルは必要。アメリカでは、コード書けるテスターが必要。

(8)Q&A

Q1：探索的テストで品質担保の説明をどうすれば...
A1：テストケースから品質担保の説明はできないと思う。
  • コードの20～30%しかテストできていないのため。
  • どうやって品質を担保できるかというone of themで探索的テストがある。
Q2：探索的テスト初期段階に陥りやすいことは？
A2：数チームでやりながら悩んで、メトリクスを取ってみる。

　探索的テスト以外のチームと仲良くなり、探索的テストと探索的テスト以外で比較してみる。

Q3：「探索的テストの人材」の話でプログラミングスキルが必要と言及していたが、どういうところで必要か？
A3：境界値テストの場合、プログラミングのif/else文を理解する必要があるから。

　例えば、sleep()のところにバグが多いな！など。
→プログラミングの構造を知ることが大切。

所感

　探索的テストとad hocテスト/ランダムテスト/モンキーテストの違いがよく分からない話題が時折見かけるが、「戦略の有無」がポイントの1つであることに気付いた。また、タスクシートでPass/Fail基準を明確化すると、ad hocテスト/ランダムテスト/モンキーテストに陥らないので、工夫する内容の1つとして実践しようと思います。
　私の中で暗黙的にPass/Fail基準はあるが、製品のあるべき姿を開発者と話したり、インシデントレポートに図解することで形式知として共有することを続けていこう。
　今後の課題は、プログラミング構造を深く知ることである。テストケースを細かく書かなくても、バグを発見できるようにすることで、開発で手戻り工程が少しでも減らせるよう、多少のテストケースを書きながら工夫してみようと思う。

　過去の私が書いたblog記事も探索的テストを実施する際のヒントになると思いましたので、時折読み返そうと思います。 masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com