本日はソフトウェアテスト勉強会のテストプロセス編。
ゲストの講師に鈴木三紀夫さんをお迎えしての勉強会になります。
今日集まった参加者は21名。
日曜日の午後の貴重な時間を勉強しに来てくれてありがとうございます！
そして驚くべき参加者。名古屋のカリスマKENさんも緊急参戦。
自分の方から鈴木さんを簡単に紹介して、タッチ。
今日は聞くほうに回ります。楽しみデス。
まずはJSTQBの話。
用語が通じないとどうなるのか？
オフショアでの単体テストの例など、経験をベースにお話してくれるので分りやすい。
確かに言った、言わないになってお金が絡んでくるのでお互いの定義をあわせないと！！
そしていよいよテストの話。
テスト技法の使い方は誰も教えてくれない。
確かに会社で網羅的な教育はやらないかもしれないですね。
ここで鈴木さんから質問。
『テスト技法を適応するとケースは増えるか、減るか？』
自分の答えは「目的による」。網羅したいと思って、そういう技法を使えば増えるし、
減らしたいと思えば減るでしょうと思った。
勢いのある学生が削減派で自分が思っている理由を答えている。凄いっす！！
鈴木さんは、組織に状態に寄りますという答え。
ケースをきちんと作っていない組織は増えるし、そうでないところは減らせる。
後の質問で出てたんだけど、3～4倍、多いところでは10倍のテストケースになるらしい。
10倍でたらどうするんだろ・・・
マインドマップとテスト技法の結びつきの説明。
マインドマップはテスト観点に基づく方法。
ちょっとTwitterを確認すると東京のテストクラスタの方がエア参加。
みんな凄いなぁ。ってか嬉しいです！！
鈴木さんはどうしてテストが上手く行かないかを
自動販売機の例などを出して説明してくれる。
ここでビックリしたのは、『テストのモデルは開発のモデルと違う』ということ。
マジか！！！
これは相当ビックリした。自分は開発でキチンと書いていたら問題ないと思っていた。
しかし、バグを出すためには仕様書どおりにテストしてはダメだと。
そして自分達の現場にあった設計をするべきというアドバイス。
言われるとそうなんだよね。
本には皆分るように標準的なところが書いてあって、
いざ自分の現場に適応しようとするとなかなかできないっていうことが多い気がする。
ここで演習1
「自分の組織においてテストケースに関する現状はどうなっていますか？」
「あなたが組織のテスト改善担当者に任命されたとして自分の組織を見た時どのように報告しますか？」
・急いでいるときはなんとなくやってしまうときがある
・ケースの数はまちまち
・影響範囲分析ができていないところがある
・フォーマットに囚われてしまう
：
そしてテスト観点のお話。
鈴木さんは「ぼくは昔から大中小スタイルのテストケースが嫌い。大中小の良くないところはこの大中小の分割に縛られてしまうところ。」というところで、フォーマットに囚われてしまうと似ているかな？！
気になった言葉は、『そこにバグが潜んでいるから、テスト技法がある！』。
名言ですなぁ。やっぱり、テスト技法は手段なんだよね。
開発で言えばデザインパターン、もっと広く言えばソフトウェアも同じだと思う。
でも気をつけないと手段が目的になっちゃうよね～
ついで演習2
「自分達の組織のテストプロセスはどうなっているでしょうか？」
色々書いてみるけど、かっちり決まったプロセス、成果物は無いんだよなぁ。
テストレベルとアクティビティの関係。
ヘビーなテストプロセスじゃないと、太刀打ち出来ないのが、今のソフトウェア。
人命に関わったり、リコールしたり本当にお金がかかるよね。
昔はテストは実行するものだったけど、どんどん細分化されていった。
これはテストも開発と同じようなレベルになってきた証拠なんだろうなぁ。
講義の資料ではないけど、経済産業省のプレゼンの抜粋。
コード行数が凄い勢いで伸びているよね。。。
このメンテナンスなんて本当に大変だと思う。
テスト計画の話。
テスト計画って「何が分らないのかを共有するもの」。
なるほど、この定義は分りやすい。テスト情報共有っていう感じなんだろうなぁ。
この計画はジワジワと修正されていく。
鈴木さんが計画が真ん中にある図を出した。
計画は全てと関連があるっていうことなんだね。
このジワジワ修正はPMBOKではローリング・ウェーブ計画法というものらしい。
ここでちょっと休憩。休憩の間にも気になった人から質問が出ている。
うん せっかくの機会なので沢山聞かないと！！
休憩明けはついにお待ちかねの3色ボールペン法。
3色ボールペン＆マインドマップの黄金コラボ。
ここで鈴木さんからアドバイス。
「色々なところでコンサルをやると技法を使う以前という点に気がついた。そもそも仕様書が読めていない。この仕様書のおかしいと感じるところをトレーニングすると実務でも効くよ」とのこと。
マインドマップでテスト対象の分析し、そこに技法を結び付けていく。
技法が出てくるのはマインドマップの枝の部分に出てくる。
技法だけ学んでも適応できないのはここなんだろうなぁ。。。としみじみ。
鈴木さん曰く、マインドマップは最初は手書きがいいとのこと。
自分の間違ったエビデンスが残り、それが価値になるとのこと。
なるほど。きちんと振り返れる環境を作ることが重要なのですね！！
そして実際のワーク。
お題は西暦和暦変換機能のソフトウェア。
マインドマップに書いてみると、その過程でポコポコと思考が生まれるのが分る。
脳は知らないうちに色々気にしているんだね。
せっかくなので、自分が書いたのを公開してみます。
テスト観点に関わる視点・視野・視座の話を少し。
テスト観点はレビューや要件定義でも使えるというアドバイス。
近頃はソフトウェアの作成と品質が近づいてきた感じがするので、
設計、コーディング時にもテストの観点を意識するのがいいんだろうなぁ。
と言ったところで、時間になってしまった。。。もっと聞きたい！！
Q＆Aを時間一杯やってもらって本日の勉強会は終わり。
もう少し演習やってマインドマップ→観点の抽出できたら面白いんだろうなぁ。
ちょっと難しいところもあったけど、有意義な日曜日の午後だった。
他の参加者の声が気になります。もし良ければコメントでも、メールでもいいのでよろしくお願いします。
せっかくマインドマップ作ったんだからこれを使ってそのまま演習できないだろうか・・・とか色々考えてます！！
8月入ったら早めに案内を出したいと思います。
それではまた8月に楽しみながら勉強していきましょう。