NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'23 Tokai
HOME > 活動報告 > イベント報告 > JaSST'23 Tokai
2023年2月10日(金) 於 オンライン開催
当イベントは Zoomによるオンライン開催である。
定刻の午前10時、実行委員長の矢野氏によるオープニングセッションが始まった。矢野氏はおもむろに、「実行委員長挨拶で笑いを取ることに重きを置いている」と始めた。低い声のシリアスな口調で、次々に笑いを誘うスライドとスピーチが繰り広げられる。オフライン開催であれば会場は笑いに包まれていただろう。そうして参加者の気持ちをほぐした後、今年度のテーマが「システムテスト再考」であると熱意をもって語り、参加者には情熱を持って当シンポジウムに参加していただきたい、と締めくくった。
本講演では、システムテストをテーマとして、以下の5つが主題として掲げられた。
まず、基本を分かっておいて欲しい、とソフトウェアテストの原則について説明した。ソフトウェアテストには「品質の良いものを世の中に送り出すための手段」と「開発ライフサイクルの活動として、技術を活かしてQCDを達成できるよう仕事をすること」の2つの役割がある。上手いテストのためには、①なんでもテストでやろうとせず、関係者に迅速に正しい情報を提供すること②テストは技術次第で合理的に効率的にスピードアップできること③開発の状況によりテストのスピードや品質も変わってしまうこと、これらを踏まえてテストを組み立てることが必要である。
「ソフトウェアテストの7原則」を取り上げ、いつの時代でも変わらない原則がある、と説いた。テストの7原則より「テストは状況次第」を掘り下げ、開発トレンドがテストに与える影響について説明した。クラウドでは本番環境と同じテスト環境を構築するのは難しく、本番環境でのテストになる。アジャイル開発によりトライ＆エラーで小さく作るようになり、テストも常に意識合わせをしながら行う必要がある。修正を繰り返すのでリグレッションテストが主役となる。開発トレンドに合わせてテストをどう変えるべきか。開発スピードが上がったことで品質リスクの許容度が変わり、すぐに修正できる欠陥のリスクは許容するようになった、と例を説明した。
V字モデルにおける典型的なテストレベルについて説明し、テストレベルごとにテストすることの重要性を説明した。テストレベルを考慮することでテスト対象を効果的、効率的にテストすることができる。分かっていても現場でずれてしまうことがある。システムテストで単体テストレベルの欠陥が検出されてしまい、システムテストの位置づけがぐちゃぐちゃになってしまう。
システムテストのテストベース（要求提示者の成果物）は、システム内部には言及せず、システムの入出力を決め、システムの振る舞いを論理的に決めたものである。また、ユーザーストーリーマッピングなどで利用シナリオを記述しているものである。システムテストは、これらのテストベースに対して「論理的な振る舞い」を実現できていることを確認するテストである。
JSTQB FLシラバスより引用し、システムテストの目的を説明した。複数の目的の中から、自分が入るプロジェクトのシステムテストの目的を、テスト計画で取捨選択することがポイントである。
システムテストにおけるテストアプローチの3原則として、①外部からの1操作を軸にテストする②2つの操作をつなげてテストする③利用シーンを想定してテストする、とだんだんに組み合わせていくことが重要である、と説明した。
また、システムテストにおけるテスト設計の4原則として、①テスト目的、リスク、テストタイプからテスト項目とP-V（パラメータと値）を限定する②3種のテストベースをあらゆる手段で集め、テスト条件を識別する③P-Vの組合せが爆発しないようにテスト設計する④想定外のP-Vを追加する、と説明した。
テスト対象を抽象的にイメージできていないと上っ面のテストしかできない、と前置きし、システムテストにおける実践Tipsを解説した。
テスト対象の全体像をイメージしながら大きく捉える。そのために、①論理的な機能構造を理解する②業務フローを書き、システムがどの段階に位置づけられるかを把握する③使う人から見ての"論理的な"状態遷移モデルを捉える。
テスト環境の準備を徹底して行う。準備タスクをリストアップしてスケジューリングし、スケジュール通りに活動が進んでいることを"積極的に"確認する。複数開発チームを統合する作業では、確認の窓口担当者を置く。複数の環境を併用する場合は、管理を確実にする。
関係者とコミュニケーションする。体制に合わせたコミュニケーションパスを確保する。プロダクトリスク、テストプラン、テスト分析結果をチームのみんなに伝えて合意する。システムテストの範囲が複数企業のシステムにまたがる場合はさらに気を配る必要がある。各社より業務フローを集め、マスターテストプランを作成した上で、統合したテスト一覧を作成し、常に意識合わせを行う。
最後に、システムテストのアンチパターンを紹介し解説した。湯本氏が事前にTwitterで集めたアンチパターン例に対しコメントする形で、アンチパターンが発生してしまう問題と対応策を説明した。欠陥が入る原因を「ほぼコミュニケーションである」と説き、そもそも原理原則として必要な活動を実施していないことを認識するとよい、と説明した。
初めにテストレベルの重要性をご説明いただいたのが非常に良かった。確かに、分かってはいるが現場では簡単にずれてしまうと感じている。前のテストレベルで検出すべき欠陥の対応をすることでシステムテストが膨大になっている。そもそも原理原則として必要な活動を実施しているか改めて確認し、チームと認識を合わせようと思った。
システムテストのアプローチも、テストレベルの段階的組合せと同様で、確認する内容を混ぜないことが重要であると分かった。筆者の組織では、システムテストで最初から利用シナリオを適用しているチームが多い。システムテスト内でも段階的に組み合わせることの重要性を説明し、今回学んだTipsを踏まえて具体的にアプローチを考えていこうと思う。
ホン活とは、本に関する学習活動を指し、読書・執筆・翻訳を含む。なかでも、翻訳をすることは読書かつ執筆を含み、インプットとアウトプット両方ができるため学びが深い、とそのメリットを説いた。
その視点はなかった！と目から鱗であった。翻訳は、英語ができない人のために、英語ができる人が実施して「くれる」ものという認識であった。読みたい洋書があるので、1単元でも挑戦してみるか！という気持ちになった。
組込み製品の開発においては、ソフトとハードを統合してからテストする。ソフトウェアのテストを前倒ししたいところだが、ハードもソフトも汎用的な規格がなく、入出力が異なるためテストケースをメンテナンスし続けなければならないという課題がある。課題の解決を図るため、「組込み向けテスト実行フレームワーク」を試作し、実機と仮想環境でのテストケース共通化を図っている。その構造と、メリット・デメリットを解説した。
課題の解決にあたり西氏の言葉からヒントを得た、と紹介されていた。ヒントを得て、それを実行に移し、こうして形にすることができる技術者を心から尊敬する。
テスト戦略とは何か、についてISO/IEC/IEEE29119などを参考に山上氏が導いた答えについて話した。テスト戦略には、「テストアーキテクチャ設計」および「テスト計画に必要な情報」が書かれている。テスト戦略を立てるには、まずテストアーキテクチャ設計の知識が必要であるから、テストアーキテクチャ設計を学んではどうか、と締めくくった。
タイムリーな課題を抱えているため非常に参考になった。テストポリシーを効率的にプロジェクトのテスト計画に落とし込むための方法論やセットという認識であったが、視点を変えてテストアーキテクチャ設計について学んでみようと思った。
敬遠されがちなMBTが身近に感じられる取り組みを紹介した。MBTのモデルをテストケースに変換するロジックをMBTパターンと呼んでいるが、これがテスト設計に近い。モデル化することでパターンが抽象化でき蓄積しやすいという利点がある。ツールを作成して蓄積することで、MBTを活用しやすくなった。
藤田氏が言う通り、「モデル化」のハードルは高いと感じている。しかし、一度モデル化してしまえば広範囲に適用できる利点は理解できるため、関心が高まった。ツール化して誰でも適用できるようにしている所に感服した。
ユニットテストのコードカバレッジは90％を維持しているにも関わらず、テストがアイスクリームコーン状態（上位のテストレベルほどボリュームが大きくなる）になっていた。原因は、ユニットテストで確認済みの内容を、手動で実施する上位のテストでも確認しており、テストが重複していたからである。その改善のため、まずは開発者自身がユニットテストを信頼できる状態を作り出す必要があった。ユニットテストの価値を数値で可視化し、テスト実行時間、テスト成功率、信頼できるテスト率によって定量的に表現し、段階的に価値を上げていく取り組みを紹介した。
価値可視化のアプローチが非常に興味深い。ボリュームやカバレッジが十分であるのに価値を出せていない、という現象はユニットテストのみならず（なんならテストのみならず）発生していることであり、このように定量化して可視化すればよいのか、ととても参考になった。
自動テストを活躍させるための要点を解説した。前半で基礎作りの話を説明し、後半で要点を深掘りしてドメインを限定しない汎用的なテスト設計について解説した。
テスト自動化は、チームの継続的な改善活動である。ステップバイステップで進化させて継続的に取り組みを行うことによって、費用対効果がプラスとなっていく。継続的取り組みであるから、長期に渡って支える"基礎作り"が重要である。基礎作りの要点として、「自動テストの開発の要点」を10個、「自動テストを支える基礎作りの要点」を6個にまとめ、そのうちいくつかを解説した。
「チームの成功につながる目的を設定する」
適切な目的を設定すること。当たり前のようだが失敗していることが多い。テストの様々な目的のうち、チームによって有益な目的を設定することが重要である。チームのニーズや制約を踏まえ、避けるべき自動化と有効な自動化を捉える。
適切な目的設定のためには、視座を高めるとよい。テストに閉じた視座でなく、チーム全体、ライフサイクル全体から見ると、より本質的な目的を設定でき、目的達成のために使える手段が広がる。短期的、短絡的な活動ではなく、継続的活動として目的を設定するのが有効である。
「ニーズ・シーズに気づくためのテスト技術力を高める」
自動化に詳しい人がいれば、プロジェクトの状況から自動テストのニーズ・シーズを見つけることができる。ニーズ・シーズに気づくためには、普段からテスト自動化の知識や技術を得ておく必要がある。
「自動テストの内部品質を作りこむ」
自動テストも開発成果物であるため、ソフトウェア開発のノウハウを活用して品質を作りこむことができる。具体的には、保守性（自動テストの試験性、解析性、可読性、等）や、信頼性（偽陽性/偽陰性の削減、等）などが自動テストの開発においても適用できる。
「自動テストの妥当性の確保」
ゴミを自動化してもゴミにしかならない。価値のある妥当なテストケースを実現し、維持しなければならない。テスト分析・テスト設計を省略した自動テストは、自動化の価値を出せない。
「テスタビリティの確保」
テスト対象の自動化しやすさを作りこむ。例えば、分解容易性の作りこみ例として、外部システムを切り分けして柔軟なインターフェイスを用意しておき、テストに応じて切り替える、といった手法が考えられる。
「テスト環境確保をマネジメントする」
アジャイルであってもウォーターフォールであっても、プロジェクトの初期段階から環境分析してスケジュールを組んで進めるべきである。環境を考える際のアプローチとしても"視座を高める"ことが有効である。視座を高めて広い視点で責務を捉えて、環境を確保していくとよい。
「能力を持つ人とチームを確保する」
テスト自動化では主に２つのロールが要となる。テストアナリストがテスト全体の視座で、あるべきテスト自動化へ先導する。SET（Software Engineer in Test）が開発技術を活かしてテスト自動化を支える。
「チーム文化の醸成」
自動テストの価値をチーム全体が理解する。自動テストの技術的負債を返済する重要性をチームで共有する。自動テストを信頼し、責務を任せられるようにする。
「良い習慣を定着させる」
ユニットテストに代表される、"習慣に支えられるテスト"がある。原則を共有することで、ボトムアップで自動テストを支えることができる。
価値ある自動テストを実現するためには、価値あるテストを実現しなければならない。テストの基本設計（テストレベルやテストタイプの設計）と、テストケース設計の2つのアプローチで対応する。
テストの基本設計での対応：
テストケース設計での対応：
自動テストを活躍させる要は、テストの基本設計にある。テスト全体を責務分担し、得意な所を活かし、不得意な所を補えるよう組み立てる。責務設計は組織の構造にも依るため、プロジェクトの全体テスト計画を行う際に、全体の建付けを考える。①テスト要求の分析②テストの責務設計③評価と改善、をチーム全体で考えることがテスト基本設計の要点である。
豊富な経験に基づく経験則を体系立てて整理され、このように公表してくださることに強く感謝する。湯本氏の講演にも通じるが、高い視座、広い視野で捉えることの重要性を改めて認識した。つい目の前の課題の解決にかかってしまうが、全体としての価値や、長期に渡る継続的な活動としての価値を捉えなければならない。ポイントは、最初に時間を取って説明されていた「適切な目的設定」にあり、その目的をプロジェクトを通して常に意識できるかにかかっていると感じた。
※セッション5は並行して4つのセッションが行われた。筆者は5-4に参加した。
ワークを通じて代表的なテスト技法の基礎を勉強するセッションである。講師および参加者の自己紹介から和やかに始まった。まずテストに関する原則などの説明を行い、次に代表的なテスト技法として、同値分割・境界値分析とデシジョンテーブルテストの解説、および演習を行った。
筆者は開発者にテストを教える役割を担っているため、その業務の参考にする意図で本セッションを選択した。初めての人にもイメージしやすいよう単純なパターンで組み立ててあり、具体例も分かりやすくとても参考になった。紹介されていたテスト技法マップが参加者の興味を引いていたので、自社でも活用してみようと思う。
メインルームに戻り、セッション5の各代表者より、セッションで行われた議論の紹介と感想が発表された。
最後に、実行委員長の矢野氏より、「システムテストの難しさを再確認した」と感想が述べられ、「テストは情熱です！」と締められた。
一日で非常に多くの新たな刺激と学びがあり、講演が終わったころにはぐったりと疲れていた。筆者はテスト現場ではなく品質管理部に所属しており、開発チームに原則を浸透させていく立場であるため、本シンポジウム全体を通じて原則の重要性を再認識できたことが非常に嬉しかった。
業務では関連がない分野の話も全てが新鮮で、発見があった。物事を高い視座で捉えているか、得た学びから行動に移せているか、可視化しようとしているか。自分に問いたいことがたくさん得られ、大変有意義な一日であった。
記：岩崎 るみ子