いよいよ本連載も終盤にさしかかってきました。 これまでは テスト自動化ツールの選び方 テスト自動化の普及の仕方 テスト自動化の学び方 などについて説明してきましたが、今回と次回はタイトルにもあるように、テスト自動化とテスト設計について考えていきます。 筆者の見てきた範囲では、テスト設計をはじめとしたテストプロセスとテスト自動化とは”別物”のように考えられることがあるように思います。 しかし、テスト自動化についても当然テスト設計を含むテストプロセスが関係してきます。 自動化対象のテストを用意する際の2つのパターン テストの自動化は、当然ながら「なんとなく」ではできません。 具体的にどんなテストをおこなうのかを事前に決め、それをツールを用いて実装します。 この”どんなテストをおこなうのか”、つまり自動化する対象のテストを用意するには、大きく2つのパターンがあります。 ひとつは、テスト自動化を前提として、新たにテスト設計をおこなう方法。 もうひとつは、作成済のテストケースを選んで自動化する方法です。 パターン1：テスト自動化を前提として、新たにテスト設計をおこなう この方法については次回の記事、「テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計」にてご紹介予定です。 次で触れる作成済のテストケースを自動化するパターンとは違い、テスト分析やテスト設計時点で自動化に向いているところと手動実行に向いているところを分けて考えたり、自動化時の効率を考えてテストの設計を行ったりします。 興味がある方は、NPO法人ソフトウェアテスト技術振興協会が主催する「テスト設計コンテスト」決勝戦出場チームのプレゼン資料などを見ていただくと、おおまかなイメージがつかめるかと思います。 参考： ASTER-テスト設計コンテスト- テスト設計コンテスト’21 OPENクラス 決勝戦レポート パターン2：作成済のテストケースを選んで自動化する こちらは、手動実行のためにExcelやテスト管理ツールなどで用意してあるテストケース、つまりすでに作成済のテストケース（※以降、手動テストケースと表現します）の中から自動化対象を選ぶという方法です。 テスト自動化の経験がある、もしくは今まさにテスト自動化に着手しているという方は、多くがこちらの方法でおこなっているのではないでしょうか。 わたしがテスト自動化の普及をおこなう際は、パターン1を理想としてオススメしています。パターン2はテストを自動化する際はよいものの、作成した自動テストの運用を考えたときにいくつか問題があります。 しかし、これからテスト自動化を行おうという現場で「絶対にテスト設計からやり直してください！」と理想を押し付けてしまってはうまくいきませんし、組織内でさまざまな事情があることも理解しています。 そこで今回の記事では、理想的ではないけれども広く行われているであろうパターン2の方法について、問題を回避しながらなるべく無事にテスト自動化をするための考え方についてご説明します。 テストケースの整理と加工 手動テストケースを自動化する際には、テストケースの整理と加工が必要です。ここでは、何をテストするのかやどうテストするのかといったテスト分析やテスト設計にあたる部分を大きく変えずに、テスト自動化に向いたテストケース（※以降、自動テストケースと表現します）に変更をする、というニュアンスを表現するために「設計」ではなく「整理と加工」という表現をしています。JSTQBなどで用いられている用語ではない点にご注意ください。 手動テストケースを自動化に向いた形に整理・加工する際のポイントは以下です。 自動化可否判断と、自動化対象ケースの切り分け ひとつめのポイントは、自動化可否の判断と、自動化可能なテストケースおよび自動化対象ケースの切り分けです。 手動実行用のテストケースの中には、コンピューターでの実行が難しいものが含まれるため、まずは「この操作・確認が含まれている部分は自動化できない」という点を挙げ、自動化対象から外します。 物理機器の操作を伴う手順 電源のOFFを伴う手順 実行のたびに正解が変化し、人間でなければ成否の判別が困難な結果 などが代表的な例です。 まずはこうした自動化困難なテストケースを切り出し、大きく「手動で実行するテスト」と「自動化の可能性があるテスト」とに分け、後者に対してこのあとの整理・加工を行います。 手順や期待結果の具体化 ふたつめは、手順や期待結果の具体化です。人間が暗黙におこなっていた操作手順や確認をコンピューターに行わせるため、細かいところまで具体化する必要があります。 ダメなテストケースの例としてよく挙げられる「結果が正しいこと」という記述などはもちろんとして、他にも 特定の画面に遷移したことを、何をもって確認するか 「メッセージが表示されること」という期待結果において、具体的なメッセージ内容は何か 表示文字列の確認は完全一致か、特定の文字を含んでいればよいのか 「検索をおこなう」という操作を、ヘッダーからおこなうかメニューからおこなうか 用いるテストデータに隠れた条件はないか などを具体化する必要があります。 細かく見ていけばキリがありませんが、人間が実行していれば”察して”実行できていたところも、コンピューターで自動実行できるようにしなければなりません。 手動テストケース全体を見て、自動化するうえであいまいなところ、人によって方法が異なりそうなところがないかを確認するところからはじめましょう。自動化を担当するメンバーを集めて「自動化に向けたテストケースの確認会」を開催し、皆で手動テストケースを見ながらコメントしていくような場を設けるのもよいでしょう。前項の自動化可否判断・対象ケースの切り分けも、時間が許せばあわせて実施できます。 なお、手動テストケースの文面をすべて確認して一箇所ずつ詳細な記述に修正していく、というのは手間がかかりすぎるためオススメしません。それよりは、自動化時のルールを別で用意して「画面遷移の確認はココで判断」「よく出てくる操作はこの方法で」など記載しておくほうがスムーズに行えるでしょう。 テストケースの粒度の整理 もうひとつは、テストケースの粒度、構成などの整理です。 わたしがこれまで見てきた限りでは、自動テストケースよりも手動テストケースのほうが粒度が細かい傾向にあります。 たとえば、以下のログイン処理に関する手動テストケースについて考えてみましょう。 ログイン処理に関する一連の流れの中で、6つのテストケースを実行するように作られています。 では、このテストケースを自動化する場合、6つの自動テストを作ればよいでしょうか？ たとえばケースNo2と3、およびケースNo4と5は、上記のテストケースではそれぞれ1セット、連続して実行するように作成されています。これらのテストケースをケースNo每に分けて自動化する場合、ケースNo3の手順の前にログイン画面への遷移処理を入れるなどの修正が必要になります。 そのため、一般には以下のように複数のケースをまとめて、自動テストにおける1ケース、とする場合が多いでしょう。 ここまではごく単純な例なので当たり前のように感じられるかもしれません。しかし、実際のテストケースを自動化向けに整理する際は、もう少し複雑な変更が必要になることもあります。 たとえば上記のテストケースで、さらにケースNo2と3をまとめることも可能です。しかし、そうすると今度は自動テストの1ケースが長くなるのが問題です。一般的に、自動テストの1ケースが長くなると、バグがなくともテストが失敗する可能性も高まります。途中でテストが失敗すると、以降の期待結果の確認が行われず、結果的に手動での再実行が必要になることもあります。 そのため、「テストケースをまとめて、実行効率を高めること」と「テストケースを分割し、バグ以外の原因で失敗する可能性を減らすこと」との間でうまくバランスをとることが大切です。 テストケースの依存関係の整理 テストケースをまとめる以外にも、決まった順番でテストを実行する必要があるところを除く、つまり依存関係をなるべくなくすことも考えなければなりません。 手動でのテストを設計・実行する場合には、なるべく同じ手順を何度も行わなくていいような工夫をするものです。たとえばデータの新規登録・編集・削除という3つの機能についてテストをする場合、これらは一連の手順として実行するようテストケースを作成するでしょう。 つまり、 ケース1：データAを新規作成 ケース2：データAを編集 ケース3：データAを削除 といった形です。 これをそのまま自動化した場合、どんな問題があるのでしょうか。 ひとつは、ケース1でなんらかのバグがあり、実行に失敗した場合。ケース2とケース3も自動テストは失敗してしまいます。手動テストであれば、「別のデータを使ってケース2と3を実行しよう」といったその場での対応が可能ですが、自動の場合はそうはいきません。 このように、手動実行を効率よくおこなうためにテストケースどうしに依存関係を持たせたり、決まった実行順序を前提とした作りにすることは、自動化した際にかえって効率が悪くなることがあります。 自動テストは、実行環境を複数用意して並列に実行させることで時間短縮ができます。そのため、テストケース間の依存関係はなるべくなくし、独立して・任意の順番で実行できるような作りが望ましいでしょう。 そのためには、たとえば 事前準備：データB, Cを登録 ケース1：データAを新規作成 ケース2：データBを編集 ケース3：データCを削除 のように、テスト実行前につど必要なデータを登録し、そのデータに対して処理をおこなうなどの対応が有効です。 自動化の前のひと手間で、失敗・手戻りのリスクを抑えましょう 手動テストケースをそのまま自動化してもうまくいかない場合が多く、自動化に適した形に整理や加工をおこなう必要があります。 整理や加工は、まず自動化不可もしくは困難なテストケースを除いたものに対して 手順や期待結果の具体化 テストケースを適切な粒度で統合 テストケースの依存関係をなくす ような工夫をおこなうこと、です。 手動テストケースをもとに自動化しながら上記の整理・加工をおこなってしまうと、手戻りが多くなったり、自動化したテストが非効率的になったりします。 そのため、事前に手動テストケースから自動テストケースへの整理・加工を行ったうえで、自動化に着手しましょう。 ただし、本記事冒頭でも述べたように、これは理想的な手段ではありません。できるだけ、テスト設計やテスト分析など、より前段階から自動化を前提としたテストを考えるのが理想です。この方法については、次回の記事でご紹介予定です。 参考 テストを自動化するのをやめ、自動テストを作ろう – Speaker Deck JaSST nano vol.3 #4「初級自動化エンジニアが考える自動テストのためのテストケース加工」 – YouTube 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント テスト自動化の普及と推進【前編】～阻害要因と対策 テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 The post テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 first appeared on Sqripts .

この記事は2023年9月26日（火）に開催されるプレミアムセミナー登壇を記念してDr. Stuart Reidによって執筆されました。 プレミアムセミナーの詳細はこちらをご覧ください : ■ 9.26開催！Stuart Reid博士 特別セミナー｜知識ゼロから学ぶAIテスト オリジナル英語版はこちらに掲載しています。 ■ Risk-Based Testing for AI (English version/オリジナル英語版) はじめに リスクベースドテスト（RBT）は、1990年代初頭から様々な形で存在し、過去25年間、主流のアプローチとして受け入れられてきました。これは、ISO/IEC/IEEE 29119シリーズのソフトウェアテスト標準の基礎であり、すべてのテストはリスクベースであるべきと義務付けています。RBTはまた、ISTQBのようなテスター認定制度にも不可欠な要素であり、全世界で100万人を超えるテスターがRBTアプローチを教わっていることになります。 AIの歴史はRBTよりも古いですが、主流技術となり、多くの人が利用するようになったのはここ数年のことです。研究室での使用から日常的な使用、時には重要な分野での使用への進化は、商業的なAIシステムを体系的にテストする必要があるという認識が高まっていることを意味しています。AIシステムに対する社会的信頼の欠如は、これらのシステムのテストに対するより専門的なアプローチの必要性を強めています。  一部のデータサイエンティストによれば、AIは従来のソフトウェアとは大きく異なるため、誰がどのようにテストするのかを含め、これらのシステムを開発するための新しいアプローチが必要です。 この記事では、RBTの基本概念を紹介し、その適応可能な性質を示し、機械学習システム（MLS）のテストにRBTをどのように使用できるか、また使用すべきかを示します。また、MLSに特有なリスクの多くを列挙し、これらを通して、これらのリスクに対処するために必要な、いくつかの新しいテストタイプと技法を特定します。最後に、これらの新しいテストタイプや技法だけでなく、これらのシステムの基盤となるAI技術を理解する専門テスターの必要性を説明します。 リスクとITシステム 私たちは日常生活の中で毎日リスクを取り扱っています（例えば、「横断歩道まで50メートル余計に歩くべきか、それとも時間を節約してここを渡るべきか」など）。同様に、多くのビジネスもリスクの管理に基づいており、おそらく金融や保険に携わる人々が最も顕著でしょう。 ITシステムの開発やテストに携わる人々にとって、リスクベースのアプローチの使用は、そのようなシステムの信頼を確保する手段として、長い間受け入れられてきました。その中には40年近く前のものもあり、安全関連とビジネスクリティカルの両方に多くの業界固有の標準が存在し、ソフトウェア開発とテストの両方についてリスクに基づく要件を定義しています。 なぜリスクベースのテストなのか？ リスクベースのテストには、以下のような利点があります： より効率的なテスト リスクベースのテストを使用する場合、テスト対象のシステムのうち、よりリスクの高い部分を特定し、その部分に対するテスト工数の割合を高くします。同様に、リスクの低い部分については、テスト工数を少なくします。この結果、一般的にテストリソースをより効率的に使うことができ、システムが納品された後に問題となる高スコアのリスクは少なくなります。RBTのこの側面は、単純に使用するテスト工数を調整するという形を取ることもできますが、特定のリスク領域に対処するために、専門的なテストタイプを使用することも含まれます（例えば、ユーザーインターフェースのリスクがある場合、そのリスクに対処するために、専門的なユーザビリティテストを実施することを決定するかもしれません）。 テストの優先順位付け どのテストが最も高いリスクと関連しているかがわかれば、それらのテストを早めに実行するようスケジューリングできます。これには主に2つの利点があります。第一に、万が一テストが途中で打ち切られるようなことがあっても、最もリスクの高い領域にはすでに対処済みであることがわかります。第二に、リスクの高い領域で問題が見つかった場合、それに対処するための時間が残されていることを意味します。 リスクベースのレポーティングとリリース リスクベースのアプローチを使うことで、いつでも、未解決のリスク（つまり、テストや処理が済んでいないリスク）の観点から、システムの現状を簡単に報告することができます。これにより、プロジェクトマネージャーと顧客に対して、今システムをリリースすることを決定した場合、まだテストしていないリスクはすべて存在することを助言することができます。（つまり、そのリスクとともにシステムを受け入れることになる） このように、システムをリリースするかどうかの決定は、彼らがその存在を知り、同意したリスクに基づいて行うことができるのです。 RBT プロセス リスクベースのテストは、典型的なリスク管理プロセスに従います。その簡略化されたバージョンを図1に示します。 図1:簡易リスク管理プロセス まず、該当するリスクを特定します。次に、これらのリスクを評価し、相対的な重要性を見積もります。そして、どのリスクをテストで処理できるかを決定します。しかし、リスク管理は一回で終わることはほとんどなく、通常は変化するリスクに対応する継続的なプロセスになります。 リスク識別 RBTは、プロジェクトリスクとプロダクトリスクという2種類のリスクの識別と管理に関するものです。 プロジェクトリスクは、 プロジェクトマネージャーが使用するリスクと同じ種類のものです（多くの場合、プロジェクトリスク登録簿に文書化されます）。プロジェクトリスクは、主に納期と予算内に納品できるかどうかに関係します。プロジェクトリスクはまた、適切なスキルを持ったテスターの利用可能性や、開発者からテスターへのコードの納期遵守の可能性にも関係します。 テストマネージャーとして、プロジェクトリスクは、テスト計画に含めるテストの種類と量に大きな影響を与えます。例えば、新しいテスト技法を使用する場合、テストチームに必要な実装スキルの欠如や、テストツールのコスト増加のリスクが発生する可能性があります。 プロダクトリスクは、 テストに特化したものです。これらは、成果物に関連するリスクであり、エンドユーザに影響を与えるリスクです。高いレベルでは、プロダクトリスクを機能的品質属性と非機能的品質属性の観点から考えることができます。例えると、機能的なプロダクトリスクは、車の窓を制御するソフトウェアが、閉まる窓が子供の頭にぶつかったときに適切に反応しないことです。非機能的なプロダクトリスクは、車載情報娯楽システム(IVI)のユーザーインターフェースが明るい日差しの下で読みにくいこと（おそらく、コントラストと明るさの管理が不十分なため）、ドライバーが新しい機能を選択したときの応答時間が遅すぎるといったことが考えられます。 リスク識別をしようとする場合、理想的には多種多様な利害関係者を巻き込む必要があります。なぜなら、利害関係者によって知っているリスクは異なりますし、可能な限り多くの潜在的なリスクを見つけたいからです（重要なリスクを見逃すと、システムの対応する部分を十分に深くテストできなくなる可能性が高いため、その部分の欠陥が見逃される可能性が高くなります）。 要件は常にプロダクトリスクの重要な源泉として考慮されるべきです。要求された機能が提供されないことは明らかなリスクであり、顧客が受け入れ可能とは考えにくいリスクです（そのため、この種類のリスクの影響が大きくなります）。 ■ なぜ要件ベースのテストではないのか？ 以前は、テストは要件ベースのアプローチに従って行われ、顧客から明示的に要求された要素だけを対象としていました。  しかし、顧客が要件を完璧に記述していない典型的な状況ではどうなるでしょうか？例えば、必要な機能をすべて文書化していなかったり、レスポンスタイム、セキュリティ要件、ユーザビリティのレベルなど、関連する品質属性をすべて明記していなかったりする場合です。単純な答えは、要求ベースのテストでは、このような欠落した要件をカバーできないため、顧客が望むシステムの部分的なテストカバレッジしか提供できません。  また、顧客の要求がすべて同じように重要でない場合（通常の状態）はどうなるのでしょうか。要件ベースのテストでは、すべての要件が同じように扱われます。したがって、自動運転車では、歩行者回避サブシステムが車載情報娯楽システム(IVI)と同じ厳密さでテストされることになります。幸いなことに、安全関連システムについては、要求ベースのテストだけではありません。このようなシステムに関する業界固有の規格では、完全性レベルを用いたリスクベースのアプローチを採用しなければならないと定めています。しかし、どのようなシステムであっても、すべての要件を等しく重要なものとして扱うと、利用可能なテストリソースを非効率的に使うことになります。 では、要件ベースのテストが非効率的で、テストカバレッジの低さにつながるのであれば、代替手段は何でしょうか。リスクベースのテストでは、すべてのシステムに明示されていない要件が存在することを受け入れるため、欠落した要件は、対処すべき既知のリスクとして扱われます。要件の欠落や乏しさが、十分に高いリスクであると認識される場合、テスターは通常、ユーザーや顧客と話をして、このリスクを処理するためのニーズについてさらに詳細を引き出します。テスターは、完全な要件が入手できない場合に有効的とされる探索的テストのような、特定のテストアプローチを選択することもできます。 リスク評価（リスクアセスメント） リスクに割り当てられるスコアは、リスクが発生する可能性と、そのリスクが問題となった場合に与える影響の組み合わせを考慮して評価されます。理想的な世界では、各リスクの大きさを正確に測定できるでしょう。例えば、リスク発生の可能性が50％で、潜在的な損失が10万ドルであれば、そのリスクを5万ドルと評価します（リスクスコアは通常、影響度と発生確率の積として計算される）。しかし、実際にはそれほど単純ではありません。 特定のリスクが問題になった場合、どのような影響があるのか、事業者から正確に教えてもらえることはほとんどありません。例えば、車載情報娯楽システム(IVI)のユーザーインターフェースに関するリスクを考えてみましょう。 旧バージョンのフィードバックから、ドライバーがユーザーインターフェースを使いにくいと感じていることがわかりました。しかし、ビジネスへの影響はどうでしょうか？これは、振り返ってみても測定が非常に困難な場合があります。しかし、自動車が市場に出る前にそれを予測することは、事実上不可能です。 リスクが問題になる確率を計算することは、しばしば簡単な仕事だと考えられています。通常、開発者や設計者（私たちテスターは、通常、より身近な存在である）から、そしておそらくは過去の欠陥データから、これを決定するために必要な情報を得るからです。しかし、特定の領域における故障の可能性を推定することは、厳密な科学ではありません。設計者と話し、リスクに関連するシステムの部分が複雑かどうか、彼らの意見を聞くかもしれません。開発者に話を聞き、彼らが故障の可能性をどのように評価しているかを聞くかもしれません。それは、彼らが不慣れな開発技術やプログラミング言語を使用しているかどうかにもよるでしょうし、設計者や開発者の能力を推定することもできます。しかし、システムのソフトウェア部分が故障する正確な確率を導き出すことはできないでしょう（ハードウェアの方が予測しやすい）。 では、RBTを行う際にリスクスコアを正確に評価できないとしたら、どうすればいいのか。まず、リスクを絶対評価しないことです。その代わり、リスクを相対的に評価し、どのリスクをより厳格にテストし、どのリスクをより緩和してテストするかを決定します。私たちは情報に基づいた推測を行います。これは非科学的に聞こえますが、実際には、リスクスコア間の差は非常に大きいので、情報に基づいた推測で十分なのです。  RBTのリスク評価で最も一般的なアプローチは、高、中、低（影響、可能性、結果としてのリスクスコア）を使用することです。図2は、これがどのように機能するかを示しています。事業者は、あるリスクに対して、低、中、高の影響を提供し、開発者は、低、中、高の故障の可能性を提供します。これらは図2のように組み合わされ、その結果、グラフ上の位置が相対的なリスクスコアとなります。実際の数値をリスクスコアとして割り当てる場合（単にグラフ上の位置から「高」、「中」、「低」のリスクスコアを読み取るのではなく）、これらの数値は、異なるリスクに対する相対的な露出を決定するためにのみ有用となります。例えば、2つのリスクがあったとして、1つは「低-低」で公称スコアが1、もう1つは「高-高」で公称スコアが9であったとしても、2つ目のリスクに1つ目のリスクの9倍の労力を割くことはしません。その代わり、2番目のリスクは1番目のリスクよりも相対的に高いので、より多くのテストを割り当てるべきであることを、スコアは教えてくれるはずです。これが正しいことを確信する必要があるのなら、同じ2つのリスクに対して、影響度と可能性を異なる尺度（例：1～3、1～5）で、同様のアプローチを適用してみるとよいでしょう。 図2:高、中、低によるリスクスコアリング ここまではシンプルでした。以下は、この方法を使う場合の提案です。可能性と影響のスコアを与える利害関係者は、（低いものから高いものまで）全範囲を使用するようにしてください。利害関係者（特にユーザー）の中には、システムの「自分の」部分が最も重要な部分であると考え、常に自分の領域内のすべてのリスクを高インパクトとして採点する人がいることに気づくでしょう。なぜなら、私たちは 相対的な スコアを得ることで、リスク間の差別化を図ろうとしているのであり、ほとんどのリスクが高スコアであれば、リスク間の差別化はできないからです。 また、利害関係者がリスクスコアを承認するようにしてください。リリース後にバグが発見されたとき、顧客から「このバグは『ハイリスク』な領域にあったのだから、あなたが発見すべきだった」と文句を言われると、非常にフラストレーションが溜まります。しかし、あなたは、その領域を低リスクとみなすことに合意し、その結果、他のいくつかの領域で実施したテストよりも比較的少ないテストになったことを明確に思い出すことができます。 最後に、リスクスコアの算出によく使う3つ目のパラメータがあります。それは使用頻度です。リスクアセスメントを実施しているときに、2つのシステム機能が共に高リスクに割り当てられたとします。しかし、1つ目の機能は1日に1回しか使用されないのに対し、2つ目の機能は1分に1回使用されるとします。もしその機能が故障した場合、潜在的な故障コストははるかに高くなることがわかります。 リスク対策 RBTプロセスの第3段階はリスク対策です。この時点では、通常いくつかの選択肢があります。例えば、ある低スコアのリスクについて、そのリスクが問題になった場合のコストと比較すると、テストのコストが高すぎると判断する場合があります。低スコアのリスクについてはこのようなケースがよくあり、閾値となるリスクスコアを設定し、このレベルを下回るリスクについてテストを行わないのはよくあることです。あるリスクに対するテストコストが非常に高いことがわかり（例えば、専門的なテスターやツールが必要な場合）、リスクスコアが比較的高くても、そのリスクをテストするのは費用対効果が悪いと判断することもあります。このような場合、私たちは通常、そのリスクを別の方法で扱おうとします。例えば、障害に対処するための冗長性を導入することで、リスクを軽減するよう開発者に求めたり、その機能をシステム内で使用しないようにユーザーに推奨したりします。 テストによってリスクを扱うとき、私たちは関連するリスクスコアを下げるためにテストを使っています。テストがパスすれば、故障の可能性が減少したと結論づけられます（影響は通常変わらない）。テストは故障の可能性がゼロであることを保証できない（欠陥が残らないことを保証できない）ので、通常、この方法でリスクを完全に取り除くことはできません。しかし、ある機能をテストし、テストがパスした場合、そのテスト環境でのテスト入力のセットに対して、その機能は動作し、リスクは問題にならなかったことがわかります。これにより、この機能に対する信頼が高まり、もしリスクを再評価するのであれば、故障の可能性を低く設定することになるでしょう。そうでなければ、リスクスコアを閾値以下にするために、信頼度が十分に高くなるまで（そして故障の可能性が十分に低くなるまで）、さらにテストを実施します。 テストによるリスク対策にはいくつかの形態があり、リスクタイプとリスクスコアの両方に基づいています。高いレベルでは、テスト戦略に何を含めるかを決めることによって、リスクを扱うことが多いです。例えば、プロジェクトでどのテストレベルを使うかを決めたり（例えば、統合が高リスクと考えられる場合、統合テストを実施する）、システムの異なる部分にどのテストタイプを使うかを決めたりします（例えば、ユーザインタフェースに関連する高スコアのリスクがある場合、ユーザビリティテストをテスト戦略の一部に含める可能性が高くなる）。また、リスクは、どのテスト技法とテスト完了基準を選択するかを決定するために使用することができ、テストツールとテスト環境の選択も、評価されたリスクに影響されることがあります。 もっと低いレベルでは、評価されたリスクと、システムとそのユーザーに関する知識の両方に基づいて、一つの機能に対して、どのようにテストを配分するかを（個々のテスト担当者として）決めることがあります。例えば、ある機能をテストしていて、その機能のある部分が他の部分よりも頻繁に使用されることがわかっている場合、（他のすべての条件が同じであれば）使用頻度の高い部分のテストにより多くの時間を費やすことは合理的でしょう。 良いリスク対策は、テスター（とテストマネージャー）のスキルと経験に大きく依存します。もし私たちが2つのテスト技法しか知らないとしたら、4つの可能な選択肢があります（技法Aを使う、技法Bを使う、両方の技法を使う、あるいはどちらも使わない）。しかし、もし私たちが知っている技法のどちらも、認知されたリスクを処理するのに適していない場合、リスクベースのテストの有効性は著しく制限されることになります。一方、テストタイプや技法について幅広い知識があれば、適切な対策を選択できる可能性がはるかに高くなるのです。 RBT は単発の活動であってはならない 多くのプロジェクトでは、リスクベースのテストは、テスト計画とそれに関連するテスト戦略を作成するためのプロジェクト開始時のみに使用され、その後は何も変わらない、限定的な単発の活動として実施されています。しかし、図1の簡略化されたリスクマネジメントプロセスで、「リスクを識別する」に戻る矢印が示すように、RBTは継続的な活動として、理想的にはシステムを廃止するまで継続すべきです。 前述したように、テストが合格し始めると、私たちの自信は増し、故障の可能性は減少するはずです。従って、テストを実行するにつれて、リスクレベルは変化し、それを反映するようにテストも変化するはずです。しかし、テストが失敗した場合など、その逆のケースもあります。この場合、（これらのテスト入力の）失敗確率は100%になり、リスクではなく対処が必要な問題となります（リスクの失敗確率は100％未満でなければならず、そうでない場合は問題となります）。  テストの原則のひとつに、欠陥は集まって発生するというものがあります。したがって、欠陥を発見したときには、欠陥群の一部を発見した可能性を直ちに考慮すべきです。新しく発見した欠陥に近いシステム部分は、故障の可能性が高くなります。そのため、関連するリスクスコアが高くなり、この部分のテストがより多く考慮されることになります。 リスクが変わるのは、テストのせいだけではありません。顧客は、プロジェクトの途中で要求を変更することがよくあり、その場合、即座にリスクの状況が変わります。また、競合システムのリリースのような外的要因によって、あるリスクのビジネスインパクトが変化することもあります（独自の機能がより重要になるかもしれない）。競合システムのリリースが間近に迫っているため、他のシステムより先にリリースできるように、納期（とテスト時間）が短縮され、プロジェクトのリスクが増大することもあります。同様に、予期せぬ冬のインフルエンザの流行も、テスターの可用性と、テスターが提供するテストの能力に関連するプロジェクトリスクを変化させる可能性があります。 RBT と AI システム では、AIシステムをテストすることで何かが変わるのでしょうか？一言で言えば、答えは「ノー」です。テストの際、RBTは、AIコンポーネントを含むかどうかにかかわらず、すべてのシステムに適用することができ、また適用すべきです。しかし、AIシステムのテストは、従来の非AIシステムとは異なります。 AIシステムには多くの種類（機械学習システム(MLS)、論理ベースおよび知識ベースシステム、統計的アプローチに基づくシステムなど）があり、それぞれに特有のリスクがあるため、AIシステムの種類ごとにテスト方法が異なります。現時点では、機械学習システムが最も一般的なAIの形態です。次にRBTを使用してMLSをテストする方法を見ていきます。 機械学習システムに伴うリスク MLSのリスクを明確に分類する方法はありませんが、MLSの開発とMLS自体の両方に関連するリスクがあります。MLSは他のシステムとは異なり、MLSの核となるモデルは、トレーニングデータのパターンを使用したアルゴリズムによって生成されます。図3に、MLSの作成と運用の概略を示します。 図3：シンプルな機械学習 従来の非MLSシステムとは対照的に、MLモデルと呼ばれるMLSコンポーネントは、人がプログラムするのではなく、機械学習アルゴリズムによって生成されます。この再利用可能なアルゴリズム（人によってプログラムされる）は、データサイエンティストによってトレーニングデータが与えられ、このデータのパターンを使用してモデルを生成します。一度導入されると、モデルは類似した実世界の運用データを予測に変換し、例えば画像が猫か犬かを分類します。MLS開発のユニークな性質を考慮し、データサイエンティストはMLモデルの開発に専門的なフレームワークを使用します。 この説明を使って、機械学習を3つの主要分野に分け、機械学習に関連するリスクをこれらの分野の観点から分類することができます： 入力データ – 機械学習をサポートするためのトレーニングデータの提供と、運用環境でモデルが使用する本番データの提供に関連する。 モデル – 生成されたMLモデルに関連する。  開発 – MLアルゴリズム、モデルの開発、ML開発フレームワークに関連する。 入力データのリスク MLSの顕著な特徴の一つは、機械学習プロセスにおけるデータの重要性に起因します。モデルの学習に使用されるデータに欠陥があれば、結果として得られるモデルにも欠陥が生じます。例えば、一部のMLSが一部のマイノリティグループに偏っていることが判明した、という話を聞いたことがある人も多いでしょう。一般的に、この偏りは機械学習のプロセスやアルゴリズムによるものではなく（その可能性もありますが）、トレーニングデータの偏りによるものです。従って、MLSを構築する際、データサイエンティストはシステムの学習に使用するデータに偏りがあるリスクを考慮する必要があります。多くの場合、本質的にバイアスのかかった過去のデータ（例えば、50年前の人種や性別に関する見解を含む）を使用することが原因でバイアスがかかっています。RBTの観点からは、もし偏ったトレーニングデータがMLSにとって潜在的なリスクであることが分かっているのであれば、このリスクに対処するためにテストをどのように利用できるかを検討すべきです。そして、驚くことに、MLSにおけるバイアスのテストは、すでにかなりよく理解されています。 バイアスは、MLSのトレーニングに使用されるトレーニングデータに関連するいくつかの潜在的なリスクの一つに過ぎません。MLS用のトレーニングデータ（および運用データ）の作成は、データサイエンティストの労力を最も多く費やす複雑な作業であるため、うまくいかない可能性（およびそれに対応するリスク）も多く存在しています。以下のリストには、MLSの入力データに関連する最も一般的なリスクをいくつか挙げています： 偏ったトレーニングデータ 誤ったデータ取得 信頼できない情報源からのデータ 安全でないデータ入力チャンネル 非効果的なデータガバナンス データパイプラインの問題 ソフトウェアおよびハードウェアの構成管理に関する問題 データパイプライン設計の潜在的欠陥 データパイプライン実装の潜在的欠陥 データセット全体に潜在する問題 すべてのターゲットクラスのカバレッジが不十分で不均衡 内部で整合性のないデータ データ補強で歪んだデータ 最適でない特徴量選択 例／事例による潜在的な問題 欠損データ 間違ったデータ型 範囲外データ 外れ値と極値 誤ってラベル付けされたデータ 非代表的なトレーニングデータ 全ユースケースのサブセットに焦点を当てたデータ データ空間のすべての領域をカバーしていないデータセット ML モデルのリスク   多くの点で、MLSのモデル部分は、他の小規模なシステムと同じように考えることができ、提供される機能に関連する一連の機能的リスクが存在し、それはシステムによって変化します。 しかし、MLモデルにはいくつかの特別な特徴があり、MLモデルに共通する以下のようなリスクを特定することができます：  機能的リスク  モデルが学習した間違った機能 要求されるMLモデルのパフォーマンス指標を達成できない（精度や再現率の不足など） 本質的に確率的であり、非決定論的である。 偏った、あるいは不公平なMLモデル  非倫理的モデル  敵対的サンプル  過剰適合モデル  受け入れられないコンセプトドリフト  報酬ハッキングを示すモデル  モデルは副作用を引き起こす  モデル結果に対するユーザーの不満 モデルAPIの欠陥  非機能リスク モデルの堅牢性の欠如  不十分なモデル性能効率 モデル展開／使用 不適切なモデル構造（ターゲットプラットフォームへの展開など） モデルの文書化が不十分（機能、精度、インターフェースなど）  モデル・アップデートがパフォーマンスを低下させる 開発リスク 既に述べたように、MLSは従来のシステムとは全く異なる方法で、アルゴリズムを用いて作成されています。ほとんどのデータサイエンティストは、MLSの作成をサポートするために専門的なML開発フレームワークを使用しています： ML開発フレームワークのリスク 最適でないフレームワークの選択 フレームワークのインストールやビルドに不備があった 評価の不完全な実装 アルゴリズムによって生成されたモデルに導入された欠陥 効率が悪い（例：フレームワークの応答が遅い、停止する） 貧弱なユーザーインターフェース APIの誤用（ライブラリへのAPI、TensorFlow APIなど） 使用ライブラリの欠陥（例：CNTKやPyTorchの欠陥） セキュリティの脆弱性 ドキュメントの不備（ヘルプがないなど） MLアルゴリズムのリスク 最適でないアルゴリズム選択 アルゴリズムに欠陥がある（アルゴリズムの実装に欠陥があるなど） 説明不足（例：選択したアルゴリズムの説明が難しい） トレーニング、評価、チューニングのリスク 不適切なアルゴリズム／モデルを選択 最適でないハイパーパラメーターの選択（ネットワーク構造や学習率など） トレーニング、検証、テストの各データセットへのデータの割り当てに欠陥がある（完全に独立していないなど）。 評価手法の選択ミス（n分割交差検証） 学習過程の確率的性質（例：非決定的な結果、テストの再現性の難しさなど） デプロイメントリスク デプロイの欠陥（ターゲットプラットフォーム用に間違ったバージョンを生成するなど） 運用環境との不適合 リスクの評価と対策 前述の通り、リスクスコアを算出するためのリスク評価は、影響度と確率の組み合わせに基づいて行われます。ここに挙げたMLS特有のリスクについては、一般的なプロジェクトにおける平均的な発生確率を見積もることができるかもしれませんが、影響は常にプロジェクト固有のものです。 特定されたリスクがテストによって処理できる場合、MLSのテストに特化した、リスク対策として選択可能ないくつかのテストタイプを特定することができます。以下に挙げるリスク処理のリストは、先に特定されたリスクに対する潜在的な処理として導き出されたものです。 インプットデータテストによるリスク対策 テスト入力データに関連するリスクについては、以下のML固有のテストタイプが処理として適用できます： データ・パイプライン・テスト データ・プロベナンス・テスト データ充足性テスト データの代表性テスト データの異常値テスト データセット制約テスト ラベルの正しさテスト 特徴量テスト 特徴量貢献テスト 特徴量効率テスト 特徴量と値のペアテスト 不公平なデータバイアステスト 加えて、非AIシステムにも用いられるデータガバナンステストも、データガバナンスが効果的でないリスクを扱うのに適切でしょう。 テストによる ML モデルのリスク処理 MLモデルの特異な特徴の一つに、その多く（特にディープニューラルネットワーク）の内部動作を理解することは、たとえアクセスできたとしても難しいということです。この点で、MLモデルは、内部動作の詳細にアクセスできない他のシステムに似ていると考えることができます。テストの観点からは、このようなシステムのテストに適した”一般的な”テスト技法があります。一般的な技法（すなわち、AI以外のシステムにも適用可能な技法）には、MLモデルのリスクを扱うのに適したものがあります： A/Bテスト APIテスト バックツーバックテスト 境界値分析 組み合わせテスト 探索的テスト ファズテスト メタモルフィックテスト リグレッションテスト シナリオテスト スモークテスト  性能効率テスト このような一般的なテスト技法に加え、MLSのテストに特に有効なテストタイプやテスト技法もいくつか存在します： 敵対的テスト モデル性能テスト 代替モデルのテスト パフォーマンス測定テスト モデル検証テスト コンセプトドリフトテスト オーバーフィッティングテスト 報酬ハッキングテスト 副作用テスト ニューラルネットワークのホワイトボックステスト 倫理的システムテスト モデルのバイアステスト モデル・ドキュメントのレビュー モデル適合性審査 ML 開発 テストによるリスク対策 MLモデルの開発に関連するリスクを処理するのに適したいくつかの一般的なテスト技法が特定できます。開発フレームワークについて、広く使われているフレームワークでは、フレームワークの機能に関連するリスクは小さいと考えられるため、特定された技法のほとんどは非機能的なものです。対照的に、MLアルゴリズムの機能性はよく知られたリスクであり（ある研究では、これがMLSにおける欠陥の主な原因でした）、MLアルゴリズムをテストするためのいくつかの機能テスト技法が含まれています。MLSに適用可能で、非AIシステムにも使用される一般的なテスト技法は以下の通りです：  APIテスト（開発フレームワーク） 構成テスト（開発フレームワーク） 設置性テスト（開発フレームワーク） セキュリティテスト（開発フレームワーク） パフォーマンステスト（モデルのトレーニング） 回復性テスト（トレーニング・データ） ロールバック・テスト（MLモデル） MLアルゴリズムのテスト コードレビュー（MLアルゴリズム） 静的解析（MLアルゴリズム） 動的ユニットテスト（MLアルゴリズム） 開発フレームワーク、MLアルゴリズム、MLモデルの配備に関連するリスクを扱うために、いくつかの専門的なテストタイプを特定することができます。これらのMLに特化したテストタイプには、以下のものがあります： フレームワーク適合性審査 モデルの説明可能性テスト モデルの再現性テスト MLアルゴリズムのテスト アルゴリズム／モデルの適合性レビュー ライブラリ実装テスト モデル構造テスト アルゴリズムのバイアステスト デプロイメント最適化テスト モデルデプロイメントテスト MLS – プロジェクトリスク これまでのところ、MLSのRBTを通じて、プロダクトリスクと関連する処理が特定されています。これらは、成果物であるMLSがユーザーニーズを満たさないというリスクです。しかし、RBTを実施する際には、プロジェクトリスクも考慮する必要があり、MLSのテストの成功を脅かす明らかなプロジェクトリスクも存在します。 ここでは、テストに影響を与え、MLS特有のプロジェクトリスクのみを考慮します。もし、あなたがMLSのテストを担当するのであれば、テストの見積もりが不正確であったり、開発者がテスト対象のソフトウェアを合意通りに納品できなかったりといった、すべてのプロジェクトに適用されるテストに関する一般的なリスクも考慮しなければなりません。残念なことに、開発者がRBTを理解していないにもかかわらず、テスターに仕事の進め方について助言をする資格があると考える一般的なプロジェクトリスクは、MLSに携わるデータサイエンティストにも適用される可能性があります。  MLSのテストの成功を脅かす可能性のあるプロジェクトリスクの一例として、以下が挙げられます：  MLSの経験豊富なテスターの確保が不十分である。 MLSに関するテスター向けのトレーニングが不足している。 MLS特有のテストタイプに精通したテスターは利用できない。 確率論的システムのテストアプローチが理解されていない。 非決定論的システムをテストするアプローチが理解されていない。 確率的システムの統計的検定のためのツールサポートが不足している。 MLSのパフォーマンスメトリクスの定義は、受入基準として使用するには不十分である。  コンセプトドリフトのための継続的なテストは考慮されない。 ニューラルネットワークのホワイトボックスカバレッジ指標が未成熟。 MLS のテストは非 AI システムのテストとは異なるのか？ イエスでもあり、ノーでもあります。リスクベースのテストはすべてのシステムに適用すべきです。なぜなら、AIであろうと非AIであろうと、多くのシステムのリスクは常に異なるからです。  MLSには特定のリスクタイプがあるため、MLSのテストには、そのリスクを特別に扱い、MLSのテストにのみ有効なテストタイプを使用する場合が多いです。例えば、前のセクションでは、偏ったトレーニングデータに対する処理として、「不公平なデータバイアステスト」が挙げられました。このリスクとテストタイプは、通信システムのテストに特化したプロトコルテスト、コンピュータゲームのサウンドテストに特化したコンテンツ聴覚テスト、およびデータベースのテストに特化したスキーマ/マッピングテストと同様に、MLSのテストに特化しています。 AI 専門テスターの必要性 これまで見てきたように、MLSのテストに特化したテストタイプや技法がいくつか存在します。つまり、MLSのテスト担当者は、これらのテストタイプや技法をどのように適用するかを知っておく必要があります。また、テスト対象のシステムの基礎となる技術を理解していることも、大きな利点となります。MLSのテストの場合、これはシステムがどのように構築されているかを理解することを意味し、非AIシステムのテスターには必要のないスキルです。 このように、MLSには特有のリスクがあるため、MLSシステムのテスターには専門的なスキルが必要とされます。同様の議論は、他のタイプのAIシステムのテスターが必要とするスキルにも当てはまります。AIベースのシステムの開発とテストを担当する者にとっての現在の課題は、このようなスキルを持つテスターが非常に少ないということです。これまでのところ、テスターに転身するデータサイエンティストはほとんどいません。データサイエンティストの現在の需要と高給を考えれば、彼らを責めることはできません。また、つい最近まで、従来の非AIシステムのテスターが、AIシステムのテストに自分のスキルセットを拡張したいと望む場合に利用できるトレーニングコースはほとんどありませんでした。幸いなことに、現在ではAIシステムをテストするためのISTQB認定資格があり、いくつかのトレーニングプロバイダーがそれをサポートしています。また、この分野のテスト標準も開発中であり、AIベースのシステムをテストするトピックの基礎を提供し、将来のトレーニングコースの開発をサポートするはずです。 結論 この記事ではまず、現代のプロフェッショナルなテスターにとってのベストプラクティスとして知られているリスクベースドテスト（RBT）の基本概念を紹介しました。RBTは、すべてのシステムのテストに使用されるべきであり、ISO/IEC/IEEE 29119シリーズのソフトウェアテスト標準によって義務付けられており、ISTQB認定資格の基本的な部分です。 AIはますます普及しつつありますが、AIシステムに対する一般の人々の不信感は高まっているようです。私たちはこの信頼の欠如に対処しなければならず、テストはその技術的解決策の重要な部分となっています（AIに関するユーザーとのコミュニケーションを大幅に改善する必要もある）。 機械学習システム（MLS）は、現在、AIシステムの中で最も広く使用されています。この記事では、リスクベースのテストアプローチを使用して、最も適切なテストタイプと技法を特定するために、MLSに関連するユニークなリスクをどのように使用できるかを示しています。 このようなMLS特有のテストタイプや技法は、ほとんどのテスターにとって初めてのものでしょう。より効果的かつ効率的なテストを通じてMLSに対する信頼を高めるためには、MLSに使用されるテストの成熟度を高める必要があります。これを達成するための第一歩は、MLSのテストが専門的なテストの中でも別個の専門分野であることを認識し、この専門分野をサポートする方法を特定することです。 この記事はReid博士の下記の記事を日本語に翻訳したものです。 オリジナル英語版はこちらに掲載しています。 ■ Risk-Based Testing for AI (English version/オリジナル英語版) The post 【日本語版】AIのリスクベーステスト/Risk-Based Testing for AI (日本語翻訳版)　 first appeared on Sqripts .

