【セミナー紹介編】ソフトウェアテスト勉強会（ASTER出張セミナー）in 長崎

ソフトウェアテスト勉強会に参加してきました( *´艸｀)

2020/2/1に長崎で開催されたソフトウェアテスト勉強会にノリと勢いで参加してきました！
こういった勉強会に参加するのは初めてでしたが、勢いで初LTに申し込み( ﾟДﾟ)
今回の記事は当日のセミナー内容についてご紹介します！
初LTについては次回の記事で紹介します

イベント概要（詳細はこちら）

Connpassページより↓
ソフトウェアテスト初心者を対象に、ASTERセミナー標準テキストをもとに、テストの基礎を経験豊かな講師により解説いたします。これまでテストを体系的に学んだことがない、日頃テストで悩んでいる、テストを学びなおしたい、現在のテストの潮流などを知りたいといった方を始めとしてテストに興味があればどなたでもご参加いただけます。

プログラム

ASTERセミナー標準テキスト１・２章の解説 池田 暁 氏
1. テストの基礎
2. ソフトウェア開発ライフサイクル全体を通してのテスト
ASTERセミナー標準テキスト3・4章の解説 秋山 浩一 氏
3. 静的テスト
4. テスト技法
ASTERセミナー標準テキスト5・6章の解説 松谷 峰生 氏
5. テストマネジメント
6. テスト支援ツール
イベント資料：ASTER標準テキスト
イベント資料：Togetter「ASTER出張セミナー in 長崎」

なんで参加したのか

• 一緒に切磋琢磨している同期に「今度長崎で勉強会あるけどどう？」と誘われ、勢いで申し込み どうせ参加するならLTもやってみようと思って申し込み！
• JSTQB FL受験のための最終調整
• テスト業界で有名な方々から学べると聞いて！

セッション内容

時々テスト初心者にも分かるように具体例を交えて解説していただいたので
スッと理解できました！
各セッションの内容と個人的に感じたことを簡潔に上げていきます！
ASTER標準テキストの詳細はテキストを参照してください！

ASTERセミナー標準テキスト１・２章の解説　（池田　暁氏）

1. テストの基礎

(/・ω・)/～個人的備忘録～

• 「ただのものつくりではなく、良いもの作りをするのが目的」
• 「テストは利用者のために行う」
• 「何も考えずものを作り始めると、バグ対応によってプロジェクト予算がショートするときがある」
• 「出資者はサービス内容だけでなく、サービス継続性を重要視している。」
  • それに気づいた会社が後追いでテストエンジニアが募集されるケースがよくある。しかしすでに品質基盤がぐちゃぐちゃな場合があるらしい...
• 「テストはチーム戦、チーム内で知識や経験の差を補完してチームとして能力を上げることが重要」

1.1 テストとは何か

なぜテストをするのか

• 「ソフトウェアの欠陥がアメリカに年間7兆～8兆円の損害を与えている」とNIST（アメリカ国立標準技術研究所）が発表
• その内約1/3は最適なテストができていれば問題回避できたとのこと。
• 最適なテストを行うことで製品の品質を向上させることだけでなく、トータルとしてコストダウンに繋がる。

テストの目的

• 要件、ユーザーストーリ―、設計、コードなどの作業成果物を評価する
• 明確にしたすべての要件を満たしていることを検証する
• ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする
• テストによって信頼を積み重ね、所定のレベルにあることを確証する
• 欠陥の作りこみを防ぐ
• 故障や欠陥を発見する
• ステークホルダーが意思決定できる、特にテスト対象の品質レベルについて十分な情報を提供する

などなどテストには様々な目的がある。（ISTQBシラバス参照）

デバッグとテスト

最近までデバッグとテストの違いが正確に分かっていませんでしたが、JSTQBの勉強をするようになり明確に区別するようになりました！

• デバッグ
  • 故障のもととなる欠陥を見つけて、解析し取り除く一連の開発活動のこと
• テスト
  • ソフトウェアに存在する欠陥に起因する故障を見つけること

