テスト勉強会の第1回が無事に終わりました。
勉強会の範囲はJSTQBシラバスの第1章でした。
今回は24名の方が参加してくれました！
ありがとうございます。
少しですが報告をしたいと思います。
仙台駅近くのAERの5階。19時少し過ぎから講義を始めました。
最初は第1章のポイントを少し解説しました。
・バグ、欠陥、エラー、故障、フォールト、誤りの使い分け
・テストはバグ見つけるだけじゃなくて、色々な目的があるということ
・7原則のいくつか
原則1：テストは欠陥があることしか示せない
原則4：欠陥の偏在
原則7：「バグゼロ」の落とし穴
・テストのプロセス
・テストに関わる人はモラルをもって、専門職としての地位向上に努める必要があるということ
このあとにテストが必要かを演習を使って考えてみました。
演習1:可変速の動く歩道（歩く歩道じゃありませんよｗ）
可変速というのは乗るときはゆっくり、途中は速く、降りるときはゆっくりの動く歩道です。実は本当にあるんですね。日本ではIHIが作っています。
まずはこの動く歩道についてテストを考えてもらいました。
皆さんの答えを見ていると、手すりが壊れないか、つまづかないか、耐水性、耐震性など沢山挙げてもらいました。なるほど～～～。自分が考えたときにもない答えが沢山でましたね。すごいです！！
その後は隣の方のテストと見比べ。色々な視点があると気づいたと思います。
他の人に見てもらうってやっぱり重要ですよ。
ここで少し考え方の説明をしました。
バグを出すという目的ですと、まずこのシステムで一番起こってほしくないことを考えます。リスクベースドの考え方ですね。この事例だと自分だったら以下についてテストしておきたいと思います。
1.人間が怪我をすること
2.機械が壊れること
人間が怪我をすることについて考えてみます。
そうすると、靴が挟まるとか、速度の変化で転ぶとか、ぼんやりと考えるより色々でてきます。人間の思考って面白いですね。
さらに利用者がどういう動きをするかを予測することでさらに出てくるんじゃないでしょうか？
横向きに乗って話している人は大丈夫かとか、動く歩道の上で走る人は大丈夫かとか、足が悪いおじいちゃんは大丈夫かとか、混雑しているときは大丈夫かとかですね。
実はこの可変速の動く歩道、パリで実際に導入されたもので開始すぐに転倒事故が多発し、閉鎖してしまったようです。
演習2:架空会社ザキヤマパンの事故事例
これはザキヤマパンの見習いがパン焼き時間に-35を設定してしまうことで内部的に4294967261という大きな値が入ってしまい、ボヤ騒ぎになったというものです。
説明のときにパンの累積枚数の箇所でJoJoネタを入れたのですが、全くのスルー。でも次回も入れます！
まずはエラーと欠陥と故障の分類分け。
この例の場合は分類は以下のようになると思います。
操作のときのミスは広義の意味ではエラーなのですが、故障の一部ということになるんじゃないでしょうか？
＜エラー＞
・画面の開発者は禁則文字のことを考えていなかった
・MINのチェックをし忘れた
・制御の開発者は値のチェックをしないでいいと思った
・MAXの60分を超えたときに、停止する仕組みを付け忘れた
など
＜欠陥＞
・禁則文字のチェックが行われていない
・MINのチェックがされていない
・制御に値のチェックが入っていなかった
・60分を超えたときのインターロックの仕組みが抜けていた
など
＜故障＞
パン焼きマシーンが黒焦げになった
講義中には回答例を出しませんでしたが、ちょっとぼんやりしたかもしれないですね。
次回からは出してみたいと思います。
その後にどのようにテストをしたら防げたかを考えてもらい、次に同じことを起こさないためにどうしたらいいかということを考えてもらいました。
そしてこれってプロセス改善になってますよね？という話をしました。
さあここでお待ちかねの現役QAの福島さんのLTです。
ほとんどのソフトウェアは保守との戦い。
テストの手を抜くとデグレスパイラルに陥るということです。
福島さんは影響範囲分析が必要と言ってました。
やっぱりQAをしている人の言葉は重いですね。しかもかなりウケていたと思います。
福島さんのお勧めの本は『えー、全部テストするんですか?―いまさら聞けないソフトウェア・テストのやり方』
最後は参加者に開発～リリースまでのプロセスを書いてもらいました。
開発に比べてテストのプロセスって少ないですねという話をしました。
本当はこの後テストのプロセスを説明しようと思ったのですが、時間がなくなってあまりできませんでした。参加者の皆さんすいません＞＜
来月は手を動かしてやってみましょう！！
楽しみにしててください。
最後にGoogleの品質の考え方は開発とテストを融合していくというアプローチで面白いですねという話をして勉強会は終わりました。Microsoftとは全く逆のアプローチに見えます。
At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other.
By James Whittaker
今回の勉強会をきっかけに自分のテストの意味、品質などを再確認してもらえると嬉しいです。
それでは また来月会いましょう！！
最後に参加者の皆さん、実行委員の皆さんどうもありがとうございました。