本記事の日本語翻訳版はこちらに掲載しています。 ■ AIのリスクベーステスト/Risk-Based Testing for AI (日本語翻訳版) This article was written by Dr. Stuart Reid in commemoration of his upcoming presentation at the Premium Seminar to be held on September 26, 2023 (Tuesday). Please refer to the following link for more details about the Premium Seminar: ■ 9.26開催！Stuart Reid博士 特別セミナー｜知識ゼロから学ぶAIテスト Introduction Risk-based testing (RBT) has been around in various forms since the early 1990s and accepted as a mainstream approach for the last 25 years.  It is the basis for the ISO/IEC/IEEE 29119 series of software testing standards, which mandate that all testing should be risk-based.  RBT is also an integral part of tester certification schemes, such as ISTQB, which means that globally well over a million testers have been taught the RBT approach. AI has been around even longer than RBT, however it is only in the last few years that it has become a mainstream technology, which many of us now rely on.  This evolution from the lab to its day-to-day use, sometimes in critical areas, has meant that there is now an increasing acceptance that commercial AI systems need to be systematically tested.  The widespread lack of public trust in AI systems reinforces the need for a more professional approach to the testing of these systems.  According to some data scientists, AI is so different from traditional software that new approaches to developing these systems are needed, including how they are tested, and by whom. This article introduces the basic concepts of RBT, demonstrates its adaptable nature, and shows how it can, and should, be used for the testing of machine-learning systems (MLS). This article lists many of the risks that are unique to MLS, and, through these, identifies several new test types and techniques that are needed to address these risks.  This article concludes by explaining the need for specialist testers who understand not only these new test types and techniques, but also the AI technology that forms the basis of these systems. Risk and IT Systems We all use risk on a day-to-day basis in our daily lives (e.g. ‘should I walk the extra 50 metres to the pedestrian crossing or save time and cross here?’) and similarly many businesses are based on the management of risk, perhaps most obviously those working in finance and insurance. For those who work in the development and testing of IT systems, the use of a risk-based approach has long been accepted as a means of ensuring trust in such systems.  Many sector-specific standards, some of which date back nearly 40 years, exist for both safety-related and business-critical areas, and define requirements based on risk for both software development and testing. Why Risk-Based Testing? Risk-based testing provides several benefits, such as: More Efficient Testing   If we use risk-based testing, we identify those parts of the system under test that are higher risk and we then spend a higher proportion of our test effort on those parts.  Similarly, we spend less of our test effort in the areas that are lower risk.  This typically results in a more efficient use of testing resources – with fewer high-scoring risks becoming issues after the system is delivered.  This aspect of RBT can simply take the form of adjusting the amount of test effort used, but it can also include the use of specialist types of testing to address specific risk areas (e.g. if we have a user interface risk, we may decide to perform specialist usability testing to address the risk). Test Prioritization   If we know which of our tests are associated with the highest risks, then we can schedule those tests to run earlier. This has two main benefits. First, if our testing is ever cut short, we know we have already addressed the highest risk areas. Second, it means that when we do find a problem in a high-risk area, then we have more time left to address it. Risk-Based Reporting and Release   By using a risk-based approach, then at any time, we can easily report on the current state of the system in terms of the outstanding risks (i.e. those risks that have not been tested and treated).  This allows us to advise the project manager and customer that if they decide to release the system now, then all the risks we have not yet tested still exist (and so they are accepting the system with those risks).  Thus, any decision they make to release the system can be based on risks that they know about and have agreed exist.   The RBT Process Risk-based testing follows a typical risk management process, a simplified version of which is shown in Figure 1.   Figure 1: Simplified Risk Management Process First, we identify any applicable risks.  Next, we assess these risks so that we can estimate their relative importance.  And then we decide which of the risks can be handled by testing. Risk management is hardly ever a one-off, however, and normally it is an ongoing process that handles changing risks. Risk Identification RBT is concerned with the identification and management of two types of risks: project and product risks.   Project risks are the same type of risks as used by project managers (often documented in a Project Risk Register). They are largely concerned with whether we will deliver on time and within budget.  Project risks also cover the availability of suitably-skilled testers and the likelihood of code being delivered to the testers from the developers on time.  As a test manager, the project risks can have a huge influence on the type and amount of testing we include in the test plan. For instance, using a new test technique may introduce the risk of a lack of required implementation skills in the test team and a risk of increased test tool costs. Product risks are more specific to testing.  These are risks associated with the deliverable product and so these are the risks that tend to affect the end users. At a high level, we may consider product risks in terms of functional and non-functional quality attributes. For instance, a functional product risk may be that the software controlling the car window fails to respond appropriately when the closing window encounters a child’s head.  Non-functional product risks could be that the user interface for the in-vehicle infotainment system is difficult to read in bright sunlight (perhaps due to poorly-managed contrast and brightness), or that the response times when a driver selects a new function are too slow. When attempting to identify risks, we ideally need to involve a wide variety of stakeholders.  This is because different stakeholders know about different risks and we want to find as many potential risks as possible (if we miss an important risk, it is highly-likely that we will fail to test the corresponding part of the system in sufficient depth, so increasing the likelihood of missed defects in that area).   The requirements should always be considered as an important source of product risks.  Not delivering requested functionality is an obvious risk and one that the customer is unlikely to consider acceptable (so increasing the impact of this type of risk). SIDEBAR: Why Not Requirements-Based Testing? In the past, testing followed a requirements-based approach, where the testing simply covered those elements explicitly requested by the customer.  But what happens in the typical situation when the customer doesn’t state their requirements perfectly?  For instance, if they do not document all their required features, or they do not specify all the relevant quality attributes, such as response times, security requirements and the level of usability they needed.  The simple answer is that requirements-based testing does not cover these missing requirements – and so only provides partial test coverage of the system that the customer wants.  And what happens when the customer’s requirements aren’t all equally important (the normal state of affairs)?  With requirements-based testing, every requirement is treated the same – so our autonomous car would have its pedestrian avoidance subsystem tested to the same rigour as the in-vehicle infotainment (IVI) system.  Luckily, for safety-related systems we don’t use requirements-based testing alone – the sector-specific standards for such systems tell us that we must employ a risk-based approach with integrity levels.  However, with any system, if we treat all the requirements as equally important, this will lead to inefficient use of the available testing resources. So, if requirements-based testing is inefficient and leads to poor test coverage, then what is the alternative?  Risk-based testing accepts that unstated requirements exist for all systems, and so missing requirements are treated as a known risk that needs to be handled.  When missing or poor requirements are perceived to be a high-enough risk, then the tester will normally talk to users and the customer to elicit further details about their needs to treat this risk. Testers may also decide to use a specific test approach, such as exploratory testing, which is known to be effective when complete requirements are unavailable. Risk Assessment The score assigned to a risk is evaluated by considering a combination of the likelihood of the risk occurring and the impact of that risk if it becomes an issue.  In an ideal world, we would be able to precisely measure the size of each risk.  For instance, if the likelihood of a risk occurring was 50% and the potential loss was $100,000, we would assess that risk at $50,000 (risk score is normally calculated as the product of impact and probability).  In practice, it isn’t so simple.   We are rarely able to get the business to accurately tell us what the impact would be if a particular risk became an issue. Take, for example, risks associated with the user interface of an in-vehicle infotainment system.  We may know from feedback on the previous version, that car drivers found the user interface difficult to use, and so we have identified this as a risk with the new interface.  But what is the business impact? This can be extremely difficult to measure, even in retrospect, but predicting it before a vehicle even goes to market is practically impossible.   Calculating the probability of a risk becoming an issue is often considered an easier task, as we normally get the information needed to determine this from the developers and architects (who we, as testers, are normally closer to), and perhaps from historical defect data.  However, estimating the likelihood of a failure in a specific area is not an exact science.  We may talk to the architects and get their opinion on whether the part of the system associated with the risk is complex, or not.  We may talk to the developers and ask how they rate the likelihood of failure, which may depend on whether they are using unfamiliar development techniques or programming languages, and we could also estimate the capabilities of the architects and developers.  However, we are never going to be able to come up with a precise probability for a software part of the system failing (hardware is easier to predict). So, if we cannot accurately assess risk score when performing RBT, what do we do?  First, we don’t measure risk absolutely.  Instead, we assess risks relative to each other, with the aim of determining which risks we need to test more rigorously and which risks we need to test less rigorously.  We make informed guesses.  This sounds unscientific, but, in practice, the differences between risk scores are normally so large that our informed guesses are good enough.  The most common approach to risk assessment for RBT is to use high, medium and low (for impact, likelihood and the resultant risk score).  Figure 2 shows how this can work.  The business provides a low, medium or high impact for a given risk, while the developers provide a low, medium or high probability of failure.  These are combined, as shown, and the resultant position on the graph gives us the relative risk score. It is important to emphasize that if actual numbers are assigned as risk scores (rather than simply reading off a ‘high’, ‘medium’ or ‘low’ risk score from the position on the graph) then these numbers are only useful for determining the relative exposure for different risks – the actual scores should not be used to directly determine how much testing to perform.  For instance, if we had two risks, one ‘Low-Low’ with a nominal score of 1, and one ‘High-High’ with a nominal score of 9, we do not assign nine times as much effort to the second risk than the first risk.  The scores, instead, should tell us that the second risk is relatively higher than the first risk, and so we should assign more testing to it. If you need to convince yourself that this is correct, you might like to try applying similar approaches to the same two risks but using different scales for impact and likelihood (e.g. 1 to 3 and 1 to 5) – you will soon see that the result can only be useful as a relative risk score. Figure 2: Risk Scoring using High, Medium and Low So far, so simple.  Here are some suggestions for when you use this approach. Make sure that the stakeholders who give you the scores for likelihood and impact use the full range (from low to high).  You will find that some stakeholders (especially users) think that ‘their’ part of the system is the most important part and so always score every risk in their area as high impact.  This is not especially useful, as we are trying to get relative scores, so that we can discriminate between risks, and if most risks are scored high then we cannot discriminate between them. Also, ensure the stakeholders approve the risk scores. It can be extremely frustrating when a bug is found post-release when the customer complains that you should have found this bug because it was in a ‘high risk’ area. However, you can clearly recollect that they agreed to consider that area as low risk, resulting in comparatively less testing than performed in some of the other areas. Finally, there is a third parameter that we often use in our calculation of the risk scores. This is the frequency of use.  Imagine we are performing a risk assessment and two system features are both assigned as high risk, but we know that the first feature is only used once per day, while the second feature is used every minute.  This extra information should tell us that the second feature warrants a higher risk score, as if that feature fails, the potential cost of failure will be far higher. Risk Treatment The third step of the RBT process is risk treatment.  At this point we typically have several options. For instance, we may decide that for a given, low-score, risk then the cost of testing is too high when compared with the cost of the risk becoming an issue. This is often the case for low-scoring risks – and it is quite common to set a threshold risk score, and not test risks that fall below this level.  Sometimes we might find that the testing costs for a given risk are very high (e.g. when we need specialist testers and tools) and may decide that it is not cost-effective to test that risk even when the risk score is relatively high. In such cases, we normally try and treat the risk another way, and we may ask the developers to try and reduce the risk, for instance, by introducing redundancy to handle a failure, or we may recommend that the users live without that feature in the system. When we treat risks by testing, we are using testing to reduce the associated risk score. The score is reduced by decreasing the perceived probability of failure – if a test passes, then we conclude that the probability of failure is reduced (the impact typically stays the same). We cannot normally get rid of a risk completely in this way as testing cannot guarantee that the probability of failure is zero (we can never guarantee that no defects remain). However, if we test a feature and the test passes, we now know that for that set of test inputs in that test environment, the feature worked, and the risk did not become an issue. This should raise our confidence about this feature, and if we were to re-assess the risk we would assign it a lower probability of failure. This decrease may be enough to move the risk score below the threshold under which we have decided that testing is not worthwhile, otherwise we run more tests until our confidence is high enough (and our perceived probability of failure is low enough) to get the risk score below the threshold. Risk treatment by testing can take several forms and is based on both the risk type and the risk score. At a high level, we often treat risks by deciding what is included in the test strategy.  For instance, we may decide which test levels to use on the project (e.g. if integration is considered high risk, we perform integration testing), and we may decide which test types to use for different parts of the system (e.g. if we have high-scoring risks associated with the user interface, then we are more likely to include usability testing as part of our test strategy).  Risks can also be used to decide which test techniques and test completion criteria are selected, and the choice of test tools and test environments can also be influenced by the assessed risks. At a lower level, we may decide (as individual testers) how we will distribute our tests across a single feature based both on the assessed risks and our knowledge of the system and its users.  For instance, if we are testing a feature and we know that certain parts of it are used more often than others, it would be reasonable to spend more time testing the more frequently-used parts (all else being equal). Good risk treatment is highly-dependent on the skills and experience of the tester (and test manager).  If we only know two test techniques then we have four possible options (use technique A, use technique B, use both techniques, or use neither).  However, if neither of the techniques we know is suitable for treating the perceived risk, then the effectiveness of our risk-based testing is going to be severely-limited.  On the other hand, if we have knowledge of a wide range of testing types and techniques, we are far more likely to be able to choose an appropriate treatment. RBT should NOT be a One-Off Activity On many projects, risk-based testing is performed as a limited one-off activity, used only at the start of a project to create the test plan and its associated test strategy, after which nothing changes.  But, as is shown by the arrow returning to ‘identify risks’ in the simplified risk management process in Figure 1, RBT should continue as an ongoing set of activities, ideally until the system is retired. As was mentioned previously, as soon as our tests start passing, our confidence increases, and the perceived probability of failure should decrease. Thus, as we run tests, the risk levels change, and so our testing should also change to reflect this.  However, it also works the other way – when our tests fail.  In this case the probability of failure (for these test inputs) is now 100% and we no longer have a risk, instead we have an issue that must be handled (risks have a probability of failure that is less than 100%, otherwise they are an issue).  One of the principles of testing is that defects cluster together, so when we find a defect, we should immediately consider the likelihood that we have just discovered part of a defect cluster.  Thus, the parts of the system near our newly-found defect will now have an increased likelihood of failure.  This will increase the associated risk score – and this should mean that more testing in this area is considered. Risks do not only change because of the testing.  Customers often change their requirements mid-project, which immediately changes the risk landscape.  Also, external factors, such as the release of competing systems may change the business impact of certain risks (perhaps unique features are now more important) or it may be that the imminent release of a competing system means that delivery (and testing times) are shortened to allow release before the other system, so increasing project risks. Similarly, an unexpected winter ‘flu epidemic could also change project risks associated with the availability of testers and the associated capabilities in testing they provide. RBT and AI Systems So, does anything change when we test AI systems?  In short, the answer is ‘No’.  When testing, RBT can, and should, be applied to all systems, whether they contain AI components or not. However, the testing of AI systems is different than for traditional, non-AI systems – and that is because the risks are different. There are many types of AI systems (e.g. machine-learning systems (MLS), logic- and knowledge-based systems, and systems based on statistical approaches), and each will have its own specific risks, so each type of AI system is tested differently.  At present, machine-learning systems are the most popular form of AI, and so we will next look at how we test MLS using RBT. Risks Associated with Machine-Learning Systems There is no definitive way of categorizing risks for MLS, but there are risks associated with both the development of the MLS and with the MLS itself.  MLS are different from other systems in that the core of the MLS, the model, is generated by an algorithm using patterns in the training data.  A high-level view of the creation and operation of an MLS is shown in Figure 3. Figure 3: Simple Machine Learning In contrast to traditional, non-MLS, systems, the deployed MLS component, which is known as the ML model, is not programmed by a person, but is instead generated by a machine-learning algorithm.  This reusable algorithm (which is programmed by a person), is fed training data by the data scientist, and uses the patterns in this data to generate the model.  Once deployed, the model transforms similar real-world operational data into predictions, such as classifying whether an image is a cat or a dog.  Given the unique nature of MLS development, specialist frameworks are used by data scientists to develop ML models.   Using this description, we can break machine learning into three main areas, and classify risks associated with machine learning in terms of these areas: Input data – concerned with the provision of the training data to support machine learning and the provision of production data used by the model in its operational environment. Model – concerned with the generated ML model.  Development – concerned with the ML algorithm, the development of the model, and the ML development framework. Input Data Risks One noticeable distinction of MLS stems from the importance of data in the machine learning process. If the data used to train the model is flawed, then the resultant model will also be flawed.  For instance, you will have undoubtedly heard that some MLS have been found to be biased against some minority groups. Typically, this bias is not due to the machine learning process and algorithm (although that is a possibility), but is due to bias in the training data.  Thus, when building an MLS, data scientists should consider the risk that the data they use to train the system is biased.  It is often biased due to using historical data that is inherently biased (e.g. including views on race and gender from 50 years ago).  From an RBT perspective, if we know that biased training data is a potential risk for MLS, then we should consider how testing can be used to treat this risk. And, unsurprisingly, testing for bias in MLS is already quite well understood. Bias is only one of several potential risks associated with the training data used to train MLS. The preparation of training (and operational) data for MLS is a complex task that consumes the highest proportion of data scientists’ effort, and so there are many chances for things to go wrong (and so for corresponding risks).  In the list below are some of the most common risks associated with input data for MLS: biased training data mishandled data acquisition data from untrustworthy sources insecure data input channels ineffective data governance issues with the data pipeline software and hardware configuration management problems potential data pipeline design defects potential data pipeline implementation defects potential issues with the dataset as a whole imbalanced by insufficient coverage of all target classes internally inconsistent skewed through data augmentation sub-optimal feature selection potential issues with examples/instances missing data wrong data types out of range data outliers and extreme values incorrectly labelled data unrepresentative training data data focused on a subset of all use cases datasets that do not provide coverage of all regions of the data space ML Model Risks  In many respects, we can consider the model part of an MLS in much the same way as any small system, and there will be a set of functional risks associated with its provided functionality, which will change from system to system. However, ML models do have some special characteristics that allow us to identify the following set of risks commonly associated with ML models:    functional risks  wrong function learnt by the model failure to achieve required ML model performance measures (e.g. lack of accuracy, recall) probabilistic in nature and non-deterministic biased or unfair ML model  unethical model  adversarial examples  overfitted model  unacceptable concept drift  model exhibits reward hacking  model causes side-effects  user dissatisfaction with model results model API defect  non-functional risks lack of model robustness  inadequate model performance efficiency model deployment/use inappropriate model structure (e.g. for deployment to target platform) poor model documentation (e.g. function, accuracy, interface)  model updates decrease performance Development Risks As has already been described, MLS are created in quite a different way compared to traditional systems, using algorithms.  Most data scientists use specialist ML development frameworks to support the creation of MLS, and so it is not surprising that several ML-specific risks can be identified in the development area, such as:   ML development framework risks sub-optimal framework selection flawed framework installation or build flawed implementation of evaluation flaws introduced to models produced by algorithms poor efficiency (e.g. framework slow or stops responding) poor user interface API misuse (e.g. API to a library, TensorFlow API) used library defect (e.g. defect in CNTK, PyTorch) security vulnerabilities poor documentation (e.g. no help) ML algorithm risks sub-optimal algorithm selection flawed algorithm (e.g. faulty algorithm implementation) lack of explainability (e.g. selected algorithm is difficult to explain) training, evaluation and tuning risks unsuitable algorithm/model selected sub-optimal hyperparameter selection (e.g. network structure, learning rate) flawed allocation of data to training, validation and testing datasets (e.g. not entirely independent) poor selection of evaluation approach (e.g. n-fold cross-validation) stochastic nature of the learning process (e.g. non-deterministic results, and difficulty in test reproducibility) deployment risks deployment defect (e.g. generating the wrong version for a target platform) incompatibility with operational environment Assessing and Treating the Risks As previously described, the assessment of risks to produce a risk score is based on a combination of impact and probability.  For the risks specific to MLS listed here, an average probability could possibly be estimated for a typical project, however the impact is always purely project-specific. Where the identified risks can be treated by testing, several test types can be identified that could be selected as risk treatments and are specific to the testing of MLS.  The following lists of risk treatments are derived as potential treatments for the previously identified risks. Input Data Risk Treatment through Testing For the risks associated with test input data, the following ML-specific test types may be applicable as treatments: Data Pipeline Testing Data Provenance Testing Data Sufficiency Testing Data Representativeness Testing Data Outlier Testing Dataset Constraint Testing Label Correctness Testing Feature Testing Feature Contribution Testing Feature Efficiency Testing Feature-Value Pair Testing Unfair Data Bias Testing In addition, Data Governance Testing, which is also used for non-AI systems, would also be appropriate for treating the risk of ineffective data governance. ML Model Risk Treatment through Testing One of the unusual characteristics of ML models is that the internal working of many of them (especially deep neural nets) are difficult to understand even when we do have access to them.  In this respect, we can consider an ML model to be similar to other systems where we don’t have access to the internal details of how they work. From a testing perspective, there is a whole class of ‘generic’ test techniques suitable for the testing of such systems, which are known as black-box test techniques.  Generic techniques (i.e. that also apply to non-AI systems) that have been identified as being suitable for treating ML model risks include: A/B Testing API Testing Back-to-Back Testing Boundary Value Analysis Combinatorial Testing Exploratory Testing Fuzz Testing Metamorphic Testing Regression Testing Scenario Testing Smoke Testing  Performance Efficiency Testing In addition to these generic test techniques, there are also several test types and test techniques that are specifically useful for the testing of MLS, such as: Adversarial Testing Model Performance Testing Alternative Model Testing Performance Metric Testing Model Validation Testing Drift Testing Overfitting Testing Reward Hacking Testing Side-Effects Testing White-Box Testing of Neural Networks Ethical System Testing Model Bias Testing Model Documentation Review Model Suitability Review ML Development Risk Treatment through Testing Several generic test techniques can be identified that are suitable for treating the risks associated with the development of ML models.  For the development framework, most of the identified techniques are non-functional, as the risk associated with the functionality of the framework is thought to be small for widely used frameworks. In contrast, the functionality of the ML algorithm is a well-known risk (in one study this was the major source of defects in MLS), and so several functional test techniques are included for testing the ML algorithm. The generic test techniques that can be applied to MLS, but are also used for non-AI systems, include:  API Testing  (Development Framework) Configuration Testing (Development Framework) Installability Testing (Development Framework) Security Testing (Development Framework) Performance Testing (training the model) Recoverability Testing (training data) Roll-Back Testing (ML model) ML Algorithm Testing Code Review (ML algorithm) Static Analysis (ML algorithm) Dynamic Unit Testing (ML algorithm) Several specialist test types can be identified specifically for the treatment of risks associated with the development framework, the ML algorithm, and the deployment of the ML model.  These ML-specific test types include: Framework Suitability Review Model Explainability Testing Model Reproducibility Testing ML Algorithm Testing Algorithm/Model Suitability Review Library Implementation Testing Model Structure Testing Algorithm Bias Testing Deployment Optimization Testing Model Deployment Testing MLS – Project Risks So far, we have identified product risks and associated treatments through RBT for MLS. These are risks of the deliverable MLS not meeting user needs. However, when performing RBT, we also need to consider project risks, and there are some obvious project risks that threaten the successful testing of the MLS.   We only consider here project risks that affect the testing and are specific to MLS. If you were responsible for testing a MLS, you would also have to consider the generic risks to testing that apply to all projects, such as the estimates for testing being inaccurate and the developers failing to deliver the software under test when agreed. Unhappily, the generic project risk where developers do not understand RBT, but feel qualified to advise testers on how to do their jobs, can also apply to data scientists working on MLS.  A small sample of the project risks that can threaten the success of testing MLS include:  The availability of testers experienced with MLS is inadequate The availability of training for testers on MLS is lacking Testers familiar with the test types that are specific to MLS are unavailable The approach for testing probabilistic systems is not understood The approach for testing non-deterministic systems is not understood Tool support for statistical testing of probabilistic systems is lacking The definition of MLS performance metrics is inadequate to use them as acceptance criteria  Ongoing testing for concept drift is not considered White-box coverage measures for neural nets are immature Is Testing MLS Different from Testing non-AI Systems? Yes, and no.  No – it is not different, because risk-based testing should be used for all systems.  Yes – it is different, because many of the risks are different.  But the risks for any two systems , whether they are AI or non-AI are always different.  Because MLS have some specific risk types, then the testing of MLS will often require the use of test types that specifically treat those risks and that are only useful for testing MLS.  For instance, in the previous section, Unfair Data Bias Testing was identified, and would be used as a treatment for biased training data. This risk and test type are both specific to the testing of MLS, in the same way that protocol testing is specific to the testing of telecommunications systems, content-auditory testing is specific to the testing of sound in computer games, and schema/mapping testing is specific to the testing of databases. The Need for Specialist AI Testers As we have seen, there are several test types and techniques that are specific to the testing of MLS.  This means that testers of these systems need to know how to apply these test types and techniques, a set of skills that is not needed for the testing of non-AI systems. It is also a distinct advantage to understand the underlying technology of the system you are testing.  In the case of testing MLS, that means understanding how these systems are built, which is a skill that is not needed by testers of non-AI systems. Thus, the unique risks associated with MLS mean that there are specialist skills needed by the testers of MLS systems. A similar argument applies to the skills needed by the testers of other types of AI systems.  A current challenge for those responsible for the development and testing of AI-based systems, is that there are very few testers available with these skills.  So far, very few data scientists have moved across to be testers, and who can blame them given the current demand and high pay available for data scientists. Also, until recently, there have been very few training courses available for testers of traditional non-AI systems, who wish to extend their skillset to include the testing of AI systems. Happily, there is now an ISTQB certification for testing AI systems with several training providers supporting it. There are also testing standards under development in this area, which should provide a foundation to the topic of testing AI-based systems and support the development of future training courses. Conclusion This article initially introduced the basic concepts behind risk-based testing (RBT), which is known to be best practice for today’s professional testers.  RBT should be used for the testing of all systems and is mandated by the ISO/IEC/IEEE 29119 series of software testing standards and is a fundamental part of the ISTQB certifications.   AI is becoming increasingly widespread, however the public’s distrust in AI systems appears to be increasing. We must address this lack of trust, and testing is a key part of the technological solution to this (we also need far better communications with users about AI).   Machine learning systems (MLS) are currently by far the most widely used form of AI systems, and this article shows how the unique risks associated with MLS can be used to identify the most appropriate test types and techniques using a risk-based testing approach. These MLS-specific test types and techniques will be new to most testers. If we are to increase trust in MLS through more effective and efficient testing, then we need to raise the maturity of the testing used for MLS. A first step towards achieving this is to acknowledge that the testing of MLS is a distinct specialism of professional testing and then identify ways in which this specialism can be supported.  本記事の日本語翻訳版はこちらに掲載しています。 ■ AIのリスクベーステスト/Risk-Based Testing for AI (日本語翻訳版) The post 【英語版】Risk-Based Testing for AI (English version/オリジナル英語版) first appeared on Sqripts .

