MasaoApril's Library.

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

JaSST'15東京(1)「How To Get What You Want From Testing(for Testers, Developers, and Managers) あなたの欲しいものはどうやってテストから手に入れるか？ ～テストエンジニア、開発者、マネージャのために～」

JaSST Rapid Software Testing Michael Bolton Conference

　2015/2/20(金)～21(土)に開催されたソフトウェアテストシンポジウム'15東京(JaSST'15 Tokyo)に参加しました。私が参加したセッションの内容を数回に分けて書いてみます。
(※おことわり：チュートリアルは有料セッションですのでblogに書けません。予めご了承下さい。)

　今回は、基調講演「How To Get What You Want From Testing(for Testers, Developers, and Managers) あなたの欲しいものはどうやってテストから手に入れるか？ ～テストエンジニア、開発者、マネージャのために～」です。

基調講演「How To Get What You Want From Testing(for Testers, Developers, and Managers) あなたの欲しいものはどうやってテストから手に入れるか？ ～テストエンジニア、開発者、マネージャのために～ Michael Bolton(DevelopSense)

基調講演を聴講する前に予習したスライド

　Michael Bolton氏のサイトDevelopSenseで公開されている"Rapid Software Testing"のスライドを一通り読み、下記に示す記事にまとめてみましたのでご参考頂ければ幸いです。

(1)"I'm biased Towards Rapid Software Testing."

  • テストする人間が中心にいる
  • 迅速かつ安価にテストできるか
  • "Rapid Software Testing"もたった1つの正解はない
  • 製品やプロジェクトに順応する必要がある
  • http://www.satisfice.comを参考のこと

(2)ダメなソフトウェア

  • エラーメッセージの意味が不明
  • トラブルシュートできないエラーメッセージ
  • 同じバージョンのソフトウェアをインストールすると、アップデートの文字が...

等々...

(2-1)共通点：感情的に反応

(a)なぜ、テスターがエラーメッセージをみて「これでいいや」と思ったのか？
(b)色々な感情
(b-1)ソフトウェアの問題を指摘している

　我々に何かの感情を教えているかもしれない。

(b-2)テストするときに退屈することはあるか？

  • もしかしたら、やっている作業が重要でない。
    →熱意を持ってテストしていない？疲れている？

  • 退屈しているなら、やり方が間違っていると考えよう。
    →そんなときは、新鮮な空気を吸ってみよう。

(2-2)感情はヒントとなる

(3)ソフトウェア開発で不思議な考え

(3-1)工場のようにやれば効率的か？

  • 最初は、設計されていないといけないということを忘れている。
  • どうやってプロセスを設計するか？
  • ソフトウェア開発は、クリエイティブである。

(3-2)学習や調査などが必要

　設計したものを理解する必要がある

(3-3)組み立てると複雑になる

　最初にモデルを作るとき、上手くいかない。
→そこで、学ぶ必要がある。

(3-4)注意深くやらないと物事に問題が発生する

(4)スキルをみつける：口で伝えられない知識(暗黙知)

(4-1)例：コーラの蓋を開ける方法

　誰かがコーラの蓋を開けるのを見た。

(4-2)明示的に学習する方法

　説明を受けて学ぶ。

(4-3)学習が深くないかもしれないが...

  • 本を読む
  • 経験を聞く

(4-4)もっと強い学習

　文化の中でやっていることを見る、やってみる。

(4-5)テストプロセス

(4-6)行動することによって学ぶ

  • 間違いを犯して学ぶ。
    →間違っても支援も得られる。

  • 間違いは必ず発生する

　子供が自転車乗って転倒する
→周りがすいすいと自転車に乗っているのを見て学習する
→何度か練習して、すいすい乗れる

(4-7)問題が起こることを配慮していない

(4-8)固執しているもの

(a)(車の)ダッシュボード
  • 例えば、評価やKPIなど
  • (車の)ダッシュボードのみを見ていると事故が起きるぞ！
  • もし、ダッシュボードが表示されていなかったら...
    →ダッシュボード外の様子が分かったほうがいいよね？
(b)数字は、理解するための情報
  • 燃費の重要度
    →乗車するときは重要度は低い。

(4-9)テストケース

(a)合格できるテストケースが多ければよい？

　数字はいくらでも変えることができるので...