1.2 テストの必要性

ソフトウェアは私たちの生活に欠かせないものになってきている
それに伴ってソフトの規模や複雑さが増加傾向にある
→ソフトウェアが正しく動かないと社会的な問題になる！

動かないソフトウェアが引き起こす問題

• 経済的な損失
• 時間の浪費
• 信用の失墜
• 損害や死亡事故

→テストによりソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減させる！

1.3 テストの7原則

テスト初心者の方はこの7原則を知るだけでも開発者、マネージャー、テスト担当者同士のすれ違いが軽減されるはず！

• 原則1：テストは欠陥があることは示せるが、欠陥が無いことは示せない
• 原則2：全数テストは不可能
• 原則3：早期テストで時間とコストを節約
• 原則4：欠陥の偏在
• 原則5：殺虫剤のパラドックスにご用心
• 原則6：テストは状況次第
• 原則7：「バグゼロ」の落とし穴

1.4 テストプロセス

• テスト計画

  • テストの使命を明らかにし、目的を定義する
  • 目的に合致するように、アプローチやルールを定義する（テストプロセスや適用するテスト技法、スケジュールなど）
  • 開発中も計画書を随時更新する

• テストのモニタリングとコントロール

  • 適切なメトリクスを使用してテスト計画書と実際の進捗を継続的に比較する活動（モニタリング）
  • テスト計画を使ってテストの諸活動を行い、必要に応じて活動の軌道修正したり計画の見直しを行う（コントロール）

• テスト分析

  • テスト可能なフィーチャーを識別し、テスト条件を決めるためのテストベースを分析する。
  • 「何をテストするか」を決定する

• テスト設計

  • テスト条件を高位レベルテストケースに落とす（様々なテスト技法を使用する）
  • 高位レベルテストケースをテストケースのセット、およびその他テストウェアに落とし込む
  • 「それをどうテストするか」を決定する

• テスト実装

  • テスト実行に必要なテストウェアを作成、完成させること
  • テスト実装は「テスト実行に必要なものすべてを準備したか」の答えである

• テスト実行

  • テスト実行スケジュールに従ってテストスイートを実行する（手動・自動）

• テスト完了

  • テスト完了した全活動のデータを集め、プロジェクトから得たこと、テストウェア、およびその他の関連する情報をすべてまとめる

この一連のテスト活動で重要なことは、テストベースと作業成果物がいつでも関連付けられるようにトレーサビリティを取ることが重要である。

1.5 テストの心理学

欠陥や故障を指摘することは、非難ととらえられてしまう場合がある。こういった心理的傾向を軽減する為に指摘する際は建設的な方法で伝えることが重要

• 対決ではなく協調姿勢
• テストの利点を強調
• 欠陥を作りこんだ担当者を非難しない
• 相手の気持ちや反応の理由を理解するように努力する

2. ソフトウェア開発ライフサイクル全体を通してのテスト

(/・ω・)/～個人的備忘録～

• 「テスト設計を前倒すことで全体が良くなる！」
• 「テストが開発工程に占める費用割合は約半分！」
  • テストはコストセンターと言われがちで、予算を確保するのが難しい場合がある。しかしテストを軽視すると何倍にもなって後で降りかかってくる..

2.1 ソフトウェア開発ライフサイクルモデル

• テストが開発工程に占める費用割合は46%にもなる
• テスト設計を作りこみの段階で実施することで、それぞれの工程とその成果物の質を見直し、向上させることができる

2.2 テストレベル

• テストレベル
  • コンポーネントテスト
  • 統合テスト
  • システムテスト
  • 受け入れテスト
• レグレッションテスト

2.3 テストタイプ

• 機能テスト（後ほど記述）
  • 機能（システムが「何を」すべきか）を評価する
  • 機能カバレッジでテストが十分であるか評価
• 非機能テスト（後ほど記述）
  • 非機能（システムが「どのように」ふるまうか）を評価する
  • 非機能カバレッジでテストが十分であるか評価