初めまして、テストエンジニアのノッカーです。 日々の業務の中で、いままでとは違う新しい経験ができましたので、その体験談を共有させていただきます。 早速ではございますが、以下のような場面に遭遇したことはありませんか？ 要件定義(要求分析含む)の問題により、実装の抜けや漏れ、実装内容の誤りが発生。 そして後の工程に影響が・・・ 私はこの問題をUSDMを用いて解消することができました。今回はUSDMがどのようなものなのか、書かせていただきますので、参考にしていただければ幸いです。 USDM概要 USDM（Universal Specification Describing Manner）とは、日本語で言うと 要求と仕様の記載方法を定義したもの となり、要求仕様を明確に定義するための手法です。詳細については後で説明しますが、まずはUSDMを利用することになった背景からお話したいと思います。 USDM導入のきっかけ 私がこれまでテストベースとして扱ってきた資料の殆どは、開発担当者が作成した機能仕様書です。その中には情報が十分に揃っている機能仕様書もあれば、情報が不足している機能仕様書もありました。おそらく、開発担当者の方もQAの方も、情報不足や共有漏れによる仕様の誤認やすれ違いの経験があるかと思います。 私が経験してきたプロジェクトでも、情報不足や共有漏れにより以下のようなプロジェクト状況となっていました。 テスト分析フェーズでの仕様質問が多く、回答待ちの時間が頻繁に発生していた テスト分析段階での仕様質問により、仕様の漏れが判明し、追加の改修が発生した 本来改修しなければならない画面とは別の類似画面に改修が入ってしまった 仕様の意図が不明瞭であるため、テストの目的を定めるのが難しい場合があった これらを解消するために、「開発前にテスト分析できる環境を整備する？」「開発担当者とQAが協力して要件定義をレビューする？」「仕様に関連する背景や意図をヒアリングするプロセスを確立する？」などQAチームで検討しました。その中で「USDMはどうだろう？」という意見が浮上し、QAチームでUSDMの勉強をして以下のことがわかりました。 USDMとは、ひとまとまりの大きな要求を細かく分割し、分割したそれぞれの要求に対して具体的な処理や振る舞いを想定して仕様化(要件定義)する手法。 期待できる効果としては、 要求、要求の背景、仕様(要件)が並列されて見やすい 細かく要求が分割され、要求の範囲を理解しやすい 理由(要求の背景)が書かれるので誤った仕様化(要件定義)が減りそう 要求の範囲が理解しやすいため、具体的な処理、振る舞いを検討しやすい 具体的な処理、振る舞いを書くため、テスト仕様にもしやすい 要求、仕様がID管理されトレーサビリティが取りやすい 仕様(要件)毎にステータス管理(仕様Fix、実装済み、テスト完了など)が可能 なんだか、プロジェクトの状況を好転できる可能性を感じました。これなら試してみる価値があるのではないかという結論に満場一致で至り、USDMを導入することとなりました。 期待できる効果を見てみると、実装の抜けや漏れ、実装内容の誤りの他にも、以下のような状況の改善にも効果がありそうですね。 要求と要件のトレーサビリティが取りづらくなってしまっている 要件毎のステータス(進捗)が把握しづらくなってしまっている 要求に変更が入った場合に検討しなおしとなる要件、物量が把握しづらくなってしまっている ということで、USDMについて、もうちょっと詳しく説明していきたいと思います。 USDMの特徴 USDMの構成としては以下のとおりとなります。 （１）要求 　要求を記述します （２）要求を分割 　大きな(複合的な)要求事項を分割して細かい(単純な)要求にします （３）要求を階層化 　分割した単純な要求を元の要求の下層に配置します （４）理由を記述 　要求を通したい理由を記述します （５）説明を記述 　補足事項や背景など要求の記述では足りない情報を記述します （６）キーワードラベル 　馴染みのある用語や別名を記述します （７）グループ 　要求や仕様が多い場合に小さい集合に分類して範囲を限定します （８）仕様を導出 　要求と理由から特定できる仕様を導き出して記述します(要件定義を行う) （９）仕様ラベル 　仕様であることを示し、要求と明確に分離します 全てをご紹介するには膨大となってしまいますので、今回は要点を抑えた以下の4点にフォーカスしてご紹介します。 要求を分割する 要求を階層化する 理由を記述する 仕様を導出する(要件を定義する)　※以下、仕様と要件は同義としてお読みください 要求は曖昧性を多分に含んでおり、中には要求を書いた本人にしかわからないということもあります。以下の図の要求を例にして、曖昧な要求を具体的にしていく方法を説明していきます。 EM1 は要求に対する通しIDのようなもので特に指定はありませんが、一意となるように記述します。画像の中にある □□□ は仕様ラベルと呼ばれるもので仕様を書く欄であることを意味し、 □ にチェックマークなどを入れることで、ステータス管理にも活用できます。 まずは複合的な要求を単純な要求に分割します。分割した要求は階層化して、元の要求を上位要求、その配下に分割した要求をそれぞれ下位要求として記述します。 次にそれぞれの要求に対して理由付けを行います。 USDMは見る人の認識のブレを抑える目的で本質的な理由を記述することが必須事項となっています。 「本来改修しなければならない画面とは別の類似画面に改修を入れた」は、改修の目的(理由)が曖昧だったため発生した事案となります。本質的な理由が書かれることで改修しなければいけない画面や機能の取り違え、改修内容の誤認を防ぐことを期待できます。 次に下位要求から仕様を導き出し、特定できるレベルまで仕様化(要件定義)を行います。下位要求EM1-1で例えるなら、保存するデータと保存先のHDDの情報を得るために何が必要かという要求に含まれる具体的な処理や振る舞いを表現します。 ※上記仕様は一部となります 単純な要求である下位要求から仕様を導き出すことにより、仕様化に必要な情報の粒度が細かくなり、仕様漏れのリスクが軽減されます。以前の問題点として前述した、仕様漏れが発覚して追加の改修が発生するような事例については、下位要求による具体性とその要求が必要な理由、そして特定できるレベルの仕様が記述されたことによって解消されました。 USDMを導入してみて 要求の理解が容易になり、手戻り開発の発生なし！ 要求仕様書作成段階で開発とQAがブレインストーミングしながら、要求の分割～仕様化を一緒に行うことで以下の表の結果となりました。 導入してまだ日が浅く、要求数も試行回数も少ないところではありますが、滑り出しとしては好転していると言ってもいいでしょう。 USDMで記述された仕様書は、要求が明確に理由を添えて具体化されており、仕様の意図が明瞭です。この明確な意図により、誤解を防ぐだけでなく、価値を高める要素として、理由を考慮した代替案やより良いアイデアが出てくる場面も増えました。 さいごに まだまだアップデートが必要な部分、改善が必要な部分は垣間見えますが、私が狙っていることは、下流工程での工数削減やプロジェクトメンバーの負担解消です。開発工程の後半で仕様変更が発生すると納期への影響が懸念されます。もちろん、要求仕様書作成にも期日はあるかと思いますが、少なくとも私が関わったエンジニアの方々は口をそろえてこう言います。 「後になって問題が発生するより、前に問題を見つけた方が何倍もマシだ」 どの業界にも同じことが言えるとは思いますが、私自身も早い段階で問題や改善点を見つけて、改善していくことを心がけています。 最後までお読みいただき、ありがとうございました。 The post USDMで初期品質を高めよう！ first appeared on Sqripts .

