2019/5/31 JaSST東北2019
書きかけで放置してたのを今更ながら。
2019/5/31のJaSST東北2019のレポート。
今回のテーマは、「基本のキ 明日のテストを楽にする」。
画像は参加者土産のソフトウェアテスト練習帳。
JaSST東北実行委員会が作成した248ページの大作。
基調講演 テスト基本のキ -テストをする前に-
講師: freee) 小山竜治さん
テストの目的と本質の話
- 欠陥を摘出する
- 対象ソフトウェアの品質レベルが十分であることを確認する
- 意思決定のための情報を示す
- 欠陥の作り込みを防ぐ
テスト自体はあくまで「知ること」しかできない。
テストにおいて何を知りたいのかを考える必要がある。
- テストにおいては、何を知りたいのか、誰かが教えてくれるとは限らない。
- 要求仕様があっても、それが正しいという保証はどこにもない
- どんな検証システムでも、プログラムが正しいことは証明できない
- 検証システム自体が正しいという保証もない
JSTQBのテストの７原則より引用
- テストは欠陥があることは示せるが、欠陥がないことは示せない
- 全数テストは不可能
SWEBOKのソフトウェアテストの定義より引用
ソフトウェアテスティングとは、通常は無限に大きいと考えられる
「プログラムの振る舞いの実行領域」から
最適だと考えられる有限な「テストケースの集合」を選定し
所期の通りかどうかを実際に動かして検証すること
テストの全量実行は不可能。
何が最適かは、自分で考えて決断する必要がある。
何を知りたいか
知りたいことは目的によって変わる。
| 目的 | 知りたいこと |
|---|---|
| 欠陥を摘出する | 欠陥がまだありそうか？出なそうか？ |
| 対象ソフトウェアの品質レベルが十分であることを確認する | 想定した通り動くか |
| 意思決定のための情報を示す | 何を知ったのか？ どんなことが起こったのか |
| 欠陥の作り込みを防ぐ | ヤバそうなところはどこか |
状況や対象によって、目的や知りたいことは変わる。
例えば、１万回に１回落ちるアプリがあったとして、
- 便利アプリなら？→まあ許容できる
- 人命に関わるシステムなら？→１万人に１人死亡の可能性あり
- 経済インパクトが大きいものなら？→１万回に１回訴訟のリスク
SDLC(Software Development Life Cycle)によっても目的が変わる
- 企画：欠陥の作り込みを防ぐこと
- 開発：欠陥の摘出
- 受入：品質レベルの確認
- 運用：品質レベルの確認
テストすることで知りたいことは何か、まず現状を知って、考える。
テスト対象の分析をする。分析手法はいろいろ VSTePとかマインドマップとか。
テストはアウトプット→思考。まず、自分が知りたいことを考えてみることが必要。
自分で考えてたたき台をアウトプットし、それをみんなで叩いてブラッシュアップして磨きをかける方法がリーズナブル。
freeeで実践しているテスト分析
- 主なインプットは「会話」と「まとめ」
- あったら、それにプラスしてドキュメント、チケット
- できる限りコーダーの時間を割かないように集中して理解して、ドキュメントにアウトプットし、ミーティングで整理する
- 手段はプロジェクトの対象・メンバー・状況によって変える
- あまりに情報がない/時間がない場合は探索的テストでテスト実行しながらまとめる
- 柔軟性が大事
リスクの識別
「知りたいことは？」と言うと色々考えてしまうので、 「何が起きたらヤバイのか」 を考えるのがお勧め。
リスク識別のメリット
- 早めにフィードバックできる
- 欠陥が埋め込まれてから摘出されるまでの期間が早ければ早いほど修正コストが低くなる
- 早めにヤバイところが共有できる
- ヤバイところがわかるのでテストの方針・計画・戦略が立てやすくなる
リスクの種類には、プロジェクトリスク(プロジェクトの遂行に影響を与えるリスク)とプロダクトリスク(ソフトウェアやシステムで失敗する可能性がある領域)があるが、テスト設計のインプットになるのはプロダクトリスクの方。
リスクを識別・分析するにはテスト対象の分析が必要になる。
- どのような構造か
- 構造上ヤバイことになりそうなところは？
- どのような機能を持つのか
- 機能上ヤバイことになりそうなところは？
- どのようなユーザーが使うのか
- ユーザーにとってヤバイことになりそうなところは？
- どのような動きをするのか
- どう動いてしまうとヤバイのか？
リスク分析を行って、それをエンジニアと共有すると、そのリスクが埋め込まれる可能性が減る。
テスト技法の必要性の話
リスクはヤバイところから潰す。ヤバイところは早めに潰して安心したい。 テスト終了間際にリスクが高い問題が見つかったらプロジェクトの遅延につながる。
ヤバイからしっかりテストしたい
→ でも全部テストするのは無理。
→ 一番ヤバイところからやりたい。数もいい感じにサンプリングしたい。
→ 有限を選定するためにテスト技法が有用。
テスト対象の何を知りたいかによってテスト技法の使い分けが必要。
テスト技法の使い分けは、秋山さん(@akiyama924)が作成したテスト技法ポジショニングマップが有用。
- 網羅的に見るのか、ピンポイントに見るのか
- 構造に着目するのか、仕様に着目するのか
- シナリオに着目するのか、単機能に着目するのか
まとめ
- テストにおいては何を知りたいのか 誰かが教えてくれるとは限らない。
まず現状を知り、考える。 - テスト対象について、何が起きたらヤバイのかを考えると、「それが起こらないことを知りたい」が出てくる。
- テスト技法は、無限から最適だと考えられる有限を導き出すテクニック。
事例発表１ テスト自動化プロセスの改善
楽天 江村さん
チームの変遷で直面したテスト自動化の課題
- テスト自動化の質を維持するための工数増
- 「自動化」することが目的に
- Manual teamから見て、Automation team が謎
- テスト自動化チームが何を担保してるのか分からない
- テスト自動化の質が低下
- 頻繁なUI改修
- テストサイクルが短い
課題を改善する活動
- テスト自動化の設計見直し
- テスト自動化設計書のテンプレート改善
- テスト観点、テスト目的を追加した
- automation teamが何をやっているのか分かるように
- テスト実施条件の明示
- 自動化しないことを明示
- 手動テストの必要性を明確化
- CI条件を明示
- CIで繰り返し動作させることを前提に、求められる条件を記載
- テスト観点、テスト目的を追加した
- テスト自動化設計書のテンプレート改善
テスト自動化のレスポンシビリティ
- 次プロジェクトまでに自動化
今後やりたいこと
- 新規機能も含めてプロジェクト内で自動化カバー
- マニュアルと自動化の相乗効果向上
事例発表２ テストエンジニア新人研修 心を掴む時間
背景 社員５名で品質管理部を急遽スタート（急造チーム 経験不足）
- モチベーション・マネジメント
- 学ぶ心を掴む
- きっかけを与える
- 会社が目指していること
- テストチームが目指していること
- テストの役割
- どういった成果につながるか
- 育成のプロセスとゴールを定める
- 学ぶ心を掴むための情報を伝える
- きっかけを与える
- 楽しむ心を掴む
- 最優秀バグの表彰
- 月間で不具合レポートから最優秀バグを決定する
- 表彰するために、他の人のレポートを見る機会を与える
- なぜこのレポートが良いと思ったのか、を表現させる
- とにかくバグを見せるべし
- 月間で不具合レポートから最優秀バグを決定する
- 最優秀バグの表彰
- 探究心を掴む
- 仕様書ベースの試験だけでなく、探索的テスト
- 試験シナリオをリレー形式で実施
- Aさんが実施したシナリオを見て、Bさんが次のシナリオ、Cさんが次のシナリオ
- チームワークで探究心を伝染させる
- 仕様書ベースの試験だけでなく、探索的テスト
- 学ぶ心を掴む
教える側が焦らないことが大事
- 表彰されるバグってどんなの？
- リスクがクローズアップされるものや手順がすごいものなど
- 単一のポイントで評価はしない
- 思った通りに成長しない人のフォローは？
- 人と会話して、その人の長所を伸ばしていくようフォローする
事例発表３ テストの実践力を養うための効果的な技術者教育に関する取り組み事例
町田欣史
- 問題
- テスト教育に時間をかけているのに、現場では教育効果が見られない
- 原因
- 教え方が悪い、ではなく
- 研修を開催することが目的になっているから
- 問題解決の糸口
- 学生向けに教える
- 専門用語は使わず簡単な言葉で
- 身近な事例からテストを考えてもらう
- 外国人向けに教える
- 品質に対する意識が低い外国人がテストできるようにしなければならない
- 人数、レベル、要望に応じて様々な形式で
- 講義、演習
- 開発演習
- マンツーマン
- 後方支援など
- 人数、レベル、要望に応じて様々な形式で
- 品質に対する意識が低い外国人がテストできるようにしなければならない
- 学生向けに教える
- 従来の取り組みの改善
- 相手本位で教育することが最も重要
- 相手のレベルに合わせて教え方を変える
- スキルアセスメントを行って、対象者のレベルに合わせて指導
- 実践に近い演習
- 相手のレベルに合わせて教え方を変える
- 相手本位で教育することが最も重要
当たり前だと思っていることを他人に教えるのは難しい。
感想など
今回は基調講演の内容が非常にしみた。 まとめに内容がまとまってるので再掲。
- テストにおいては何を知りたいのか 誰かが教えてくれるとは限らない。
まず現状を知り、考える。 - テスト対象について、何が起きたらヤバイのかを考えると、「それが起こらないことを知りたい」が出てくる。
- テスト技法は、無限から最適だと考えられる有限を導き出すテクニック。
最初に考えたテストをすべて実施して、発生したバグは全て対応したのでテスト終わり、ではなくて、
発生したバグの内容から、プロダクトがどういう状態なのか考えるということが大事ということ。
ソフトウェアテストの７原則にあるように、バグがどこかに固まっていることもあるかもしれないし、
テスト方法を変えたら新たな問題が出るかもしれない。
テストを専門にやってる人からしたら当たり前の話かもしれないが、そういう目でバグを見たことがなかったので新鮮だった。
あと、組み合わせテストの演習で使っていたPictMasterを仕事の現場で導入してみた。
最初は「面倒くさい」という若干の拒否反応があったけど、テストやってみたら想定していなかったバグが見つかったりと効果は出ている。
あと、このツールをきっかけに、開発チーム内で「この機能のテスト因子にはどういうものがあるか？」という会話が出てた。ツールで枠組みがある程度決まっているので、その枠の中に入れるべきものは何かという議論に集中できるのだと思う。これもテスト技法の導入効果かと思う。
リンクなど
www.slideshare.net
www.slideshare.net
