2013年1月30日にJaSST'13 Tokyoに参加してきました。
毎年開催されているらしいのですが、今年初参戦してきました。
会場の雰囲気は、Jenkinsカンファレンスに比べると、若い方が少ない印象でした。
そして、Mac率が低い、、、そもそも机がない場所が多いのでPCを持参している方が少ない、みなさん、しっかりPDFで落とし印刷してペンで書いているという姿を目にしました。
その時の報告をさせていただきます。
私が聴講したのは、以下セッションです。
- 基調講演「Challenges in Software Testingソフトウェアテストのチャレンジ」 Dorothy Graham氏
- D2-1
- 「ユーザビリティ評価方法の実践的拡張および適用」
- 「Test.SSFを活用したソフトウェアテストリーダの人材育成」
- 「上流設計工程における未然防止プロセスの実用化に向けて－不具合モード発想力を高める秘訣－」
- B3 富士通グループが提供するテストツールのご紹介～時間と手間のかかるテストをラクにし、さらに信頼性も向上！～
- C4 「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」
1.基調講演「Challenges in Software Testingソフトウェアテストのチャレンジ」
□今までの変化(2000年以降の流行り)
・アジャイル、自動化、メディア
・JSTQBの資格を持っていない人はテストしてはいけないといった風潮に変わりつつある
□昔から何も変わっていないこと
・マネージャーがテストに対しての理解が足りない
・組織(マネージャー、CEO含め)のテスターへの知識不足
・大学でテストに関する学びが極端に少ない、むしろ皆無に等しい
・過去から学ぶ習慣
・開発の技術は日々新技術として増えているのに対して、テスト技術は増えない(比例でなくてはいけない)
・テストは人が行っているということ
□テスティングの価値
・テストに欠陥がなかった時(バグがなかった)の価値はないと言えるのか？
"DDP"評価がよいかもしれない
テスターが発見するバグ数：本番で発見されるバグ数=7：3の割合であったら、そのテストは良いテストを行ったという評価に繋がるであろう。
ユーザが発見するバグ数/(テスターが発見するバグ数+ユーザが発見するバグ数)*100(%)
*注：この評価は個人を評価してはいけない、チーム全体の評価でなければならない(shanonでは、バグジラのバグ数とエマージェンシーの数とで、7倍の差があればよいテストをした月と評価されるであろう)
・ユーザが発見するバグ数が多い場合の見方
数が多いからと言って、テスターのパフォーマンスが悪いという意味ではない(さまざまな理由も含まれていることを忘れてはいけない)
⇒デッドラインからのプレッシャー
⇒外部要因からのプレッシャー
・DDPのkeyPoint
⇒ユーザが発見するバグの数を認識するという必要性が見えるかできる
⇒一貫したやり方でDDPを評価する必要性が大切、つまり全体の統計をとることが大事になる
⇒信頼性を高める、テストの際の結果やテストが良いものであるかの測定、レビューをすることが大切になる
⇒カバレージを見る(精密性ではなく、カバレージ)
□知的な過ちについて
・ツールはテストの代わりである
・自動化をすれば、手動テストはしなくてもよい
→自動化の意味をもう一度よく考える必要がある
<ex1>たくさんバグを見つけたいなら、手動テストの方が効率的に発見できる
<ex2>回帰テストを自動化に組み込んでもバグ発見率はせいぜい6%未満。
・自動化は探索型(参考)テストで自動化を作ると、よりたくさんのバグを発見できるかもしれない
⇒つまり、より具体的な怪しいパターンと言えるケースを自動化に組み込むことで、より多くのバグを発見できるであろう
□テスターの将来像
・クラウド、ソーシャル、モバイルのつと技術が必要
→開発者とのオペレーションがより大切になる
→開発中にテストを行う手法も進んできているし、テスター自身もコードを書いてテストをする傾向もみられる
→ユーザ目線のテスト
→テストをユーザがするようになる手法
２．C4 「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」
こちらのセッションはディスカッション形式で行われたとてもフランクなセッションでした。
まず、ここでのkeywordは「バグ分析」についてです。
正直、私たちシャノンでバグ分析って何やっているのか知らなかったことと、バグ分析が世の中にあるという事実を初めて知り驚いてしまいました。
後から、先輩に聞いたら、「うちはやってないかな？でもそれって本当に意味あるのかってわかりずらいし大変。各自でやっているかもしれない。うち特有のバグっていうのは共有できてるし、、、。」的なかっこいいことを言っていました。。。
実際に会場アンケートをしていて、
１：バグ分析をしているセッション来場者は、全体の1/3、
２：効果を実感できているというのは、上記１より1/3、
３：バグのパターンがいつも一緒であるという来場者は、上記２より1/2。
上記統計より、その価値や効果を実感し、バグのパターン等を把握できている来場者はほぼゼロに等しい感じでした。
では、なぜバグ分析が必要だと言われているのでしょうか。
・事実確認を確実に行い、同じバグを繰り返さないため
・失敗事例を共有するため
これができていないから、失敗するという話をしていました。
つまり、「過失に着目する」・・・人間が行うことなので、必ずミスが起こります。その盲点をしっかり認識することに意味がある
その中で一際カリスマ性のある方がいらして、その方いわく、まとめると
「医者(QA)は、患者の病気(バグ)をどう治すかを考えるべきだ」
っとのことをおっしゃっていました。
医者は、この病気にはこの治療法があり、この時はこうする、というようなたくさんのパターンが存在する、いくつもの知識から引き出している。
それをQAができないはずがないっということなのです。
今、QAには例えるならば、医者になるために医学を学ぶためのさまざまな病気を知る必要があり、その原因を研究することが求められているということでしょうか。
そうなると、更に、大学でのテストについての講義も増えていってほしいというのは、これからに期待したいということです。テストという分野があるという事実さえも、知らない学生が多い。私もその一人でしたから。
バグ分析ってなんでこんなにも実感できていないのに、みなさんがやっているのか不思議でしたが、ちゃんとやることによって、解決できそうな未来があるからやっているのでしょう。
たくさん考えると、いろいろなことがでてきます。
こういう場でこういう疑問とか知識とかさまざまな人がたくさんの活動を行っている事例とか、とても刺激になりました。
自分にとって足りないもの、これからどうしたいかの目標、どう変えていきたいのかの願望や思惑、とても考えさせられましたし、とても面白かったです。
そして、まだ、この分野は確率したものになっていなく、これからもっと進化し続けるであろう分野なんだと感じました。
また、来年も参加したいです!!!
以上です。