クオリティマネージャー（Quality Manager 略称：QM）という職種をご存じでしょうか？ その名の通り、品質を保証（Quality Assurance）する責任を持った専門家です。この記事では、ソフトウェア開発におけるクオリティマネージャーにスポットを当てて解説します。 クオリティマネージャー（QM）とは？ ソフトウェア開発の世界では、クオリティマネージャーの役割は多岐にわたり、また重要な役割を担っています。 クオリティマネージャーは、ソフトウェア製品、サービス、プロセスの品質保証（Quality Assurance）に直接的に関与しています。実際の業務では、初期開発フェーズから最終的な納品・運用までの広範な品質管理プロセスを監督しています。 クオリティマネージャーの主な目的は、開発されたソフトウェアが、企業や業界で決められた品質基準を上回っていることを確認することです。さらに、隠れた品質問題の特定、品質管理プロセスを改善するための施策の実行、ソフトウェアの性能と信頼性を阻害する可能性のあるエラーや欠陥の軽減にも責任を持ちます。 また、クオリティマネージャーは開発チームとステークホルダー（利害関係者）の間の重要な橋渡し役も担います。両者と積極的にコミュニケーションを取り、ユーザーからの重要なフィードバックを開発者へ伝えるだけでなく、プロジェクトの品質状況と進展についてステークホルダーが理解し、透明性が保たれるように活動します。 このようにクオリティマネージャーは、ソフトウェア品質の最高水準への妥協しない姿勢を持ち、プロジェクトの全過程に深く関わる役割を持った存在です。 クオリティマネージャーの重要性 前章で述べた通り、ソフトウェア開発の全過程に関わるクオリティマネージャーは、とても重要な役割を担っています。 この章では、クオリティマネージャーの重要性を具体的に見ていきましょう。 品質保証の重要性 ソフトウェアの品質は、完成した製品の成功を大いに左右します。バグや欠陥が存在すれば、ユーザーからの不満を引き起こし、企業の評判にも影響を与えます。クオリティマネージャーが率先して適切な品質保証活動を実施し、欠陥を未然に防ぐことで、これらのリスクを軽減できます。 デザインと仕様の合意の重要性 クオリティマネージャーは、要件定義やデザインの段階からプロジェクトに関与し、開発チームとステークホルダーが共通理解を持てるようにします。 これにより、初期段階での誤解を防ぎ、開発プロセス全体をスムーズに進めることが可能となります。 プロジェクトのコストとスケジュール管理の重要性 効率的な品質管理は、全体の開発コストおよびスケジュールにも影響を与えます。 後に直面するであろう問題を早期に特定し対処することで、その後のフェーズでの問題解決に費やす時間と労力を削減できます。クオリティマネージャーは、品質に関する問題がプロジェクトの予算やスケジュールにネガティブな影響を及ぼすことを防ぎます。 顧客満足度向上の重要性 クオリティマネージャーの働きは、顧客の期待を満たす高品質な製品の提供という形で最終的に顧客満足度に繋がります。 より良い品質の製品を提供することで、企業は信頼性を高め、顧客ロイヤルティを向上させることができます。 以上の点からも明らかなように、クオリティマネージャーはソフトウェア開発における品質保証だけでなく、プロジェクトの全体的な効率と成功に大いに寄与します。 クオリティマネージャーは今やソフトウェア開発に不可欠であり、その存在価値は計り知れないと言っても過言ではないでしょう。 クオリティマネージャーの主な仕事内容と役割 近年、品質管理が重要視されるようになった背景には複数の要因があります。 その一つとして挙げられるのが、開発プロセスが複雑化し技術が進化するにつれて、品質への要求が高まったことです。これまで通りの開発では品質の確保が難しくなり、その役割を担う人が必要になりました。これがクオリティマネージャーや品質保証（QA）エンジニアの役割を生んだ基盤です。 では、そのような役割を担うクオリティマネージャーが普段どのような業務に従事しているのか、この章では実際の業務をご紹介します。 品質計画と戦略の策定 クオリティマネージャーは、ソフトウェアの品質目標を設定し、品質に関する計画と戦略を策定します。これには、品質方針や品質目標の策定、品質管理手法やガイドラインの作成、品質保証活動の計画立案などが含まれます。 品質方針と目標の定義 品質管理手法とプロセスの策定 品質保証活動の計画立案 品質ガイドラインや文書の作成 品質管理プロセスの確立 クオリティマネージャーは、組織内の品質管理プロセスを策定し、適切に実施するための枠組みを確立します。これには、品質規格や品質基準の策定、品質管理ツールやテクニックの導入、品質監査の実施などが含まれます。 品質規格や品質基準の策定 品質管理ツールとテクニックの導入 品質監査の実施と報告書の作成 プロセス改善の提案と実施計画 品質保証と品質管理の実施 クオリティマネージャーは、品質計画に基づいて品質保証活動を実施し、品質を確保する役割を果たします。これには、テスト戦略やテスト計画の策定、テスト設計やテスト実行の管理、不具合管理とその解決、品質データの収集と分析、リリース前の品質ゲートの設定などが含まれます。 テスト戦略とテスト計画の策定 テスト設計とテストケースの作成 テスト実行と不具合管理 品質データの収集と分析 品質改善の推進 クオリティマネージャーは、定期的な評価や検証を通じて品質の問題点を特定し、改善のための取り組みを促進します。これには、品質トレンドのモニタリング、品質改善提案の収集と評価、品質意識の向上のための教育やトレーニングの実施、プロセス改善やベストプラクティスの導入などが含まれます。 品質トレンドのモニタリングと報告 品質改善提案の収集と評価 教育とトレーニングの実施 プロセス改善とベストプラクティスの導入 チームとの連携 クオリティマネージャーは、開発チームや関係者とのコミュニケーションを通じて、品質に関する情報共有や意識の向上を図ります。これには、品質に関するミーティングや報告の実施、品質に関する相談やサポートの提供、チーム内での品質文化の醸成などが含まれます。 クオリティマネージャーは、継続的な品質向上を追求し、組織の品質目標の達成に貢献する役割を果たします。 品質に関するミーティングと報告書 品質に関する相談とサポート 品質文化の醸成と意識向上の活動 クオリティマネージャーは日々このようなタスクをこなしています。 クオリティマネージャーを取り巻く職種 クオリティマネージャーを取り巻く職種には以下のような職種があり、チーム一丸となってプロジェクトの成功に向けて努力し続けています。 品質保証コンサルタント(QAコンサルタント) 品質保証技術やプロセスに精通し、専門的な知識を駆使してプロジェクトチームに助言を提供、ガイド役でもあります。 プロジェクトマネージャー(PM) プロジェクトの監督、進行管理、リソースの配置など、さまざまな管理業務をこなす。QMとは密に連携しています。 品質保証エンジニア(QAエンジニア) ソフトウェアのテスト実施や、その結果に基づく品質改良の提案を行います。ソフトウェアの品質保証における重要な役割を果たします。 こちらの記事もおすすめ ⇒ ソフトウェアのQAとは　ーシステムの品質を守るQAエンジニアの役割と仕事も紹介 </Sqripts> クオリティマネージャーに必要なスキルや経験・資格 ソフトウェア開発に携わっている方でも、クオリティマネージャーという職種にピンとこない方もいるかもしれません。また、「クオリティマネージャーって難しそう…」と考える方もいるでしょう。 とはいえ、同じソフトウェア開発に携わる職種ですので、クオリティマネージャーに必要なスキルは決して特別なものではありません。 近年はプロジェクトマネージャー（PM）経験者がクオリティマネージャーにステップアップすることも少なくありませんので、ここではクオリティマネージャーに必要なスキルや経験をご紹介します。 分析的思考力 クオリティマネージャーに必要な最も重要なスキルの一つが、数値や状況を分析して、論理的な結論や行動計画を導き出す能力です。具体的な問題解決に向けて、データをいかに解釈し、どう利用するかが重要となります。 円滑なコミュニケーション能力 クオリティマネージャーは開発チームやステークホルダーと頻繁にコミュニケーションを取るため、コミュニケーション能力が必要となります。関係者が理解しやすいように、複雑な情報を明確かつ簡潔に伝えることが求められます。 プロジェクト管理スキル 多数のプロジェクトやタスクを適切に進行管理し、必要なときに優先順位をつけて対処するためのスキルも欠かせません。ソフトウェア開発現場では、予期しない変化や調整が必要となることが頻繁にあるため、変動する状況を的確に把握し、プロジェクトをスムーズに進行させる管理能力が求められます。 テクニカルスキル 基本的なプログラミング知識や、ソフトウェアやハードウェアの一般的な理解があると大いに役立ちます。また、企業やプロジェクトによっては、特定の品質管理ツールやソフトウェアの経験を求められる場合もあります。 経験 多くの場合、企業はソフトウェア開発（要件定義、基本設計）、品質保証・テスト、プロジェクトマネージメント、または関連するフィールドでの数年の経験を持つクオリティマネージャーを探しています。先に述べたスキルを育て、実務経験を積むことは、この職種で成功するための大事なステップと言えます。 資格 クオリティマネージャーとして従事する際に、資格が必須となっている例は少ないようです。しかし、クオリティマネージャーを求める多くの企業では「取得することが望ましい資格」として以下の資格を挙げています。 ■ JSTQB（Japan Software Testing Qualifications Board） ソフトウェアテスト技術者認定組織・JSTQBが実施している認定資格。国際的な認定組織ISTQBにも加盟しており、JSTQBのソフトウェアテスト技術者資格は海外でも有効となっています。 現在、以下の3つの資格認定を行っています。 JSTQB認定テスト技術者資格 Foundation Level JSTQB認定テスト技術者資格 Advanced Level（テストアナリスト） JSTQB認定テスト技術者資格 Advanced Level（テストマネージャ） こちらの記事もおすすめ ⇒ JSTQB学習のススメ #1 〜JSTQBとは〜 </Sqripts> ⇒ JSTQB Advanced Level テストアナリスト試験〜みんなの勉強方法と受験結果発表！ </Sqripts> クオリティマネージャーのキャリアパスと将来性 ここまでクオリティマネージャーの実業務についてご紹介してきました。ここではクオリティマネージャーのキャリアパスや将来性について考えてみましょう。 初級クオリティマネージャー 一般的に、多くのクオリティマネージャーは初めて組織で実務経験を積み始めるときには、初級クオリティマネージャーやJunior QMとなります。この段階では、監査、報告作成、簡単な問題解決などのタスクを扱います。 中級クオリティマネージャー 経験を積むと中級クオリティマネージャーになり、より大きなプロジェクトを手がけたり、自身のチームを率いたりする機会が増えます。品質管理の判断を下すなど、高度な職務も求められるようになります。 上級クオリティマネージャー さらに経験を積むと、大規模プロジェクトの監督や組織全体の品質保証プログラムの設計・実施などを担当する上級クオリティマネージャーとなります。 品質保証コンサルタント、クオリティマネージメント部門マネージャー/ディレクター 最終的に、品質保証（QA）コンサルタントや企業のクオリティマネージメント部門のリーダー、マネージャーになる道もあります。これらの役職では、組織全体の品質方針を決定したり、品質管理計画の立案や実施に大いに関与します。 一方、特定の産業分野で特殊なスキルや経験を積んだ人は、その分野の専門家として活躍する道も開けます。製薬業界や金融、航空宇宙産業など、厳密な規制に対応するための深い知識と経験を求める分野では、特にその傾向が強くなっています。 以上は一般的なキャリアパスですが、クオリティマネージャーの経験は多くの分野で役立ちます。クオリティマネージャーという職種は、将来的には自分自身でキャリアパスを切り開くこともできる職種であると言えます。 今なぜクオリティマネージャーが求められているのか テクノロジーが急速に進化する時代において、「クオリティマネージメント」や「品質管理」がますます重要視されるようになっています。その背景には、以下のような環境の変化が関与していると考えられます。 デジタルトランスフォーメーションの推進 社会全体がデジタル化に大きく動いている昨今、企業内部の業務プロセスはもちろん、プロダクトやサービスに至るまで、目まぐるしくデジタル化は進んでいます。 このような状況は、新たに生まれるソフトウェアやテクノロジーに対し、極めて厳格な品質基準を求めることにもつながっています。これらの要求を満たすためには、品質を管理すること、すなわちクオリティマネージャーの存在が不可欠となりました。 データ駆動型の意思決定の重要性 企業が仮説ではなく事実に基づいて意思決定を行うためには、「データ駆動型の意思決定」が重要となります。品質保証の世界でもこのトレンドはあり、データ駆動型の意思決定は問題の特定と対応を可能にするため、重要視されています。 データ駆動型の意思決定を適用できる品質保証コンサルタントやクオリティマネージャーは、将来的に高まる需要に対応することになるでしょう。彼らはデータを分析し、その結果が企業の製品にどのような影響をもたらすか理解することが求められます。また、得られた知見を他のチームメンバーが理解しやすい形で伝えられる能力も必要です。 より多くの「自動化」の必要性 企業のテクノロジー依存度が高まる中、自動化の必要性は引き続き増加すると考えられます。 クオリティマネージャーや品質保証コンサルタントは、自動テストツールにも精通し、効果的に使用する方法を心得て、導入を推し進める必要があります。 そのような専門知識を持つクオリティマネージャーの先導によりテストを自動化することができれば、企業は手動テストのニーズを減らし、時間とコストを節約することができます。さらに、製品が様々な条件下でテストされることを保証することで、製品の信頼性を向上させることができるのです。 ユーザーニーズの高度化 ユーザーは迅速な結果と完璧なパフォーマンスを求めています。このニーズを満たすために、ソフトウェアの「品質」は以前に増して重要な要素となりました。品質を管理・維持する役割はクオリティマネージャーが担っていますので、ここでもクオリティマネージャーの役割が大きいことがわかります。 法規制の厳格化 ビジネスがよりグローバル化するにつれて、コンプライアンス強化の動きが活発になっています。 これは、クオリティマネージャーなどの品質保証の専門家が、規制要件に強い理解を持つ必要があることを意味しています。彼らは、企業に適用可能なすべての法律や法規に準拠していることを確実にする必要があります。 また、特に医療、金融、自動車といった特定の業界では、製品やサービスに対する規制が一層厳格化しています。これらを遵守し、同時に高度な品質とプロセスの管理を保つため、プロジェクトでは常にクオリティマネージャーが求められています。 安全とセキュリティ データ侵害やサイバー攻撃の増加に伴い、企業はより高度なセキュリティ対策を求められています。 製品の質が悪ければ重大なセキュリティホールからサイバー攻撃の標的になったり、情報漏洩したりといった事故にもつながりかねないため、「安全・セキュリティ」と「品質」は密接に関わっていると言えます。クオリティマネージャーは安全を確保する役割も担っているのです。 このように、デジタル社会で企業が生き抜くためにはクオリティマネージメントが必要不可欠になりました。社会がテクノロジーに依存する度に、クオリティマネージャーの重要性は一段と増し、それに伴い求められる能力は高まっていると考えられます。 クオリティマネージャーの魅力 さて、ここまでクオリティマネージャーの職務や将来性について書いてきましたが、この章ではクオリティマネージャーという仕事の魅力について紹介します。 大きな影響力 一つのバグや問題が製品全体の質を大きく左右することは珍しいことではありません。クオリティマネージャーが行う品質管理活動は、製品やサービスがユーザーに好評を博すための大きな一歩と言えます。 強い需要 前章でも述べたように、品質管理は多くの業種で重要視されています。それは、求人市場でも明らかで、クオリティマネージャーの需要は年々高くなっています。 多様なキャリアパス クオリティマネージャー経験者のスキルセットは転職に有利で、さまざまな業種・職種へと進出できる可能性を秘めています。品質を確保するための理想的な手段を知っているQMは、ITのみならずエンジニアリング、製造業など多くの領域で活躍できます。 常に学び続けられる環境 テクノロジーは絶えず進化し続けるため、クオリティマネージャーは新しいトレンド、ツール、手法を学び続ける必要があります。これは、探求心旺盛な人にとっては大きな魅力となります。 大きな達成感 製品やサービスが市場で成功を収めたとき、その背後にある高品質なプロセスを作り上げることに大きく寄与する一人がクオリティマネージャーです。その達成感は計り知れないでしょう。 クオリティマネージャーの醍醐味は、大きな影響力を持つ職務に従事することで、自分の行動が製品やプロジェクトの成功に直接貢献しているという感覚を得られることです。仕事のやりがいや達成感を重視したい人にとっては、大変魅力的な職種と言えるのではないでしょうか。 まとめ：クオリティマネージャーを目指す方へ ここまで述べてきた通り、クオリティマネージャーはソフトウェア開発の成功に欠かせない存在であり、その責任と影響力は大変に大きいものです。クオリティマネージャーが確保した品質は、最終的に企業の製品やサービスの質、そして顧客満足度に直結します。この観点から見れば、クオリティマネージャーの役割は企業全体、さらには業界全体においても重要な評価を受けるものと言えます。 もし現在プロジェクトマネージャー(PM)として従事している方が、より大きなプロジェクトで全体見据えた活動を望むのであれば、クオリティマネージャーへのステップアップは理想的な選択肢です。プロジェクトマネージャーの経験と知識を活かして、製品やサービスを一段上の次元へ導く役割を担うことができるからです。 また、初めてのキャリア選択でクオリティマネージャーを目指したいと思う方は、まずは品質保証(QA)エンジニアとして従事することをお勧めします。未経験から技術的なスキルを獲得しクオリティマネージャーを目指すことは、今後の需要から見ても理想的なキャリアプランだと考えられます。 The post ソフトウェア開発におけるクオリティマネージャー（QM）とは？その役割や重要性・将来性について first appeared on Sqripts .

皆さんこんにちは！　テストエンジニアのマツキョーです！ ソフトウェア開発で品質を担保する活動の1つがソフトウェアテスト（以降、テスト）です。テストには様々な種類がありますが、基本的にテストを設計して実行するという工程で実施されます。 ですが、テストといえばテスト実行のことをイメージされる方も多いのではないでしょうか。現在はテスト技法が確立されたり、プロセスの概念が浸透してきたことでテストプロセスという考え方もかなり浸透してきました。しかしながら、現在もテストを「ひとつの作業」と捉えている人や、詳しいテストプロセスについて知らない人も少なくありません。 テストプロセスとは、「テスト計画」「テストのモニタリングとコントロール」「テスト分析」「テスト設計」「テスト実装」「テスト実行」「テスト完了」の7つで構成された テストの目的を達成する確率を高めるための活動 のことです。その中でも「テスト分析」は、テスト計画やテスト設計に比べるとまだまだ知名度の低い活動の1つではないでしょうか。そんな少し影の薄いテスト分析ですが、私はテスト全体の成否を分けるくらい重要な工程だと考えています。 私が「テスト分析」を重要だと考える理由として以下の３つがあります。 理由１：『テスト分析』は、テストの土台をつくる作業である 理由２：『テスト分析』は、最もテストを理解しやすい工程である 理由３：『テスト分析』は、テストと品質を繋ぐ中継地点である この記事では、テスト分析がどのような活動なのかを説明した後、３つの理由を通じてどのように重要かをお話できればと思います。またテスト分析を適切に行うことのメリットや、適切に行えなかった場合のリスクについても触れていきたいと思います。 テスト分析とは？ テスト分析の位置づけ まず、テスト分析がテストプロセス全体のどこに位置するのかを確認しましょう。 上図では、テスト分析はテスト計画とテスト設計のあいだに位置しています。 JSTQBテスト技術者資格 Foundation Level シラバス では、以下のように記述されています。 テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定する。 JSTQB-SyllabusFoundation_Version2018.J03 要約すると、テスト分析はテストベースからテストする機能とテスト条件を定義することで「 何をテストするか 」を決める工程ということが書かれています。 テスト分析の作業 テスト分析の作業は、以下の４つのステップで行います。 ステップ１：テストレベルに適したテストベースを読み解いて情報を整理する ステップ２：テストベースの欠陥を見つける ステップ３：テスト対象の機能とテスト条件を洗い出してカテゴライズし優先度をつける ステップ４：テストベースとテスト条件のトレーサビリティを確立する 各ステップを理解するために、ここまでに度々出てきた「テストベース」という用語を知る必要があります。 ISTQB Glossary では、以下のようにテストベースが説明されています。 テスト分析と設計のベースとして使用するあらゆる情報。 ISTQB Glossary 具体的には、要件定義書、機能設計書、ユーザーストーリーといった開発ドキュメントが主なテストベースとなりますが、開発者との口頭でのヒアリング内容といった形のない情報もテストベースに該当します。 まとめると、テスト計画で定めたテスト目的を達成するためにテストベースを分析して、テストする機能やテスト条件を導き出していく工程が「テスト分析」というわけです。 簡単ではありますがテスト分析についてご説明したところで、ここからはテスト分析が重要だと考える理由をひとつずつお話していきます。 『テスト分析』は、テストの土台を作る作業である テスト分析では後続のテスト工程に影響するテスト条件を決める テストは、テストプロセスを通じて目に見えない品質を積み上げていく活動と言えます。「テスト計画」でテストの目的や達成するためのアプローチを定め、「テスト分析」「テスト設計」「テスト実装」で目的を達成するためのテストを構築し、「テスト実行」で品質を担保していきます。その中でも「テスト分析」は、以降のテスト工程にも影響する テスト条件 を決める工程です。 テスト分析が適切に行われない場合のリスク テスト分析が適切に行われない場合、以下の問題が発生する可能性があります。 テスト条件の抜け漏れが出る 誤ったテスト条件を定義してしまう 後続の工程であるテスト設計では、テスト条件を基にテストケースを作成します。そのためテスト条件に抜け漏れがあると、必要なテストケースが作成されず、テストしていない機能や条件ができてしまいます。同様に誤ったテスト条件が定義されると、間違った仕様のままテストケースが作成されてしまう事でしょう。いずれの場合も、そのままテストが終わってしまうと 不具合の流出 や 本来の品質・価値を提供できない というリスクが高まります。 テスト条件は後続のテスト工程の基礎となる重要な要素であることから、 テスト分析はテストの土台をつくる作業である と言えます。 『テスト分析』は、最もテストを理解しやすい工程である テスト分析の成果物 テスト分析では、膨大なテストベースから情報を読み解いてテスト条件を定義していきます。当然、テスト条件を定義するためには、対象となる機能を深く理解する必要があります。 そのためテスト分析では、ドキュメントの文字を追うだけでなく、情報を図表などを用いて整理していきます。この過程で、テストベースとテスト条件の関係が整理されたドキュメントが作成されます。このドキュメントは、テスト全体を俯瞰で捉えることができるため、他者とのコミュニケーションや後続の工程における情報整理に利用できます。 テスト分析の成果物の活用例 テストエンジニアが作成したテスト成果物のレビューを例にしてみます。テスト成果物は、開発者やプロダクトマネージャ等のステークホルダと共にレビューを行うことでテストが品質を担保できるかを検討します。立場によってプロダクトに関する知識にはバラつきがありますので、レビューの際はできるだけ関係者間で共通認識を持つことが重要だと考えます。 このときテスト全体をシンプルに整理したドキュメントがあれば、ステークホルダ全員が共通の認識を持つことを助け、テストを正しく理解することができ、より建設的なレビューが可能になるでしょう。 テストベースを、 テスト目的の達成のために分析してテスト条件を定義する というシンプルな構図で整理されたドキュメントを作る工程がテスト分析というわけです。 このことから、テスト分析が 最もテストが理解しやすい工程である と言えます。 『テスト分析』は、テストと品質を繋ぐ中継地点である テスト分析でトレーサビリティを確立する テスト分析は、テスト計画で定めたテスト目的を達成するためにテストベースを分析して「何をテストするか？」を決める工程です。この「何をテストするか？」はテスト設計の「どうやってテストするか？」を考える基盤になります。 このようにテスト分析は、テスト計画とテスト設計の工程を関連づける役割をもっています。この関連付けされた状態を作ることを「トレーサビリティ（追跡可能性）を確立する」と言い、テスト分析ではテストの目的と様々なテストベースや後続の工程を関連付けてトレーサビリティを確立します。 トレーサビリティが確立されていない場合のリスク もしも、テスト分析の時点でトレーサビリティが確立されていないと、以下のような状況に陥るリスクが高まります。 テストがどのくらい仕様をカバーしているのかがわからない 仕様変更が発生した時にプロダクトやプロジェクトにどれだけ影響があるかわからない テストの実行結果でテスト目的を達成したかを計測できずリリース判断ができない 適切にトレーサビリティが確立され、各工程や情報間の結びつきが強固なほど、正確なテストのモニタリングとコントロール、そして品質の管理が可能となります。 このようにテスト目的とテスト条件や、テスト計画と後続のテスト工程などを連動させるトレーサビリティの中核となる役割を持つことから、テスト分析は テストと品質を繋ぐ中継地点である と言えます。 さいごに テスト分析が重要な理由のおさらい テスト分析が重要だと考える理由についておさらいします。 理由１：『テスト分析』は、テストの土台をつくる作業である テストベースを分析してテスト条件を決め、後続の工程の基礎を固める役割 理由２：『テスト分析』は、最もテストを理解しやすい工程である テストをシンプルに整理したドキュメントを作り、コミュニケーションを補助したり、仕様変更に柔軟に対応できるようにする役割 理由３：『テスト分析』は、テストと品質を繋ぐ中継地点である テスト全体のトレーサビリティの中核となってテストと品質を結びつける役割 以上の3つの理由から、テスト分析はテスト活動全体においても重要な役割を担っており、適切な工数をかけて実施することはプロダクトにとって十分なリターンのある工程だと考えます。 現状と今からできる対応 しかしながら、様々な要因でテスト分析を含めテストプロセスを導入できない場合もあると思います。特に、QCD（Quality/品質、Cost/予算、Delivery/納期）の Cost/予算 や Delivery/納期 に制約がある場合は、テスト分析の優先度を低く設定してしまう状況も多々あるのではないでしょうか。 そういった制約のある場合でも、テストエンジニアとして品質を担保していく上では、テスト分析をテスト活動に組み込んで適切に実施したいところです。理想を言えば、 テスト分析の重要性について決定権を持つステークホルダの理解を得て工数を確保する ことですが、すぐに実現するのは難しいでしょう。今からできる対応としては、テスト分析を行う範囲や作業を絞って工数内でやりくりする方法が考えられます。 一例 重要度の高い機能や複雑な機能にポイントを絞って実施する トレーサビリティの確立に絞ってドキュメントを作成する このように制約があっても、工夫次第でテスト分析をテスト活動に取り入れることはできますので、少しでもテスト分析をテスト活動に組み込んでみてください。 テストプロセスの各工程はどれも重要な役割を持っています。その中でもテスト分析は、テストの土台を作り、コミュニケーションや情報共有を助け、テスト全体と品質を繋ぐ重要なポジションを担っています。テスト分析の重要性を正しく理解して、効果的で建設的なテスト活動を推進していきましょう。 The post テスト分析の重要性～テストを支える縁の下の力持ち～ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第8回目のテーマは、「スクラムイベントの実践方法」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 スプリントプランニングを実践する スプリントプランニングは、スプリントの最初に行うため、起点となるMTGです。スプリントプランニングはその名の通り、スプリントの計画を立てるイベントです。スプリント計画とも呼ばれたりします。 このMTGの目的は、プロダクトバックログからスプリントバックログを選択し、決定することです。スプリントバックログには、スプリントゴールが含まれます。スプリントバックログとスプリントゴールが決定すれば、このスプリントにどういう価値があるか？なにができるのか？が明確になります。 スプリントプランニングの手順を解説します。 スプリントプランニングの成果物は、スプリントゴールとスプリントバックログなので、この2つが満たされるのであれば、どんな方法でも良いと思います。ただ、多くの人がやっている方法は、何かと参考になるので、まずは世の中のやりかたから学んでみましょう。 スプリントゴールを決める スプリントバックログを選ぶ。POは選んだスプリントバックログの説明を行い、開発者と質疑応答する 明確になったスプリントバックログの見積もりを行い、スコープ（やる量）を決める 必要であればスプリントバックログをタスクに分割する スクラムガイドにはイベントに書ける時間が目安として書かれています。1週間スプリントだと2時間。2週間スプリントだと4時間。1ヶ月スプリントだと8時間ぐらいが目安になります。しかし、周囲を見てみると、1週間スプリントで30分ぐらい。2週間スプリントで1時間ぐらいが多いです（1ヶ月スプリントはあまり見かけない）。 この時間については、やりかたによってかわってきます。たとえば、スプリント中にちょっとずつ準備を進める場合は、短い期間でできるとおもいます。MTG内ですべてを決定するなら、それ相応の時間をかける必要があります。 デイリースクラムを実践する デイリースクラムは、スクラムチームのための15分のイベントです。15分と限定するように、短い期間で情報を共有していきます。デイリースクラムは、毎日、同じ場所、同じ時間に開催するコミュニケーションの場でもあります。スクラムチームが集うMTGなので、積極的なコミュニケーションをとっていきましょう。スクラムマスターであれば、コミュニケーションをチームに促していきます。 開発者は、スプリントゴールの進捗を中心に1日分の作業計画を立てます。これをスプリントの最後まで繰り返します。スクラムにおける計画は、スプリント開始時の計画づくりで1回します。朝礼で再計画を行うことで、スプリントが1週間5営業日だとすると5回、合計6回計画づくりができます。このように小刻みに適応していくことで変化に強い開発を実現します。 もちろん、計画の調整が必要になった場合は、次のデイリースクラムまで相談を待つのではなく、デイリースクラム外でも積極的に調整していくべきです。 デイリースクラムでは、計画づくりだけでなく、問題や課題があれば解決策を議論し、迅速な意思決定を促進します。スクラムマスターにとって、デイリースクラムにおいて、「問題ありません」からが勝負になります。本当に問題ないのか、不安はないのか、チームに問いかけながら、発言を促していきます。 デイリースクラムの一般的な手順を解説します。チームのひとりひとりが、3つの質問に答えていくのが一般的です。 昨日やったことは何か？ 今日やることは何か？ 課題や不安がないか？ 昨日やったことから昨日立てた計画の確認を行います。うまくいったのか、うまくいかなかったのか、うまく行かなかった場合はどうするのか？を個人だけでなくチームで考えます。今日やることは、今日の計画づくりです。朝礼で自分の計画をうまく話せないのであれば、きちんと準備して朝礼に来るように促していきます。 課題や不安の解決に時間がかかりそうであれば、別で時間をとって議論します。あくまで短い時間で朝礼を終わらせるのが重要です。 スプリントレビューを実践する スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することです。デモMTGや成果発表会と呼ばれたりもします。スプリントレビューの大切な目的は、よいフィードバックを得ることです。 レビューを確実に行うために、主要なステークホルダーが集まる必要があります。見て欲しい人がいない状況でレビューをしてもこのイベントの効果が薄れてしまいます。 レビューをする時間は決まっていても、スプリントレビュー時にまとめてみせるのではなく、できたものをどんどん見せていってもいいでしょう。もしそれですむのであれば、スプリントレビューで確認をやめて、デモを見ながら次のアイデア出しに時間を使うのも手です。 スクラムガイドには目安の時間が書かれています。1週間スプリントで1時間、2週間スプリントで2時間、1ヶ月スプリントで4時間になります。筆者の周囲では、1週間スプリントで30分、2週間スプリントで1時間ぐらいが多いです。 スプリントレビューの手順を解説します。 成果の発表方法は、スクラムチームによって異なりますが、一般的には、開発者が開発したものをプレゼンテーションします。そして、開発者とレビュアーで質疑応答を行い、レビューOKかどうかを判断します。 プレゼンテーションがメインですが、質疑応答セッションも大切です。レビュアーによるFフィードバックを元に、新しいアイデアを考えたり、次の計画に盛り込んでいくことが重要です。 生まれたフィードバックは、対応するならバックログに追加します。やらないならやらないと意思決定します。いつ対応するかはスプリントプランニング等で決めていきます。 スプリントレトロスペクティブを実践する スプリントレトロスペクティブは、レトロと略される場合もありますが、それだけだと意味がよくわからなくなりますし、レトロスペクティブという言葉自体があまり馴染みのない英単語なので、筆者はわかりやすい「ふりかえり」という言葉を使うようにしています。 スプリントレビューは、成果物の改善のための検査でした。ふりかえりは、プロセスやツール、開発全体の改善のための検査と言えます。 ふりかえりででてきた問題の対策や改善方法は、スプリントレビューと同じくバックログに追加できます。 目安の時間は、1週間スプリントで1時間、2週間スプリントで1.5時間、1ヶ月スプリントで3時間とスクラムガイドにあります。筆者の周辺だと、1週間スプリントで30分、2週間スプリントで1時間ぐらいが多いです。 ふりかえりにはいろんな手法があるのでここでは一例としてKPTを紹介します。 ふりかえりの方法のひとつ「KPT」 まず、KPTをはじめるまえに、はなしやすいようにKPTボードを作ります。このスライドの右図のように、Keep（よかったこと）、Problem（いまいちなこと）、Try（チャレンジ）と区分けして、チームでふせんをはりながらすすめます。 ボードは、ホワイトボードを使ってもいいですし、オンラインのお絵かきツールを使ってもいいと思います。使いやすく、やりやすい方法を選んでください。筆者の場合、リアルタイムで話すときはホワイトボードを使い、オンラインだと Miro や FigJam というサービスを使うケースが多いです。 時間を区切ってまずKeepを集め共有します。次にProblemを集めます。たくさんでてきたときは、優先順位を決めて優先順位が高いものから話します。ふりかえりの時間は限られているので、限られた時間内で最大の成果が生まれるように考えます。 問題の確認をして、対策を考えられたならTryに貼り付けます。誰がいつまでにやるかを決めて、ふりかえりを終わります。アクションは忘れないようにバックログに追加してもいいと思います。 次のふりかえりでは、前にきめたTryの確認から始めます。そしてまたKeep、Problem、Try、Tryの確認、またKeepに・・・というサイクルをまわして改善を進めていきます。 スクラムの成果物 スクラムイベントを通して成果物を出していく必要があります。スクラムの成果物は、プロダクトバックログ、スプリントバックログ、インクリメントの3つです。 ひとつめの成果物は、POの説明でも出てきたプロダクトバックログです。プロダクトレベルのやることリストです。プロダクトバックログは、どんどん磨きこんでよいものに仕上げていく必要があります。この磨き込みをリファインメントと呼び、バックログリファインメントというイベントを追加で行うチームも多いです。 スプリントバックログは、スプリントプランニングで作られます。スプリントバックログは、成果物であるインクリメントを届けるための、具体的な計画と言えます。長期的なプロダクトバックログと、短期的なスプリントバックログは、解像度が異なります。 プロダクトバックログにプロダクトゴールがあるように、スプリントバックログにはスプリントゴールがあります。 最後の成果物はインクリメントです。インクリメントは、プロダクトゴールに向けた具体的な階段になります。インクリメントはスプリントレビューで検査されます。インクリメントは完成の定義を満たさなければなりません。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 The post 第8回 スクラムイベントの実践方法 first appeared on Sqripts .