• ホワイトボックステスト
  • システムの内部構造や実装に基づいてテスト導出
  • 構造カバレッジでテストが十分であるか評価
• 変更部分のテスト
  • 確認テスト
  • リグレッションテスト

2.4 メンテナンス（保守）テスト

• メンテナンステスト
  • 変更が正しく適用されていることを評価する
  • システムの変更していない部分での副作用を評価する
• 影響度分析
  • 変更により意図した結果になるか評価
  • 変更により予想される副作用があるか評価
  • 変更が影響するシステム領域を分析
  • 既存テストで変更が必要な個所を分析

ASTERセミナー標準テキスト３・４章の解説　（秋山　浩一氏）

3. 静的テスト

(/・ω・)/～個人的備忘録～

• 「レビューに参加する時に対象製品の詳細が分からないからといって遠慮は必要ない。エンドユーザー目線の指摘ができる」

3.1 静的テストの基本

• 静的テスト
  • あらゆるものがレビューできる
  • 欠陥（defect)を探す
• 動的テスト
  • 動くものが必要
  • 故障（failure)を検出する

使用するテスト技法

• 静的テスト
  • 静的解析ツール＋レビュー技法
• 動的テスト
  • ブラックボックステスト技法
  • ホワイトボックステスト技法
  • 経験ベースのテスト技法

3.2 レビュープロセス

プロセスは以下の通り。みんなでただ集まって成果物を評価するのがレビューと思っていた自分にとって、考えを改めるきっかけになった。
特に3.個々のレビューを実施できている所は少ないように感じる。

1. 計画
2. レビューの開始：対象の成果物を配布する
3. 個々のレビュー：作業成果物を各個人でレビューする
4. 懸念事項の共有と分析：レビュー会で欠陥について議論と分析
5. 修正と報告：欠陥レポートの登録と修正、報告

ありがちなレビュー（As Is）

• 全員が成果物を１ページ目から見ていく為、後半部分のレビューが薄くなる
• ある分野について集中的にチェックする（ネットワークやサーバーについては重点的にチェック出来たが、セキュリティ観点はチェック出来ていないなど）

あるべき姿（To Be）

• 成果物を満遍なくチェックできるように、チェックするページを割り振る
• チェックする分野に偏りができないように適切に人選をする
• チェックするページ・分野を明確に区切らず、ある程度被るように割り振る

レビュー技法

• アドホック
  • 特に決まりのない非公式なレビュー
• チェックリストベース
  • チェックリストを使用する
  • お客さんの立場になってチェックリストを作成する
• シナリオとドライラン
  • シナリオにある使い方に基づいて、成果物に対してドライランを行う
  • シナリオにはお客さんへの価値が含まれている
• ロールベース
  • 様々なステークホルダーの観点で評価
• パースペクティブベース
  • ロールベース＋各レビューアの役割で導出する成果物の作成）
    

4. テスト技法

(/・ω・)/～個人的備忘録～

• 「コンピテンシーを発揮するためにはモチベーションが必要」
• 「テスト観点を考える際、自分の視点だけでは思いつかない観点があるため、作成したテストについて共有し意見を交換することが重要」
• 「非機能要件に対するテストを考えるときはユーザーが誰かを決めることが重要」

4.1 テスト技法のカテゴリ

テスト技法のカテゴリ分け
それぞれ偏らず、バランスが大事

ブラックボックステスト

• ユーザー指向
  • ユーザーの要求に合うか、利用時に満足しているか
• 要件指向
  • 仕様通り実装しているか

ホワイトボックステスト

• フォールト指向
  • 発生しやすい、あるいは推測される欠陥が検出されるか
• コード指向
  • ロジックは正しいか、実行されないコードはないか

4.2 ブラックボックステスト技法

代表的なブラックボックステスト技法

• 同地分割法
• 境界値分析
• デシジョンテーブルテスト
• 状態遷移テスト
• ユースケーステスト←グループワークあり
• 組み合わせテスト

グループワーク（ユースケーステスト）

