mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

Mass塾:SQiP論文を肴としたソフトウェアテスト分析の激論

参加したんですよ

connpass.com

 

プログラマーとテスターにバイキルトをかけることを生業にしているMassKaneko氏が発表されるということで、参加してきました。

Togetterまとめはこちら。ブロッコリーさんどうもありがとうございます。

Mass塾:SQiP論文を肴としたソフトウェアテスト分析の激論 #massjuku - Togetterまとめ

タイムテーブル(告知ページより抜粋)

19:30-20:10 論文で示した手法がターゲットとする問題と手法そのものの解説

20:10-20:20 嵐の前の静けさ(そんなに静かじゃありませんでした)

20:20-21:30 激論(普通の質疑応答が行われました)

勉強会で出た質問(抜粋)

勉強会で出た質問(抜粋)の簡単なまとめです。

市場不具合をシステムテストで摘出するのを目的としているが、市場不具合を発見すべきなのは本当にシステムテストレベルだった?

→Massさんの論文に載ってました。本当すいません…

ちなみにシステムテストレベルで摘出すべき(そこで初めて気がつくような)問題が多かったそうです。

「入力、アプローチファクター、内部状態、外部状態、ユーザーの特徴」ではユーザーの特徴だけレベルが違う気がする。(抽象度が高い?)そもそもどう使うものなの?

→不具合誘発条件を導くヒントみたいな使い方が良さそう?

使い方はまだきちんとは決めてはいないそうです。

ユーザーファクターとか、経験や知識がないと出てこないものもあるのではないか?

→ある程度はベテランの知識が必要になりそうです。初心者+ベテランで教えながらやるのが良いかもしれません。

網羅的なテストとピンポイントなテスト、どっちに主眼を置いている?

→ある程度は網羅的に押さえて、そのあとはピンポイントな摘出を目的にする。完全な網羅的テストをするための手法ではない。

これはあくまで目的をどこに置いているかという話なので、良い悪いの話ではありませんね。

ラルフチャートは参考にしたの?

→作るときは参考にしてないそうです。作ってみたら類似した部分もあった、という話のよう。ちょっとずれた質問でした。すみません。

イテレーティブな開発など、他のプロセスでもこの手法は使えるだろうか?(Massさんからの質問)

→不具合誘発条件について考えることで、よりテスト条件が明確になる。このメリットはプロセスに関係なくあるのではないか。

なるほどと思いました。そうかだから、これはテスト分析の手法なのか。

新人に使ってもらうためにはどんな工夫がある?

→まずはFL表を書いてもらう。そこからファクターを探し、テスト設計書に落とし込んでいく、とのこと。いかにうまい感じにファクターを出していけるか、ということのようです。ファクターを出すこと自体が、テストに頭を使っていることになりますからね。

個人的な感想

品質特性に基づいて、テストタイプごとに思考過程を固定する(テストタイプごとに、テスト設計書の書式が異なる)というのは、テスト初心者からしたら非常に取り組みやすそうだなと感じました。

また、「機能テストとパフォーマンステスト」のようにテストタイプをセットにして検証するのは、信頼性テストと保守性テストとを一緒にやる感覚なのかなと理解しました。

あと、私は未だにテスト分析とテスト設計がよくわかってません。ですが、ここに悩むよりは色々試してみてもいいのかなと思いました。まずはちゃんと論文読み込んで使ってみようと思います。(当然そのままでは使えないので色々カスタマイズしなければいけませんが。)

機能ってどのレベルから機能って分類するの?といった質問も出ましたが、まずは使ってみてから色々考えていこうと思います。