ペネトレーションテストとは？ ペネトレーションテスト （侵入テスト）とは、情報システムのセキュリティ対策を評価するために行われるテストの一つです。 実際に攻撃者となって脆弱性を利用しシステムに侵入することで、潜在的なリスクを具体的に把握 します。これによりセキュリティレベルの客観的な評価や改善につながります。 ペネトレーションテストの目的 ペネトレーションテストの主な目的は、セキュリティ対策の妥当性や実際の攻撃を模擬することで、理論上では考えにくいセキュリティリスクを特定します。 主な実施目的は下記の通りです。 リアルな攻撃シナリオでの評価 システムの評価を実際の攻撃シナリオに基づいて行うことが、ペネトレーションテストの一つの大きな目的です。実際の攻撃者がどのようにシステムを突破しようとするのか、その視点からセキュリティの有効性を検証します。これにより、実際のセキュリティ事情を反映した具体的な改善策を立案できます。 複数の脆弱性を組み合わせた攻撃の評価 一つの脆弱性だけでなく、複数の点を組み合わせて攻撃される可能性もあります。ペネトレーションテストでは、個々の脆弱性を単体で評価するだけでなく、それらを一組にして攻撃された場合のリスク評価も行います。 システム管理者の反応評価 システムに不正侵入しようとする活動を検知して、システム管理者が該当する活動に適切に対応できるかどうかを評価するためにも、ペネトレーションテストは必要です。これにより、組織全体のインシデント対応能力を向上させることができます。 法的・規制上の要求への対応 特定の業界や地域では、サイバーセキュリティ法やグローバルな規制に従うために、ペネトレーションテストが求められる場合があります。それらの要求に準拠するためにも、ペネトレーションテストの実施は不可欠です。 以上のように、ペネトレーションテストの目的は広範で包括的であり、その中核には、システムと組織全体のセキュリティポスチャを強化するという役割があります。 ペネトレーションテストの必要性 情報システムの脆弱性は、システムの設計・開発・運用の各ステージで生まれる可能性があります。この脆弱性が悪意ある第三者に利用されると、重要な情報が盗まれたり、システムがダウンしたりすることにつながります。ペネトレーションテストにより、これらのリスクを把握することができます。 いかなるセキュリティシステムでも、理論的なテストやモデリングだけでは十分な評価はできません。 ペネトレーションテストでは、実際の攻撃シナリオに沿った試験を行うことで、セキュリティの懸念点が具体的に可視化され、セキュリティ対策の優先順位が明確になります 。 また、システム管理者やデベロッパーが予測しきれない視点からの攻撃も含めて、システムへの攻撃耐性を評価できます。たとえば、設計段階で想定していなかった使われ方をするユーザーや、システム全体としては見えにくい特定部分への攻撃など、様々な角度からの評価が可能になります。 一方で、企業のITスタッフやエンドユーザーが、どのようにしてシステムが攻撃される可能性があるのかを理解する機会ともなります。これにより、意識向上を目指した取り組みとして、教育やトレーニングの一部として取り入れることができます。 多くの場合、特定の規模や業種の企業は、定期的なセキュリティ評価を行うことが法律により義務付けられています。また、ペネトレーションテストは顧客の個人情報やビジネスの秘密を保護するための信用度の一部としても見なされます。 以上のように、ペネトレーションテストは攻撃をされた場合のリスク、攻撃者の視点の理解、スタッフの意識向上、法令遵守と信用維持を目指して行うのが理想的です。 脆弱性診断との違い 脆弱性診断は、システムやアプリケーションが持っている可能性のある脆弱性を発見するための評価です。主にエンジニアによる手動のテストや自動化されたツールを使用した脆弱性をスキャンによって、脆弱性がシステムに存在するかどうかを調査します。 一方、ペネトレーションテストは、見つけた脆弱性を実際に利用してみることで、その影響を評価します。つまり、実際に攻撃を模擬してシステムに侵入を試み、どの程度のダメージを与え得るかを評価します。 そのため、脆弱性診断とペネトレーションテストは、目的も手法も異なります。前者はシステムやアプリケーションの脆弱性を発見することに重きを置く一方で、後者はそれらの脆弱性が実際に悪用された場合の影響を評価します。 以上のように、脆弱性診断とペネトレーションテストは、セキュリティ評価の異なる側面を補完するもので、どちらも有効なセキュリティ対策の一部として扱われます。これらを組み合わせることで、システムの脆弱性を発見し、それが実際に攻撃者に利用された場合のリスクを評価することが可能になります。 ペネトレーションテストの進め方 一般的なペネトレーションテストの進め方は下記の通りです。 1. プロジェクトの範囲定義（Scoping） まず初めに、テストの目的、スコープ、時間割、テスト対象、そしてどのような方法を用いて攻撃を模倣するかなどを定義します。ここで取り決められる内容は、組織のセキュリティポリシーや要件、そして予算によって異なる場合があります。 目的 何を達成するためにテストするかを明確にします。 スコープ テストの対象となるシステム、ネットワーク、またはアプリケーションを定義します。 時間割 テストの種類やスコープに応じて、テストの期間を設定します。 テスト対象 検証したい特定の脆弱性や関心項目を明示します。 攻撃方法 使用するツールや手法、そしてどの程度まで侵入を試みるかなどを定義します。 2. 情報収集（Reconnaissance） 次に、テストの対象について情報を収集します。これには公開情報（例えば、WHOISデータやDNSレコード）や非公開情報（システム設定やネットワーク構造等）の両方が含まれます。 3. 脆弱性探索（Vulnerability Assessment） 収集した情報を基に、システムやアプリケーションの脆弱性を探索します。これには自動化ツールや手動テクニックの両方を使用します。 4. 侵入試験（Exploitation） 次に、発見した脆弱性を利用して実際にシステムへの侵入を試みます。これがペネトレーションテストの主要な部分であり、システムがどの程度まで攻撃耐性があるのかを評価します。 5. 脆弱性利用（Post-Exploitation） 侵入成功後は、どの程度の被害が想定されるかを評価します。例えば、機密情報へのアクセスや、追加的なシステム控えへの侵入などが考えられます。 6. 報告（Reporting） 最後に、テストの結果を詳細に報告します。これには、見つかった脆弱性、それらがどの程度重要か、そしてそれらを修正するための推奨料が含まれます。 ペネトレーションテストサービスの活用と選定ポイント ペネトレーションテストは専門的な知識と技術を必要とし、しかも定期的に行うべきであるため、手間と時間がかかります。そのため、専門のサービスを活用することが推奨されています。 ペネトレーションテストサービスを選定する際のポイントとしては、まず、サービス提供者が持つ専門的な知識と経験を確認してください。さらに、提供されるレポートの質や、テスト後のサポートも重要な要素です。テスト結果を基にした改善策の指導や再テストなどを含む継続的なサポートがあれば、セキュリティ対策の品質を高められます。 ペネトレーションテストサービスの活用 ペネトレーションテストサービスは有効なセキュリティ対策の一つであり、専門的な知識と技術が必要なため、企業にとっては外部のプロフェッショナルサービスに委託することが一般的です。以下にその主な理由を示します。 専門的なスキル ペネトレーションテスターは、最新の脅威と攻撃技術を理解し、それらに対抗するための専門的な技術と知識を持っています。 客観性 外部のサービス提供者は、内部のエンジニアや開発者が見落とす可能性のある問題を特定できます。 時間とコストの節約 サービスを利用することで、企業は自身のリソースを他の重要なタスクに集中することができます。 ペネトレーションテストサービスの選定ポイント ペネトレーションテストサービスを選定する際には、次の要素に注意を払うと良いです。 能力と経験 提供者はどの程度テストの経験があり、どのような方法でテストを実施するか？ 報告 テストの結果はどのように報告され、それは明確で理解しやすいか？ どのような改善策が提案されるか？ サービス後のサポート テスト終了後にもサポートを提供してくれるか？ 具体的には、レポートの解説や必要に応じてフォローアップのサポートがあるか？ コスト サービスのコストは理解しやすく、それが予算内に収まるか？ ビジネスの成長やニーズの変化に応じてスケーリングするオプションがあるか？ 以上の要素を踏まえて、ペネトレーションテストサービスを選定すると良いでしょう。また、選定したサービスが企業のセキュリティ目標と合致していることを確認します。 参考： 脅威/シナリオベース・ペネトレーションテスト（株式会社AGEST） まとめ ペネトレーションテストは、情報システムのセキュリティ対策を検証するための重要なテストです。脆弱性診断がシステムの弱点を示すのに対し、ペネトレーションテストは実際の攻撃の視点から、現実の脅威に対する耐性を試すものです。このようなテストを定期的に行うことで、システムのセキュリティレベルを維持し、改善することができます。それが手間や時間がかかる作業であっても、ペネトレーションテストサービスを活用することで、一歩進んだセキュリティ対策を行うことが可能です。 The post ペネトレーションテストとは？脆弱性診断との違いや手法について first appeared on Sqripts .

はじめに 前回 は、BDDとATDDとSbEの違いについて説明しました。 今回は、BDDで勘違いされやすい部分について説明していきます。 BDDはツールの1つではない 「BDDとは何か？」と聞くと、「振る舞いを用いてテストを自動化するもの」「Given/When/Thenを使って書かれた自動テストのコード」と答えられることが多いです。 しかし、これは誤解です。 Seb Roseは自身の書籍『 The BDD Books – Discovery （邦訳： The BDD Books – Discovery Japanese Edition ）』の中で、以下のように述べています。 私はビジネスチームが参加しない形の「BDD」を実施しているチームをたくさん見てきました。（中略）個人としては基本的にはそれらは BDD にまったく従っていないと考えています。彼らはせいぜい、（中略）高価なテスト自動化プラットフォームとして使用しているだけです。 結果として得られるのは、たいていは遅くてメンテナンスが難しく、組織にごく限られた価値しかもたらさない自動テストスイートです。 BDD は協調に関するものです。 BDDツールを使用したり、Given/When/Thenを使用してテストを自動化しても、開発アプローチは少しも BDD にはなりません。 The BDD Books – Discovery BDDは会話を重視します。特に、ビジネス関係者（非開発チーム）との会話を重視し、共有言語(Shared Languege)の構築を大切にしています。そのため、同書籍では「business」という単語が非常に多く出てきます。 プロセスに組み込まれたBDD 書籍『 The BDD Books – Discovery （邦訳： The BDD Books – Discovery Japanese Edition ）』の中では、プロセスとしてのBDDについても説明しています。今回はその一部を軽く紹介します。 BDDのプラクティスの概要 この書籍では、BDDのプラクティスを以下の3つのフェーズに分けています。 BDDでよく勘違いされるのは、この3つのうち「自動化(Automation)」のみに注目してしまうことです。 そうではなく、 協調作業が行われる「発見(Discovery)」が最も大切です。 同書籍では、この順序でプラクティスを採用することが大事であり、「発見(Discovery)」のプラクティスを採用するだけでも大きな効果を得られると語っています。 逆に、「自動化(Automation)」のみを採用してもBDDで期待しているメリットを得られません。 BDDを用いたプロセス 上ではBDDのプラクティスの概要を示しましたが、実際にBDDを用いたプロセスはどのようになるのでしょうか。その中身について描いた図は以下の通りです。 先ほど紹介したBDDのプラクティスと対応づけると以下のようになります。 ・発見(Discovery)…#2 要件ワークショップ ・定式化(Formulation)…#3 定式化 ・自動化(Automation)…#5 自動化 知らないことを分かっていない分野(unknown unknowns)への挑戦 2002年にラムズフェルド国防長官（当時）が会見時に発した言葉 を元にした「ラムズフェルド行列(Rumsfeld matrix)」というものがあります。 BDD、特に「発見(Discovery)」のフェーズでは、ラムズフェルド行列の右下の部分「Unknown unknowns（知らないことを分かっていない）」状態のものを見つけ出し、右上の部分「Known unknowns（知らないことを分かっている）」状態にシフトさせる活動を目指します。 次回予告 今回はBDDに対して「振る舞いを用いてテストを自動化するもの」「Given/When/Thenを使って書かれた自動テストのコード」という考えが誤解であると言うこと、BDDのプラクティスを3つに分けて考えられていることを紹介しました。 次回以降は、それぞれのプラクティスで行う内容を具体例を用いつつ説明していきます。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE The post TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第3弾です。 今回はくまねこからまーくーへ、探索的テストでより良い結果を出していくためのあれこれを会話形式でお話しさせていただきます。 最後まで楽しんで読んでいただければ幸いです！ 第1回 ゆるっと♪ファームウェアテストよもやま話 第2回 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 JSTQB ALTM試験のことを考えるふりをしながら歩いていたところ、くまねこに声をかけられる。 くまねこ QA業界経験1x年のエンジニア。 前回の記事 を投稿後、JSTQB FLに無事合格。 弱い陽ざしの窓辺から外を眺めていたところ、通りかかったまーくーに話しかける。 イラストby くまねこ 今回はいつもと逆の展開…!? それでは、二人のやりとりをお楽しみください。 探索的テストについて、改めて考えてみる あっ、まーくーさん、お疲れ様です。JSTQB ALTMの勉強中ですね。(ニヤニヤ) そうね・・・そろそろ具体的に試験に向けて勉強しなくちゃだから！（話を合わせておこう♪）。で、どうしたんだい？（ニヤニヤしてる…何かあるな？） 前の記事を投稿した 後、探索的テストのことをあれこれ考えていまして…。まーくーさん、ちょっと意見を聞かせてもらえませんか？ もちろん良いよ！早速本題に入っていきたいところだけど、私もくまねこさんも探索的テストは経験してるけど、簡単に認識を合わせておこう。 探索的テストとは？ 探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。 テスト技術者資格制度 Foundation Levelシラバス Version 2018V3.1.J03 要するに経験ベースのテスト技法で、テスト対象を動作させながらテスト設計/実行/結果の確認まで行うものだったね。詳細は以下の記事に記載があるから、お互いこちらを理解している前提で話を進めていこう！！ 探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説 はい！ 探索的テストの取り組み例の紹介 じゃあ、どんな感じで進めようか？ そうですね。今まで第三者検証として僕が行った探索的テストの進め方・考え方をお伝えして、まーくーさんが気がついた点をコメントする形が良いです。 OK。探索的テストのプロジェクト開始から流れに沿って話していこう。 プロジェクト開始からですね。まず実際の製品を動作させながら、製品全体の理解・お客様と探索的テストのゴールを認識合わせをするための活動を行います。プロジェクトによって仕様書などのドキュメント有無・量が異なるため、お客様の製品紹介ページやマニュアルなども参考にして、機能や画面単位で分類していきます。この分類は、お客様とテスト内容を共有する際や、テストチームにとってもテスト対象の全体像を俯瞰するのに役立ちます。 ふむふむ。まずはテスト対象を俯瞰できるようにするってことね。 洗い出した機能や画面に対して、プロジェクトの状況・目的と、前述の作業結果(製品を動作させた感触/分類結果など)から、実施優先度をつけていきます。優先度については、テストを行う観点数や工数で重み付けをしていきます。ここでお客様のご要望も反映して、観点のカスタマイズや優先度の調整を行います。 テストチャーターを使った探索的テストをする場合には、テストチャーターも作成します。探索的テストはスクリプトテストのように手順などを詳細に記載したドキュメントは残さないことが多いですが、チャーターを作成すると、お客様にもテスト担当者にもテスト範囲の全体像・テストの実施状況を見える化できて便利です！ テストチャーターとは？ テストチャーターはテストの目的や観点を記載します。作成したテストチャーターをテスト担当者間で共有して、テストを実施することで経験のバラツキを軽減することができます。 探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説 プロジェクトや探索的テストの期間によって明確なフェーズとして表現しないこともありますが、本記事では「テスト計画（準備）」という表現で進めます。 ここまでが事前準備だね。特に気を付けていたことってあるかい？ プロジェクトの目的にもよりますが、最初からテスト範囲を絞り込み過ぎないこと、ですね。まずは全体的に触ってみることで、予測と実際の動作があっているかの感触を得る期間を作ります。その結果から、不具合が潜んでいそうな機能を絞り込んでいくようにする事で、いきなりある一部分だけ深く掘り下げてしまい、他の不具合が潜んでいる部分に時間をあてられなくなるということが無くなると思います。 全体の感触を得たのち機能を絞り込み、効率的に探索できるよう計画することで、より良い成果を出すことに繋げられると思っています。 技法としてセッションベースドテストを取り入れて、機能や画面単位で時間を区切ってテストを行うようにして、全体的なテストと掘り下げたテスト、状況によってどちらにも時間が割けるように心がけています。また、”時間”という単位であれば、お客様も作業ボリューム感を実感しやすいと思います。 なるほど。不具合が出そうなところをテストできないってのは探索的テストではいちばん避けたいことだよね。時間で作業ボリューム感を共有するってのも分かりやすいと思うよ。 あと、すぐに探索的テストに入れる環境が整っているのか？対象システムにテスト可能なデータがあるのか？などの確認もこのフェーズに含まれるね！ じゃ次はテスト開始！テスト中はどんなことを心がけているのかな？ 実際にテストを行ってみると、不具合の検出状況やテストのための工数が想定と異なる場合があります。そのため、計画通り全体的な確認が終了したところで中間報告の場を設けて、後半の進め方を検討していきます。例としては以下のようなケースですね。 ・ これまでに検出した不具合の発生状況から、該当機能のテストをより掘り下げていくか ・ 類似の機能/画面で問題が起きないか、対象範囲を広げてテストを行うか 探索的テスト期間中でも、テスト内容を柔軟に調整して、テストの効果を最大化できるようにしています。 適宜、テストの状況をお客様と共有しながら進めているんだね。掘り下げるか？広げるか？それが問題だ！(笑)探索的テスターの腕の見せ所だね！ 他にもテスト実施のときに気を付けていることっていったら何かあるかい？ 対象製品の目的やユーザーの利用シーンを想像しながらテストを行うこと、ですね。 「ユーザーはこの機能を使ってこういうこともやりたいのではないか」と考えたり、「どういう状態になるとユーザーが困ってしまうか」など、エラーを推測しながらテスト実施しています。 ふむふむ、ユーザー目線でのエラー確認は特に大事だよねぇ。探索的テストはイマジネーションが命！で、テスト報告はどのようにしているのかしら？ チャーターから概算実施ケース数やテスト工数を集計したり、検出した不具合のまとめ（件数や重大度の高かった不具合）をご報告する形です。これらのテスト結果を元に、プロジェクトの目的に対して探索的テストの成果をお話ししていきます。また、お客様の課題に対する情報提供や、今後の品質向上に向けたアイデアをご報告します。 ありがとう。探索的テストの一連の流れはこんな感じかな？ そうですね。まとめるとこんな感じです。 きれいにまとめたねぇ！何を気にして作業を進めたのかが分かりやすい！！！ Yeah! \ / まとめ -より良い結果のために必要な事とは？- この作業の中で、まーくーさんだったら、どのようなところを工夫しますか？ この中で言ったら、テスト計画(準備)の所だね。お客様のプロジェクト内で探索的テストの立ち位置(取り扱い)や、テスト結果をどんな情報として求めているかをしっかりヒアリングするかな。 つまりお客様が「探索的テスト」に「何を」求めているか？目的とゴールをしっかり把握するところが大事 だと考えているよ。 ふむふむ。 とにかく不具合を見つけて欲しいのか、不具合が無いことをスクリプトテストの補完的に確認するのか、時間的な制約で準備の期間が取れないから、探索的テストでもある程度網羅的に見て欲しいとか・・・その目的とゴールをはっきりさせることで、その後の動きも変わってくるよね。 ふむふむふむふむ。 また言葉の定義もお客様と認識合わせしておくことも必要だよね。例えば、”ケース数”という言葉を使ってやり取りをする場合、同じ”1ケース”と言ってもスクリプトテストとは粒度が異なったりするし。もっともこれは、機能テストとユースケーステストとかでも同じだけど ふむふむふむふむふむふむ。 （あ、ふざけ始めた・・・飽きてきたのか？？？気を取り直して）こういった探索的テストの定義をお客様としっかり認識を合わせた上で、必要であればスクリプトテストとの比較や一般的な指標(テスト密度/バグ密度etc）との比較、お客様内の指標があれば、その指標との比較なども使いながら、お互いに理解しやすい形でテスト結果をアウトプットできるようすると良いと考えているよ。 ふむふm…あっ！ありがとうございます！なるほど…ここまでの話だと、『探索的テストの内容』についてフォーカスが当たっていましたが、『目的に対する最終的な成果（何がアウトプットされるか、そこで何がわかるか）』を最初にしっかりと共有しておくことで、より良い成果を出していけるようになりますね！ そうだね、コメントした内容は探索的テストだけに限らない部分もあるけれど、上記を考慮しつつ探索的テストのメリットである、『少ない工数でのテスト』や『スピード感を持ったテスト』という特性を活かしながら進めていけると良いね！これからも心のアクセルふかしていこう！ Yeeeeeeeeeeaaaaaaaaaah! \ / 次回予告 今回はここまでにして、JSTQB ALの学習に戻ろうかな！（ ）次回の記事はどんな感じにしようか？ 次回のまーくー＆くまねこは、 ・まーくー、JSTQB ALTM試験、いったいいつ受けるの？まだでしょ！（仮） ・くまねこ、JSTQB FL試験を振り返る！（仮） の2本でーす。 最後まで読んでいただき、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー ﾉｼ ﾉｼ ゆるっと♪シリーズ 第1回 ゆるっと♪ファームウェアテストよもやま話 第2回 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3回 ゆるっと♪どうやってる？探索的テストの世界！ The post ゆるっと♪どうやってる？探索的テストの世界！ first appeared on Sqripts .