• ユースケーステストテストとは
  • 1個のサブジェクト（コンポーネントまたはシステム）と1個以上のアクターとの相互作用による振る舞いを表すユースケースのシナリオをテストする
• グループワークのお題
  • 「交通系ICカードを使って電車の改札口に入るまでのユースケーステストを作成しなさい」
• 気づき
  • ユースケーステスト作成時点では作ったテストケースに考えの抜けはないだろうというバイアスが無意識の内に働いていた。
  • グループで共有した際に、チャージ金額が最低金額以下でも改札に入ることができる交通ICカードがあることを初めて知り、テストケースの良し悪しはテスト作成者の知識や経験に左右される部分があることを改めて実感した。
  • 実業務において、より効果的なテストを実施する為にはテストケースのレビューが重要

4.3 ホワイトボックステスト技法

制御フローテスト

• カバレッジ（網羅率、被覆率）
  • C0（命令網羅、ステートメントテスト）
  • C1（分岐網羅、デシジョンテスト）
• サイクロマチック数（複雑度）

データフローテスト

• 制御フローグラフ

4.4 経験ベースのテスト技法

• エラー推測
• 探索的テスト
• チェックリストベースドテスト

ASTERセミナー標準テキスト５・６章の解説　（松谷　峰生氏）

5. テストマネジメント

(/・ω・)/～個人的備忘録～

• 開発チームやテストチームは同じプロダクトを作っていくチームである！品質はみんなで育てていくという共通認識が必要
• 開発担当者とテスト担当者の間で協力関係の維持や開発担当者の品質意識を高める活動が必要
• 偽陽性「ソフトの動きなんかおかしいからFail（実は仕様通り）」
• 偽陰性「ソフトのこの動きはなんかいい感じだからPASS!（本当はバグ）」
• 偽陰性は表に現れないため、一番危険
• 普段からソフト仕様やテスト観点をチーム内ですり合わせを行うことが大事である

5.1 テスト組織

テストの独立性と開発の関係

• 独立
  • 技術面
  • 管理面
  • 財務面
• 独立性の度合い（下に行くほど独立性が高い）
  • 独立したテスト担当者不在
  • 開発チームに所属する独立した開発担当者またはテスト担当者
  • 組織内にある独立したテストチーム
  • 顧客やユーザコミュニティから派遣されたテスト担当者、または特定のテストタイプを専門に行うテスト担当者
  • 組織外の独立したテスト担当者

独立したテスト組織のメリット・デメリット

• メリット
  • 異なる視点で異なる欠陥や故障を検出する
  • 設計中に検証できる
• デメリット
  • 開発との協力関係が欠落する
  • 重要な情報が伝わらない
  • 開発担当者の品質に対する責任感が薄れる

テスト対策の実施

• 試験性（Testability）を考える
• テスト設計の前倒しを考える

量産開発をしていると、開発者が機能開発とバグ修正に追われ、十分に機能テストできないままテストフェーズにソフトが流れてくることがあるが、テスト担当者は開発者の状況を把握してサポートできるように考慮していく必要がある。

試験性とは

• 実行円滑性（Operability）
• 観測容易性（Observability）
• 制御容易性（Controllability）
• 分解容易性（Decomposability）
• 単純性（Simplicity）
• 安定性（Stability）
• 理解容易性（Understandability）

→試験性を高めることで、レビュー・テスト効率向上する。
→開発全体の生産性向上につながる。

5.2 テストの計画と見積り

テスト計画までの流れ
1. テストポリシー
2. テスト戦略
3. テストアプローチ
4. テスト計画

松谷さんが述べていたテスト計画の立て方
1. 最初の20~30分で概要を聞く
2. 話をしながらテストする機能を分けていく
3. 細かく分けていくとテストの粒度が分かる
4. 話をしながらテストアプローチを組み立てる
5. 後からリスクを挙げて、テストアプローチでケアされているかを確認する

テスト工数に影響する要因

• プロダクトの特性
• 開発プロセスの特性
• 人の特性
• テスト結果

5.3 テストのモニタリングとコントロール

