はじめに
2020年2月1日(土)にソフトウェアテスト勉強会（ASTER出張セミナー） in 長崎 に参加しました。
ので、そのイベントレポートを作成しました！
イベント紹介
- イベント概要 (connpassイベントページより)
ソフトウェアテスト初心者を対象に、ASTERセミナー標準テキストをもとに、テストの基礎を経験豊かな講師により解説いたします。これまでテストを体系的に学んだことがない、日頃テストで悩んでいる、テストを学びなおしたい、現在のテストの潮流などを知りたいといった方を始めとしてテストに興味があればどなたでもご参加いただけます。
- セッション
- ASTERセミナー標準テキスト１・２章の解説 池田 暁 氏
- 1. テストの基礎
- 2. ソフトウェア開発ライフサイクル全体を通してのテスト
- ASTERセミナー標準テキスト3・4章の解説 秋山 浩一 氏
- 3. 静的テスト
- 4. テスト技法
- ASTERセミナー標準テキスト5・6章の解説 松谷 峰生 氏
- 5. テストマネジメント
- 6. テスト支援ツール
- ASTERセミナー標準テキスト１・２章の解説 池田 暁 氏
- イベントの資料
イベント参加目的
- ソフトウェアテストの基礎を定着させること
- JSTQB Foundation Levelに受験前に、ソフトウェアテストの内容を総ざらいすること
リンク : 過去記事「【イベント申込みました！】【初心者向け】ソフトウェアテスト勉強会（ASTER出張セミナー） in 長崎 」
セッション
(詳細はリンク : ASTERセミナー標準テキストを参照ください)
オープニング
ソフトウェアテストについて体系的に学んだことありますか？ ➡ 学んでみましょう！
- 大学でもソフトウェアテストに関する講義は少ない
- 職場でも開発手法を学ぶことはあるが、テストについて学ぶ機会は少ない
- テストは自己流で進めている人も多い
- テストの用語を理解していないと、テストに関する論文読んでいても理解が苦しい
ASTERセミナー標準テキスト１・２章の解説 (池田 暁 氏)
1. テストの基礎
1.1 テストとは何か？
テストをしないとどんな問題が起きる？
ソフトウェアをリリースするための通過儀礼のようにテストを捉えていると、質の高いテストはできません。また、テストに対するモチベーションも上がりません。テストを行わないとどんな問題が起きる可能性があるのかを知り、テストの意義を再確認しましょう！
- 経済的な損失
- 会社に多額の損害を与える
- 時間の浪費
- 故障のせいで、ユーザの時間を奪う
- 故障の修正で、時間を奪われる
- 信用の失墜
- 企業ブランドイメージへの悪影響
- 傷害や死亡事故
- 人を傷つけてしまう
- 人の生活を間接的に狂わせてしまう
ソフトウェアの悪意のある技術転用を防ぐことも重要
ソフトウェア(技術)を開発するエンジニアとして、開発するソフトウェアの品質を確保することは重要です。さらに、ソフトウェアの最終的な使われ方(テロ行為などに利用されないか？)を理解・把握して開発を進める必要があります。これは、開発者・テスト担当者に共通して必要。
テストの目的は拡大している (機能充足 -> 目的達成 -> 価値提供)
- 機能充足
- プログラムに欠陥がないことを検証する
- 機能が仕様通りかつ非機能機能要件含めて問題ないことを検証する
- 目的達成
- 顧客が満足できることを検証する
- 価値提供
- テストは出荷するために行うものではない ビジネスを成功させるために行う
- ライフスタイルやビジネススタイルを変革できるか (イケてるシステム/ソフトウェアかどうか) を確認する
- テストは出荷するために行うものではない ビジネスを成功させるために行う
1.2 テストの必要性
テストの目的は？(ISTQBベース)
- 欠陥の摘出
- 対象ソフトウェアの品質レベルが十分であることを示し、その情報を示す
- 意思決定のための情報を示す
- 欠陥の作り込みを防ぐ
- など
デバッグとテストの違いは？
- デバッグ
- 故障のもととなる欠陥を見つけて、解析し、取り除く一連の開発活動
- 開発担当者が責任を持つ
- テスト
- ソフトウェアに存在する欠陥に起因する故障を見つけること
- テスト担当者が責任を持つ (デバッグ後の確認テストも含め)
1.3 テストの7原則
- 原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない
- 原則2：全数テストは不可能
- 原則3：早期テストで時間とコストを節約
- 原則4：欠陥の偏在
- 原則5：殺虫剤のパラドックスにご用心
- 原則6：テストは状況次第
- 原則7：「バグゼロ」の落とし穴
1.4 テストプロセス
職場のソフトウェア開発の基準書やテストに関する基準書があれば、内容を確認してみましょう。もし、テストについて具体的なプロセスが定められていないなら、定める必要があるかもしれません。また定めてあってもテストの実行にだけしかフォーカスされていないようなら、更新が必要かもしれません。
- テストプロセス
- テスト計画
- テストのモニタリングとコントロール
- テスト分析
- テスト設計
- テスト実装
- テスト実行
- テスト完了
- テスト作業成果物は、トレーサビリティをとること
1.5 テストの心理学
テストに対して開発者もテスト担当者もネガティブな感情を抱いてしまうことがあります。これは無意識やイメージにより抱いてしまうものなので、意識的に認識し、マインドチェンジしてテストを捉えることが重要です。
- 人の心理とテスト (だれしもが一度は感じたことあるのでは？)
- 欠陥の指摘は、開発担当者に対する非難と解釈されがち
- テスト情報へのネガティブな印象
- テストは破壊的な活動という印象
- テスト担当者と開発担当者とのあるべき関係 (意識的にマインドチェンジしましょう！)
- 開発者とテスト担当者の協調姿勢
- テストの利点を強調
- 欠陥を作り込んだ開発者を非難しない
2. ソフトウェア開発ライフサイクル全体を通してのテスト
2.1 ソフトウェア開発ライフサイクルモデル
- 開発ライフサイクルモデルにおけるテスト
- 早期テストの原則を適用するとよい
- テスト設計は前倒しができる(ShiftLeft)
- レビューや静的解析により欠陥の早期検出を行う
- 早期テストの原則を適用するとよい
2.2 テストレベル
- V字モデルとテストレベルの例
- コンポーネントテスト
- 結合テスト
- システムテスト
- 受け入れテスト
2.3 テストタイプ
- 機能テスト (ブラックボックステスト技法を使う場合がある)
- 非機能テスト (ブラックボックステスト技法を使う場合がある)
- ホワイトボックステスト
- 変更部分のテスト
- 確認テスト
- リグレッションテスト
2.4 メンテナンス（保守）テスト
- メンテナンステスト
- 変更が正しく適用されていることを評価する
- システムの変更していない部分での副作用を確認する
- 影響度分析
- 変更により意図した結果を評価
- 変更により予想される副作用を評価
- 変更が影響するシステムの領域を評価
- 既存のテストに対する修正が必要な箇所を評価
ASTERセミナー標準テキスト3・4章の解説 (秋山 浩一 氏)
3. 静的テスト
3.1 静的テストの基本
- 静的テストと動的テストの違い
- 両方の良いところを組み合わせて計画し実施すること
- 静的テストの効果
- 欠陥の検出を動的テストの前に実施できる
- 動的テストでは検出できない欠陥を識別できる
- 欠陥を直接検出できる
- 開発とテストの生産性の向上と品質コストの削減ができる
3.2 レビュープロセス
なんちゃってレビュー(適当に集まって読み合わせしていることを"レビュー"と呼んでいませんか？)ではあまり効果は期待できない。適切なプロセス、レビューの種類(レビュータイプ)や技法を使い分けて効果的に実施することが重要。
- レビュープロセス
- 計画
- レビューの開始
- 個々のレビュー
- 懸念事項の共有と分析
- 修正と報告
- レビュータイプ (下に行くほど形式的)
- 非形式レビュー(バディチェック,ペアリング,ペアレビューなど)
- ウォークスルー
- テクニカルレビュー
- インスペクション
- レビュー技法
- アドホック
- チェックリストベース
- シナリオとドライラン
- ロールベース
- パースペクティブベース
- レビューの成功要因
- 目的と終了基準に応じて、レビュータイプを選択する
- 対象は小さく分割
- 適切な人を関与させる
- レビューアのトレーニング
レビューのポイント レビューで見つけた欠陥を適切に管理すること
- 指摘した欠陥が解決しないまま、リリースされてしまうのはまずい
- レビューアの心理的にも、きちんと修正されないと、レビューに対するモチベーション下がる
レビューアはソフトウェア開発に関して開発者よりも経験・理解が必要か？
必ずしもレビューア自身がレビュー対象となる成果物を作成できるスキルがなくてもよい。それ以上に、多角的な視点から成果物をレビューするスキルが重要。
4. テスト技法
4.1 テスト技法のカテゴリ
テスト分析～テスト設計とは、テストの段階的詳細化を行う活動
テスト対象に対して、テスト結果だけしか存在しなければ「何をテストしたのか？」「どのようにテストしたのか？」が分からない。テスト分析～テスト設計により、「何をテストするのか？」と「どのようにテストするのか？」を 段階的に詳細化することで、テストの内容と結果について他の人にも理解してもらえる。
- テスト分析
- ➡ テスト条件 (何をテストするのか)
- テスト設計 ← テスト設計技法の活用
- ➡ テストケース (どのようにテストするのか(入力条件と期待結果))
テスト技法
闇雲にテストを考えていては、質の高い(漏れのなく、多くの欠陥を検出できる)テストは難しく、非効率的である。
テスト設計技法を用いることで
- テストケースを合理的に少なくする
- 多くの欠陥が見つかるようにする
- テスト対象を漏れなくテストする
4.2 ブラックボックステスト技法
- 同値分割法
- 境界値分析法
- デシジョンテーブルテスト
- 状態遷移テスト
- ユースケーステスト ← 今回演習あり！
- 組み合わせテスト
4.3 ホワイトボックステスト技法
- 制御フローテスト
- データフローテスト
4.4 経験ベースのテスト技法
- エラー推測
- 探索的テスト
- チェックリストベースドテスト
リグレッションテストについて
ソフトウェアの変更の影響が、どのように出るかは誰にもわからない。そのため、影響が出そうなところを勘で探るか全体をテストし直す必要がある。リグレッションテストでは全体をテストし直すことで、変更点が他へ影響しないことを確認する。
演習 ユースケーステストについて
- 実際にテスト設計を行ってみると、難しいと感じた
- グループワークでテストケースの共有を行い、他の人の観点を共有することで気づきがあった
ASTERセミナー標準テキスト5・6章の解説 (松谷 峰生 氏)
5. テストマネジメント
5.1 テスト組織
テストの独立性について
独立(技術面、管理面、財務面で独立)したテスト担当者はより効果的に欠陥を発見できる。一方で、開発担当者は自分のコードにある多くの欠陥を効率的に検出できる。
独立したテスト担当者と開発者の心理的な課題
- ソフトウェア開発者はテストを軽視している。というイメージ
- テスト工程が開発のボトルネックになっている。というイメージ
5.2 テストの計画と見積り
テストの計画では、計画に対して、実績を何で測るかを決めておくことも重要
テスト計画(テストの目的、戦略、開始条件、終了条件、リスク、工数、人員、スケールなど)を計画し、それを計測する方法を検討しておかないと、計画に対して実績の妥当性が評価できないので、計測するメトリクスを決めておくことが重要
テスト計画書はテストを進めながら、更新し続けるもの
テストを進めるなかで、問題が表面化したり、テストの計画と進捗の間に差が生れることがある。(それは当然といえば当然のことして。)その際に、テストの計画を更新して、対策を講じることが大切。
テスト戦略とアプローチを事前に検討してからテストを進めないと効果的なテストとならない
組織レベルでのテストポリシー、複数のプロジェクトの全般的なテスト戦略、特定のプロジェクトにおけるテスト戦略を事前に検討する必要がある。
テストの工数を見積り
納期から逆算してテストのスケジュールを立てないこと！プロダクトの特性、開発プロセスの特性、人の特性、テスト結果から工数を見積もる必要がある。
5.3 テストのモニタリングとコントロール
テストのモニタリング：テスト計画で定義したメトリクスによって、計画に対する実際の進捗を継続的に比較する
テストのコントロール：計画に対して実際の進捗が合致しない場合に、対策を講じる。また計画書の更新を行う
- 代表的なメトリクス
- 計画したテストケースの準備完了の割合
- テストケース数 (実行/未実行, 合格/不合格)
- 欠陥情報 (欠陥密度, 検出及び修正した欠陥数)
- テストカバレッジ
- 工数、コスト
5.4 構成管理
全テストアイテムとテストウェアを適切に管理しましょう
- バージョンコントロール
- 変更履歴を残す
- 各アイテム間を関連付ける(トレーサビリティ確保)
5.5 リスクとテスト
プロダクトのリスクのタイプとレベルに基づいて、テストを行う
5.6 欠陥マネジメント
欠陥レポートについて
- ステークホルダーに対し、発生したあらゆる期待に反する事象についての情報を提供する
- 作業成果物の品質や、テストへの影響を追跡する手段を提供する
- プロセス改善のためのヒントを提供する
6. テスト支援ツール
- テストとテストウェアのマネジメントの支援ツール
- 静的テストの支援ツール
- テスト設計とテスト実装の支援ツール
- テスト実行と結果記録の支援ツール
- 性能計測と動的解析の支援ツール
- 特定のテストに対する支援ツール
6.1 テストツールの考慮事項
ツールをテストに用いることで、反復作業の削減、テスト作業の一貫性・再現性が向上、テストの客観性の向上などの効果が期待できるが、一方で、過度な期待や導入時/運用時の必要時間・コスト・工数の過小評価、ツールへの過剰な依存は、リスクの原因となる
6.2 ツールの効果的な使い方
ツールを効果的に使い、導入するために↓を行いましょう
- ツールの基本原則を理解する
- パイロットプロジェクトでツールの評価を行う
- 成功要因に基づいてツールを順々に展開する
ライトニングトークス
- rin2_氏
- IT業界の病理学について
- リンク:Amazon「IT業界の病理学」
- 金田直純
- ソフトウェアテスト社内勉強会の始め方
- リンク:SlideShare ソフトウェアテスト社内勉強会の始め方
- Keita Nakazawa氏
- "Don't think, Feel!"マインドで行動してみたソフトウェアテスト勉強会長崎CO-DEJIMA_20200201
- リンク:SlideShare "Don't think, Feel!"マインドで行動してみた
＋α 松谷氏 「テスターちゃん」のご紹介
松谷氏作のソフトウェアテストの用語や進め方をとても分かりやすく描いた4コマ漫画です。(登場人物がとてもCuteです(>_<)!)
イベント後懇親会
イベント後は、懇親会があり、参加者の皆さんとテストに関する情報交換を行いました。また、講師の方にはイベント中に聞けなかった質問をしたり、ライトニングトークスのフィードバックを頂いたりしました！ありがとうございました！
最後に
イベントで得たものまとめ
- ソフトウェアテストの基礎を総ざらいできた
- テストの必要性・目的と具体的な進め方(テストプロセス)
- レビューとテスト設計の進め方
- テストマネジメントのポイント(テスト計画の重要性)
- テストツールの効果と注意点
- JSTQB Foundation Level 受かるかな？
- 2/8(土)に試験受けてきました。手ごたえはあったけれど、100%の自信はない。。。
- 結果は3か月後なので乞うご期待。
番外編
目的の1つ長崎ちゃんぽんを堪能してきました！
ちゃんぽんとトンポーローとから揚げとグルメを堪能してきました。
ランタンフェスティバルを満喫してきました！
ランタンフェスティバルは、とても綺麗でした。
また、中国変面ショーもみることができました。(変面の仕組は結局暴けませんでした。)
最後まで、読んでくださりありがとうございました！(^^)/