前回の記事 では、組織の中でテスト自動化を普及するためには個人やチームが頑張るだけではなく、組織でどう取り組むかについて考える必要があるというお話をしました。 たとえばマネジメント層の理解や適切なリソース配分などが大事、という内容でしたが、組織で普及していくために欠かせない要素は他にもあります。 それは、テスト自動化に関わる個々のエンジニアがテスト自動化について知識とスキルを身につけること、です。 テスト自動化に限らず、組織の後押しだけでは物事は進みません。現場で業務をおこなうひとりひとりが技術や考え方を身につける必要がありますよね。 今回は前回の記事とは視点を変えて、実際にテスト自動化をおこなう個人に焦点を当て、テスト自動化スキルを身につける方法について解説します。 なお、本記事中の「テスト自動化」は前回までと同様、E2Eテストなどテスト対象のUI、とくに画面を操作しておこなうようなテストのことをターゲットとします。 テスト自動化をおこなうために身につけるべきもの システムテストの自動化をおこなうにはさまざまなスキルが必要ですし、同時にすでに知られているベストプラクティスやアンチパターンなどの考え方を把握しておくことも大切です。 これらをひとつずつ挙げていくとキリがないですし、何においても「学ぶべきこと」は無限にあります。 ここでは 技術面 知識面 の2つの側面から主な例を説明し、次の項目でその学び方についてご紹介します。 技術面 技術面、テクニカルなスキルとして身につけておきたい点は大きく2つです。 ①プログラミングのスキル ひとつは、プログラミングのスキルです。 SeleniumやPlaywright、SikuliXなどのライブラリを用いる場合はプログラミング言語でテストを書く必要があるため、当然プログラミングスキルは必要になります。 しかし、最近ではノーコード・ローコードのテスト自動化ツールも普及しています。プログラミングのスキルがなくてもテスト自動化にトライできる環境が整ってきているといえるでしょう。 ここで注意が必要なのは、テストを自動化できることと、自動化したテストをうまく使い続けられることとは別である、という点です。たとえノーコード・ローコードのツールであっても、行いたいテストに応じた詳細な設定などをおこなう機会はあり、「結局JavaScriptを書く必要が出てきた」というシチュエーションもよくあります。 また、テスト手順の一部を共通化したり、同じ手順でもより効率的な操作の仕方を考えたりと、一般的なプログラミングで求められるスキルが転用できる部分は多々あります。 プログラミングのスキルがなくてもテストは自動化できるけれども、うまくやる、継続するためにはあったほうがいい、と考えておきましょう。 ②テスト対象を構成する技術要素のスキル もうひとつは、テスト対象を構成する技術要素に関するスキルです。 極端なことを言えば、「テスト対象を自分でも作れるくらいになりましょう」です。ただ、これからテストを自動化を学ぼうと思っている方にとってはハードルが高いですよね。こんなことを書いているわたし自身も、いまテストしているWebサービスと同じものを作れ！と言われたら、おそらくできないと思います。 QAエンジニア・テストエンジニアの方が開発者と同等のスキルを身につけることは大変です。ただ、ここで言いたいのは、基本的なところについては実際に手を動かして理解をしましょう、ということです。 たとえばWebサービスのテストを自動化したいのであれば、HTML・CSS・JavaScriptなど、使われている技術要素に関する基本的な理解が必要です。Windowsのアプリケーションを自動化するには、ウィンドウハンドルの考え方や、場合によってはWin32APIを知っておくことも必要かもしれません。 以上2点がベースにあれば、あとは個々のツールやライブラリの使い方を身につけることで、テスト自動化に関して「手を動かして進める」ことができるでしょう。 ただし、手を動かせるだけではテスト自動化ができるとは言えません。技術面のスキルと同時に、考え方についても学ぶ必要があります。 知識面 手を動かしてテストを自動化するだけでなく、どんなテストを自動化するかや、テスト自動化自体をどう進めていくかを考えることも必要です。 そのために必要な知識として、こちらも大きく2つが挙げられます。 ①ソフトウェアテストの知識 ひとつはソフトウェアテストに関する知識です。テストプロセスや、各テストレベルにおいてどんなテストをおこなうべきか、などを知っておく必要があります。 ソフトウェアテストについての知識がなくとも、技術面で挙げたスキルを持っていればテスト自動化はできます。しかし、『 テスト自動化の8原則 』にも 2. 手動でおこなって効果のないテストを自動化しても無駄である テスト自動化の8原則 とあるように、そもそもテストとして有効かどうかが重要なポイントです。 意味のあるテスト自動化をおこなうためには、その土台としてソフトウェアテストに関する知識が必須です。 ②テスト自動化の知識 もうひとつは、テスト自動化に関する知識、とくに一般に公開されている事例およびベストプラクティス・アンチパターンは押さえておくべきです。 テスト自動化も取り組む組織が増えてきたおかげで、「こうしたらうまくいった」「こうしたら失敗した」といった事例が多く公開されています。これからテスト自動化を学ぶ方にとっては、とてもありがたい状況です。 他社での成功事例をそのまま真似すればいい、というわけではありません。しかし、すくなくとも同じ失敗をしないように他社事例を把握しておくことは大切です。 学ぶための手段 ここまで、技術面と知識面それぞれ身につけておくべき代表的な事項について説明しました。 ここからは、実際にそれらの事項を身につけるにはどうしたらいいのかをご紹介します。 わたしが考える、テスト自動化に関する技術と知識を身につける最良の方法は「詳しい人に教わりながら実務でテスト自動化をおこなう」です。そうはいっても、そんな方法で身につけられる機会というのはそうそうない、とも思っています。 たとえば社内の研修がある、もしくは詳しい方に聞ける環境があれば、それらを最大限活用するところから始めましょう。 なかなかそうした機会が得られない、身の回りにはない、という場合は以下を参考に学び始めてみてください。 技術面の学習方法 身につけるべき内容、として先に挙げた プログラミングのスキル テスト対象を作るためのスキル については、書籍やWebサービスなどが多数あります。 プログラミングが未経験である、という場合は簡単な入門書から始めてみたり、最近ではWebブラウザ上でプログラミング学習ができるサービスを利用したりするのがオススメです。わたしが過去、テストエンジニア向けにプログラミングを教えていた際には、ブラウザ上で説明を読みながらコードが書けるタイプの学習サービスを用いていました。独力で書籍を頼りに学習するのに比べ、効果的に身についていた印象です。 プログラミングの感覚が掴めたら、ごく簡単なものでもよいので、動作するアプリケーションを作ってみましょう。 また、最近ではプログラミングや開発に関して学ぶためにChatGPTを使うのも有効です。プログラミング言語を指定して「こんなものを作りたいから、順序立てて説明してほしい」と書くと丁寧に教えてくれますし、エラーが出た場合に「こんなエラーが出たが、どう解決すればいいか」と聞くと答えてくれます。 あまりにもChatGPTに頼りすぎてしまうとスキルアップに繋がらないため、ある程度自分で考えたうえでどうしてもわからない場合に質問をするか、「直接答えを書かずにヒントを教えてほしい」と依頼すれば上手にサポートしてくれます。 テスト自動化に関する技術を学ぶ際は、プログラミングを学ぶのとは少し違ったアプローチになります。 わたしのオススメは、テスト会社や第三者検証会社、テスト自動化ツールを開発している会社がおこなっているハンズオンに参加することです。誰かに教わりながら実際に手を動かしてテスト自動化ができるという点で、よい機会になるでしょう。 一方ハンズオンだけでは実践レベルのスキルを身につけることが難しいので、学んだことを手元で、できれば業務でテストを自動化したい対象でおこなってみるのが理想です。 SeleniumやPlaywright、あるいはKatalonStudioなど無料で使えるツールやライブラリもあるので、これらを用いて実践してみることが一番です。 テスト自動化ツールは テスト自動化関連ツール・ライブラリまとめ – Qiita にまとめてありますので、ここから無料のものを探して使ってみてください。 他には、動画で学ぶという方法もあります。 たとえば Test Automation University | Applitools では、テスト自動化に関するさまざまなツールやライブラリの使い方など、実践的な動画が公開されています。すべて英語にはなってしまいますが、動画自体はYouTubeにアップされており、自動翻訳で字幕をつけることもできます。 知識面の学習方法 技術面の学習に比べると、テスト自動化の知識をたくさんインプットするほうが始めやすいかもしれません。 身につけるもの、として挙げた「ソフトウェアテストに関する知識」は、書籍や資料がたくさん存在します。 個別のテスト技法に習熟することも大事ですが、テスト自動化の前提知識として学ぶ場合にはテストプロセスやテストの全体像を把握することのほうが優先です。 テストプロセスなど、ソフトウェアテストに関して学ぶには ASTERセミナー標準テキスト ASTERオンラインセミナー – YouTube が無料でいますぐ見られる点でオススメです。こちらを読んで＆視聴して、必要に応じて書籍などを読むのがよいでしょう。 テスト自動化について学ぶには、『 テスト自動化の普及と推進【前編】～阻害要因と対策 』の最後でもご紹介した、以下の書籍やサイトが参考になります。 Test Automation Patterns Experiences of Test Automation: Case Studies of Software Test Automation システムテスト自動化 標準ガイド (CodeZine BOOKS) ただ、上記はいずれも英語だったりボリュームが多かったりと、最初に読むには大変かもしれません。 もっとも短くてポイントをおさえられるのは、本記事でもご紹介している『 テスト自動化の8原則 』です。こちらはテスト自動化研究会が公開しているもので、テスト自動化をおこなううえで意識すべき点が簡潔にまとまっています。 他にも、 玉川 紘子(たまがわ ひろこ) | Sqripts さんの連載も読んでおくとテスト自動化を実際に運用する面で大切なことを学べます。 学習の両輪を回そう 本記事では、技術面と知識面の2つの側面からテスト自動化について何をどう学ぶかを説明しました。 テスト自動化のコードやスクリプトだけが書けても継続的な自動化は難しいですし、一方で知識のみがあっても手を動かせなければ自動テストは実現できません。技術と知識はどちらも必要です。 手を動かすことと、ベストプラクティス・アンチパターンなどを知ることの両輪を回しながら学習と実践をしていきましょう。 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント テスト自動化の普及と推進【前編】～阻害要因と対策 テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ The post テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ first appeared on Sqripts .

▼ 参加応募フォームはこちら イベント概要 AIを”どう使うか？”に注目が集まっていますが、完璧ではないAIを” どうテストするか？ “についてはほとんど議論がされていません。 AIプロダクトのテストについて、AIテストの第一人者であるStuart Reid博士と西康晴先生をお招きして特別セミナーを開催します。 なお、当セミナーは オフラインのみでの開催 （於：帝国ホテル東京）です。 ※1 AIの話題に浸りながら、コーヒーブレイクも味わえる、オフラインならではの体験をお届けします。 AIテストについての新たな知識と、共に学ぶ仲間とのつながりを得る貴重な機会をお見逃しなく！ ※1　オンライン配信はありません Sqripts会員を特別ご招待！ 今回は当セミナーに Sqripts会員のみなさまを抽選でご招待 します。 ぜひご参加ください。 まだSqripts会員ではない方は、本イベントを機に会員登録（無料）をご検討ください。 ご登録いただくと、会員限定で公開している各領域のエキスパートによる特集記事もお読みいただけます。 ▼ 参加応募フォームはこちら Speakers ▼ 参加応募フォームはこちら 日時・場所 日時： 2023年9月26日（火曜日）18:30～20:30（Door Open 18:15） 場所： 帝国ホテル東京　本館3階 鶴の間 〒100-8558東京都千代田区内幸町1-1-1 交通アクセス： 帝国ホテル東京「アクセス」ページ ▼ 参加応募フォームはこちら タイムテーブル 18:30-18:35 開会挨拶 18:35-19:15 Reid博士 講演　※同時通訳サービスをご提供いたします 19:15-19:40 Coffee Break * Networking　　　　　　　　　　　　　　 19:40-20:10 西 康晴 氏 講演 「AIのAIによるAIのためのテスト」 20:10-20:30 高橋 寿一 講演 「AIテスト及びシフトライト戦略」 20:30 閉会 ▼ 参加応募フォームはこちら 募集要項 応募資格 2023年9月7日17時時点で参加応募フォームからのお申込みかつ、 Sqripts無料会員の登録が完了していること 応募方法 下記「セミナー参加応募フォーム」に入力の上ご応募ください。 Sqripts会員未登録の方は、応募フォーム入力後画面より無料会員登録をお願いします。 （Sqripts無料会員登録は こちら ） 応募期限 2023年 9月 7日　17時00分 定員 60名（応募多数の場合は抽選） 参加費 無料 当選発表 抽選結果は9月中旬にメールでご連絡します ご案内 当日参加される方は、お名刺を2枚ご持参ください セミナー参加応募フォーム MktoForms2.loadForm("//lp.agest.co.jp", "730-KXO-656", 1567); お問い合わせ先 当セミナーに関するお問い合わせ先 株式会社AGEST　マーケティング本部 TEL： 03-6735-2051 　※土日祝除く10～18時 Mail： ml-IS_group@agest.co.jp The post ◆ご招待◆9.26開催！Stuart Reid博士 特別セミナー｜知識ゼロから学ぶAIテスト first appeared on Sqripts .

こんにちは、クオリティマネージャーのこやまです。 QAメンバーやプロジェクトマネージャーの方で、お客様や上司から「不具合を分析して対策をまとめて」と言われたことはありませんか？ 不具合分析と言われるとなぜなぜ分析と信頼性成長曲線分析が思いつきます。信頼性成長曲線分析は不具合収束の傾向を把握できますが、不具合の原因特定までできません。一方、なぜなぜ分析では、不具合の詳細な調査に多くの時間と労力が必要です。 そこで、効率よく原因と傾向が分析できる「ODC分析」があると知り、調べた内容をご紹介します。 ODC分析とは 1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」です。ODC分析のODCは「Orthogonal Defect Classification」の略称で、直訳すると「直交　欠陥　分類」となります。「直交とは直線どうしが直角に交わること」との意味で、お互いに依存しない別軸から欠陥を分類して分析する手法だと理解しました。 お客様よりテスト工程の不具合分析についてご相談をいただいたため、ODC分析を使用してみようと思い「ソフトウェア不具合改善手法ODC分析　工程の『質』を可視化する」 ※1 を用いて更に知識を深めました。 この書籍には以下のように記載してあります。 『ODC分析は、成長曲線のような数量的状態の統計的分析とRCAのような局所的な原因分析とちょうど中間に位置づけられる。ODC分析は、個々の不具合の要因分析とその要因の数値的な分析という両面を持ち合わせている分析手法といえる』 不具合の測定・分析手法におけるODC分析手法の位置付づけ ソフトウェア不具合改善手法 ODC分析 RCA(Root Cause Analysis:根本原因分析) ODC分析の手順 ODC分析の手順ですが、大きくは３段階で分析する手順を簡単に説明します。 A.分析したいシステムの不具合を分類 B.定規や尺度、指標となる不具合の分類結果と比較 C.プロセス実施の改善策を提供 A.分析したいシステムの不具合を分類 分析する前に不具合に関する考え方を理解する必要があります。ODC分析では、不具合はお互いに依存しない4つの属性（タイプ、トリガー、ソース、インパクト）で構成され、これらの属性が相互作用を起こして引き起こされると考えられております。 各不具合に対して４つの属性それぞれの属性値を割り当てて分類します。因みに属性値は選択肢として予め定義しておきます。 属性の概要 ※1 属性 属性概要 例 タイプ属性 プロセスに関わる不具合を示唆する属性 値の設定、条件分岐、機能性など トリガー属性 不具合を表面化した動機 レビュー、結合テスト、総合テストなど ソース属性 不具合を含んでいたコードの箇所 新規、再利用、修正など インパクト属性 ユーザ、顧客への影響 使用性、性能、信頼性など 引用元 ※1 には属性の詳細や選択肢も掲載されています。 ソフトウェア不具合改善手法 ODC分析 Ｂ.定規や尺度、指標となる分類結果との比較 定規や尺度、指標となる分類結果は、「プロセス・シグネチャー」と言われており、「開発プロセスの期待」です。「開発プロセスの期待」とは『「正しくプロセスを実施すれば、正しく「しかるべき不具合」の分布になる」』（引用※１）というものです。 ODC分析では前記Aでの分類結果の内、「プロセス・シグネチャー」と異なる点に課題があると考えます。分析したいシステムの不具合を分類した結果と「プロセス・シグネチャー」をグラフ化すると視覚的に異なる点を確認できます。 なお、最初にODC分析を行う場合、定規や尺度、指標となる「プロセス・シグネチャー」を策定する必要がありますが、同じ開発プロセスで成功したプロジェクトの不具合内容を基にODC分析を行い「プロセス・シグネチャー」とするなどの方法が考えられます。 Ｃ.プロセス実施の改善策を提供 前記Bで比較した違いの原因を調べ、原因から示唆されるプロセス実施の「やり方」を考察し、「弱点」を見つけ出し、改善策を策定します。 例として、あるプロジェクトでのプロセス・シグネチャーと現状の不具合分類結果のグラフ、現状の評価、総合評価を以下に紹介します。 プロセスの期待（プロセス・シグネチャー）’（出典 ※1 P108）　 ソフトウェア不具合改善手法 ODC分析 プロジェクトの現状（出典 ※1 P108） ソフトウェア不具合改善手法 ODC分析 現状の評価 『設計・単体テスト工程でのFunction（機能性）の不具合が少なく、機能テスト（統合テスト）で、急増している。設計上はまだまだ機能性の不具合が残存しており、次工程で漏れ出る可能性が高い。』 ソフトウェア不具合改善手法 ODC分析 総合評価 『システムテストの開始基準を満足していないレベルと考える。このままシステムテストを開始すると、前工程で修正すべき不具合が多発し、システムテストの妨げになり、十分なシステムテストができないと考える。前工程の特にFunction、Timing/Serializeを見直しを行ったうえで、開始作業を判定すべきである。』 ソフトウェア不具合改善手法 ODC分析 試しに実施した感想 少ない件数ですが過去の不具合データで試しにODC分析を行った感想です。プロセス・シグネチャーと比較することで、プロセスにおける差異を視覚的に説明することができました。しかしながら、全不具合1件ずつに対して4つの属性を割り当てる作業は、属性毎に多数の選択肢から選ぶ必要があり作業に時間を要しました。 また、複数の担当者で作業をする場合、人により異なる解釈をしてしまうと同じ割り当て結果になるとは限らず、正確な分析ができない可能性があると感じました。分析する前に各選択肢の意味を関係者間で認識合わせしておくのがよいと思います。 導入する際は、不具合管理ツールの入力項目として4つの属性を追加し、各属性に選択肢を定義して、いつ誰がその属性を入力するのか等のワークフローを決めておき、関係者へ説明してから利用開始するのがよいと考えました。 まとめ ODC分析を利用することで、不具合の調査から対策の策定までを行い、プロセスの品質を改善できます。ただ、属性に割り当てる選択肢が多いため、最初は時間が必要になるかもしれません。ですが、事前準備と慣れで解消できると考えます。慣れてしまえばODC分析は効率的な技法であり、QAメンバーやプロジェクトマネージャーが活用を検討してみる価値がある技法だと確信しました！ ※1　杉崎 眞弘 (著), 佐々木 方規 (著), 日科技連ODC分析研究会 (編集), 2020/08/21, 「 ソフトウェア不具合改善手法 ODC分析 」, 日科技連出版社 The post ODC分析：なぜなぜに疲れたQAメンバーに捧ぐ分析手法 first appeared on Sqripts .