テストモニタリング

• テスト計画書で定義したテストモニタリングのメトリクスを使用して進捗を継続的に比較する

テストコントロール

• テスト計画書の目的に合致させるために対策を講じる
• テスト計画書を継続的に更新する

メトリクス

• プロダクトメトリクス：コードの量など
• プロセスメトリクス：テストがどれくらい進んでいるかなど

代表的なメトリクス

• 計画したテストケースの準備が完了した割合
• テストケース数
• 欠陥情報
• テストカバレッジ
• 工数、コスト

典型的な終了基準

• 計画したテスト実行が完了している
• 定義済みのカバレッジを達成している
• 未解決の欠陥の件数は合意された制限内である
• 残存欠陥の想定数が十分に少ない
• 信頼性、性能効率性、使用性、セキュリティ、他の関連する品質特性を十分に評価している

5.4 構成管理

• 全テストアイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付ける
• テストウェアの全アイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付ける
• テストアイテムのバージョンとの関連付けを行い、テストプロセスを通してトレーサビリティを維持できる
• 識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記載してある

5.5 リスクとテスト

リスク

• プロダクトリスク
• プロジェクトリスク

今流行りのインフルエンザなどもプロジェクトリスクに含まれる

リスクベースドテスト

• 対応するリスクのタイプとリスクのレベルに基づき、テストの活動とリソースの利用をマネジメントし、選択し、優先順位付けするテスト
• R-Mapを用いてリスクを評価、テストの重みや優先度を決める

5.6 欠陥マネジメント

不正と欠陥

• 不正（anomaly）
  • 要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態
• 欠陥（defect）
  • 作業成果物に存在する、要件または仕様を満たさない不備または欠点

欠陥レポート

• 開発担当者や他の関係者に対して、発生したあらゆる期待に反する事象についての情報を提供する
• テストマネージャーに対し、作業成果物の品質や、テストへの影響を追跡する手段を提供する
• 開発プロセスとテストプロセスを改善するためのヒントを提供する

6. テスト支援ツール

6.1 テストツールの考慮事項

テストツールの種類

• テストとテストウェアのマネジメントの支援ツール
• 静的テストの支援ツール
• テスト設計とテスト実装の支援ツール
• テスト実行と結果記録の支援ツール
• 性能計測と動的解析の支援ツール
• 特定のテストに対する支援ツール

テスト自動化の利点とリスク
利点

• 反復作業が減る。特に「データ駆動方式」
• 一貫性や再実行性が増加する
• 客観的な評価が可能になる
• テストやテストケースの情報へのアクセスが容易になる

リスク
下記は実際に仕事をしていて、いつも実感する(;´･ω･)

• テストツールの効果を過大に期待する
• テストツールを初めて導入する場合に要する時間、コスト、工数を過小評価する
• 大きな効果を継続的に上げるために必要な時間や工数を過小評価する
• ツールが生成するテスト資産を保守するために必要な工数を過小評価する
• ツールに過剰に依存する

6.2 ツールの効果的な使い方

ツールを効果的に使うために

• ツールを使用する際の基本原則を理解する
• パイロットプロジェクトを導入し、ツールを事前評価
• 成功要因を分析し、順次展開する

最後に

今回のイベントに初参加し、初めての事だらけで四苦八苦しましたが、得られたものは多く、茨城から参加したため出費はありましたが、自分の成長につながる良い経験をすることができました！

• JSTQB試験前に範囲の総ざらいができた
• その道のプロ講師達が実体験をもとに分かりやすく説明していただける為、普段自分で勉強するだけでは理解しきれない部分も含め、深い理解をすることができた
• 当日の参加者がほぼテスト専門外の方ばかりだった為、普段聞けない貴重な話を聞くことができた

また、懇親会では長崎の美味しい海の幸を堪能しました！そちらについてはまた次の記事で紹介します。
ソフトウェアテスト勉強会非常におすすめです( *´艸｀)　興味ある方はぜひ！

次回の【初LT編】もよろしくお願いします！