JaSST'13 Tokyoに行ってきました。

このエントリーをはてなブックマークに追加

こんにちは。
QA inomataです。

1/30・31はテストエンジニアの祭典ソフトウェアテストシンポジウムが東京で開催されます。

ソフトウェアテストシンポジウム JaSST'13 Tokyo
http://www.jasst.jp/symposium/jasst13tokyo/outline.html

1/30に参加したので、その勢いでレポートを書きます。
後日上記のwebから発表の資料がダウンロードできるとの事です。また、このほかにもいろんなセッションがあるので、参加できなかった方、興味を持った方はぜひのぞいてみてください。

Challenges in Software Testing
Dorothy Graham氏による基調講演でした。テストについてのトレンド、やキーワードについての講演でした。

最近のトレンドについて
・方法論だとアジャイル、オフショア、探索的テスト、自動化が話題。
・テストの対象だとSNS、モバイル、cloudサービスなどなどSoLoMoってやつ。
・このように環境が変わって開発の手法も変わってきてる。テストの方法も考えていく必要がある。

テストの価値とは何か?
・バグを探す(除く)ことでユーザーの満足度が上がる
・バグを探す(除く)ことででリスクを下げる→製品の信頼性を高める。
などなど。ならばその価値を示すことは出来ているのか?→メトリクスをとるといいよ。

DDP(Defect Detection Percentage)を取る
テスト中の発見バグ/(テスト中の発見バグ+リリース後に発見したバグ)

しかし、これは以下のように完全ではない。
・分母にリリース後のバグが入ってるので、時間経過とともに値が下がっていく。
・アプリケーションに機能の追加をした場合、ユーザーが機能を使うまで100%になる。
・テスト期間が強制終了し、テストをやりきれてない場合はリリース後のバグが多い→値が下がる。
などなど、状況によって数値がいろいろな意味を持つので、数値だけをみて一概に良い悪いの評価にはできない。
ただ、結果からいろいろ考察できるので、プロセスやテストケースの品質を測ったりできる。
重要なのは一貫性を保って計測する事とのこと。
他にも、テストカバレッジを上げる事でソフトウェアの信頼性をあげるなど。

テスト自動化について
回帰テストを自動化するという事は一貫性のあるテストを実行し続けるということ。そのうちバグの発見率が下がってくるのは当然。バグを見つけるのは設計されたテスト。自動テストと人がやるテストは目的が違う。
バグを見つけるのは設計されたテスト。(大事なことなので2回言いました)
自動化の導入はメリットも考える。例えば実行が早くなるが、結果の分析は遅くなりがち。メンテコストとかも。トータルでメリットを考える。


「テスト要求分析やテストアーキテクチャ設計を重視したテスト開発」
HAYST法、ゆもつよメソッド、VSTePの方法論を通して、テスト開発には何が必要かを考えるセッションでした。製品の性質、プロセスによって三者三様の意見がありました。今回議論されたのはテスト設計の上流工程についてのQ&Aを紹介します。細かい用語等の説明は端折ります。

テストベース(仕様書、要求などテスト作成のネタ)は必要か?
・あれば越したことはないけど、仕事によっては無い事もある。ただあった方がそれだけ良いテストケースが出来上がる(V、ゆ)
・単機能のテストの先をテストするのが対象なので必要。ないならそれを用意するプロセスを組んだ方が品質が上がる(H)

テスト開発に経験が必要か?
・フレームワークなのである程度のものは出来る。経験がある方が質が良くなる。(H、ゆ、V)
・テスト開発を通して組織にナレッジを蓄積できる(V)
・経験がないと(レビュー等で)テストケース妥当性の担保が難しい(ゆ)
・製品知識やテスト技法など、各ドメインの知識は必要。(H、ゆ、V)

「使う人の立場」の「使う人」って誰?
・要求元であるユーザー、要求元の派生先として先であるユーザーのユーザー。(H)
・誰が結果を欲しがるかを考える。営業、開発、QAなど組織内での立場の違いなども考える(V)

観点をどうやって網羅するか?
・6W2Hでテストベースを分析する。現在の観点だけでなく、将来を見据えた観点も重要(H)
・マインドマップ的なものでISO9126の品質特性、組織、個人の知識などからモデリングする。(V)

テストレベルってどうする?
・開発の段階に従う。適切なテストレベルの設定が早いフィードバックを生む。(H、ゆ)
・テスト設計時に決める。あくまでもテスト開発主導で(V)

テストアーキテクチャ設計はどうつくる?
・目的機能間の組み合わせ、機能間の順番を分析する。(H)
・影響範囲とか構成図にできればいいなーと思う(ゆ)
・最終的に俯瞰できる図にする。また目的別(品質特性別とか)に分けられるとよい→トリアージできる。(V)


「Test.SSF スキル基準及びキャリア基準解説」
テストエンジニアのスキルを計測する方法の紹介でした。これは組込みスキル標準のETSSをベースに作成されています。
内容は、テストライフサイクル全体における準備や分析、実行等について4つのレベルで評価します。例えば開発技術の、「テスト条件(確認項目)の設計」であれば「デシジョンテーブルテストを使って設計が出来る」に対して「独力で実施できる(Lv2)」など。
これを人材育成のベースにして、組織や個人のスキルを測定したり成長につなげようという話でした。なお、実施するにはそのまま使うより、各組織用の項目にした方がよさげです。
これはASTERで公開されています。
http://aster.or.jp/business/testssf.html


私は参加していないのですが、自動化やオフショアといったキーワードは、未だに人気があったようです。また、今回はテストの設計やアーキテクチャといった、テスト開発の上流工程に注目したものもいつもより多く見られたように感じました。

こういう場に行って研究成果や事例を見るといい刺激になります。テストエンジニアの方は是非参加してみてください。
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...