惭补蝉蝉塾：テスト分析
?
5 likes?1,548 views
http://connpass.com/event/21897/ 2015年11月27日に行った勉強会「Mass塾：SQiP論文を肴としたソフトウェアテスト分析の激論」の資料。
惭补蝉蝉塾：テスト分析
- 1. Mass塾 SQiP論文を肴とした ソフトウェアテスト分析の 激論 Mass Kaneko / @masskaneko 2015年11月27日
- 2. 本イベントについて ● SQiPシンポジウム2015 “不具合と開発現場の実態に基づくテスト分析手法の提案” をベースにしたテスト分析の勉強会 ● 論文発表だけでは物足りなかったのが開催動機 ● 19:30~20:10 手法の解説 ● 20:20~21:30 激論 (遠慮なき議論) ● #massjuku をつけてツイート ● 遅いので懇親会はありません ● Thanks! Webrage!!!
- 3. Mass Kaneko / @masskaneko ● 電機メーカー勤務 ● プログラマー, プランナーを経て技術支援職 ● Software Engineering Consultant ● 現状の分析(プロダクト,不具合,プロセスなど) ● エンジニアリングツール/プロセスの普及 ● エンジニア向け教育 ● DTM, DJ, 工作, 釣り, 料理, スキー
- 4. 叁枚おろしやりたい病
- 5. 私と製品ドメイン ● タッチパネル,物理ボタン,音声認識をUIとした、 一般消費者(コンシューマー)向けの、 音楽再生、映像再生、道案内ができるデバイス。 ● その他はわかりません ○ 組込みでも：白物家電,半導体,医療,鉄道,航空… ○ スマートフォン, Web(フロントエンド) ■ 想像はつかなくもない ○ Web(バックエンド),エンタープライズシステム ■ 完全なる未知
- 6. 私のテストの知識と経験 ● JSTQB Foundation Level (2014年に取得) ● 知ってる, できる, 経験あり ○ ユニットテスト, いい加減なTDD ○ コードレビュー, 文書のレビュー ○ 静的コード解析 ● ちょっとは経験あり, でもあんまり知らない ○ システム全体, またはそれに近い環境のテスト ○ ユーザーの立場で動かすテスト
- 7. テスト分析？ ● …って何なのかは今でも良くわかっていない ● おのれISTQBめ ● テスト計画：目標, 日程, 人員, 設備 …わかる ● テスト設計：工夫してテストケースを導く…わかる ● 計画 → (なんか必要) → 設計 ● なんか ○ テストできる空間, テストすべき空間の識別 ○ 不具合が潜んでいそうな空間への照準合わせ ○ 使用するテスト設計技法の決定
- 8. 高いテストレベルほどテスト分析が重要 パラメータ 品質特性 テストベース 高 あれも これも どれが関係？ タイミング？ 同値分割:難 あれや これや ISO25010？ 品質とは一体 文書の選定 だけでも大変 文書以外も？ 低 引数 内部変数 同値分割:易 とりあえず 機能 性能 コード 設計文書 図
- 9. 提案手法を生んだ動機と過程 ● ミッション：わが社のテストを改善するのだ！ ● そんな壮大な…とりあえず不具合情報を分析 ● どうすればテストで見つけられたか？ ● 結局, 高いテストレベルのためのテスト分析に 論文図1より引用
- 10. 提案手法のコンセプト ● あまり不具合を見つけられない人が ステップアップできるように ○ よく不具合を見つけられる人にとっても 思考を助けられるように ● 説明できる成果、レビューできる成果を残す ○ スプレッドシートに慣れている人向け ● 文書(仕様書,ユーザーズマニュアルなど)を分析する ○ 過去の不具合の経験も併用 ● 頭を使うよう誘導する (CPMで終わらせない) ○ どうすれば不具合が起きそうか考えるよう誘導する ○ 基本的なテスト設計技法を使うよう誘導する
- 11. 提案手法の特徴 ● テストタイプ ○ 機能テスト,パフォーマンステスト,ストレステスト,ロングラン テスト,フォールトインジェクションテスト,異常原因解析テスト ○ テストタイプごとに思考過程を固定しつつ、できるだけ メジャーなISO25010製品品質特性をカバー ○ ユーザビリティ, セキュリティは無理だった ● 不具合誘発条件 ○ 入力, 入力の仕方(アプローチ), 内部状態, 外部状態, ユーザーの特徴 ○ 提案手法の元となった不具合情報を分析したら、 不具合を狙うために “気づかなければいけないこと” とは これらの5種類であった
- 12. テストタイプ 論文表7より引用 ● うちの組織ではこれだけあればいいよね、というもの ● ISO25010製品品質特性の他に考えることもあると思う。 しかしそれはもっとテストができるようになってからの話。 ● 回帰テストと构造テストはテストタイプとは见なさない
- 14. 不具合誘発条件：なぜこの分類に？ ● 市場不具合の分析で、それら発見するのに必要な要素は テストレベル, テストタイプ, テスト設計技法…それ以外の何か ● 何らかの分類ができないか？ ○ 入力, 内部状態, 外部状態…あとは？ ○ 連打や同時押しは入力じゃなくて入力の仕方 ○ 残りはユーザーの特徴 発表資料P7より引用
- 15. 機能テスト?パフォーマンステスト ● あるテストベースの記載内容について ● どのような機能的振る舞いを期待するのか ● どのようなパフォーマンスを期待するのか ● どのような入力をすれば期待通りにならなさそうか ● どのような入力の仕方をすれば期待通りにならなさそうか ● どのような内部状態であれば期待通りにならなさそうか ● どのような外部状態であれば期待通りにならなさそうか ● このテストに向いているテスト設計技法は何か 論文表12より引用 パフォーマンスは 機能に対するので 一緒に思考する
- 17. 機能テスト?パフォーマンステスト 発表資料P16より引用 ● これも”コピペで終わらせない”プロセスの一つ ● ただし, まとまりを見つける方法は提案手法の範疇外 ● 例えば状態遷移モデルを見出すのはテストの手法ではない
- 18. FL表を書く ● バリエーションを列挙し、不具合誘発条件を選ぶ。 ● 同値分割法, 境界値分析法, 特異値分析法を用いる。 ● 何が不具合誘発条件となるかは確認内容による。 ● 不具合誘発条件に気づくためにFL表を使う。 発表資料P14より引用
- 19. フォールトインジェクションテスト 異常原因解析テスト 論文 表13より引用 ● 信頼性のテストと保守性のテスト ● どちらも故意に異常を起こすテストなので、 思考過程をまとめられる。
- 20. ストレステスト, ロングランテスト 論文 表14より引用 ● ストレスがかかる条件下でどこまでの動作を期待するのか ● ロングラン(連続稼働時間)もストレス条件の一つとみなす
- 21. まとめ ● 高いテストレベルにおいては開発文書を分析して 不具合を狙うというプロセスが必要 ● その成果物を説明してレビューできるように ● まぁまぁマトモになるくらいのレベルを狙う ○ ISO25010とテストタイプ概念の導入 ○ テストタイプ別思考過程 ○ 不具合誘発条件 ○ 基本的なテスト設計技法のみ使用 ● 手法が生まれた現場ではまぁまぁ有効っぽい ○ もっと実績が必要。
- 22. ● 不具合誘発条件、皆さんの経験に合ってますか？ ● テストタイプ別の思考過程、固定してるけど、どう？ ● 包括的な文書を書くスパイラルプロセスの現場から生まれた。 それ以外のスタイルでも有効か？ 何か工夫すれば有効になるのだろうか？ ● 組込み以外でも有効か？ ● テストベースって開発文書と過去の不具合情報 以外に何がありますか？むしろなんかあんの？ ● 「うちじゃ使えなさそう」 みたいなご意見があればぜひ 激論の種
- 23. 議論?質問：イベント後記 ● 操作頻度などのアプローチファクターは中身の作りによると思う(操作イベントの キューとか)。一方、ブラックボックス的にわかる不具合誘発条件もあると思う。 テスト分析手法なり不具合誘発条件は両者に分かれるのではないか？ 中身のわかる開発者の方が向いているテスト分析もあるのではないか？ ○ そういう考え方はしかことが無かったがそうかもしれない ○ 不具合誘発条件はどちらかというと「手順」に重きを置いているのでブラックボックス的だが、 内部状態についてはユーザーからは見えない状態も扱うので開発知識が必要。 ● テストタイプ別テスト分析の表とFL表はどっちを先に書くのか？ ○ どっちでも良い。提案手法では規定していない。 ○ テスト分析の表だけで不具合誘発条件が書ける上級者もいると思う。 ○ そうではない場合のための FL表がある。詰まったとき、整理したいときに FL表を使う。 ○ 先にテスト分析の表を作って後から FL表を作っても良いし、 FL表で先にパラメータを整理してからテスト分析の表に取り掛かっても良し、 両方を行ったり来たりしても良い。 ● 機能テストの思考過程と表の横のつながりがよくわからなかった。 ○ 思考過程の順番は表の左から右に流れてゆく。 ○ ISTQB的に言えば、表の1行分がテスト条件。 1行分の内容から1つ以上のテストケースが導出できる。
- 24. ● 経験が無いとわからない不具合誘発条件があるのでは？ ○ Yes. 開発文書から導けるものと、経験が無いと気づけないものがある。 ○ 入力と内部状態については開発文書 (テストベース)に書いてある。 また、書いてない無効同値クラスもそこから連想しやすい。 ○ アプローチ(入力の仕方)、外部状態、ユーザーの特徴は経験が必要。 開発文書には書いてない。過去の不具合レポートを見たり、経験に頼る必要がある。 ● 経験不足を助けるような取り組みは提案手法とは別にあるか？ 有効な不具合誘発条件を教育資産にするなどの取り組みが考えられるのでは？ ○ 一つはレビュー。経験者からの有用な指摘がチームに広まることが考えられる。 ○ もう一つは実例の共有。実践したチームが複数出てきたあとの話だが、それらの複数のテスト設計 書を見て、共通した不具合誘発条件や、実際に不具合を見つけられた不具合誘発条件をあつめて 「あるある集」のようなものを作る手が考えられる。 ● 提案手法のテスト分析はどのフェーズで行うのか？ 実装が始まる前など早期にやるのか、結合テスト実施後なのか、など。 ○ 分析するテストベースができ次第行う ● 開発文書が無い、不十分なときはどうすれば？ ○ 私はそのケースは経験していないのでこれは単なる案だが、プロトタイプなどの動くものがあれば、 そこから分析表の”テストベース”欄に相当する内容を起こしてテスト分析することは可能だと思う。 ○ 派生開発であれば、前製品に共通するところは前製品の動作をテストベース代わりにできると思 う。 ○ 分析できるところから早く分析しておくのがよいと思う。
- 25. ● 網羅する手法なのか、ピンポイントで狙う手法なのか？ 不具合誘発条件が特徴的だから、どちらかというとピンポイントなのか？ ○ 両方の側面があり、両方のバランス感覚を考慮した。 ○ 網羅については、テストベースの網羅と (必要な)品質特性の網羅。 他にも網羅する基準はあるが、網羅はそのくらいにとどめておき、重くなり過ぎないようにした。 ○ ピンポイントについてはご意見の通り不具合誘発条件が相当。 ● HAYST法を参考にしたそうだが、FV表の6W2Hに相当する内容がアプローチファ クターやユーザーファクターに入っている。なぜか？ ○ 不具合誘発条件の分類を考える際に、まず「入力」「内部状態」「外部状態」が目についた。 ○ そのあとに「入力の仕方 (アプローチ)」と「ユーザーの特徴」に気付いた。 ○ ラルフチャートとFV表を知ったのはその後。 ○ 実はFL表も元からは知らず、「こんな表を作ればパラメータを整理して不具合誘発条件に気付きや すくなるのでは？」と考えた後に、「あれ、これって FL表って言うの？既存なの？」と。 ○ 私はV列に書くより不具合誘発条件の列に書く方が明確でわかりやすいと考えている。 ● テストベース欄の記載単位はどうすれば？機能とは？ ○ 提案手法ではそこは決めていませんし、決められません。 ○ そこは悩まずに開発文書の項目単位に従うのが良いと思います。 ● テスト分析によって開発側にフィードバックするようなことは得られるか？ ○ 開発文書(仕様書)の書き方についてフィードバックできた。 ○ 無効同値クラスに属する入力パラメーターに関する仕様の漏れなど。 ○ テスト視点での開発文書のレビューを行っているような側面がある。 ● http://togetter.com/li/905920 #massjuku ツイートまとめ
- 26. おまけ ● 高いテストレベルのテスト分析については この先悩みたくなく、「もうこれでいいじゃない」 という 手法を作りたかった。 ● テスト分析以外にも頑張れることは沢山あると思うんです。 ユニットレベルのテストコードを真面目に書くとか、 高いテストレベルでも自動化を頑張るとか、 開発者も簡単なシステムテストをやるとか、 人間の感覚をフル活用したマニュアルテストを頑張るとか… ● テスト分析は定石があるんだか無いんだかわからず、悩みや すい領域だと思います。でも悩むのはほどほどにして、他に先 にやることが無いか探した方が良いと思ってます。 ● もちろんそれは個人や組織の課題によるでしょう。 でも、私は「テスト分析はもうこんくらいでいいかなー」と。