「テスト推進」という仕事 はじめまして、おかじです。私は、テスト推進というポジションの業務を担当しています。 テスト推進とは、簡単に言うとテスト分野を専門としたPMO（プロジェクトマネージメントオフィス）のような仕事です。PMOはPM（プロジェクトマネジャー）やプロジェクトチームに対して、プロジェクトの計画・実行・状況管理などをサポートし、プロジェクトの品質向上を図る役割を担っていますが、一方テスト推進はテストの計画・実行・状況管理などをサポートし、プロジェクトの品質向上を図る役割を担っています。 本記事は、テスト推進業務の経験を元に「現場で意外と困ることの多いテスト環境利用問題」をテーマにテスト環境利用管理について記載します。 これからテスト推進を担当する方にとって、この記事がなにか参考になればと思います。 意外と困るテスト環境利用問題 テスト環境の利用調整に困っているという声をよく耳にします。「テスト環境の管理なんて必要ですか？」と思う方もいると思います。例えばスタンドアローンのアプリケーションのように、自前で用意した環境だけでテスト対象アプリをインストールしてテストできるものであれば、テスト環境利用の問題は発生しないと思います。しかし複数の機能群（サーバー群）から構成されるシステムや特殊なハード機器がある場合などは、簡単に複数のテスト環境を用意することは難しく、テスト環境の利用管理が必要になってきます。 テスト環境利用管理の検討が必要なケース、テスト環境利用で起きる問題例を以下に記載します。 テスト環境利用管理の検討が必要なケース 複数のサーバー群で連携動作するシステムである場合。 マルチベンダー開発や関連事業者が複数いる場合。 複数の案件が同じ環境利用で絡む場合。 テスト環境利用で発生する問題 テスト環境を利用したいが、他のチームが利用して使えない。 　→　テストスケジュールの見直しが発生した。 環境を占有利用していたが、他のチームが別作業を行って作業中にトラブルが発生した。 　→　テスト実施のやり直しや環境故障の修復作業が発生した。 環境を利用し始めた際に想定の環境状態と実際の環境状態が異なり、トラブルが発生した。 　→　予定作業が始められず、スケジュール遅延となった。 などなど。 このようなトラブルが続出してしまうとトラブル対応工数や調整工数の増加、スケジュールの再計画の発生が各作業者の負担を増加させてしまい、その結果より大きなミスを誘発してしまう可能性もあります。 「現場で意外と困ることの多いテスト環境利用問題」に対して、私はテスト環境の利用管理を行うことでテスト環境利用問題を軽減し、テストを推進するよう取り組んでいます。 テスト環境の利用管理 大規模なプロジェクトになると以下のような体制で開発することがあります。 体制：複数社・複数チーム 環境構成：大規模Webシステム・サーバー数十台単位の構成 利用状況：複数案件が並走 上記のように複数のサーバーで構成された環境、複数会社やチームによって複数案件が並走しているプロジェクトでは、テスト環境利用管理が必須となります。 これから私が実際に行ってきた管理方法をベースに、テスト環境利用管理の４つのポイントを紹介します。 【ポイント１】環境利用の管理表を考える 【ポイント２】作業区分の定義を考える 【ポイント３】環境変更区分の定義を考える 【ポイント４】環境管理の運用を考える 【ポイント１】環境利用の管理表を考える テスト環境利用管理を行うために、把握しやすい管理表が必要です。 私は日単位の管理表と時間単位の管理表の二つをエクセルで作成して管理しています。この二つに分けた管理を行っている理由は俯瞰的な状況と詳細な情報を管理し易くするためです。 日単位の管理表 日単位の管理表は、利用予定の俯瞰的な確認、プロジェクト内での情報共有を図ることに利用します。また、主要な環境状態（資材、マスターデータ、システムの設定状態など）を一緒に記載することで、環境状態も可視化できるようにしています。 時間単位の管理表 時間単位の管理表は同日に複数チーム、複数作業が並走した場合に各作業時間や順序を調整したり、環境変更を伴う作業の記録を残すために利用しています。 この時間単位の管理表があることで、より詳細な作業対象環境、作業時間帯を把握できるようになります。 【ポイント２】作業区分の定義を考える 作業区分定義の目的は、利用調整が必要になる作業なのかを簡易的に把握するために定義します。私は「占有作業」「非占有作業」「部分占有作業（条件付き作業）」の３つの区分で整理しています。 占有作業 環境変更など、他の作業と並走不可能な作業 非占有作業 システム動作を停止しなければならない作業がない。他の作業と並走可能な作業 部分占有作業（条件付き作業） 一部のサーバー、一部のデータ領域のみを占有し、条件によっては他の作業と並走可能な作業 【ポイント３】環境変更区分の定義を考える 環境変更区分定義の目的は、環境の状態が変わるのか、変わらないのか、一時的に変えて元の状態に戻すのかを簡易的に把握するために定義します。 環境変更なし 資材変更、設定変更、マスターデータ変更などを伴わない。 環境変更あり 資材変更、設定変更、マスターデータ変更などを伴う。 環境一時変更あり 資材変更、設定変更、マスターデータ変更を伴うが作業後に元の状態に戻す。 【ポイント４】環境管理の運用を考える 環境管理の運用を考える際の重要なポイントは「続けられる運用であること」です。 ルールが複雑で理解しにくかったり、時間や手間が掛かってしまうものだと、管理の考え方が良いものでも続かなくなってしまいます。 私が現場で設けている運用ルールは大きく以下５点です。 日単位の管理表に予定を記載したい場合は、各チームから環境管理者に申告する。 環境変更を伴う作業や同日に複数利用者がいる場合、利用者が時間単位表に作業を記入する。 時間単位で作業が重複した場合、記入した利用者から環境管理者へ連絡する。 環境管理者は各チーム情報をもとに調整が必要な場合、関係者を集め調整を行う。 環境占有、環境変更を行う作業は作業開始時、作業完了時にメールで周知連絡を行う。 これらの運用は、管理者を置くことで作業情報を集約すること、また作業重複時の調整役とすることで、認知されていない環境変更の抑止を目的としています。 最後に 本記事では環境利用管理を行う際にポイントとなる考えを記載しましたが、環境利用管理を行うことで以下の様なメリットがあります。 環境利用状況を視覚化することで各チームのテストスケジュール計画がし易くなる。 調整が必要となる作業を把握し易くすることで環境利用の調整工数を削減できる。 環境状態を視覚化することで、各チームが利用開始時に想定と異なる環境状態になっていた場合の作業遅延リスクを低減できる。 管理者に環境の利用状況を集約するこで、環境変更に伴うトラブルが発生した際の、変更が行われた作業を特定しやすくなる。 など、環境を利用する作業者の負担を軽減することができます。 ソフトウェア品質の根幹には「人はミスをするもの」という考えが根底にありますが、人がミスし易くなる時を考えると作業者の負担が大きい時にミスを犯しやすくなると思います。逆に考えれば、作業者の負担を軽減することで、ミスは減らせるのではないでしょうか。 些細な環境利用管理という側面からでも、作業者の負担を軽減することで作業者のミスを減らすことに繋がり、ソフトウェア品質の向上への間接的なアプローチになると思います。 最後まで読んでいただき、ありがとうございました。 The post テスト推進虎の巻 ～テスト環境利用管理～ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第4回となる今回は、オンチェーンデータ分析の手法としてSQLを用いることのメリットについて、SQLの背景にある概念や歴史などを交えながら解説していきます。 データ分析のためのSQL SQLとは、もともとリレーショナルデータベースと呼ばれるデータベースシステムからデータを抽出したり、データを操作したりするための専用の言語でした。近年では、SQLの完成度と汎用性の高さから、データベース分野に留まらず、広くデータ分析の用途でもSQLが活用されています。 コード1. SQLのサンプルコード CREATE TABLE sample ( id INT, name TEXT, description TEXT ); INSERT INTO sample VALUES (1, 'AAA', 'some text'); INSERT INTO sample VALUES (2, 'BBB', 'some text'); SELECT id, name FROM sample WHERE id <= 1 LIMIT 10; ここで、単なるデータの集合とデータベースの違いについて補足しておきます。まず、「データ」という言葉の定義自体がさまざま存在しますが、ここでは「一定の形式（フォーマット）で整えられた事実や数値」といった意味で取り扱うこととします。例えば、ある企業に属する従業員のIDや氏名、生年月日などをCSV形式やJSON形式で保存したテキストファイルは、典型的なデータの一種です。 一方、データベースとは、こうしたデータの集合を体系的に構成し、データを簡単に検索したり、整合性を持って更新したりできるようにしたものを指します。無秩序なデータを単に寄せ集めたもので、目的のデータを簡単に抽出したり更新したりできないような状態になっているデータの集まりであれば、一般的にはデータベースとは呼ばれません。 なお、ビッグデータの文脈では、従来のデータベースで管理されているような体系的なデータの集合を「構造化データ」、それ以外の多種多様で雑多なデータ群を「非構造化データ」と呼ばれることもあります ※1 。ICT技術の発展に伴い、この「非構造化データ」が急速に生成・保存されるようになったことで、ビッグデータの活用という概念が注目を集め始めました。この文脈に即して冒頭の説明を言い換えると、「SQLはもともと『構造化データ』を操作するために利用されていた言語だが、近年では『非構造化データ』に対してもSQLを適用してビッグデータ分析に活用する事例も増加している」とも表現できます。 ※1 総務省 平成25年版 情報通信白書 – ビッグデータの概念: https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h25/html/nc113110.html 3層スキーマ 多くのデータベースシステムでは、物理的に保存されたデータのフォーマットとは別に、抽象的な概念としてのデータモデルを備えています。 米国国家規格協会（ANSI）の標準化計画要求委員会（SPARC）が提唱した「3層スキーマ」というモデルでは、データベースの構造を「外部スキーマ」「概念スキーマ」「内部スキーマ」という3つのスキーマに分けて定義しています。これは、データの物理的な保存形式である「内部スキーマ」と、データを加工して利活用するビューとしての「外部スキーマ」との間に、緩衝材となる抽象的な「概念スキーマ」の層を配置することで、データの独立性を保つための構造です。 図1. 3層スキーマ 3層スキーマの考え方を用いず、物理的なデータを直接プログラミング言語などで加工してデータ分析する手法も存在します。CSVファイルなどで保存されたデータをPythonなどで読み込み、直接加工するような方法です。 このとき、物理的なデータの格納方法を変えたいときに、同時にプログラム側の改修が必要となったり、逆にデータの表示形式を変えたいときに、物理的なデータの格納方法を変更しなければならなくなったりすることがあります。こうした状態はデータの独立性が存在しない状態と言えます。一人のデータ分析者がデータを取り扱うだけであればそれほど問題はないかもしれませんが、多くの分析者が同時に同じデータを扱ったり、分析者とは異なる人物がデータの保存方法をメンテナンスしていたりする場合には、3層スキーマのような形でデータの独立性を担保してあげたほうが良いでしょう。 こうしたデータの独立性を担保するために、SQLという言語は共通のインターフェースとして非常に都合が良かったため、データベース分野だけでなく、広くデータ分析のために活用されてきています。 リレーショナルモデル データベースの種類には、オブジェクトデータベースやグラフデータベース、ドキュメントデータベースなど様々なものが存在しますが、SQLとともに広く普及しているデータベースの種類がリレーショナルデータベース（RDB）です。 さきほど説明した通り、多くのデータベースでは、物理的なデータを直接取り扱うことは少なく、抽象的なデータモデルを持っている場合があります。リレーショナルデータベースの場合は、リレーショナルモデル（関係モデル）と呼ばれる独自のデータモデルを持っており、そのモデルはSQLの思想にも強く反映されています。 リレーショナルモデルでは、データを取り扱うための基本的な構造を「リレーション（関係）」と呼びます。ただし、これは日常生活における「関係」や「リレーションシップ」という言葉から連想するものとはかなり異なる、数学的な独自用語であることに注意が必要です。 日常生活における「関係」という言葉は、「親子関係」や「因果関係」など、２つの項目に注目した場合が多いでしょう。例えば、「サザエさんとタラちゃんは親子関係である」や「風が吹けば桶屋が儲かるのは因果関係である」といった形です。 この「関係」という言葉を少し数学的に表現すると、「2つの集合A, Bに対して、直積A×Bの部分集合を、AとBの間の二項関係と呼ぶ」といった表現ができます。集合AやBを人物の集合とすると、直積A×Bというのは、その集合に含まれる人物同士のすべての組み合わせの集合となります。その人物同士の組み合わせには、親子関係である組み合わせもあれば、そうでない組み合わせも含まれるでしょう。このとき、親子関係にある組み合わせのみを取り出した集合を、数学的には「直積A×Bの部分集合」という表現をします。 リレーショナルモデルにおけるリレーション（関係）は、上記の数学的な二項関係の定義をN項関係に拡張し、「属性の定義域(ドメイン)D1, D2, D3, …, Dnに対して、 直積D1×D2×D3×…×Dnの部分集合Rを関係と呼ぶ」と定義されます。 例えば、日本人のすべての名字を含む集合Aと、日本人のすべての名前を含む集合Bを、それぞれ名字の定義域、名前の定義域として直積A×Bを計算すると、A×Bにはすべての日本人の名字・名前の組み合わせと、存在しない架空の人物の名字・名前の組み合わせが含まれることになります。このとき、実際に存在する日本人の名字・名前の組み合わせを「日本人の名字・名前を示す関係」と呼ぶ、といった考え方が、リレーショナルモデルのデータの表現方法になります。 図2. 名字・名前のリレーション（関係）のサンプル このリレーション（関係）を人間が理解しやすいように可視化する際に、よく属性列とデータ行とで構成された二次元テーブルの形式で表現することが多いため、リレーショナルモデル＝二次元テーブルだと考えてしまいがちです。しかし、CSVファイルやエクセルファイルで取り扱われることの多い二次元テーブルの表示形式と、抽象的な集合論に基づくリレーション（関係）とでは、見え方が似ていても厳密には異なるものなのだということを頭の片隅に置いていただければ、SQLの理解が深まるでしょう。 関係代数とSQL リレーショナルモデルでは、上記のように定義したリレーション（関係）というデータモデルに対して、関係代数と呼ばれる演算を定義しています。これは、「整数」という型のデータに対して、足し算や引き算などの演算を定義しているようなイメージです。リレーションに関係代数を適用することで、リレーションの形を変形したり、新たなリレーションを生成したりすることができます。SQLという言語は、この関係代数を簡単に記述するための言語であり、PythonやJavaScriptのようなコンピュータへの命令を記述していく命令型言語よりは、抽象的な関数や述語論理に基づくHaskellやPrologのような宣言型言語に近いプログラミング言語です。 SQLや関係代数の重要な特徴として「閉包性」と呼ばれる性質があります。これは、リレーション（関係）に対して関係代数を適用した結果は、必ずリレーション（関係）になる、という性質です。例えば、整数に対して足し算や引き算を何度繰り返し適用したとしても、その結果は常に整数であり、突然文字列データになったりはしません。このことは、基本的な演算子を無数に組み合わせて複雑な計算を表現することができる点や、どれほど複雑な演算子の組み合わせを適用した計算結果であっても、それを別の演算子の入力として利用できる点などが保証されていることを意味します。 図3. 関係代数の閉包性（関係代数演算の出力は、別の関係代数演算の入力となれる） したがって、SQLによるデータ加工やデータ分析のためのクエリ文は、非常に複雑な処理を記述できる柔軟性と、それを別のクエリと組み合わせることのできる可用性を担保することができます。この性質により、SQLはデータベースのみならず、ビッグデータ領域を含む幅広い領域でのデータ加工・データ分析用途のために活用され続けています。 標準SQL規格 SQLの言語仕様は、米国国家規格協会（ANSI）や国際標準化機構（ISO）によって標準化されており、異なるデータベースや分析システムであったとしても基本的に同じSQLの標準規格に準拠しており、SQL文の保守性や移植性の担保に貢献しています。ただし、システムによって標準規格への準拠状況が異なっていたり、独自の機能拡張が行われていたりすることも多いため、100%同じSQL文が他のシステムでも流用できるというケースは多くありません。それでも、独自フォーマットのファイルシステムを直接操作するプログラムを移植するよりは、遥かにデータの独立性を保った運用が可能です。 また、標準SQL規格は、古い規格で書かれたSQL文との後方互換性を維持しながら、データ分析用途で需要の高い構文も取り入れつつ進化を続けています。特に、SQL99で導入された共通表式（WITH句）や、SQL:2003で拡張されたウィンドウ関数などは、近年のデータ分析用途では必須の構文となります。詳しい構文の説明は本連載記事の次回以降でおこないますが、SQLを用いたデータ分析のための技術選定をする際には、これらの標準SQL規格への準拠度合いなども参考にしていただければと思います。 オンチェーンデータのためのSQL実行基盤 本連載の第2回や第3回記事において、ビットコインやイーサリアムのオンチェーンデータをSQLで分析できるオンラインサービスとして、Google BigQueryやDuneなどをご紹介しました。 特に、Duneというサービスは、ブロックチェーンのオンチェーンデータ分析に特化したスタートアップであり、これまで複数のSQL実行エンジンを利用しながらバージョンアップを繰り返してきました。ここでは、Duneが採用したSQL実行エンジンをサンプルとしながら、SQLを用いたデータ分析の利点や注意点などを解説します。 Dune 初期のDune v1では、オープンソースのリレーショナルデータベースマネジメントシステム（RDBMS）であるPostgreSQLを用いて、オンチェーンデータのオンライン分析サービスを提供していました。その後、データフォーマットを修正したDune v2が登場し、SparkSQLによるSQL実行環境が追加され、2023年8月現在ではDuneSQLという独自のSQLを用いたインターフェースに移行しています ※2 。 ここで、Dune v1とv2の採用しているSQL実行エンジンの違いについて深掘りしてみましょう。PostgreSQLのようなRDBMSは、さまざまなアプリケーションのバックエンドとして、多数のトランザクションを同時に実行するOLTP(Online Transaction Processing)を想定して実装されています。 サンプルデータとして、日本の全人口1億人強の戸籍データベースを想像してみましょう。OLTPで想定するデータ処理としては、約1億人のデータベースから該当する人物のレコードを抽出し、詳細データを表示したり、一部のデータを更新したりする処理が考えられます。このとき、約1億人のデータをCSVなどのファイルベースで管理していると、検索のためのコストも高く、多数の更新トランザクションを同時に実行することも困難となります。このような用途を効率的に処理するためにRDBMSのようなデータベースが存在し、高速な検索のためのインデックス機能や、トランザクションの排他制御などの機能を提供しています。 一方、Dune v2で採用しているようなSparkSQLやDuneSQLなどのSQL実行エンジンは、OLTPではなくOLAP（Online Analytical Processing）と呼ばれるデータ処理を想定して設計されています。さきほどの約1億人の戸籍データベースを例にすると、全人物の平均年齢を計算するような処理がOLAPで想定しているデータ処理です。このようなデータ処理は、もちろんPostgreSQLのようなRDBMSでも可能ではありますが、必ずしも効率的ではありません。そのため、RDBMSとは異なる方向性で最適化したソリューションが登場してきました。OLAP用途のデータ処理で広く採用されているアーキテクチャとして、「列指向」と「分散処理」が挙げられます。 ※2 Introducing Dune SQL: https://dune.com/blog/introducing-dune-sql 列指向アーキテクチャ 列指向とは、データの物理的な保持形式を、レコードのような行単位ではなく、属性値などの列単位とするアイデアです。代表的な実装として、Apache Parquetというオープンソースの列指向データファイル形式があります。 さきほどの戸籍データベースから全人物の平均年齢を計算するという処理の場合、あらかじめ各人物の年齢、もしくは生年月日を記録したデータだけを1箇所にまとめたデータフォーマットにしておいたほうが、ファイル読み込みの効率が良いでしょう。また、全人口が1億人強存在するデータベースであっても、年齢や生年月日といったデータのバリエーションは1億通りあるわけではなく、当然同じ年齢や同じ誕生年、誕生月の人物が大量に存在します。そのようなデータは一般的に圧縮効率がよいため、さらにデータの読み込み効率を上げることができます。Databricksの資料 ※3 によると、1 TBのCSVデータをParquet形式のデータに変換することで、データサイズが130 GBにまで削減でき、クエリの実行時間もCSVの場合に236秒だったものが、Parquetでは6.78秒にまで短縮されるというデータもあります。 ※3 Databricks – Parquetとは: https://www.databricks.com/jp/glossary/what-is-parquet 分散処理アーキテクチャ 大量のデータに対してOLAP型のデータ処理をおこなう場合、ボトルネックとなるのはデータ読み込み部分です。このボトルネックを解消するために、列指向と並んで用いられるアーキテクチャが分散処理です。例えば、読み込み性能が100MB/sのハードディスクに2TBのデータを保存した場合、そのデータすべて読み込むためには、単純計算で2万秒（約6時間）かかってしまいます。これを、100台のハードディスクにデータを100分割して同時に読み込むことができれば、読込み時間を100分の1に短縮できるのではないか、というのが分散処理の根源的なアイデアです。 ディスクIOを分散化するための代表的な分散ファイルシステムが、Apache Hadoopというプロジェクトのコア機能であるHDFS（Hadoop Distributed File System）です。このHDFS上のCSVファイルやParquetファイルに対してデータ処理をおこなう方法として、HadoopではMapReduceと呼ばれる分散処理のプログラミングモデルを提供していました。しかし、MapReduceモデルのプログラムをJavaなどのプログラミング言語で実装するのは、専門のスキルが必要であったため、そのハードルを下げるために、SQLのクエリ文を自動的にMapReduceのプログラムに変換するApache Hiveのようなプロジェクトが登場しました。さらにHiveの処理性能を向上させるソリューションとしてApache SparkのSparkSQLや、Trino（旧Presto）などが登場しました。Duneで採用しているDuneSQLは、このTrinoをベースにしています。 SQLの物理データ独立性 DuneのSQL実行エンジンが、PostgreSQLからSparkSQL、TrinoベースのDuneSQLに遷移していったように、データの増加やプロジェクトのフェーズ、技術の進歩といったさまざまな要因で、データの物理的な格納方法が劇的に変わることが想定されます。そのような物理層での変更があった場合でも、SQLをインターフェースとして分析ロジックを実装していれば、その影響は最小限に留めることができます。 もちろん、PostgreSQLやSparkSQL、DuneSQLの間でも、関数や予約語の微妙な違いや、対応している構文に差異があったりして、100%書き換えが必要ないというわけではありません。また、効率的なSQLを記載するためには、列指向や分散処理などの物理層のアーキテクチャを理解する必要がある場合もあります。しかし、物理層と分析ロジックが密に結合しているようなデータ分析環境は、多人数による共同管理や業務分担に支障をきたすことが多いでしょう。SQLを用いたデータ分析では、リレーショナルモデルをベースにした概念スキーマ層が暗黙的に存在し、物理層とアプリケーション層とのデータ独立性を保つことが容易となります。 ブロックチェーン上のオンチェーンデータや、その他ビッグデータの分析に興味を持たれた方は、ぜひ今後の連載を参考に、SQLを用いたビッグデータ分析に挑戦してみてください。 次回予告 ブロックチェーン上のオンチェーンデータを分析するための手法として、SQLを用いるメリットについて、リレーショナルモデルやSQL実行エンジンの考え方や歴史などから深掘りをしました。 次回の記事では、これまでも何度か登場してきたDuneが提供するイーサリアムのオンチェーンデータをサンプルとして、データ分析のためのSQL基本構文について解説していきます。 連載一覧 【第1回】：ブロックチェーンとは 【第2回】：ビットコインの仕組み 【第3回】：イーサリアムの仕組み 【第4回】：ビッグデータ分析のためのSQL基礎 The post 【第4回】ビッグデータ分析のためのSQL基礎 first appeared on Sqripts .

初めまして、テストエンジニアのやままいです。 テストスイートはテスト設計と密接に関わりのある要素です。しかし、テスト技法やレビュー等と異なり、”確立した手法があまり説明されていない”ように感じました。そこでテストスイートについて調べる過程で得た知見や私なりの考えをまとめようと思います。 この記事では、まずテストスイートの定義を再確認したあと、具体例を用いて実際にテストスイートの作成手順をご紹介します。それから作成したテストスイートをベースに「テストスイートのまとめ方」について考えていきたいと思います。 テストスイートとは まず、テストスイートについてJSTQB Foundation Levelシラバス（以下、JSTQB FLシラバスと記載）とISTQB_Glossary（以下、ISTQB用語集と記載）にどのように記載されているか見てみましょう。 （以下、JSTQB FLシラバスから抜粋） テスト手順や（存在する場合）自動化テストスクリプトからテストスイートを作成する。 効率的にテスト実行ができるように、テスト実行スケジュール内でテストスイートを調整する（5.2.4 節を参照）。 テストケースやテスト手順を作成（テスト手順は可能な限り自動化）し、テストスイートにまとめた後、テスト実行スケジュールを作成してテストを実行する順序を定義する。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 （以下、ISTQB用語集から抜粋） 特定のテストランで実行されるテストスクリプト、またはテスト手順のセット。 ISTQB Glossary つまりテストスイートとは、効率的にテスト実行ができるように 何らかのルールに沿ってテストケースをまとめたもの と定義できそうです。 では、テスト実行を効率化するテストスイートのまとめ方とは、どのようなものでしょうか？　ここからは具体例をもとに実際にテストスイートを作成しながら考えてみましょう。 実際にテストスイートをまとめてみる テストケースを洗い出す まず具体例として、会員用webページの簡単なテストを想定します。テスト対象の画面と要素を以下に記載します。 【A：ログイン画面】 「ログインボタン」と「その他の要素（入力フォーム含む）」を表示する 正常値（登録情報）を入力して「ログインボタン」を押下するとマイページ画面へ遷移する 不正値（空欄含む）を入力して「ログインボタン」を押下するとエラー画面へ遷移する 【B：エラー画面】 「戻るボタン」「その他レイアウト」を表示する 「戻るボタン」を押下するとログイン画面へ遷移する 【C：マイページ画面】 「ログアウトボタン」「その他レイアウト」を表示する 「ログアウトボタン」を押下するとログイン画面へ遷移する 上記の仕様をもとに状態遷移図を作成し、10個のテストケースを識別しました。 では、早速上記の10テストケースを、テスト実行の効率化を目標にまとめてみましょう。 確認内容でまとめてみる まず【Ver 1.0】では同じ確認内容で並び替えを行いました。同じ確認内容であれば、似たような確認手順になるのでテスト実行を効率化できるかもしれません。このテストスイートを上から順に確認していくと仮定して検証してみましょう。 実行順序（1）～（2）のテストケースは同じ画面なので効率良く確認ができそうです。ですが、実行順序（3）を実行しようとした場合、ログイン画面からエラー画面への遷移が発生しています。同様に実行順序（4）と（5）、（6）と（7）なども、テストケース終了時の画面が次のテストケースの開始画面と異なるため、余分な手順（下準備）が発生してしまいました。 では、さきほどの【Ver 1.0】に下準備の工程を追加してみましょう。 下準備を含めると、テストケース10個を確認するのに15回の手順が必要となっていることがわかります。これでは効率的とは言えません。逆に、下準備が必要ない構成にするほど効率的になると言えます。 次は、下準備を減らすために各テストケースの終了時の画面と、前提条件となる対象画面が揃うように並べ替えてみましょう。 終了時の画面と前提条件が一致するようにまとめてみる テストケース間の下準備が不要になり、10個のテストケースを10回の手順で完了できる構造にできました。ここで完成としても良いですが、更に同じテスト対象のテストケースを隣接させることで連続性を高めることができます。たとえば、実行順序（1）と（3）、（4）と（6）、（8）と（10）は、確認内容こそ異なりますが同じボタンを確認するテストケースです。同じテスト対象を隣接させることで前後のテストケースの連続性が高まりテスト実行がより効率的になるでしょう。それでは、同じテスト対象を確認するテストケースを隣接させてテストスイートを並べ替えてみます。 同じ要素が隣接するようにまとめてみる いかがでしょうか？ テストケース実行終了時の画面が次のテストケースの前提となる画面となり、確認する要素が隣接することで連続したテスト実行ができるテストスイートが完成しました。 テストスイートの目的である”テスト実行の効率化”を十分に達成できたと考えます。 テストスイートのまとめ方について考える テストケースを並べ替えることで実行順序を効率的にできました。ここで、ひとつの疑問を提示します。それは「”テストを早く実行できること＝効率が良い”なのか？」ということです。テストの目的は、テストケースを実行することでプロダクトの表示や動作を担保し、品質を保証することです。品質には様々な特性があり、どの品質を重視するかはプロジェクトやプロダクトにより異なります。 たとえば、「システム・ソフトウェア製品の品質モデル（JIS X 25010）」 ※1 の品質特性である「使用性」には、副特性として「ユーザインタフェース快美性」というものがあります。これはUIの美しさを表す特性で、一例として”画面間での要素デザインが統一されているか”といった観点が考えられます。プロジェクトが目指す品質としてテスト観点で追加するほどではない場合でも、担保できればユーザの満足度を高めることができそうです。この品質特性の不具合を見逃さないテストスイートを考えた場合、「表示確認」というテスト観点がまとまっている【Ver 1.0】のテストスイートの方がデザイン不一致に気づきやすく、該当する不具合検知の可能性を高めることができそうです。 他にも「保守性」の副特性である「解析性」を担保する場合、”ログイン成功時／失敗時のログ情報フォーマットが統一されているか”といったテスト観点が考えられます。こちらもテスト対象である「ログインボタン（正常値）」と「ログインボタン（不正値）」が隣接している【Ver 1.0】のテストスイートの方がログ情報フォーマットの比較がしやすそうです。 以上から【Ver 3.0】よりも【Ver 1.0】の方が”不具合検出という点で効率化されている”ことがわかりました。適切なテストスイートの作成を行うには、どのような効率を高めるかを明確にして作成することが重要だと言えそうです。 ※1　[ システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル JIS X 25010：2013（kikakurui.com） ] まとめ テストスイートを適切に作成することでテスト実行手順を効率化できました。さらに、品質特性など何の効率を目的としているのかを意識すると、テストスイートの最適なまとめ方も変化することがわかりました。 今回紹介した以外にも、過去の不具合傾向やリスク、システムの実装状況など様々な要因で求める効率は変わってきます。また、状況によっては目的とする効率を達成する方法として、テストスイートで解決するのが最善なのかといった点にも注意する必要があるでしょう。 担当するプロジェクトやプロダクトの状況・性質・要件を適切に理解して、より良いテスト実装をするためにもテストスイートを上手く使いこなせるようにしていきたいですね。テストスイートを使いこなして、効率的で生産性の高いテストを作っていきましょう。 The post テストスイートって何？ テストケースのまとめ方を考える first appeared on Sqripts .