(b)サイエンスはサイエンスケースを利用している？
(c)なぜ、テスターが話題にする
  1. マネージャが分かりやすいから
  2. マネージャが聞くから
  3. テスターが話す
  4. ...(以下、ループ)
(d)もっと上手くやれるよ！

　テストするのは何の意味があるか？ →チェックすることとテストすることの違いを学ぶべき。

(d-1)学習はheuristic(試行錯誤)プロセス
(d-2)モデルから学ぶ
  1. 製品のモデル
  2. 要求のモデル化
  3. テスト実施のモデル化
(d-3)テスターの中心にテストが存在する

(5)Heuristic(試行錯誤)

  • ガイドラインや経験則
  • heuristic(試行錯誤)な方法で問題解決する
  • 完全に理解できないものも取り扱う

(6)チェックはテストではない

(6-1)動かして○○であることを判定することをチェック

　アルゴリズム的なこと。

(6-2)チェックの要素

  1. 観察
  2. まちがっているか、正しいか？

  3. 1.と2.がプログラムによって判定できる

    • 正確にチェックできるが、考えることはできない。
    • 多くのテスターは、機械のようにやれと(上から)言われている。

(6-3)テストはチェック以上のもの

  • チェック＝確認
    →仮説がある？
  • プログラムは多くの問題がある

(7)Harry Collins on S/W Testing

(7-1)チェックとテストの違い

  • Harryは社会学者
  • 科学者はどう意思決定しているか？

(7-2)コンピュータとS/W

(a)機械がある
  • ギアが絡んでいる
    　歯車のチェックのような
  • 社会プロセス
    　弟は左手を失い、義手を使っていた。しかし、成人になってから義手をやめた
(b)足りないものを補填しているものがコンピュータ
(c)人間が必要としている暗黙知がない
  • 社会に溶け込むことができない。
  • 順応する必要がある。
  • 学習しなくて使い続けるか？
  • 社会的な判断が必要。
  • 製品を利用して満足するか？
  • チェックは、社会的コンテキストが無い。

(7-3)テストの中にチェックを埋め込む

(8)七面鳥の話

(8-1)幸福度を手帳に記録

　えさ、水、柵などが豊富にあって幸福度は高かったが、Thanks giving dayで一気に下がった。

(8-2)S/Wは複雑なもの

(8-3)テストが合格しなくてもよいかもしれない

(8-4) 2 + 2 = 4

　もし、2+2+=6だったら...
→次回のテストが2+2=6になっていると期待していない

(8-5)ソフトウェアが上手くいっているとだまされているかもしれないと思う

(8-6)戦略を変えながら、ソフトウェアの問題を探す

  • リスクがあることを知ってもらうこと
  • 問題を見つけること
  • 設計者が品質を上げればよい

(9)Testing is ...

(9-1)探求/学習/製品を評価/試行

  • 製品を研究する。
  • 人々は欲しがっているか？

(9-2)スキルを身につける必要があるし、動機、信頼性も必要。

　テスト手法などに疑問を投げかける必要がある。
→問いかけ続ける。

(10)What Is Testing

(10-1)価値のあるテストになるには？

　以下の製品の側面を見る必要がある

  • 歴史
  • アーキテクト
  • 言語
  • 文化

(10-2)Windows Vista

　16万件のビルドとテスト。
→つまらないテスト。
→テストをやりましたと言うが、製品が気に入らんと気付かなかった。

(10-3)うまく動く、動かないということを学ぶこと

(11)Testing is about Learing and Adaptation

(11-1)学んだことのレポート

  • 探索
    　アイディア→実行→発見→調査→学習→報告→アイディア→(以下、ループ)

  • クライアントの感覚(センス)が必要
    　クライアントの代わりに製品を触ることができる

(11-2)知っていることと知るべきこと

　テストは、ギャップを縮めること。

(12)重要なword

  • Bug
    　問題があったらバグ
  • Issue
    　テストの価値を脅かすもの
  • Coverage
    　製品の中でどれだけテストしたか
  • Oracle
    　問題に気付く(問題を認識する)

　素晴らしいテスター
→常に問題を探すことだ。Pass/Failを判断することだけではなく。

　Issueがあったとき、「こんなのでいいのか？」と合理的にテスト

(13)3つのストーリー(三本の紐を三つ編みにして、三本の矢のように強固)

  • 製品の状態についてのストーリー