アジャイル開発とは変化するビジネス要件に素早く対応するためのソフトウェア開発手法です。この記事では、その重要な一部であるアジャイルテストについて詳しく説明します。 アジャイルテストとは？ アジャイルテストとは、アジャイル開発手法におけるテストのアプローチで、開発の早い段階から連続的かつ反復的にテストを行うことを重視します。開発サイクル全体に渡りテストが組み込まれ、フィードバックが素早く反映されることで品質の向上とリスクの軽減を図ります。また、テスターと開発者の協力を推奨する点も特徴の一つです。 アジャイル開発が普及した背景と課題 アジャイル開発の普及に至った背景には複数の要因があります。まず、1990年代後半から2000年代初頭にかけて、インターネットの普及によりネットベースのビジネスが急速に成長しました。これにより従来型のウォーターフォールモデルでは迅速な対応が難しいと認識されるようになりました。新しくなるビジネス要件への短時間での適応が求められ、変化に素早く対応できるソフトウェア開発手法の必要性が高まったのです。 また、従来のウォーターフォールモデルでは、リリースまでに長期間を要し、その期間中に市場環境や企業のビジネス戦略が変わってしまうケースが多く見られました。そうすると、結果としてリリース時点でのソフトウェアが既に古くなってしまい、想定していたビジネス価値を提供できないという問題が生じていました。これらがアジャイル開発手法の普及を後押ししました。 しかし、アジャイル開発が普及するにつれて、いくつかの新たな課題も浮かび上がってきました。従来のウォーターフォールモデルでは、テストは開発の最後の段階に位置していましたが、アジャイルでは開発とテストが連続的に行われます。 この状況では、「短いリリースサイクル」と「頻繁な変更」という二つの要素が互いに関係し合っていますが、同時にトレードオフの関係にあります。 「短いリリースサイクル」は、素早く製品や機能を顧客に提供できる利点がある反面、「頻繁な変更」は、開発チームに対する負荷となる可能性があります。変更が迅速であるため、テストや品質管理の適切な実施が難しくなる場合もあります。 また、迅速なリリースが求められる状況では、品質の低いコードや設計がリリースされることがあります。この問題は「技術的負債」と呼ばれ、長期的に見るとソフトウェアの品質や開発効率を低下させる要因となります。 これらの課題に対応するため、新たなアジャイルテストの手法が生まれ、普及しました。 アジャイルテストのメリット アジャイルテストは、アジャイル開発の特徴と共に、以下のようなメリットを提供します。 フィードバックの早さ アジャイルテストは開発サイクルの初期から行うため、テスト結果に基づくフィードバックが非常に早く提供されます。これにより、問題が発見された際の修正コストが大幅に削減でき、品質向上に貢献します。 高い適応性 アジャイルテストは、ビジネスの要件が変わった際に即座に対応することができます。テスト計画は継続的に更新され、プロジェクト目標に対する柔軟な適応が可能となります。 意思決定の迅速さ アジャイルテストでは、テスト結果に基づくデータ駆動型の意思決定が可能となります。これにより、品質の問題やリスクを迅速に認識し、必要な対応を計画することができます。 チームワークとコミュニケーションの改善 アジャイルテストは、開発者とテスターの協力を促す手法です。この方法を採用することで、コミュニケーションの改善が図られ、全体の開発プロセスが円滑に進むようになります。たとえば、テスターが開発サイクルの早い段階から関与することで、問題や要件に関する意見交換が促進されるなどの効果が期待できます。 問題の早期発見 アジャイルテストの手法と短い開発サイクルは、ソフトウェアの機能に問題がある場合に早い段階で見つけることが可能です。これにより、修正や改善のための追加作業を迅速に行うことができます。 以上のように、アジャイルテストは、開発プロセスの各段階で高い柔軟性と機能性を提供し、これに基づいた意思決定を可能にすることで、最終的な製品の品質を向上させることができます。 アジャイルテストのメリットの反面、以下のような気を付けないといけない点もあります。 繰り返し迅速なフィードバックを得ることができる反面、詳細なドキュメント作成が後回しになることが多く、新メンバーが参加した際に問題が生じる可能性がある アジャイル開発では頻繁にリリースが行われるため、適切なテスト自動化が求められるが、その導入や維持には手間やコストがかかる リリースや開発の反復期間が短いと、テスト設計と実行のための時間が削られ、テストカバレッジが十分でなくなることがある 新機能が頻繁に追加または変更される場合、テストの優先順位や範囲を決定することが難しくなることがある アジャイル開発では頻繁な変更に合わせてテストケースを随時更新する必要があり、これが作業の負担になることがある アジャイルテストとウォーターフォールテストとの比較 アジャイルテストとウォーターフォールテストは、開発とテストのプロセスに大きな違いがあります。 アジャイルテスト 連続的なフィードバック： アジャイルテストでは、開発とテストが交互に行われるため、コードの品質に関するフィードバックをすぐに受け取ることができます。これにより、バグや問題が早期に発見され、修正が容易になります。 変更への柔軟な対応： アジャイルテストでは、新たな要件や変更に対する柔軟な対応が可能です。アジャイルなアプローチでは、開発者とテスターが継続的にコミュニケーションを取りながら、テスト計画やテストケースを柔軟に更新していくことが重要です。これにより、変更に迅速に対応し、効果的かつ要求事項に適合した品質保証を実現することができます。 ユーザーフォーカス： 顧客のニーズやフィードバックを通じて、ユーザーストーリーや要件を明確にし、ユーザーが求める機能や改善を実現します。これにより、顧客との連携を強化し、より使いやすい製品を提供することが可能となります。 ウォーターフォールテスト 逐次的な進行： ウォーターフォール開発では、ソフトウェア開発プロセスが段階的に行われます。各フェーズ（要件定義、設計、開発、テストなど）は明確に区切られ、一つのフェーズが完了すると次のフェーズに進みます。 変更の難しさ： 一度開発が始まると、新たな要件や変更を取り入れるのは困難で、かつコストがかかる場合があります。 開発終盤でのテスト： テストは開発プロセスの終わり、あるいはリリース直前に行われるため、バグや問題が発見されても修正が難しくなる可能性があります。 総じて、アジャイルテストは変化の速い現代のソフトウェア開発に親和性が高く、ウォーターフォールテストは安定した要件と長期的な計画が可能なプロジェクトに適しています。 参考） 【第1回】アジャイル時代に求められる「品質」とは何か？ さまざまなアジャイルテストの手法 ここでは、広く普及しているアジャイルテストと親和性が高いアプローチをいくつかご紹介します。 DevOps DevOpsは開発（Dev）と運用（Ops）が連携して作業を行う考え方で、これにより開発からリリース、運用までのプロセスが連続的かつ無駄なく進められます。テストはこのサイクルの一部として自動化され、リリースの質と速度を上げる役割を果たします。 シフトレフト シフトレフトとは、「品質保証のためのテスト活動を可能な限り開発プロセスの早い段階に取り入れる」アプローチのことです。早い段階で問題点をフィードバックすることで、大きな手戻りや未然にバグを防ぐことを目指します。シフトレフトを適切に行うと、ソフトウェアの品質向上に繋がるだけでなく、全体のテスト時間を短縮し、コストを抑える効果も期待できます。 テスト駆動開発 テスト駆動開発（TDD）は、まず要件を満たすテストを作成し、それに合格するプロダクトコードを書いていくソフトウェア開発手法です。TDDには、品質の高いコードの生成と、バグの早期発見と修正を容易にするなどの利点があり、信頼性の高いソフトウェアの開発に貢献します。 探索的テスト 探索的テストは、テスターが自身の経験と直感に基づきテストを進める方法です。予定されていたテストケースに捉われず、リアルタイムでテスト設計と実行が行われます。これにより、従来のテストでは見逃されがちなバグを発見することが可能となります。 上記のアプローチは、ウォーターフォールテストにおいても活用することは可能ですが、アジャイルテストにおいては、より親和性が高いとされ、多くのプロジェクトで採用されています。 アジャイルテストの4象限 アジャイルテストの4象限は、特定のテスト活動がプロジェクトにおいて何を目指し、どのような視点で行うべきかを明示するフレームワークです。以下の4つの象限が存在します。 象限1 – （技術面・開発チーム支援に焦点） ユニットテストやコンポーネントテストなどのコードレベルのテストが含まれます。これらは主に開発者が行い、ソフトウェアの基本的な機能性と内部の品質を確認します。 象限2 – （ビジネス面・開発チーム支援に焦点） この象限には一般的に機能テスト（手動/自動）、ストーリーテスト、プロトタイプ作成などが含まれます。これはビジネスエキスパートが行い、システムがビジネス要件を適切に満たすかを判定します。 象限3 – （ビジネス面・プロダクト批評に焦点） ユーザー受け入れテスト（UAT）、探索的テスト、ユーザビリティテストなどが含まれます。これらのテストはエンドユーザーやステークホルダーが行うこともあり、システムがユーザーの期待に照らして適切に動作するかを評価します。 象限4 – （技術面・プロダクト批評に焦点） この象限ではパフォーマンス、負荷、セキュリティ、互換性などをテストします。これにより、システムの非機能的な側面を評価し、技術的な限界を確認します。 これらの象限は個別に役割を持ちながら、全体としてソフトウェアの内外の品質を総合的に確保する指標になります。そして、各象限のテストはソフトウェア開発ライフサイクルのそれぞれの部分で実行され、独立していても相互に関連し合っています。 重要なことは、これらの象限が階層的な順序を表すものではなく、すべての象限のテストが全体として協力してソフトウェアの品質を確保するということです。 自動化ツールによるアジャイルテストの効率化 アジャイルテストでは継続的なインテグレーションと高速なフィードバックが求められます。そのため、テストの自動化は、アジャイル開発において非常に重要な要素となります。 自動化による主な利点 速度と効率  テスト自動化ツールは、高頻度で繰り返されるテストケースを迅速に実行する機能を提供します。これにより、テストの実行に費やされる時間が大幅に短縮され、開発チームは早期にデバッグを開始できます。 一貫性と高い精度 自動化ツールはヒューマンエラーを排除し、テストケース間で結果の一貫性を保障します。 リグレッションテストの簡易化 新しいコードを追加または改修するたびに、全体のシステム動作に影響を与えることなく、変更が正しく統合されていることを確認するためには、頻繁にリグレッションテストを行う必要があります。このテストを効率的に実行するために、テストの自動化は有効です。 人気のある自動化ツール Selenium ウェブアプリケーションのテストに広く使用されるオープンソースのツールです。多言語対応しており、複数のブラウザでのテスト実行が可能です。 JUnit Javaで書かれたアプリケーション向けにユニットテストを作成、実行するためのフレームワークです。 TestNG JUnitから派生したテストフレームワークで、テストケースのグループ化、並列実行、テストケースの依存関係の定義など、高度な機能を提供します。 Cucumber BDD（ビヘイビア駆動開発）スタイルのテストを作成、実行するためのツールで、テストケースを自然言語に近い形式で書くことができます。 Jest JavaScriptのテストフレームワークで、スナップショットテスト、モック、統合されたアサーションライブラリなど、豊富な機能を備えています。 上記のようなツールの利用はアジャイルテストにおいて有効ではあるものの、全てのテストケースを自動化するべきだというわけではありません。テスト自動化はコストと時間を必要としますので、高頻度で繰り返し行われるテストや、人間による実行が困難または時間がかかるテストに対して優先的に自動化を検討すべきです。 アジャイル開発におけるテスト駆動開発とは テスト駆動開発（Test Driven Development：TDD）は、まずテストを作成し、それに合格するプロダクトコードを書いていくソフトウェア開発手法です。テストケースを先に作成することで、要件を明確にし、品質を担保しながら効率的な開発を行います。 TDDは以下の繰り返しプロセスで構成されます。 1.「Red」テストの作成 まず、失敗するテストケースを書くことから始めます。このテストはまだ実装されていない機能を対象とするため、初めて実行すると必ず失敗します。この工程は要件を明確に理解していることを確認するためのステップです。テストツールにおいてテストが失敗すると赤色でエラー表示されるため、「レッド」と呼ばれます。 2. 「Green」コードの実装 つぎに、テストを成功させるためのコードを書きます。ここで重要なのは、完璧なコードではなく、設定したテスト条件をクリアする「最小限」のコードを書くことです。 3. 「Refactor」コードの改善 コードがテストに合格したら、コードをリファクタリングして整理し、冗長性を排除します。コードのリファクタリングは、小規模な段階で行うべきです。後回しにすると、プログラムが大きくなるにつれて修正が難しくなります。 このTDDのサイクルは、コードあるいは機能の一部分を書くたびに繰り返されます。これにより、アプリケーション全体が組み上げられます。 TDDでは、開発の初期段階からテストに着目し、コーディングの品質を向上させることを目指します。テストファーストのアプローチによって、開発者は繰り返しコーディングとリファクタリングを行いながらテストを実行します。これにより、開発段階で不具合を早期に検知し修正することが容易になるだけでなく、システムを理解するための手掛かりを提供し、作業における安心感を高めることができます。TDDは近年の短サイクルの開発プロセスにおいて特に有効であり、コーディングの品質向上に貢献する重要な手法として広く認識されています。 参考） テスト駆動開発（TDD）への招待 まとめ アジャイルテストは、ソフトウェア開発プロセスの品質と効率性を改善する強力な手段です。現代のビジネス環境は絶えず変化し続けており、ソフトウェア開発においては柔軟に対応することが不可欠です。迅速なフィードバックを通して、顧客の要求に柔軟に対応するアジャイルテストは、このような状況下で非常に効果的なアプローチとなります。 また、開発チームとテストチームが協力し、テスト駆動開発やテスト自動化、探索的テストなどの先進的な手法を組み合わせることで、生産性や品質、顧客満足度の向上も期待できます。 この記事がアジャイルテスト導入のきっかけとなったり、チーム全体での実践を通じて品質向上と効率化を図る参考になれば幸いです。 The post ソフトウェア開発におけるアジャイルテストとは？ first appeared on Sqripts .

こんにちは！エンジニアのまさです。 最近、会社で利用するためのSlackBotを作成する機会がありました。時間をかけずに簡単に実装する方法を模索し、SlackBoltを利用することにしました。その結果、簡単にSlackBotを実装することができました。今回はその内容を紹介したいと思います。 はじめに Slackは、ビジネスチャットとして広く使われており、多くの企業で導入が進んでいると思います。私の会社でもSlackをコミュニケーションツールとして利用しています。 Slackはそのまま利用してももちろん便利ですが、Slackアプリケーションを作成することで更に便利にSlackを活用することが可能です。Slackアプリケーションの作成というとハードルが高いイメージがあるかもしれませんが、SlackBoltを利用することで、簡単にアプリケーションの作成をおこなうことができます。 Slackアプリケーションでできること Slackアプリケーションには多くの機能があります。以下は、その一例です。 チャットボットの作成 Slackアプリケーションを使用することで、簡単にチャットボットを作成することができます。チャットボットは、簡単なタスクの自動化や、情報の収集、ユーザーとの対話、など多くの用途に利用されます。 スケジュール管理 Slackアプリケーションを使用することで、スケジュールを管理することができます。例えば、チャットボットを使用して、会議のスケジュール調整を行うことができます。 ファイル共有 Slackアプリケーションを使用することで、ファイルの共有が簡単にできます。例えば、Google DriveやDropboxとの連携を行い、ファイルの共有を行うことができます。 通知の送信 Slackアプリケーションを使用することで、通知を送信することができます。例えば、重要なイベントが発生した場合に、Slack上で通知を行うことができます。また、チャットボットを使用して、自動的に通知を送信することもできます。 Slackアプリケーションを作成することで、Slackの利便性を更に高めることができます。 この記事では、特にチャットボットの作成について紹介します。 SlackBoltとは？ SlackBoltは、SlackのAPIを使用して、簡単にSlackアプリケーションを作成することができるフレームワークです。このフレームワークは、特にWebSocketを使用する場合に優れたパフォーマンスを発揮します。 SlackBoltを使うことで、Slackアプリケーションを簡単に開発できます。Slackアプリケーションは、ビジネスチャットとして広く使用され、多くの企業で導入されています。Slackアプリケーションを利用することで、Slackをより便利に活用できるだけでなく、ビジネスプロセスの改善や生産性向上にもつながります。 特に、WebSocketを使用する場合には、SlackBoltのパフォーマンスが優れています。WebSocketは、リアルタイム通信を実現するための技術であり、HTTPよりも高速で効率的です。SlackBoltは、WebSocketを使用して、SlackアプリケーションとSlackのリアルタイムAPIの間で通信を行います。WebSocketを使用することで、Slackアプリケーションは、Slack上のイベントに対してすばやく反応することができます。 この記事では、SlackBolt for PythonのWebSocketを使って、簡単にSlackアプリケーションを作成する方法について説明します。SlackBolt for Pythonのマニュアルは こちら から参照できます。 Slackアプリケーションの登録 まずは作成するSlackアプリケーションの登録を行います。Slackにログインした状態で こちらのページ(slack api) にアクセスし、ページ上部の「 Your Apps 」をクリックします。 アプリケーションの編集画面に遷移するので「 Create New App 」をクリックします。 作成するアプリケーションのタイプを選択します。シンプルにアプリケーションを作成する場合は「 From scratch 」、YAML等でmanifestを指定する場合は「 From an app manifest 」を選択します。 次にアプリケーション名の設定とこのアプリケーションを使用するWorkspaceを選択します。 項目を入力後「 Create App 」を押下することでアプリケーションの登録が完了します。 Slackアプリケーションの構成設定 Slackアプリケーションを作成すると下記の画面からアプリケーションに必要な情報の取得や設定が可能になります。 まずはチャットボットアプリケーションを作成するために必要な情報を取得するため、左サイドバーの「 OAuth & Permissions 」をクリックし、「 Bot Token Scopes 」セクションまで下にスクロールします。 「 Add an OAuth Scope 」をクリックし、「 chat:write 」というスコープを追加します。 スコープ追加後にページ最上部の「 Install App to Workspace 」をクリックします。 アプリケーションのインストールが完了するとOAuth&Permissions画面から「 Bot User OAuth Access Token 」を確認できるようになります。これは後で実際にアプリケーションを作成する際に必要になりますのでメモ等に保存しておきましょう。 「 Basic Information 」のページを開き、「 App-Level Tokens 」の「 Generate Token and Scopes 」をクリックしてトークンを作成します。このトークンに「 connections:write 」のスコープを追加します。ここで作成されたトークンも後ほどアプリケーションを作成する際に必要になりますので控えておいてください。 左サイドメニューの「 Socket Mode 」を選択し、「 Enable Socket Mode 」を有効にします。 ここまででアプリケーションの構成の設定は完了です。 チャットボットアプリケーションの実装 登録したアプリケーションの実体となるpythonアプリケーションを実装します。 WebSocketアプリケーションのクライアント実装となるので、インターネットに接続可能なPC上でpythonアプリケーション実装することで動作させることが可能です。サーバーアプリケーションではないのでドメインを取得したりする必要はありません。 アプリケーションの実装は以下のようになります。 import re import os from slack_bolt import App from slack_bolt.adapter.socket_mode import SocketModeHandler # BotTokenの設定 app = App(token=os.getenv("SLACK_BOT_TOKEN")) @app.message(re.compile(r"^!bot ((.|\\s)*)$")) def handle_message(message, say, context): # ユーザー名を取得 user = message['user'] # 会話メッセージを取得 talk = context["matches"][0] # メッセージを投稿 say(f"こんにちは! <@{user}>さん、あなたの会話内容は'" + talk + "'です") # アプリケーションの実行 if __name__ == "__main__": SocketModeHandler(app, os.getenv("SLACK_APP_TOKEN")).start() このプログラムを見ていただけるとわかるとおり、先ほどのSlackアプリケーション設定時に取得したトークンを2つ設定しています。 一つがOAuth&Permissions画面で取得した「 Bot User OAuth Access Token 」です。もう一つは「 Basic Information 」のページで取得した、「 App-Level Tokens 」になります。 プログラムを実行する際は環境変数「 SLACK_BOT_TOKEN 」に「 Bot User OAuth Access Token 」を、「 SLACK_APP_TOKEN 」に「 App-Level Tokens 」を設定します。 export **SLACK_BOT_TOKEN=xoxb-XXXXXXXXXXX export SLACK_APP_TOKEN=xapp-XXXXXXXXXXX** プログラムは以下のようにして起動します。 python app.py プログラム起動後、Slack側で登録したアプリケーションをチャンネルに追加します。 当該チャンネルで以下のようにメッセージを送信します。 !bot テストメッセージ このメッセージにボットが反応し「こんにちは！@XXXXXさん、あなたの会話内容は’テストメッセージ’です」とメッセージが投稿されます。 以上でSlackのチャットボットアプリケーションの実装は完了です！ おわりに いかがでしたでしょうか？ 今回のサンプルのチャットボットアプリケーションでは、ユーザーから受け取ったメッセージをそのまま返すだけでした。そのため、業務を大きく効率化するものではありませんでした。しかし、受け取ったメッセージから様々な処理を行うように調整することで、業務を効率化するアプリケーションを作成することが可能です。 実際に運用する際には、アプリケーションを起動しておくための環境が必要になると思います。しかし、サーバーアプリケーションではないため、環境の選択の幅が広がると思います。Slackを利用している方は、Slackアプリケーションの活用を検討してみることをおすすめします。 The post SlackBoltのWebSocketを使った簡単なSlackアプリケーション作成のススメ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第7回目のテーマは、「スクラムチームメンバーの責任」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 スクラムマスターの責任 スクラムマスターのメインの仕事は支援です。 スクラムガイド を見ると、スクラムマスターが支援する内容がたくさん並んでいます。 ⾃⼰管理型で機能横断型のチームメンバーをコーチする スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する スクラムチームの進捗を妨げる障害物を排除するように働きかける すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする これらはスクラムチームに対する支援内容の一覧です。これがPOや組織に対しても続きます。まずはPO。 効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう 複雑な環境での経験的なプロダクト計画の策定を⽀援する 必要に応じてステークホルダーとのコラボレーションを促進する 次に組織。 組織へのスクラムの導⼊を指導・トレーニング・コーチする 組織においてスクラムの実施⽅法を計画・助⾔する 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう ステークホルダーとスクラムチームの間の障壁を取り除く やることがたくさんあるので、筆者が顧客に説明するときは、これらの動詞部分を並べて伝えます。 コーチする ⽀援する 働きかける 守られるようにする ⽀援する 理解してもらう ⽀援する 促進する 指導・トレーニング・コーチする 計画・助⾔する 理解・実施してもらう 取り除く このように、スクラムマスターは色んな方向でいろんな支援を行います。ただ、スクラムマスターは支援するだけなので、実務はスクラムチームがやります。 よって、スクラムマスターはチームができることはやらないけど、チームができないことをやるのが仕事といえます。 プロダクトオーナー責任 POの責任 プロダクトオーナーは、POと呼ばれます。POの責任を見ていきましょう。 まず、プロダクトゴールを策定し、明示的に伝えることです。プロダクト自体のゴールである、プロダクトゴールを策定し、開発チームやステークホルダーに明示的に伝えていきます。 現実の開発では、プロダクトゴールとは別に、プロダクトのロードマップであったり、プロダクトのマイルストーンのような中長期的な計画も作り上げていく必要があります。プロダクトオーナーは、短い期間であるスプリントだけでなく、プロダクト全体、四半期、半期、年次・・・というように高い視点を持つ必要があります。 次に、プロダクトバックログアイテムの作成、優先順位付けです。プロダクトバックログアイテムは、ユーザーストーリーと呼ばれる形になっていることが多いです。もしくは機能であったり、フィーチャとよばれることもあります。 プロダクトバックログアイテムは、ビジネス側の人間も関心があるものです。よって、そのビジネスの専門用語やドメイン知識が入り込んでいるかもしれません。もちろん、スクラムチームはそれらを学んでいきますが、開発するためには、だれでも理解できる言語や表現でまとめていく必要があります。 技術的な情報がプロダクトバックログアイテムの完成に必要になるかもしれません。その場合は、開発者に手伝ってもらいながら完成します。 プロダクトバックログアイテムを積み重ねていくと、プロダクトバックログになります。 プロダクトバックログの管理はPOのもっとも重要な役割とも言えます。これがきちんとできていなければ、間違ったものを、間違った優先順位で開発しなければなりません。 開発者の責任 最後に開発者の責任を見ていきましょう。 開発者はスプリントごとの計画の作成に責任を持ちます。計画はPOやスクラムマスターも交えながら作り上げていきます。開発者はスプリントバックログの作成に積極的にかかわります。スプリントバックログは、チーム全体で責任を持つものです。 次に、完成の定義を守ります。完成の定義は完了の定義とも呼ばれています。開発者は、なにかを完成させる上で「これが満たされれば完了」という基準を作り、その基準を厳守します。 そして、毎日計画を適応させ、スプリントごとのゴールであるスプリントゴールを目指します。適応はスクラムの三本柱にも登場しました。スプリントゴールとは、スプリントごとに立てるゴールです。ゴールがないと、スプリント自体が生み出す価値がぼやけてしまいます。このスプリントで何を成し遂げたいのか？スプリントゴールによって提供する価値の解像度を上げます。 最後はお互いに責任を持つことです。開発者とくくっていますが、スクラムチームにはフロントエンドエンジニアがいたり、バックエンドエンジニアがいたり、QAエンジニアがいたりするかもしれません。それぞれは得意分野が異なるため、異なる部分で責任を持ち合い、スプリントゴールを目指していきます。 スクラムチームが気をつけること スクラムチームは開発をするだけのチームではありません。 POはビジネスと開発の間に立つ通訳者だとしても、通訳だけしていればいいわけではありません。ビジネスや顧客が言うことすべてが正しいとは限らないため、さまざまなフィードバックをもとに、プロダクトとしての判断をしなければならないからです。 また、POと開発者は上下関係でもありません。 だから、開発者たちは「意味はわからないけどとりあえずこれ作ればいいのね」というように、いわれたことをやるマシーンになってはなりません。境界を超えてビジネスやプロダクトにも関心を持つ姿勢が必要です。これはビジネスやPOも同じです。 そして、何事もそうですが、正しさを目指してはいけません。 スクラムがいくら正しくできても、ビジネスやプロダクトがうまくいくとは限らないからです。スクラム、さらにいうとアジャイル開発はとても楽しい開発手法です。だから、大好きすぎて正しさを求め過ぎ、原理主義者に進化してしまう人も多くいます。 チーム内で熱量の差が生まれると、そこからメンバーの間にギャップが生まれてしまう可能性が高まります。熱意は双方向にぶつかって良い方向に向かうものです。熱量をきちんとうけとめ、消化できるチームを目指すといいでしょう。 そして、正しさを目指すよりも、自分たちが成し遂げたいゴールを達成できるかを考えるようになりましょう。 今回はスクラムチームの責任を解説しました。次回はスクラムイベントの具体的な実施方法を解説します。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 The post 第7回 わかるようでわかりにくいスクラムチームの責任 first appeared on Sqripts .

こんにちは。テストオートメーションを担当しているWです。 気が付けば前回自分の担当した[ 記事 ]から約1年ぶりの投稿となりました。 今回は自動テストを実装する上でほぼ避けては通れないXPath/CSSセレクタについて、自動テストの安定性と絡めて話していきたいと思います。 はじめに 近年ではユーザの操作をレコーディングしてテストシナリオを作成できる自動テストツールが増えてきてテスト自動化の間口が広がっているのを感じます。 このような自動テストツールはコードが書けなくても自動テストを作成できることが最大の売りですが、万能という訳ではありません。 レコーディングできても実行時にうまく要素が識別できないということがよくあります。 そのような場合にはXPathやCSSセレクタで要素を指定するということが要求されます。 XPathやCSSセレクタを取得するだけならChromeの開発者ツールから簡単に行うことができますが、それをそのまま自動テストに使ってしまうと自動テストの安定性を著しく低下させることになるかもしれません。 本記事では自動テストでXPath/CSSセレクタを使用するときに気をつけるべき点について、自動テストの安定性の観点から検討していきたいと思います。 またそれに合わせて、XPath/CSSセレクタを取得する際に便利なツールの紹介も行います。 Chromeの開発者ツールによるXPathの取得 CSSセレクタについてはここで話をする範囲ではXPathと記載方法が異なるだけになるので、読み替えて確認していただければと思います。 ここでは例として、株式会社AGESTサイトのトップページの検索ボックスをXPathで指定することを考えたいと思います。 XPath自体はChromeの開発者ツールから以下のように簡単に取得することができます。 ブラウザ上のXPathを取得したい要素を右クリックをして「検証」を選択 開発者ツールでXPathを取得したい要素を右クリックして「コピー」→「XPathをコピー」を選択 上記の手順により検索ボックスのXPathを取得すると以下のような文字列が得られます。 //*[@id="wrapper"]/header/div/div[2]/div[2]/form/input このXPathで検索ボックスを指定できるのですが、XPathの書き方は何通りもあるため、これはその1つにすぎません。 XPathの詳細については他の様々なサイトで解説されているのでここでは全てを説明しませんが、自動テストの安定性という観点からこのXPathについて簡単に見ていきたいと思います。 XPathに含まれる / は階層構造を示す このXPathは7つの要素が / で繋がっているため、7つの要素の階層構造（下図の赤枠）を指定してテキストボックスを指定していることになります。 これを言い換えると、テキストボックス自体に変更が加えられていなくても、その手前の6階層の要素（下図の黄色枠）のどれかが変更されただけでテキストボックスが特定できなくなる可能性があります。 div[2] はその階層における2番目のdiv要素を示す このため、div要素の順番が変わってもテキストボックスが特定できなくなります。 これらのことから、このXPathを自動テストで使用すると自動テストの安定性が著しく低くなってしまう事が容易に想像できると思います。 安定性の高いXPathとは？ 先に述べたことを踏まえると、自動テストの安定性を高く保つには以下の点に気をつけてXPathを記述しなければなりません。 / を減らす（＝階層構造の指定を避ける） [n] を減らす（＝順番の指定を避ける） しかしながら、テスト自動化をやり始めたばかりでXPathについてあまり理解していない人がこのようなXPathを書くのは難しいと思います。 そこで、私も実際に使用している便利なXPath/CSSセレクタ自動生成ツールを紹介したいと思います。 POM Builder 私がお勧めするXPath/CSSセレクタ自動生成ツールは、[ POM Builder ]です。 これは、LogiGear社が提供するブラウザの拡張機能でChromeとEdgeに対応しています。 インストール方法（Chrome） [ POM Builder公式サイト ]へアクセス 「Add to Chrome」を選択 chromeウェブストアが開くので、「Chromeに追加」を選択 以下のポップアップが表示される場合は「拡張機能を追加」を選択 使用方法 ブラウザ上を右クリックをして「検証」を選択 「要素」内のタブから「POM Builder」を選択 この時、幅が狭いと折りたたまれているので「>>」をクリックして展開する 開発者ツール上でXPathを取得したい要素を選択する 上記の手順で任意の要素のXPathやCSSセレクタの取得が可能になります。 Recommended Locatorには最適なロケータを提示してくれるので、Selenium等でコードをガリガリ書く際にも有用です。 またLOCATOR TESTの欄にXPathやCSSセレクタを入力して検索をすると、そのページ内に該当する要素が何個あるのか表示してくれるので、自分でカスタマイズしたXPathの確認も行うことができます。 ここで株式会社AGESTサイトのトップページの検索ボックスのXPathをPOM Builderで取得してみましょう。 //input[@name='s'] どうでしょうか。 開発者ツールから取得したXPathと比べると、階層構造の指定や順番の指定が全く入っておらず、非常にすっきりとしたXPathが取得できました。 このXPathであればname属性の値さえ変えられない限りテキストボックスを検出することができます。 検索ボタンのXPathも比較してみましょう。 開発者ツール：//*[@id="wrapper"]/header/div/div[2]/div[2]/form/button POM Builder：//button[@class='search-submit'] こちらもPOM Builderによって生成されたXPathの方が階層や順番の指定がなく、自動テストの安定性が維持できるものとなっています。 もう一つ、ソリューション・サービス画面の「AQアジャイル品質/QA品質保証」セクションの要素を見てみましょう。 開発者ツール：//*[@id="qa"] POM Builder：//section[@id='qa'] これを自動テストの安定性という視点で考えてみると、どちらもIDの指定をしていますが、POM Builderはタグの種類もsectionに指定しています。 その点、開発者ツールのXPathはタグの種類については指定していません。 この要素についてはタグの種類を変更されても要素を特定できる開発者ツールのXPathの方が安定性が高いようです。 いくつかの要素について具体的にXPathを比較してみましたが、多くの場合においてPOM Builderが安定性の高いXPathを生成してくれることがわかったかと思います。 ただしPOM Builderも万能というわけではないので、開発者ツールとPOM BuilderのXPathを比較して、安定性の高い方を採用するというやり方がおすすめです。 まとめ 自動テストの安定性が高くなるXPathについて考察をしました。 安定性の高いXPath/CSSセレクタの自動生成ツールのPOM Builderを紹介しました。 POM Builderを使用して安定性の高いXPath/CSSセレクタを取得する方法について紹介しました。 自動テストの安定性を高めて、保守の負担が少ない自動テストライフを過ごしていきましょう！ The post 自動テストの安定性からXPath_CSSセレクタについて考える first appeared on Sqripts .