　バグ。

  • 製品がどのようにテストされたことについてのストーリー

　○○のテストより、△△のテストの方をやったほうがいいねとクライアントと合意する必要がある。 →重要なことを見極める。

  • どれほどテストがよいか？ということについてのストーリー

　問題を常に知る必要がある。

(14)モデル

(14-1)複雑なアイディアを簡略化した表現

　飛行機や気象図、ファッションモデル、数学など

(14-2)多彩な戦略が必要

  • どうやってテストするか？
  • 問題を認識するには？
  • Oracleを使う
  • 背景を見る

(15)要素

(15-1)プロジェクトの環境

MIDTESTED
  • Mission
  • Information
  • Developer Relations
  • Test Team
  • Equipment & Tools
  • Schedule
  • Test Items
  • Deliverables

(15-2)テストの方法

FDSFSCURA
  • Function Testing
  • Domain Testing
  • Stress Testing
  • Flow Testing
  • Scenario Testing
  • Claims Testing
  • User Testing
  • Risk Testing
  • Automatic Checking

(15-3)製品の要素

　あるモデルでカバーした。

SFDIPOT(San Francisco Depot)
  • Structure
  • Function
  • Data
  • Interfaces
  • Platform
  • Operations
  • Time

(15-4)品質基準

　製品を愛する。

CRUCSSCPID
  • Capability
  • Reliability
  • Usability
  • Charisma
  • Security
  • Scalability
  • Compatibility
  • Performance
  • Installability
  • Development

(16)Oracleの一般的な例

(16-1)Oracle

　問題があるか否か

(16-2)良い問題、悪い問題

(16-3)パターン

　統計的なパターンを示すなど。

(16-4)メカニズム

(16-5)専門家(開発者も)

　曰く、「○○は問題があると思うけど」

(17)忘れてはいけないのは感情(Feeling)

　合否判定といったドライなものではなく、生まれてくる感情を考慮する必要がある。

(18)継続性：問題の認識

  • 何か混乱することがあったら
  • かつて○○だったのに違う動きになっているなど
  • 質が悪い
  • 製品を使ってやりたいことと違う場合も
  • どこかで一致しない場合
  • 規制に合わない

(19)Is Regression Yor Biggest Risk

(19-1)回帰問題

　テストでやるべきでない。開発などで解決する問題。

(19-2)回帰のパターン

(20)Rapid Software Agile Testing Ecosystem

(20-1)資料の在処

　http://www.developsense.com/past.html の"December 2014"→"December 4"の文中にある"Rapid / Agile Software Testing Ecosystem"を参照。

(20-2)リンク先(PDF)

　http://www.developsense.com/presentations/2014-12-04-SAST-AgileAndRapidTesting.pdf

(21)テスターにとって向かない質問

　「出荷してもよいか？」 →テスターの仕事ではない。オーナーの仕事。

(22)テスタにとって良い質問

　「製品のストーリーは何？」

(23)Tester Light the way

　『プロダクトオーナーが意思決定できる情報を提供するのがテスターの役割』 →社会に対し、貢献できるか？

所感

　基調講演を聴講して印象に残ったのは、『(2-2)感情はヒントとなる』と『(4-6)行動することによって学ぶ』の2点です。 私やテストチームメンバーが実施したテストをふりかえると、「感情が問題を認識することに寄与」したり、「テスト対象及びテスト対象に取り巻く人/物/事を探求するために行動」することで、開発者にリスクやユーザビリティなどの情報をフィードバックしていたことに気付きました。また、日科技連 SQiP(Software Quality Profession) ソフトウェア品質のホンネ(第161回)「シンクロニシティな世界アジャイル、欠陥エンジニアリング、そして要求開発編」永田 敦さんの連載：http://www.juse-sqip.jp/wp3/honne/backnumber_161/ "13.細谷さん"にも言及されていますが、『フィードバックの設計』に繋がる話だなと思いました。
　本稿を書いているとき、「ソフトウェアテスト293の鉄則」の鉄則1『プロジェクトの行く手を照らせ』及び鉄則27『テストとは探求することだ』を思い出しました。じっくりゆっくり読み返し、これからのプロジェクトにテストから、何に対し、どのように貢献していくかを問いかけてみようと思います。