この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第9回目のテーマは、「エクストリーム・プログラミング（XP）」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 価値・原則・プラクティス XPの話をする前に、価値・原則・プラクティスを解説します。スクラムやXPのように、世の中にはさまざまな開発手法がありますが、それぞれの手法には価値・原則・プラクティスが定義されてるケースが多いです。これらがどういった意味を持つのかを見ていきましょう。 まず、価値とは、「何を考え、何を行うのかを判断するのに使用する基準」です。開発手法が持つ価値観なので、開発手法が大切にしていることが価値としてまとめられています。この価値があることで、開発手法を利用する人は、「自分たちは、この開発手法の価値を満たしているだろうか？」と判断ができます。 価値はふんわりした言葉になるので、じゃ、どうやったらその価値を実現できるのか？がわかりにくいと思います。たとえば、アジャイルマニフェストの一例をあげると、「個人と対話を」という価値がありますが、これをどう実現すればいいか？ これだけではそこまでわかりません。 また、価値だけだと間違った判断になってしまう可能性があります。たとえば、アジャイルマニフェストだとコミュニケーションに価値を置いてますが、「コミュニケーションを重視したいから1000ページのドキュメントを書こう！」となると、ドキュメント作成に時間がかかりすぎて、アジャイルな開発とは言えません。そこで登場するのが原則です。 原則は、価値とプラクティスを支える橋のような存在です。原則は、「具体的な指針」なので、具体的に何をすればいいかわかりやすいものになっています。 アジャイルマニフェストの原則を見てみると「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というのもあります。この原則を守って、価値を実現していこうというものです。 先程の例にでてきた「1000ページのドキュメントを書こう！」の場合、「フェイス・トゥ・フェイスで話をする」や「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」という原則にマッチしません。マッチしないので、価値を満たさない可能性のあるアクションだと気がつけます。 プラクティスは、価値へと向かう原則をより具体的にしたものです。アジャイルプラクティスとも呼ばれます。プラクティスには「実行」、「練習」、「習慣」という意味があり、アジャイル開発だと「アジャイルになるための習慣」という表現がふさわしいかもしれません。アジャイルプラクティスをやればアジャイル開発になる！とはかぎりませんが、少なくとも価値へと続く橋のような存在になります エクストリーム・プログラミング XPの考案者のケント・ベックさんは、Javaエンジニアであれば誰もが知っているであろうテストフレームワーク「JUnit」を開発したひとりです。 XPは、価値・原則・プラクティスに分かれて解説されています。XPは、コミュニケーションやチーム運営だけでなく、具体的なエンジニアリングプラクティスが揃っているので、開発者の方であれば共感しやすい内容にもなっています。ただ、エクストリームとあるだけあり、極端なプラクティスも多く、ペアプログラミングなど、賛否両論を呼ぶプラクティスも多数あります。 XPを解説した書籍は、第1版が出た5年後に第2版が登場しました。第2版は内容も修正・追記されています。副題も変わっており、第1版では「ソフトウェア開発の究極の手法」だったのが「変化を受け入れる」になっています。ここでは、手元にあるエクストリーム・プログラミング第2版『 XPエクストリーム・プログラミング入門―変化を受け入れる 』を使って説明しています。 まずは、XPの価値を順に見ていきましょう。XPの価値は5つあります。 XPの価値 XPの価値： コミュニケーション ひとつ目の価値は「コミュニケーション」です。書籍では「もっとも重要」とされています。 XPの生みの親であるケント・ベックさんが、実際の仕事において、顧客とのやりとりがうまくいかず失敗するプロジェクトを多く見てきたため、コミュニケーションをもっとも重要視するようになったという逸話もあります。 XPに限らず、アジャイル開発全般において、チームの意識を高め、効率的な協力関係を生み出すためには、コミュニケーションは必須の価値とも言えます。 XPの価値：シンプルさ 2つ目は「シンプルさ」です。 シンプルさは、開発するシステムであったり、問題や課題の解決策であったり、さまざまなものに適用できる価値観です。私自身も、若手エンジニアを育成するときは、「140文字以内で報告をしてみよう」とか「これがもっともシンプルな方法だろうか？」といった話を意識してしています。 もちろん、複雑なシステムも必要でしょうが、開発活動も開発するシステムも、コミュニケーション方法も、できるだけシンプルな方が、よいシステムに近づけるように思います。 XPの価値： フィードバック 3つ目は「フィードバック」です。 完璧なシステムを開発するのはとても難しいことです。たとえ、完璧になったとしても、時間の流れや世の中の変化によって、それもすぐ不完全になってしまいます。 ただ、完璧を目指していく姿勢はとても大切です。自分の力だけで完璧になれればよいですが、フィードバックがあればよりはやく完璧に近づけるでしょう。十分な改善を行うためには、さまざまなところからやってくるフィードバックが重要になります。 また、アジャイル開発に取り組むのであれば、フィードバックに慣れておくのも必要だと思います。たとえば、コミュニケーションを重視するアジャイル開発では、フィードバックをもらうだけでなく、あなたからもフィードバックを与えるケースが多くなるはずです。よいフィードバックをする習慣を身に着けておくと良いでしょう。 そして、フィードバックにはポジティブなものもあれば、ネガティブなものもあります。ネガティブな場合でも、どうすればよくなるのか？ ポジティブに相手とコミュニケーションを取っていく必要があります。 ネガティブなフィードバックは、誰もがすぐに受け入れられるものではないでしょう。相手を気遣って本当のフィードバックを避けてしまう気持ちもわかります。 しかし、将来の宝になるかもしれないフィードバックが与えられない、受け取れない環境は健康的な環境とは言えません。ネガティブな内容であっても、チームで話せる、話し合える、そういうチームを目指してみてはどうかと思います。 XPの価値： 勇気 4つ目は「勇気」です。 フィードバックでも書きましたが、真実を伝える勇気、新しい解決策を探す勇気など、開発のなかで様々な勇気が求められます。ふりかえりでも勇気を持ったチャレンジを考えていきます。 アジャイル開発では、どんどん変化を受け入れていくため、勇気を持った対応がとても重要です。そうでなければ、新しいチャレンジができなかったり、できることだけやってしまったりして、その結果、改善が進まなくなり、「なんだかうまくいかない」となってしまうでしょう。 個人的には、やりなおせるものであればどんどんチャレンジしてほしいと思いますが、どれだけ心配であっても、作業全体の20％ぐらいはチャレンジを入れていかないと、現場が良くなっていく体感が得られにくいのではないかと思います。 XPの価値： 尊重 最後は「尊重」です。 書籍には、「これまでの4つの価値の背後にあるのが尊重」とあります。続けると「ソフトウェア開発で人間性と生産性を同時に改善するには、チームにおける個人の貢献が尊重されるべき」と書かれています。 アジャイル開発では、コミュニケーションを重視します。コミュニケーションはひとりではできないものです。相手に対する尊重であったり、敬意であったり、よいコミュニケーションに必要な価値は、アジャイル開発でなくとも持っておきたいものだと思います。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 The post 第9回 エクストリーム・プログラミングとその価値 first appeared on Sqripts .

こんにちは、QAコンサルタントのツマミです。 唐突過ぎますが私ツマミ、JIS（日本産業規格：Japanese Industrial Standards）が大好きです。 お客様のプロダクト品質やプロセス品質の課題に対して何か基準は無いか、定義や分類法は無いかと探ると何かしらのJISに行き当たるのは本当にすごいことだと思います。そんなJISのいずれかの制定に絡んでいればもっと学術的な話や裏話の一つもできたかもしれませんが、そこはあくまで利用者側のツマミ、JISの一つひとつを道に例えて、こんなことが(書いて)あったよ、こんなことを見つけたよといったことをお気楽な道行のごとく書き連ねて参りたいと思います。 さて、初めてのさんぽは JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 。ゆるゆると楽しんでまいりたいと思います。 どうぞ皆さま、ちょっとした気分転換としてこのJISさんぽにお気楽にお付き合いの程、よしなに願い奉ります。 今回のJIS JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 とは この規格はツマミがAGESTで担当している「UI/UX向上支援サービス」と深いかかわりがあります。表題にあるように、人とシステム（サービスであったり、プロダクトであったり）との間でのやりとり(インタラクション)がどうあればよいかについて、原則が具体的かつ豊富な事例を添えてまとめられています。 インタラクション(Interaction)：相互作用，相互の影響 Weblio英和辞典 なぜ、このJISを選んだのか 「新しくて」「例が豊富で」「カテゴリ分類が手ごろ」と三拍子揃っているので、ユーザビリティを評価する際に使いやすい点が「UIやUXを検討しよう」という方にとって役立つと思ったからです。 「新しい」本JISは改訂が2022年です。一つ前の版でも2008年改訂なので新しい見解が盛り込まれていることが期待できます。 「例が豊富」後で詳しく述べたいと思いますがなんと141もの例が示されています。 「カテゴリ分類が手ごろ」レーダーチャートにした時に形の違いが分かりやすい7カテゴリという所が買いだと思っています。 道行 まえがき、序文 まえがきは8行。前半で「一般社団法人人間工学会」と「一般財団法人日本規格協会」が原案を出したと記載されています。それとJIS Z 8520:2008からの改訂であること。後半4行で示されている「この規格が著作権法で保護対象になっている云々」は重要なことですがどのJISでも記載されているはずなので、実質前半の4行がこの規格の前書きといってよいですよね。 あっさりしたまえがきと本文における豊富な例との対比にちょっとグッと来てしまいます。 1章　適用範囲 「安全を重視するシステム、共同作業、人工知能などの一部の応用技術には適用しない」ものの、それ以外の全てのインタラクティブシステムに適用可能と書いてあることからも分かるとおり、かなり適用範囲の広い規格です。 また、対象（利用者）も要求仕様に関係するエンジニアやUI関係の設計者、評価者だけでなく使いやすい製品を調達しようとする購入担当者も使えるということが書いてあります。 確かに、インタラクティブシステムを使いやすくしようと思う方や、使いやすさを何らかの形で評価する方に使っていただきたい規格です。 2章　引用規格 「この規格には、引用規格は無い」と記載されています。つまりこの規格単独で利用することが出来るわけで、本文の豊富な例も相まってUI/UX教育に使いやすいのではないでしょうか。 3章　用語及び定義 ここでは11の用語が定義されています。ツマミが特に着目したのは3.8項で定義されている「ユーザ」についてUI/UX評価での解釈を明確にするために、3.8A「ユーザエンゲージメント」を追加し、より詳細に定義されている点（この定義を含めると12個の用語が定義されていることになります）。 「エンゲージメント」は英語では一般用語だそうですが、日本語だと「婚約」の意味がまだ強く、ここで定義されている「インタラクティブシステムがユーザとシステムとのインタラクションの継続を促し、動機付けるような機能及び情報を提供すること」という意味はしっくりこないような気がします。 ただ、この「ユーザエンゲージメント」の考え方が盛り込まれていることによって、この規格がUX(ユーザエクスペリエンス)の設計や評価にも使えるようになっているので、わざわざ用語として定義されているのはこの規格の良い点の一つだと思っています。 その他、「アクセシビリティ」「利用状況」「ユーザビリティ」「ユーザエクスペリエンス」「ユーザインタフェース」などUI/UX教育で押さえておきたい用語が定義されています。 4章　インタラクションの原則 概要に7つの原則が記載されているのですが、ここに”7”という数字を持ってくることに「規定自体を分かりやすくしよう」という心意気を感じてしまうのはツマミだけでしょうか。 ここには7つの原則について概要が記載されており、また原則に含まれる主な推奨事項が表になっていますが、やはり概要だけで理解するのは少々厳しい。是非、5章の「原則及び推奨事項」を読んでいただきたいところです。 この4章の一番の読みどころは「推奨事項を一つしか適用しない場合，原則を完全に満たしたことにはならない」と「設計推奨事項を分類することよりも，それらの意味を理解して利用することの方が重要」のどちらかなのではと思います。学ぶ立場で読むと後者の「理解して利用することの方が重要」に目が行きがちですし、もちろん大切な考え方です。しかしながら前者が意味するところの「一つ適用できたからと言って改善できた！とはならない」というUI/UX改善時の注意点は、肝に銘じておきたいところです。 また、4章には、JIS Z 8530 で示される「人間中心設計」との関係が記載されていますが、ツマミには規定していることが違うということだけ伝わってきて、もう少しかみ砕いて記述されていると嬉しかったなぁと思ってしまいます。要は使いやすいインタラクティブな製品やサービスとはどういったものか、どのような特徴を備えているのかを示しているのがこのJIS8520、他方JIS8530は使いやすいインタラクティブな製品やサービスを作る際の作り方やプロセスがどうあればよいのかを示しているのだと理解しました。 5章　原則及び推奨事項 この章では7つの原則についての説明が記されています。 パッと見ると文章量に圧倒されそうになりますが、7つの原則それぞれが「原則(節題)－原則の説明ー注記－補則/細則ー補則/細則の説明－事例」という構成になっていることを予め知っておくと、とても理解しやすく記載されていることが分かります。 そのまま引用すると著作権に触れてしまいますから、例えば5.1節をツマミが理解した範囲でかみ砕きますと、まず節題として「5.1 ユーザーが行うタスクへの適合性」が記載されています。 続いて、この原則の説明が述べられます。5.1節の場合、「手段と目的を取り違えないように、手段が凄くなくてもユーザーが目的を達成できることが重要です」といったようなことが書かれているわけです。 そして、この説明に対して注記が記載されています。「達成する目的自体もユーザーニーズに沿ったものでないと駄目ですよ」「手段も奇をてらったものではなく、何がしたいかの本質に沿った手段を選びましょう」といった原則の説明をきちんと理解するためのアドバイスが注記として記載されている訳です。文章が延々と続くとつい本文だけ拾い読みしてしまいたくなりますが、是非、注記も読み込んで欲しいですし、その価値があります。 更に、原則をもう少し具体的にした補則、細則的な項目が述べられ、続く各項でこれらの補則、細則について詳しい説明と例が示されます。例えば5.1節の場合、3項目が挙げられていますが、3つ目の項目では「ユーザーが入力したり決定したりしやすいように予め適切な設定をしておきましょう」というようなことが書かれている訳です。そしてこの項目を実現するための推奨事項が複数点挙げられ、更に推奨事項を理解しやすくするために実施例がほぼ全項目2点以上挙げられています。 このように7つの原則が複数の項目に詳細化され、各々に例が複数示されるため、全部で141点もの例が掲載されるに至るわけです。 しかも、この例が工夫されていて、異なったインタラクティブシステムや別手段による対応策について述べられているので異なる観点から原則について考えることができます。推奨事項を「～は実現できているか？」といった形でチェック項目にし、例のいずれかを自分たちのサービスや製品に当てはめた書き方にするだけでかなり使えるチェックリストが出来ると思われます。 附属書A(参考)　この規格の推奨事項を適用するためのチェックリスト 前項で「かなり使えるチェックリストが出来ると思われます」と書かせていただきましたが、なんと本JISにはすでに付録としてこのチェックリストがついています。それが「この規格の推奨事項を適用するためのチェックリスト」です。 このページをコピーするだけでチェックリストとして使えます。ただし、例は掲載されていません。ツマミとしては、例を是非ご自身のサービスや製品に適した事例に書き換えていただいてチェック項目に追加することをお勧めします。事例を考えることが自身の勉強にもなりますし、チェックリストを利用する方に対して適切な利用に関するハードルを下げる事にもつながります。 参考文献 本JISを策定するための参考文献となった33点の資料が並んでいます。もし、本JISに触れて更に色々と知りたいとなったならこれらの資料にも是非あたってみてください。 JIS Z 8530「人間工学－人とシステムとのインタラクション－インタラクティブシステムの人間中心設計」はいつかこのJISさんぽでも取り上げたいと考えております。 附属書JA(参考)　JISと対応国際規格との対比表 本JISとISO9241-110:2020との対比が一覧表となっています。大きく2点が追加となっていて、1点目は「ユーザーエンゲージメント」、定義が追加されています。 2点目は「自己記述性」、分かりづらいから「インタラクティブシステムの自己記述性」としたと書いてあるのですが、まだわかりづらいかもしれません。 インタラクティブシステム＝自己なんですよね。インタラクティブシステムが今どうなっているのか、期待する結果を得るためにはどうすればよいのか、といったことをインタラクティブシステム自身がユーザーに分かりやすく情報提供しているかといったことなのですが、「記述性」という言葉が案外難しい。自己記述性に関する問題に気づきやすいよう、指摘しやすいよう例を読み込んで言葉の意味を説明できるようにしておかないと今後手こずりそうな気がします。 以上がJIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」となります。 今日見つけた宝物： 「代替テキスト 」 このJISの4章に図が示されている ※1 のですが、この図について「代替テキスト ※2 」が記載されていました。 音読アプリを使えばどんな図が記載されているか分かるようになっている点はアクセシビリティに関する規定として「あらまほしきことなり（望ましい、理想的である）」と感じました。 JISは登録すれば無料で閲覧できるPDFファイルが提供されていますが、同様に音声ファイルも提供されています。代替テキストがあれば音声ファイル利用者も使い勝手が良いですよね。 ※1：参照文献の図1：ユーザーシステムインストラクションのための指針に関する主要な情報源の関係 ※2：代替テキスト　画像をテキストによって説明したもの 最後までお付き合いくださりありがとうございます。本日の道行きはいかがでしたでしょうか。次のさんぽはJIS Z 8522「人間工学－人とシステムとのインタラクション－情報提示の原則」を予定しております。次回またご一緒できることを楽しみにしております。 参照： JIS Z 8520 インタラクションの原則 The post JISさんぽ (01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 first appeared on Sqripts .

こんにちは。チュンです。 オンラインで開催されたソフトウェア品質シンポジウム2023の本会議に参加してきました。 複数の講演や発表を聴講しましたが、基調講演と当社社員が登壇した発表についてご紹介します。 参考までに、 昨年の参加レポート です。※参加レポート内のソフトウェア品質シンポジウム2022の公式サイトは、 こちら に変更されています ソフトウェア品質シンポジウムとは ソフトウェア品質シンポジウム とは、1981年から開催されている日本科学技術連盟主催の歴史あるシンポジウムです。 今年で42回目を迎え、本会議前日の9/6に（今回は9/2(土)も）併設チュートリアルが開催され、本会議が9/7〜9/8の2日間で行われました。本会議1日目の終了後には、本会議Special Talk Session (STS)も行われました。 本会議レポート 基調講演について 今回の基調講演は 狩野 紀昭先生の「Kano Modelから品質について学ぶ！」でした。 狩野先生の講演を直接聴講できる貴重な機会です。 品質の概念として学習したことはありましたが、聴講前におさらいをと思い、ChatGPTで「狩野モデル」で確認してみたところ、ほしい回答が得られず…。 「Kano Model」で確認してみると難なく回答が得られました。まさに世界的な「Kano Model」であることを実感した次第です。 「Kano Model」の誕生 「Kano Model」の誕生について、狩野先生のこどもの頃の品質の思い出から始まり、「魅力的品質と当り前品質」の論文が学会誌に掲載されたところまでを語ってくださいました。 研究のきっかけとなったのは、 こども時代からの期待である「すぐに壊れる玩具を作らない」（よい品質とは壊れにくいものという期待をもって育った） 「品質不良の低減」 これらが、学生時代に学んだ「消費者を満足させるという品質」と同じであるということにギャップがあった、というところからだそうです。 「消費者を満足させるという品質」は、品質不良を低減するなどというだけでは十分ではなく、『「不満をもたらす品質」と「満足を与える品質」は異なる』という漠然とした考えから始まったとのことでした。 その後、ハーズバーグの動機付け・衛生理論に出会い、疑問を解明できるかもしれない、ということから研究を進めて論文を提出したそうです。 …が、品質管理分野以外の文献調査が不足しているとの理由で却下されたことがあるとのこと。 他の分野には明るくなかったようですが、研究室でアルバイトをしていた方から哲学者のアリストテレスにたどりつき、最終的に論文が認められるに至ったとのことでした。 そのアリストテレスが「形而上学」で主張していた質についての内容から、「品質とは、ある事物に関して２つの品種が存在する時、それらの種差を指す」ということを、アリストテレスの品質論として説明してくださいました。 魅力品質のライフサイクル Kano Modelの特徴として、品質要素を二次元で図式化していることがあげられます。 各品質要素を図解すると以下のようになります。 一元品質：ないと不満、あれば満足なもの 当り前品質：ないと不満、あっても満足とならないもの 魅力品質：なくても不満にはならないが、あると満足なもの 無関心品質：あってもなくても不満にも満足にもならない。関心がないもの 魅力品質理論図解 この魅力品質理論ですが、多くは「無関心品質」として生まれてそのまま終わってしまうことが多いようです。 ただ、その「無関心品質」の一部は「魅力品質」となり、さらにその「魅力品質」が「一元品質」に、いずれはそれが「当り前品質」になる、というようなライフサイクルがあります。 この魅力品質のライフサイクルについて、狩野先生が大学で講義していた時代に、他の品質関連に関する内容と比較すると学生の理解力に問題があったそうです。 狩野先生は学生が理解できないのは教える側が悪い、として、どうやったら理解が深まるのかについて、「MaryとJohnの恋の物語」として二人の恋の変化に例えて解説するようにしたところ、学生の理解力が大幅に上がったとのことでした。 それまでとは異なる雰囲気の資料で驚きましたが、確かにこれならわかりやすい、と感じました。 余談ですが、自分も教える側になることがあります。 なかなか理解してもらえない、と思うこともありますが、教える側が悪い！と断言された狩野先生のことばにグサッときました。 教える側として改善しなければいけないですね。 競合優位としての品質の歴史的変化 競合優位としての品質は歴史的に変化しているという、品質の3レベルについてのお話もありました。 第1レベル：品質統制（顧客苦情解消、製品の基本的要件への適合） 第2レベル：品質管理（顧客満足、顧客の明示要求の実現） 第3レベル：魅力品質創造（顧客歓喜、顧客の潜在要求の実現） 第2レベルが出てくると第1レベルは当たり前になる、というように、品質競争は変化するというお話でした。 品質は第1レベルから第2レベルへ発展し、さらには第3レベルとなるように発展してきたとのことです。 これらの話の中で、突如「BFの3レベル論」という資料が提示されたのですが、BFって？と思っていたら、「BoyFriend」のことでした。 品質3レベル論をいろいろな3レベルに例えるようにレポートを書かせた際、学生が考えた場合の例として提示されていたものです。 このようにくすっと笑ってしまうような内容が講演中のところどころに含まれており、狩野先生の人柄が垣間見えたようでした。 まとめ（業務における「品質」を考えてみた） ご紹介しきれていない内容もありますが、基調講演では全体的にハードウェアを前提としてお話しされていました。 基調講演後には「ソフトウェア、サービスにおける魅力的品質とは？」というパネルディスカッションもあったのですが（こちらはSNS禁止のため割愛）、ソフトウェアやサービスにも大きく関連する内容です。 別の一般発表や講演で、狩野先生のお話を引き合いに出されている方も複数いらっしゃいました。 論文発表当初から時間は経過していますが、現時点でも色褪せずマーケティングの場でも活用されていることなどを考えると、狩野先生から直接お話を聴けたことは本当に貴重でした。 自分自身は、テスト業務を担当しています。 お客様が開発した製品に対するテストの依頼を受け、テストを担当することが多いです。 品質管理として「品質不良の低減」のための業務であり、「不満をもたらす品質」にあたるものだと考えます。 そのため、今回のお話のメインである「魅力品質」を意識して業務することはほとんどありませんでした。 今回のお話を聴いて、少し視点を変えてみました。 そもそも、お客様から依頼されている「ソフトウェアテスト業務」そのものの品質を考えてみると、お客様からの期待や要望という意味では、この「魅力品質」に関連するのではないかと。 お客様から依頼されたテスト業務そのものに対して、最低限の成果を出すということは「当り前品質」であり、期待に対して成果を出すことが「一元品質」にあたるのかなと思いました。 お客様との会話の中から潜在的な要求を読み解くことができ、それらに対応することができれば、それは「魅力品質」になるのではないのかと。 長期間担当する場合には、ライフサイクルとして変化することもありそうです。 業務に対する姿勢として、「当り前品質」をこなすことはもちろんですが、一元品質や魅力品質にも対応できるようになるため、日々精進していく必要があると感じました。 ※注：本文内の表記について、論文名やパネルディスカッションの名称は「魅力的品質」、その他は講演中の資料に提示されていた「魅力品質」としています。 林 尚平さんの発表について 本会議2日目には、当社社員の林 尚平さんによる経験発表がありました。 発表のテーマは、 IoT技術を用いた組込み系製品のラズベリーパイを使用した自動化の問題点と解決方法 です。 林さんは本Sqriptsにおいてスクリプターとしても 記事 を執筆しており、テスト自動化エンジニアとして活躍しています。 こちらの特集もおすすめ！ ■ 【連載】自動テストはなぜ失敗するのか。失敗事例からひも解く成功への道筋 Sqripter：林 尚平 問題点 IoT組込み系製品のテストを自動化するためには、自動化ツールを製品やサーバ、シミュレータといった機器と連携させる必要がありますが、ラズベリーパイを用いて自動テスト環境を構築したとのことでした。 テスト自動化の導入にあたって選定した自動化ツールでは、前提条件の設定やテスト実行結果の確認ができないことが判明したようですが、他の自動化ツールでは代用できないことを自動化できるといったメリットがあったことから、その自動化ツールを用いた環境構築ができないかを検討し、「AutoIt」と連携させることで不足する機能追加の対策をしたそうです。 これにより、自動テストの導入としては成功できたようなのですが、その後の運用フェーズでエラーが多発してしまったとのこと。 エラーの要因としては、テスト対象が数十機種にもおよんでいたこと、ツールを２つ連携させたことにより環境構築が複雑になってしまい、ヒューマンエラーが発生してしまったことなどが挙げられていました。 解決方法 解決のために着目したこととして、できるだけシンプルなテスト自動化環境を構築することが望ましいとのことで、自動化ツールの選定について検討し、AGESTのプロダクトである TestArchitect を利用する方法を紹介しています。 TestArchitectであれば、ハーネス機能によりラズベリーパイを制御する機能を取り込んで使用することができるため、環境構築をシンプルにすることが可能となります。 まとめ 自動化ツールの選定については、プロジェクトの状況などにもよると思いますが、導入だけではなく、運用まで見据えることも重要な要素であると改めて感じました。 TestArchitectは、デスクトップやWebアプリケーションをはじめ、モバイルにも対応しており、幅広いシステムの自動化が可能なツールです。 現在はこれらのシステムに利用されているケースが大半ですが、林さんの発表のとおり、ハーネス機能を用いることで組込み系製品の制御が技術的に可能であることが判明しました。 TestArchitectが組込み系製品の自動化ツールとして利用できることは、まだまだ知られておりません。 本記事をご覧いただいた方で気になった方がいらっしゃいましたら、ぜひお問い合わせください。 お問い合わせ先 さいごに ご紹介した内容以外にもたくさんの講演や発表がありました。 基調講演や特別講演はもちろんですが、一般発表として多くの品質に対する考え方などを聴講することで、「基本の本質を学び、 見つめなおす場をご提供します」という開催概要にもあるように、日々の業務を見つめなおす学びの場となりました。 同時間帯に聴講したい内容が重なっていたこともあり、悩ましくもありましたが、アンケートに回答してアーカイブ視聴特典をいただいたので、アーカイブでさらに学びたいと思います。 The post 狩野モデル（Kano Model）から考えるテストエンジニアの”品質”　～ソフトウェア品質シンポジウム2023参加レポート～ first appeared on Sqripts .

はじめに 前回は、自動販売機を題材にして、BDDを用いたプロセスの「発見(Discovery)」の部分（2.要件ワークショップ）までを説明しました。 今回は、「3. 定式化(Formulation)」の部分を、BRIEFの原則を交えつつ説明します。 3. 定式化 定式化では、システムの振る舞いの例（実例マッピングでいう具体例の部分）をシナリオの形で文書化します。 例えば、以下のような実例マッピングができた時に、書かれてある具体例「550円を入れて120円のコーラを選ぶとコーラと430円のお釣りが出る」をシナリオの形で文書化します。 例えば、Gherkin記法を用いて以下のように書けます。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Given 自動販売機がある When 500 円硬貨を入れる And 50 円硬貨を入れる And コンボボックスから 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 100 円硬貨が 4 枚出てくる And 10 円硬貨が 3 枚出てくる Gherkin記法 Gherkin記法とはGiven/When/Thenなどのいくつかのキーワードを用いて、実行可能な形式で記述する構文方法です。 今回は、以下の6つのキーワードが登場します。 Feature…ソフトウェアのフィーチャーの概要を記述するためのキーワードです。 Scenario…ビジネスルールを表す具体例を記述するためのキーワードです。 Given…システムの初期段階やシナリオの前提を記述するためのキーワードです。 When…実際に行うアクションや操作を記述するためのキーワードです。 Then…期待される結果を記述するためのキーワードです。 And…複数のGiven/When/Thenに値する内容が出てきた時には、この「And」のキーワードで繋げます。 例えば今回書いた内容の場合、以下のような内容を説明していることになります。 自動販売機についてのフィーチャーです。 「飲み物を買うとお釣りが出る」という具体例について記述します。 「自動販売機がある」という前提があります。 以下の操作を行います。 「500 円硬貨を入れます」 「50 円硬貨を入れます」 「コンボボックスから120 円のコーラを選びます」 すると、以下の結果が期待されます。 「コーラが出てきます」 「100 円硬貨が 4 枚出てきます」 「10 円硬貨が 3 枚出てきます」 シナリオを改善する さて、今回Gherkin記法で書いたような以下のシナリオがあれば全て大丈夫なのでしょうか。 Feature: 自動販売機   Scenario: 飲み物を買うとお釣りが出る     Given 自動販売機がある     When 500 円硬貨を入れる     And 50 円硬貨を入れる     And コンボボックスから 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 100 円硬貨が 4 枚出てくる     And 10 円硬貨が 3 枚出てくる このままでも実行可能なテストを作成していくことが可能ですが、もう少しシナリオの改善を考えることができます。 自分一人で考えても良いですが、他の人からフィードバックを得ながら進めるとなお良いでしょう。BDDを用いたプロセスの「#4. レビュー」の部分に該当します。 シナリオを改善する時の参考になるのが、BRIEFの原則です。 BRIEFの原則 BRIEFの原則とは、シナリオをより良くするために考えられた経験則です。それぞれの頭文字5つとBriefという言葉自体の計6つからなります。以下の説明は、「 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 （原文は Keep your scenarios BRIEF ）」から引用。 Business language（ビジネス言語）…ビジネスチームのメンバーが明確に理解できる用語を使用すべきです。 Real data（実際のデータ）…具体的な実際のデータを使用すべきです。 Intention revealing（意図を明らかにする）…シナリオのアクターが達成しようとしている意図を明らかにすべきです。達成する方法のメカニズムを説明するのではありません。 Essential（必須）…シナリオの目的は、ルールがどのように振る舞うかを説明することです。 この目的に直接関与しない部分は偶発的なものであり、削除すべきです。 Focused（焦点を絞る）…ほとんどのシナリオは、1つのルールの説明に焦点を絞るべきです。 Brief（簡潔である）…ほとんどのシナリオを5行以下に制限することをお勧めします。 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 今回のシナリオにBRIEFの原則を適用して改善する それではBRIEFの原則に当てはめて今回のシナリオを改善していきましょう。 ビジネス言語を用いる(Business language) 今回のシナリオの中で「コンボボックス」という単語は、実際の画面を想定して表現しており、ビジネス言語ではありません。また、コンボボックスでなくチェックボックスなどであっても今回行いたい内容を満たすことができます。そのため、以下のようにシナリオを改善します。 Feature: 自動販売機   Scenario: 飲み物を買うとお釣りが出る     Given 自動販売機がある     When 500 円硬貨を入れる     And 50 円硬貨を入れる      And コンボボックスから 120 円の "コーラ" を選択する      And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 100 円硬貨が 4 枚出てくる     And 10 円硬貨が 3 枚出てくる 意図を明らかにして(Intention revealing)、必須(Essential)の目的のみに焦点を絞って(Focused)記述する 今回のシナリオで示したい目的は、「飲み物を買うと飲み物の値段を引いた金額だけお釣りが出る」ということです。重要なのは金額であり、どんな硬貨が出てくるかは今回のシナリオの意図ではありません。そのため、以下のようにシナリオを改善します。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある When 500 円硬貨を入れる And 50 円硬貨を入れる When 550 円を入れる And 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 100 円硬貨が 4 枚出てくる And 10 円硬貨が 3 枚出てくる And 430 円が出てくる なお、どんな硬貨が出てくるかを示したい場合は、別のシナリオとして記述を検討すべきでしょう。おそらく、「発見(Discovery)」に立ち戻って、実例マッピングでいう具体例（緑色の付箋）やルール（青色の付箋）を追加することになると思います。 結果として簡潔(Brief)なシナリオになっている 改善した結果、以下のようなシナリオになりました。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる これを見ると、シナリオ自体は5行に収まっており、簡潔になっています。 「BRIEFの原則は必ず全て守るべき」ではない BRIEFの原則は必ずしも全て適用すべきではありません。 例えば今回の場合、シナリオで示したい目的は「飲み物を買う」ということなので、必須(Essential)の原則に従うと「コーラ」を指定する必要がありません。一方で、実際のデータ(Real data)の原則に従うと、「コーラ」という具体的なデータを用いた方が良いと思われます。 このように、原則の一部は排反する可能性があるので、その場に適した内容を適宜考えてください。 おわりに　〜BDD以外でもBRIEFの原則を活用する〜 今回は「3. 定式化(Formulation)」のプラクティスとして、Gherkin記法のシナリオをBRIEFの原則に従って改善していきました。 なお、BRIEFの原則はBDDの場面以外での活用も考えると良いでしょう。例えば、TDDやUnitテストの作成時には、色々なことが気になりすぎた結果、テストの意図(Intention revealing)が明らかになっていないことが多々あります。 ぜひ、そのような場面でもBRIEFの原則を活用してみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 The post TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 first appeared on Sqripts .

こんにちは、QAエンジニアのカンパチロックです。 今回は、マイクロサービスアーキテクチャにおける通信の品質保証としてCDCテストと、その実行において規模や多機能性に応じて一般的に使用されるツールである Pact の使用についてのワークショップを紹介します。このワークショップを通じて、CDCテストとPactの基本的な使い方や有用性を紹介できればと思います。 マイクロサービスとCDCテスト マイクロサービスアーキテクチャは、開発の効率化、デプロイメントの簡易化、そしてスケーリングの容易さをうたった誘惑的な選択ですが、サービス間の適切な通信はシステム全体のスムーズな運用に不可欠です。その中心に位置するのが、Consumer Driven Contract (CDC) テストです。 CDCテストは、各サービスが他のサービスとの通信契約を順守しているかを確認し、システム全体の信頼性と安定性を向上させる有効な手段です。そして、CDCテストを容易に実施できるツールとして、Pactが広く活用されています。 この記事では、Pact Workshop JSを用いてCDCテストを行うための知識と具体的な事例についてご案内します。深く理解や体験を通じて、マイクロサービスアーキテクチャを検討する開発者さんたちの視野を広げ、より豊かな選択肢を提供できればと考えています。 CDCテストの基本 Consumer Driven Contract (CDC)  テストは、マイクロサービス間の相互通信をテストするための方法論です。このテストでは、各サービス（ここでは”コンシューマー”）が他のサービス（”プロバイダー”）との間で期待する通信の動きや振る舞い、すなわち”契約”を定義します。この手法の目的は、サービス間の通信が予期された方法（つまり契約に従って）で行われることを保証することです。 CDCテストの一般的なフローは以下の通りです。 契約の定義 ：すべては、コンシューマーがプロバイダーに期待する振る舞いを正確に規定する契約の定義から始まります。この契約は、具体的には特定のリクエストに対する期待されるレスポンスを示す仕様となるべきです。この手間をかける理由は、明確な契約によりコンシューマーとプロバイダーの間の誤解や食い違いを最小化し、次の段階であるテストの成功率を高めるためです。 コンシューマーによるテスト ：次に、コンシューマーは上記の契約を基にしてテストケースを作成し、実行します。このステップでは、期待したレスポンスがプロバイダーから正確に返すことができるか、システムの限界をテストすることが目的です。この結果により、コンシューマーは契約が正しく機能することを確認でき、信頼性の高いコードをプロバイダーサイドに提供できます。 契約の共有 ：テストが無事合格した後、コンシューマーは契約をプロバイダーと共有します。このステップは、双方向のコミュニケーションと協調を促進し、広範で一貫性のある結果を生むために不可欠です。 プロバイダーによるテスト ：最後に、プロバイダーは受け取った契約に基づいて、自身のテストケースを作成し実行します。このステップでは、プロバイダーが契約仕様を適切に遵守していることを確認します。これにより、双方のマイクロサービス間の信頼性が高まり、安全なプロダクション環境への適用が可能となります。 Pactの特性 CDCテストの基本を理解したところで、次に紹介するのは、CDCテストを実施するための強力なツール、Pact( https://docs.pact.io/ )です。 Pactは、CDCテストを効果的に実施するためのオープンソースのフレームワークです。主に、コンシューマーとプロバイダー間の契約を定義し、その契約が適切に遵守されていることを確認するためのテストを作成、実行、検証する作業を容易にします。 出典： https://docs.pact.io/ Pactのもう1つの大きな利点は、言語に依存しないことです。これにより、異なる技術スタックを持つマイクロサービス間でも使用することができます。さらに、視覚的に理解できるテスト結果を提供し、契約違反が発生した場合にはその詳細を明示します。これにより、開発者は問題を素早く特定し、その修正に努めることができます。 しかしながら、この章ではPactの全機能について詳しく説明するのではなく、PactがCDCテストをどのようにサポートするか、そしてそれがなぜ重要なのかに焦点を当てたいと思います。Pactの詳細な機能や使用方法については、 公式ドキュメンテーション をご覧ください。 ワークショップ紹介 これまでに、CDCテストとPactについて説明してきましたが、まだ、これらの概念が抽象的に感じるかもしれません。そこで、このセクションからは具体的な実践体験を通して、Pactの使用方法とCDCテストのメリットをわかりやすく説明します。 Pact Workshop JSは、CDCテストの実践的な運用を体験できるワークショップです。ここでは、Pactを使用したマイクロサービス間の契約の定義方法とそのテスト方法を体験できます。このワークショップは、現場で直接応用することができる知識とスキルを得るためのネタ足しとなります。さらに、約60分で完了できるよう設計されています。 ワークショップのレポジトリは以下からアクセスできます。 https://github.com/pact-foundation/pact-workshop-js このハンズオンワークショップは、Pactを使ってCDCテストを体験する機会となります。 CDCテストを正確に理解し、適切に設定することでマイクロサービスの信頼性を向上させることができます。この機会をぜひ活用して、CDCテストの実践的な運用を体験してみてください。 準備手順 ワークショップの為の準備は、Pact Workshop JS公式ののgithubに記載されておりますが、以下のソフトウェアのインストールが必要となりますので、事前にインストールして下さい。 Docker Docker Compose Node + NPM ソフトウェアを全てインストールしたら、次に下記のコマンドを実行し、ワークショップのリポジトリをcloneしてください。 git clone <https://github.com/pact-foundation/pact-workshop-js.git> 以上がワークショップの準備手順になります。これで準備は完了です！ 学習内容 Pact Workshop JSは、Pactを使用したConsumer Driven Contract (CDC) テストの具体的な手順と例を学ぶためのワークショップです。このワークショップは11のステップで構成されていますが、それらは以下の4つの主要なフェーズに分かれています。 ステップ1 – 5: Pactの利用の基本 ：このフェーズでは、コンシューマとプロバイダの間で通信の契約を定義し、それに基づいてテストを作成、実行、検証します。これにより、Pactを利用したCDCテストの基本的な流れを理解します。また、コンシューマとプロバイダ間の通信契約がしっかりと担保されることを確認します。 ステップの実施内容としては、コンシューマ側のエンドポイント名の誤認識により結合テストが失敗する状態をスタートとして、PactによるCDCテストにより問題の検知・解消を行うところまでが含まれていますので、CDCテストの有益性を確認する上では十分な内容と思います。 ステップ6 – 7: データ状態(stateHandlers)を利用したテスト ：次のフェーズでは、プロバイダ側に格納されているデータの状態に応じたテストを行います。これにより、データ状態と応答データの関係性の検証をPactで行う方法を学びます。具体的には、対象のIDの商品が存在しないケースや、商品が全くない場合のケースについての実装を行います。 APIのエンドポイント、リクエスト、レスポンスの形式などは、IDL(Interface Definition Language)を利用することで静的な検証を行うことが可能ですが、データの状態に基づくレスポンス内容は動的な性質を持つため、テストでの検証が必要となります。PactではstateHandlersの機能を利用することで、これらの動的なレスポンスを効率的にテストすることが可能となります。 ステップ8 – 10: 動的なデータについてのテスト ：この段階では、動的なデータ（例えば、認証トークンなど）についてのテストを行います。この段階では、動的なデータを扱うテストケースでPactをどのように利用するかに焦点を当てます。具体的には、APIの認証機能としてタイムスタンプを含むトークンの組み込みをユースケースとして考えます。ここでは、このような問題を解決するためにPactをどのように活用するかを学びます。 ユニットテストで期待値を検証する際、日付情報や一時的な認証トークンのような動的なデータの取り扱いは常に課題となります。PactではRequestFilterという機能を使ってこれらの動的な要素に対応したテストを実装することが可能です。これにより、テストの信頼性と精度が大幅に向上し、問題解決の手間を削減できます。 ステップ11: Pact Brokerを利用した効率的なPactファイルの管理 ：最後のフェーズでは、Pact Brokerを導入し、Pactファイルの管理を効率化します。Pact Brokerは、Pactファイルのバージョン管理、共有、検証結果の追跡などを行うことができ、複数のサービスやチーム間での契約テストを容易にします。さらに、Pact BrokerはCDCテストの結果を一元的に管理し、それを基に自動的にデプロイを許可するか判断するなど、CI/CDパイプラインとの統合を強力にサポートします。これにより、CDCテストの結果を直接CI/CDプロセスに反映させることが可能となり、開発プロセス全体の効率化に寄与します。 ワークショップでは、Pactのテストが意図的に失敗する状況も設けています。それらを「なぜテストが失敗するのか？」を自己学習の一環として理解することが求められます。 このように、各ステップを順次進めながら、Pactの使用方法とその有益性を深く理解することが、このワークショップの主な目的です。 体験と洞察 ワークショップを終えてみて感じたのは、CDCテストの全体的なフローを理解し体験することができ、さらにはPactを使用して契約を定義し、テストを作成、実行、検証する方法を学ぶことが非常に有益だったということです。 このワークショップの最終段階でPact Brokerの組み込みを行ったことにより、「最後にいつCDCテストが行われたか？」や「どのバージョンのプロバイダと接続を確認したか？」といった情報をWeb上で簡単に確認できるようになったのも大きな収穫でした。 また、ワークショップで学んだことは基本的な例にすぎません。実環境のCDCテストは、さらに多くのシナリオをカバーできると思います。特に、マイクロサービス環境では、CDCテストによって実現されるサービス間のネットワークグラフは、各サービスの接続状況を一覧表示することに非常に役立ちます。 その為、このワークショップが期待以上に価値ある体験であったと感じています。 出典： https://github.com/pact-foundation/pact_broker#network-diagram 最後に 今回は、 Consumer Driven Contract (CDC) テスト と Pact に関するワークショップについてご紹介いたしました。これらの知識とツールが、あなたの開発プロセスを更に丁寧で、効率的なものに進化させ、より高品質なソフトウェア作りに貢献することを心から願っています。 このワークショップを通じて、新たなスキルを獲得し、自身の技術スタックを拡張するための第一歩となることを期待しています。どうぞ、この機会にワークショップを試してみてください。 The post CDCテストに触れてみよう。Pact JS workshopを利用したCDCテストの実体験 first appeared on Sqripts .

前回の記事（ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 ）では、テスト自動化のために既存のテストケースを整理・加工する際のポイントについて説明しました。 今回はテスト自動化を前提としてテスト設計（およびそれに伴うテスト計画やテスト分析の見直しなど）を行う際の方法について考えます。 これまでの連載記事とは異なり、「こうするとよい」「こうしましょう」といった、わたしの経験や一般の知見に基づくノウハウの共有という意味合いは少なくなっています。 むしろ、「わたしはこう考えて、こんなことをやっている。世の中ではこんなことが言われている。みなさんはどうですか？」といった、半分は読み手の皆さまへの問いかけとして本記事を書いています。 これをきっかけに、テスト自動化を前提としたテスト設計について情報の流量が増え、議論が活発になればうれしいです。 テスト自動化とテストプロセスとの関連についてあらためて整理 テストエンジニアやQAエンジニアの間でも、テスト自動化を業務で行っている方や経験がある方が増えているようです。 ソフトウェアテスト自動化カンファレンス2022アンケート結果サマリー より テスト自動化研究会が行ったアンケート結果の毎年の推移をみると、テスト自動化の経験がない方は少しずつですが下がっています。 しかし、テスト自動化が普及している一方で、テストエンジニアが普段の業務で扱っている「テストプロセス」と、「システムテストの自動化」とを完全に別のものとして考えてしまっている場合があるように思います。 上の図に近い形の方法が、 前回の記事 でご紹介したやり方です。 ただ、これも前回の記事で何度か触れたように、このやり方で進める場合はデメリットもいくつか考えられます。たとえば自動化をする際の手戻りが多くなるリスクがありますし、暗に「手動実行の効率化・工数削減」という視点で考えてしまいがちでもあります。 本記事でお伝えしたいことのひとつは、先の図における「手動テストの世界」と「自動テストの世界」は別々のものではなく、下図のように同じプロセスで検討されるべきものである、という点です。 テスト設計の先が2つに分岐していますが、実際には先の図で「手動テストの世界」として表現したテストプロセスと、そのアウトプットやフェーズには大きな違いがありません。 つまり、テストプロセスのアウトプットをあとから自動化向けに加工するのではなく、テスト自動化を考慮してテストプロセスに沿って進み、手動・自動それぞれのアウトプットを作成するほうが効果的ということです。 手動実行が前提のテスト設計と、自動化を考慮したテスト設計との違い 手動実行が前提のテスト設計、つまりテスト手順をあとから自動化するパターンの場合と、自動化を考慮したテスト設計とでは何が異なるのでしょうか？テスト分析やテスト設計の段階で自動化について考えておくと、どんなメリットがあるのでしょうか？ ひとつは、 前編 で触れた – 手順や期待結果の具体化 – 順序や依存関係の整理 などが後追いではなく最初から行えるという点です。 他にも、以下のような違いが考えられます。 テストの範囲が広がる・網羅度合いが高まる 手動実行を前提としてテスト設計を行うと、プロジェクトの現実的なリソースでできる範囲でテストケースを作成する場合があると思います。 自動実行によって効率的に実行できるのであれば、本来やりたかった範囲をすべてテストする、網羅度合いを高めるといった選択ができるかもしれません。手動実行時に比べてテストケースの量を増やすことができる、とも言えます。 もちろん、テストは多ければ多いほど良いわけではありません。しかし、手動実行ではリソース等の制約があってできなかった範囲・量のテストが実行できる可能性が生まれる点は、メリットと考えられます。 実行頻度・フィードバックサイクルを増やせる テストの範囲や網羅度合いに加えて、実行頻度やフィードバックサイクルを増やせる、というメリットがあります。 手動でシステムテストを実行する場合、たとえば「システムテストフェーズ」として一定の期間を設け、この期間内にシステムテストをすべて完了させるというやり方があります。その場合、テストケースもシステムテストフェーズで1回ずつ実行される前提で作成します。 しかし、自動実行を考慮してテスト設計を行うことで、「システムテストフェーズで行うテスト」というひとかたまりのテスト設計ではなく、より段階を分けて考えることができます。リグレッションテストに相当するテストをCIパイプラインに組み込んだり、もしくはステージング環境で毎晩実行したりと、テストの目的や内容に応じて実行タイミングや頻度を分け、増やすことができます。 自動化を考慮したテスト設計のポイント これらのメリットを得るために、テスト分析やテスト設計の段階から自動化を考慮しておくことが大切です。 自動化を考慮してテスト設計を行う際のポイントは前述の「手動実行が前提のテスト設計と、自動化を考慮したテスト設計との違い」がほぼそのまま該当します。 ただ、ここまでに出てきていない注意点としては – 自動化によって抜けがちな観点に注意しましょう ということをお伝えしておきます。 手動実行向けのテストを自動化する際にも同様の注意が必要になりますが、テストを自動実行することによる実行効率UPと引き換えに、手動実行時に人間が暗に確認しているさまざまな観点が抜け落ちることになります。 単純な例で考えると、たとえばテスト設計時に「ログイン処理は簡単に自動化できるから、自動実行するテストとして設計しよう」と考えたとします。そうするとログインに関するテストは自動実行でカバーできているからOK！と思いがちですが、ログイン処理における画面表示の問題などは単純な自動テストスクリプトでは見逃されてしまいます。 こうした、自動実行するテストでカバーできていない範囲・観点があるにもかかわらず、機能や画面としては自動テストで見ている、という場合は必要な観点が見逃されがちです。 まとめ 今回はテストプロセス、とくにテスト設計時にテスト自動化を考慮して行う際の考え方等について説明しました。 こうした、テストプロセス中のどのタイミングで、自動化に関するどんなことを考慮するかについてはまだまだ議論や改善の余地があると考えています。 わたしも普段の業務における自動化向けのテストケース設計のやり方はいろいろと模索中で、 過去のテスト設計コンテスト決勝進出チームの成果物 なども繰り返し参照しながらよりよい形を考えています。 本記事がなんらかのヒントになればもちろんうれしいですが、それ以上に「もっとこう考えるべきでは」などいろいろな意見をいただけると、よりありがたいです。 参考 – 自動テストを活躍させるための基礎作りとテスト設計の工夫 – Speaker Deck – テスト設計チュートリアル U-30版 資料 2019 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント テスト自動化の普及と推進【前編】～阻害要因と対策 テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計 The post テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計 first appeared on Sqripts .

JSTQB FL の取得に向けて学習中のみなさん。初めまして、Yoです。 シラバスの読み込みは順調ですか？各項目をしっかり理解できていますか？ JSTQBの学習において、シラバスの熟読は避けて通れません。しかしながら、シラバスは言い回しが少々難解であったり、耳慣れない用語が多かったりとなかなかとっつきにくいものです。私もFL学習の初期には全然理解が追い付かずに苦労しました。 本記事では、シラバスを理解する上で私が個人的につまづいた箇所をかみ砕いて解説していこうと思います。 今回はプロダクトリスクとプロジェクトリスクについて解説します。 シラバスにおいて プロダクトリスクとプロジェクトリスクについて、JSTQB FLシラバスでは以下のように解説されています。 ※少々長いので、箇条書きにされている具体例は割愛します。 プロダクトリスクについて プロダクトリスクは、作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む。プロダクトの特定の品質特性（例えば、機能適合性、信頼性、性能効率性、使用性、セキュリティ、互換性、保守性、移植性）に関連するプロダクトリスクは、品質リスクとも呼ばれる。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 プロジェクトリスクについて プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与える ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 英語の意味を考える シラバスの引用だけではまだ表現が固くて取っつきにくいので、英語の意味を考えていきましょう。 プロダクトは「製品」、プロジェクトは「事業、計画」といった意味の言葉です。つまり、プロダクトリスクは「製品に対するリスク」プロジェクトリスクは「計画に対するリスク」と言い換えることができます。 ※プロジェクトの和訳として、ここでは計画の方を採用しました。 もっと簡単に表現してみる 英語で意味を噛み砕いてみると、それぞれのリスクがどういったものか、多少はイメージしやすくなったのではと思います。更に、それぞれのリスクを「製品」「計画」というキーワードに着目して言い換えてみましょう。 プロダクトリスク = 製品の利用者に害があるリスク、製品の提供者に不都合があるリスク プロジェクトリスク = 計画通りに進まないリスク、計画そのものが抱えるリスク こうして両リスクを言い換えてみると、冒頭で引用したシラバスの記述が理解できるかと思います。 シラバスの例を具体的に考えてみる 言葉の意味の解説が済んだところで、ここでは両リスクが具体的にどういう物かを考えてみます。 先ほどのシラバス引用では割愛しましたが、シラバスには具体例が箇条書きで記載されているので、それらを見てみましょう。 プロダクトリスクの例 プロダクトリスクの例について、シラバスに以下のような記載があります。 特定の計算結果が状況によって正しくないことがある。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 これがプロダクトリスクである、と答えありきで言われると、確かにそうかもなと思うかもしれませんが。ヒントなしで何のリスクであるかと答えるためには、両リスクがどの様なものであるかをしっかり理解していることと、例からどの様な事象に発展してしまうのかを想像することが大切です。 この例では、計算の結果が正しくないということですので、以下のような事象に発展する可能性があります。 ショップの購入者への請求額の誤り 在庫数の表示と実態の不整合 これらのようなことが実際に起こってしまうと、利用者は金銭的な損害を被りますし、サービス提供者は機会の損失が発生する可能性があります。これらは「製品」の機能不備によって引き起こされたものであるため、プロダクトリスクになります。 プロジェクトリスクの例 プロジェクトリスクの例としては、以下のような記載があります。 テスト環境が予定した期限までに用意できないことがある。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 経験がある方もいらっしゃるのではないでしょうか。予定通りに環境が出来上がらない場合、どういった事態が考えられるでしょうか。すぐ思いつくのは、 テストが遅延する などでしょう。更に言うと、リリース判定、申請、リリース等が後ろにずれてゆき、当初計画していたスケジュール通りに開発が完了しないということが起こりえます。そうなると当然。 開発コストの高騰 等も発生しえます。これらは「計画」に影響を与えるリスクであるため、プロジェクトリスクだと判断できます。 上記の例のように、「どこで」「どの様に」悪影響があるのかを具体的に考えることで両リスクの判断が可能になります。 例題 ここまでで両リスクの説明と、具体例からの判別について一通りの解説ができたので、応用として簡単な例題を解いてみましょう。 以下のうち、プロダクトリスクはどれか A：ループ制御構造が正しくコーディングされていない B：人員のスキルやトレーニング不足 C：ツールによる支援が遅れる D：欠陥や他の技術的負債が累積する それぞれに対し、リスクが何に影響を与えるかと、どの様な問題が発生するかを想像して回答してください。 回答はAです。合っていたでしょうか。 解説になります。プロダクトリスクはどれか、という問いですので選択肢のうち「製品」が直に利用者か提供者に不都合をもたらすリスクであれば正解となります。Aはアプリなどで考えると離脱不可やフリーズなどを引き起こしかねないため「製品」のリスクとなります。故にプロダクトリスクとなります。 他3つのリスクに関して、個別の解説は省きますが、ザックリと言ってしまえば「うまく製造できない」という結果に繋がります。これは「計画」に対するリスクとなるためプロジェクトリスクです。 いかがでしたでしょうか。両リスクはシラバスで取り上げられる例も多いので一つ一つ覚えると大変ですが、内容を理解した上で想像することで問題の難易度がぐっと下げることが可能です。 リスクにどう対処するか JSTQB FL対策というテーマからは若干逸れますが、それぞれのリスクに対して、業務でどのようなアプローチをとると良いのか、リスクを判断できるとどういうメリットがあるのかという話をしたいと思います。 プロダクトリスクに対処する プロダクトリスクに対処するものとして、リスクベースドテストというものがあります。リスクベースドテスト自体もFLで軽く触れられているものになりますが、可能性や影響から優先度を決定していくアプローチになります。ただ、当然ながらリスクベースドテストでなくとも、テストの対象となる機能にはどういったプロダクトリスクがあるかを常に意識することは重要です。 可能性や影響を適切に判断することによって、テスト優先度やテストの詳細度合い等を決定することができるというメリットがあります。例としては、要件レビューに参加し、リスクの観点からレビューを行う、非機能テストの戦略をリスクに基づいて決定するなどです。 プロジェクトリスクに対処する プロジェクトリスクへの対処は、JSTQBでは主にTMで解説される内容のため簡潔に、かつ個人の見解も含むものになりますが、自身が担当する範囲で、何かしら作業が滞る要因は全てプロジェクトリスクです。 阻害となっている要因（たとえばテスト環境構築の遅れなど）を適切に判断することができれば、テスト実行スケジュールの再検討などができるようになり、影響を最小限に抑えることができます。 環境構築はあくまで一例ですが、プロジェクトリスクを判断できるということは、プロジェクトやチームが抱える問題を発見できるということでもあるため、テストコントロールの観点においてもプロジェクトリスクを適切に判断できることは重要となります。 このように、対処のアプローチ、対処することのメリットも異なるため、それぞれの対処法だけでなく、それぞれを正しく「判別」出来ることが重要になります。 まとめ 以上でJSTQB FL対策の第1回、プロダクトリスクとプロジェクトリスクの解説は終了します。あくまで私が受験時に苦戦した内容をまとめているものになるため、「そんなことは知っている」という方もいるでしょうが、私と同じ個所で苦戦している方がいらっしゃいましたら、この記事で理解のお手伝いが出来れば幸いです。 本記事はFL対策と銘打っていますが、テストに向けてというだけでなく、JSTQBの用語理解にも役立てていただければと考えています。JSTQBの用語を基準とすることで認識の共通化を図ることでステークホルダとのコミュニケーションにおいてエラーも発生しにくくなると思いますので、プロジェクト内のポジションに関わらず、用語を深く理解することは重要と考えます。 では、また別の記事でお会いしましょう。 The post JSTQB FL対策 弱点強化解説　～１回目～ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 チームではスクラム開発を導入しており、今回はNotionでのバックログ管理の話をしたいと思います。 当初のバックログ管理方法 自分が所属するチームでは、バックログは、当初Miroで原案を作ったのちGitHub + ZenHubにて作成し管理していました。 バックログに加えバグや要望も同様にGitHub + ZenHubで管理していましたが、ナレッジやドキュメントはNotionに作成しており、下記のような課題を持っていました。 バックログ、要望、バグが混ざって見にくい バックログとドキュメントを参照するのに複数のサービスを行き来するのは手間がかかる Sprint単位のバックログや状態が把握しにくい 現在のバックログ管理方法 これらの課題を解決するため、バックログ等をすべてNotionに移植し、ボードビューのグループとサブグループを用いて見やすいビューを作成し管理するようにしました。 実際に使用しているビューの形式はこちらです。 ※実データは載せられないため、形式は同じもので仮のデータを入れたものになります。 縦軸に担当者、横軸にSprint、プロパティにはバックログのステータスとindex（通し番号）を表示しています。 また、タイトルにも indexを付与することで、他pageからバックログをリレーションのプロパティとして関連づける際に検索しやすくしています。 ※今は手動で付与していますが、Notion APIを用いれば半自動などでの付与も可能だと思います。 いちいちバックログ名を検索するのは大変ですが、番号で検索することで、スムーズに目的のバックログを表示することができます。 プロパティはこちらです。（最低限のものを表示しています） 担当者は今回のブログ記事用のデータベースを作成して割り当てていますが、Notionのユーザー一覧でも問題ないかと思います。 Tasksは後述する開発者のタスクボードへのリレーションです。 こちらは自分達のチームでは関連付けを追加する機会が多いこともあり、セクションとして表示しています。 なお、今回はページ内容は空白ですが、ユーザーストーリーや受け入れ基準など開発に必要な内容を記述していきます。 要望、BUGの管理 これらはバックログとは異なるデータベースとし、主にテーブルビューで管理しています。 先ほどのプロパティからは省いていますが、バックログのページとリレーションを設けることで、互いに参照ができるようにしていきます。 なお、同じデータベースで管理するのも一つの方法なので、ここを分けるかどうかはチームで運用しやすい方法を選択するのが良いかと思います。 タスクボード 開発チームのタスクも別のデータベースを作成し、バックログと同じ形式のボードビューとして利用しています。 これらに互いにリレーションプロパティを作成することで、開発チーム プロダクトオーナーの情報共有に役立っています。 その他通知設定 Notionではビューの設定で簡単にSlack通知を行うことが出来るため、自分たちのチームではこれを活用しています。 例えばバックログボードやタスクボードのステータスが指定のものに変更されたときにSlackに通知を行なえます。 例として、自分たちのチームではステータスを横軸にした別ビューを作り、ステータスがQAメンバの評価待ちを表す 開発完了 というステータスになったら、QAメンバの居るチャンネルに通知するといった運用を行っています。 おわりに 今回の内容のまとめです。 バックログや要望一覧などをNotionに移植することで、各種課題を解消 データベースを分けた場合も、リレーションを活用することでリンクしやすくする バックログの管理方法にお困りの方は、ぜひ参考にしてみてください。 なお、Notionには継続的に新しい機能が追加されており、以下の2つの機能を今後は試す予定です。 スプリント機能 GitHub連携機能 The post Notionでプロダクトバックログを管理するビューを作成する first appeared on Sqripts .

こんにちは。ゆーてぃです。 2023年9月8日(金)に開催されたJaSST’23 Hokkaidoに参加してきましたので参加レポートを書いてみたいと思います。 テーマ「心動かさる”コト”の品質」 今回のテーマは、「心動かさる”コト”の品質」とし、利用時品質、UI/UX、DevOpsに焦点をあて、ソフトウェアテストと品質の今後のあり方を考えます。 JaSST’23 Hokkaido 北海道外の方がこのテーマを目にすると、「動か さる 」ん？誤字？と思うかもしれませんね。私は生まれも育ちも北海道なので何の違和感も覚えず、よいテーマだなと思いました。 JaSST’23 Hokkaidoの開催要項にも書かれていますが、「～さる」は北海道弁で「自分の意思以外の何かによってそうさせられてしまう」という意味となり、私はよく弁解のためにこの言葉を使ってきました。 おい！なんでそのボタン押したんだよ！→いや、押ささったんだよ！ 私は言い訳に使うことが多く(たぶん？)ネガティブな言葉として捉えてましたが、今年のテーマを見て、ポジティブな表現としても使える良い方言だな、と感じました。そしてソフトウェアを使用する人の心が動かさる仕事がしたいなと思いました。 基調講演「ユーザビリティとソフトウェア品質」 今回の基調講演では、国立研究開発法人理化学研究所革新知能統合研究センター 兼 東京都立大学客員教授／公立千歳科学技術大学客員教授の福住 伸一様が登壇され、様々なユーザビリティの考え方や捉え方、さらにソフトウェアの品質としての利用時品質、製品品質におけるユーザビリティの問題点についてお話をされてました。 DX(デジタルトランスフォーメーション)が注目されている中で、「デジタル化していけばいいんじゃなくて、人間中心に考えていかないとダメだろう」という観点から、どのように考えていけば良いかについて例を挙げながら語られていました。印象に残った内容をピックアップして記事にまとめたいと思います。 人間中心の考え方 1980年代後半から、ユーザビリティという概念が提唱され、当初は「何とかして使えるようにする」という目標から、「使いやすくする」という思想へと変化しました。さらに、視覚的なGUIにとどまらず、聴覚や触力覚などにも広がり、ユーザビリティの捉え方が多様化してきています。 この変遷の中で、顧客との要求明確化に課題があると指摘され、システムの利用に焦点を当て、ユーザビリティやユーザエクスペリエンスを満たすために人間中心設計とインタラクティブシステムの活用が重要だと強調されました。 人間中心設計とは 国際規格ISO9241-210で定められた、 システムの利用に焦点を当て、人間工学(ユーザビリティを含む。)の知識および技法を適用することによって、インタラクティブシステムをより使いやすくすることを目的とするシステムの設計および開発へのアプローチ。とのこと。 人間中心設計では実際に以下のことが重要とお話をされてました。 ・例 発表者(ユーザ)は、限られた発表時間(利用状況)の間に発表を完了させるために(利用目的)、どれだけの時間が残されているか(前提条件)を知る必要がある。ユーザ要求事項は、タイマーを使って、残り時間および経過時間を計測し、視覚的および聴覚的情報として提示する、などとなる。 このように、利用者が誰で、どのような操作や環境で行うかを考慮し、利用状況と関連付けながら要件を抽出し、ユーザ要求事項に合致する設計解を作成、および評価を行う流れを繰り返すことにより、ユーザ要求事項に適した設計につながると述べられました。 所感 利用状況を理解し、要求事項を明確にした上で設計し、評価することは、私たちが担当している機能テストでも同様に重要な要素です。非常に興味深い内容であり、多くの共感を覚えました。そして、何よりも重要なのは、このサイクルを繰り返し、より良いものにしていくことだと感じました。 新しい利用時品質 次に「新しい利用時品質」についてご紹介いただきました。以下の理由から新しい利用時品質の考え方が必要だと述べられています。 従来は製品やシステムが仕様を満たすことで品質が評価されていた(製品品質)。 デジタル化が進んでそれらを「使う」ことの影響が直接のユーザだけでなく、所属する組織や社会にも及ぶようになってきた。 これらの影響をできる限り制御できるようにすることが、組織の社会的責任として感じられる(利用時品質)。 デジタル化が進むことにより使う人の影響範囲が広くなったため、ユーザと製品・システムの1対1の影響ではなく、製品・システム・サービスを利用したことによって、多くの人々や社会など間接的な影響に目を向ける必要があるとお話をされてました。 また、製品品質モデルと利用時品質モデルの動向について、以下のように紹介されました。 品質モデルとして、製品品質モデルと利用時品質モデルの2つが存在する。 製品品質モデルにはusability(使用性)として品質特性が含まれている。 利用時品質モデルではusabilityが使用されていないという問題があった。 製品品質モデルとインタラクションの原則の品質特性であるusabilityに関連する品質副特性が、実質的に製品品質モデルの品質副特性として活用されている。 そのため、製品品質モデルの品質特性名を「usability」から「interaction capacity(インタラクション能力)」に変更することが適切ではないかという議論が国際規格の中で進行中であるようです。この変更については、直近の国際会議で合意がされており、現在最終審議中であるとのことです。 所感 常日頃、ユーザ目線でのテストを心がけていますが、今後は「ユーザ周辺目線」なるものが必要になるかもしれませんね。 製品を使うユーザだけでなく、さまざまな属性を持つユーザや所属する組織、会社、その他の関係者にも影響が及ぶことを考える必要があり、視野を広げて物事を検討することが、今後のテストにおいてより重要になると感じました。 最後に 福住様は最後に以下をまとめとしてお話をされています。 ユーザビリティ(を含めた人間工学)とソフトウェア工学はもっと仲良くすべき ユーザビリティはさまざまな観点からアプローチされており、これまで一緒に考えてこなかった部分があることが指摘されています。より密接に連携し、協力して取り組むべきだと述べられました。 人間中心設計で抽出されるユーザ要求事項を上流の段階で要件に組み込む 上流の段階でユーザ要求事項をうまく要件に組み込む方法を向上させる必要があり、要件定義は行われても、それを具体的な仕様に落とし込むことが難しいことが指摘されました。結果的に、ユーザビリティが把握しづらくなるという課題が示されました。 開発プロセスの中で段階的にユーザビリティを評価する方法 発表の最後で、福住様はこの問題に焦点を当て、テストの観点で確認してもらえると嬉しいと述べ、発表を終えられました。 所感 今回はユーザビリティと品質に関する内容をお話いただきました。こういった概念を理解した上でテストするとよりユーザエクスペリエンスが向上に繋がると感じました。 また、今回お話いただいた内容は開発、テストエンジニアも双方で考えることによって、より良い品質になるのではと考えさる内容でした。 ワークショップ 今回、オンサイトでワークショップに参加してきました。合同会社CGFMの金内 和子様、金内 透様が開催する「クライアントも開発メンバーも巻き込んで作るUIデザイン」をテーマにしたワークショップになります。 ワークショップの流れ ワークショップは以下の流れで即興演劇、ユーザシナリオ作成、ペーパープロトタイプ作成、簡易ユーザテストを行いました。 １）抽選により4人1組のチームを作成 ２）即興演劇 一人がユーザになり切って空想でアプリを使用します。 この時、ペルソナの心境、考えなどを言葉に出しながらアプリを触ります。 他のメンバーはペルソナの心境やアプリの情報など、ユーザ役の言葉を付箋にメモしていきます。 ３）ユーザシナリオ作成 ２で書いた付箋を時系列で整理し、ユーザシナリオを作成します。 ４）ペーパープロトタイプ作成 手書きで簡易的なUIを作成していきます。 これが思ったよりも難しく、ついペルソナの人物像、課題を忘れてしまう場面もありました。 ５）ユーザテスト 紙で作成したUIに対してどうやってテストしていくんだろう？と思っていましたが、一人がサーバ役をやるんです！ユーザが遷移ボタンなどを押すと、サーバ役が別画面の紙に差し替える方法でユーザシナリオを進行していきます。 道中に不具合などがあればユーザシナリオ、ペーパープロトタイプを修正し、再度ユーザテストします。 その後各チームで1名テスターを選出して、別のチームへ赴きそのチームのシナリオと簡易ユーザテストを実際に進められるか、といった流れで進めていきました。 所感 「早くつくって、早く試す」と金内様が強調されておりましたが、兎に角すごい早い速度で進行していきました。1つの工程は5分程度だったかと思います。 また、初めは自分のチーム内で話ながら進めていたため、完成したもので概ね問題ないだろうと思っていたものが、別チームの方が進めてみると思ったように進まない、というのが大体のチームで起きていたと思います。 これでよかろうと思って作成したものが、実はユーザからしたら分かりにくかったり、使いにくかったりするため、実際に使用するユーザの事を考えてUIを作成することの難しさを体験できました。 まとめ 「心動かさる”コト”の品質」をテーマに参加させていただきましたが、どの講演内容も考えさる内容でした。日頃、機能テストを担当しているため、機能性を中心に考えてしまいがちですが、様々なユーザ要求を達成するには使用性に目を向けることも重要であると再認識しました。 今まで機能テストでもユーザ目線でのテストは心掛けて実施してきましたが、今回の講演やワークショップで学んだ内容を活かして、よりユーザの事を考えたテストが行えるよう日々精進していきたいと思います。 The post JaSST’23 Hokkaido 参加レポート first appeared on Sqripts .

IoT機器とは IoT機器とは、インターネットに接続される機器のことです。 パソコンやスマートフォンは当たり前のようにインターネットに接続されている機器ですが、近年では一般家庭向けの機器だけみても、エアコンや冷蔵庫、洗濯機など、これまでインターネットに接続されていなかった家電製品がインターネットに接続されるようになっています。 外出先から家の鍵の状況を確認し、解錠や施錠が行えるスマートロック、外出先から家の中の様子を確認できるネットワークカメラなど、様々な機器が販売されており、今後ますます広がりをみせていく分野となっています。 IoT機器に潜在するセキュリティリスク 機器がインターネットに接続され、便利な暮らしを提供するようになった一方、インターネットに接続されていない機器とは異なり、新たにセキュリティ上のリスクに対応する必要がでてきました。 適切なセキュリティ対策が行われていないと、悪意をもった第三者に機器が乗っ取られたり、機器で扱う重要な情報を窃取されたりするなど、重大な問題が発生する可能性があります。 IoT機器は、機器自体に利用されている基板やチップ、連携するサーバ、ソフトウェアなど、セキュリティを考慮しなければならない要素が多数存在します。 機器の基板やチップなどのハードウェアに潜在するリスク IoT機器は、ソフトウェアだけでなく、ハードウェアそのものに対する攻撃にも対策が必要となります。 例えば、UARTなどのデバッグポートが利用可能なまま残されていると、攻撃者によって機器で利用しているシェルへの不正アクセスを許してしまい、重要なデータを窃取される恐れがあります。 その他にも、メモリ上からファームウェアを抜き取られ、解析される等のリスクがあります。 連携するサーバやWebアプリケーション / Web APIに潜在するリスク IoT機器を管理するために利用するWebアプリケーションや、そのWebアプリケーションが稼働するサーバなど、ネットワーク経由で攻撃を受けるリスクがあります。 サーバやWebアプリケーションの脆弱性により、IoT機器を利用するユーザーの情報の窃取、サーバやIoT機器への不正アクセスなどが考えられます。 また、一般家庭向きのIoT機器ではスマートフォンアプリ（モバイルアプリ）と連携し、離れた位置からインターネット経由で機器を操作できるものが増えており、アプリで利用するAPI、アプリの動作についても同様の危険性があります。 ローカルで動作するソフトウェアに潜在するリスク インターネットに接続されるIoT機器であっても、全ての動作がネットワーク経由で処理されているとは限りません。 例えば、液晶画面付きの機器を起動させた際に、機器へログインするための画面が表示されるとします。 機器へログインするためには、機器に登録されているユーザーである必要がありますが、何らかの方法によりログイン画面を迂回し、不正に内部機能の利用が可能であるかも知れません。 ネットワークを介さない部分の動作においてもセキュリティ上のリスクは存在します。 このようにIoT機器には、機器自体や関連する様々な要素に対してセキュリティのリスクが存在します。 起こり得る問題の具体的な例としては、脆弱なスマートロックを利用していた場合、モバイルアプリのローカル部分の動作不具合により、解錠権限のない第三者に家の鍵を開けられて侵入される、脆弱なAPIを利用するネットワークカメラによって、第三者に密かに家の中の様子を監視されていた、などが考えられます。 IoT機器のシステムに対する主な検証内容 IoT機器のシステムに対する検証内容の例をご紹介します。 IoT機器のシステムに対する検証では、IoT機器や関連するアプリケーションなど、様々な要素に対して検証が必要となります。 ハードウェア診断 IoT機器自体の基板やチップに対して、UARTやJ-TAGなどのデバッグ用のインターフェースが利用可能でないかを調査するハードウェア解析や、ファームウェアの解析、USB/Bluetooth/NFCなどの各種インターフェースの調査を行います。 プラットフォーム診断 IoT機器や、 IoT 機器が利用するサーバに潜在する脆弱性の有無を調査します。 Webアプリケーション / Web API診断 IoT機器との連携管理に利用されるWeb アプリケーションや、ルータ等の機器自体に内包されるWebアプリケーション、連携するモバイルアプリケーションの通信先となるWeb API に対する脆弱性を調査します。 探索型セキュリティテスト（総合的な動作確認） AGESTでは、IoT機器単体での動作確認や、連携するWeb アプリケーション、モバイルアプリケーションを含めた動作確認など、正規ユ ーザーと同等の環境を想定した、探索型のセキュリティテストを実施することをお薦めしております。 探索型セキュリティテストにより、セキュリティ上問題のある仕様の洗いだしや、イレギュラーな操作によって機器の動作に問題が生じ、結果としてセキュリティにかかわる問題に繋がるなど、未知の不具合/脆弱性が発見される場合があります。 探索型セキュリティテストの具体例 では、一般家庭向けのスマートロックに対して探索型セキュリティテストを実施すると仮定して、機器の動作やモバイルアプリを検証する際の具体例をご紹介します。 一般家庭向けのスマートロックでは、既存の鍵の上に重ねるようにして貼り付けるタイプが多く、機器を動かすことによって、同時に既存の鍵を動かす、という仕組みになっています。 解施錠の判定 モバイルアプリと連動しているスマートロックでは、現在鍵が施錠されているのか、解錠されているのかをモバイルアプリで確認することができます。 施錠状況をモバイルアプリで確認できる 機器側で施錠、解錠の判定が行われた後、機器からネットワーク経由（インターネット、またはBluetoothなど）で現在のステータスが送信され、モバイルアプリにも反映されます。 では機器側ではどのように判定を行うのでしょうか。 スマートロックでは、まず初回利用時に、施錠位置と解錠位置の設定を行います。 実際に家の鍵に取り付けた状態で施錠/解錠状態にし、モバイルアプリを利用して施錠/解錠位置として設定します。 このサムターン（鍵のつまみの部分）の位置によって機器が施錠位置と解錠位置を判定し、現在の状態がモバイルアプリに表示されることになります。 では以下の状態となったとき、モバイルアプリの表示はどのようになるべきでしょうか。 この状態では、実際に鍵は開いていない状況が高いと考えられるため、施錠されていると判定されるのか、それともサムターンが施錠状態の位置から解錠側へ動いているので、解錠されていると判定されるのか。 今回の場合、丁度施錠状態と解錠状態の中間に位置しているため、どちらを正解とするかは難しく、各種メーカーによって取扱いに違いがあるようです。 では次の例を見ていきましょう。 こちらの場合、大きく解錠側にサムターンが回っていますが、まだ完全に解錠位置に設定したところまでは回っていません。 モバイルアプリの表示も施錠状態のままであるとします。 実際に施錠されている状態なのであれば、モバイルアプリの表示は間違っていないことになりますが、取り付ける鍵の種類によっては、既にこの時点で解錠されてしまっているものが存在します。 つまり、実際には鍵が開いている状態であるにもかかわらず、機器側の判定、およびモバイルアプリの表示上は施錠されているということになります。 実際の状態を適切に反映できていないため、セキュリティ上問題があるといえます。 解施錠のログ スマートロックでは、解錠/施錠が行われた際の記録がログとして残るものが多いです。 複数人でそれぞれモバイルアプリを利用している場合、モバイルアプリにログインするアカウントに設定されているユーザー名が履歴に表示されます。 また、スマートロックを取り付けていても、手動で解施錠を行うことはできるため、手動で操作した場合には、手動で施錠/解錠したログが表示されるものが多いです。 このログの機能も、誰がいつ利用したかを把握できるために存在するものと考えられるため、常に正しいログが保存されている必要があります。 正しくログが保存されなかったり、ログが改ざんされたりするようなことがあれば、セキュリティ上問題といえます。 モバイルアプリでログを表示する際には、サーバ上に保存されたログを取得していることが多く、モバイルアプリで解施錠を行うと同時に、モバイルアプリからサーバに向けてログ情報が送信されている場合もあります。 モバイルアプリから送信されるログ情報を改ざんして、不正なログを送信できないか、送信時のリクエストをドロップし、サーバにログ情報を送信しないことでログを残さず操作できないか、などもチェックします。 他の例として、手動解施錠によるログの扱いを取り上げます。 モバイルアプリで解施錠した場合には、モバイルアプリからログ情報が送信されますが、手動で解施錠した場合には、どのようにログが送信されるのでしょうか。 あくまで一例となりますが、インターネットに接続可能なスマートロックであれば、手動で解施錠した後、機器からサーバに対してログデータが送信されます。 インターネットに接続できず、Bluetoothのみで利用するタイプのスマートロックの場合には、未送信のログ情報が機器内部に保存されており、モバイルアプリで解施錠を行った際に、モバイルアプリでの解施錠のログと同時に、手動解解施錠のログも送信されるようになっています。 手動による解施錠でも正しくログが保存される必要がありますが、ログが正しく保存されない状況はないか、という考えでチェックを行います。 施錠状態から、ゆっくりとサムターンを回して解錠した場合に、正しいログが残るのか、逆に高速でサムターンを回しても正しくログが残るのか。 ログが残ることが当たり前のように思いますが、実際に検証してみなければ、どのような挙動になっているかは分かりませんので、実際の動作をしっかりと確かめます。 まとめ IoT機器のシステムに潜在するセキュリティリスクと、検証方法の例についてご紹介しました。 IoTの分野は、今後も広がり続けていく分野と考えられており、より複雑なシステムが増えてくることが予想されます。 IoT機器では、サイバー空間からの攻撃によって機器が誤動作し、それを利用する人が怪我を負うなど、現実世界への影響も軽視できません。 このような問題を未然に防ぐためには、事前にしっかりとした検証を行うことが重要です。 AGESTでは、具体例として記載した探索型セキュリティテストを含めたIoT機器検証のサービスを展開しております。 セキュリティエンジニアとテストエンジニア双方の視点から、製品に含まれる問題を発見し、製品の品質向上に貢献いたします。 お困りごとがありましたら、お気軽に当社にご相談ください。 AGESTのIoT機器診断サービスの詳細はこちら から。 The post IoT機器に潜在するセキュリティリスクと検証方法とは？ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第5回となる今回から、オンチェーンデータのオンライン分析サービスのDuneを用いて、Ethereumを対象としたデータ分析の演習を始めていきます。 Hello Dune Dune は、ブロックチェーン上のデータ分析に特化したオンラインサービスで、類似サービスの中でも開始までのハードルが低く、コミュニティ機能やチュートリアルなども豊富なため、データ分析初学者の人にとってもおすすめなサービスです。 Duneのユーザは誰でも自分の分析クエリや可視化のためのダッシュボードを公開できるため、公開されているダッシュボードを見る用途だけでも有益なサービスです。今回は、実際に自分で新しいクエリを作成して実行してみることから試してみましょう。 なお、今回ご紹介するDuneの機能は2023年8月現在の仕様であり、今後のアップデートで変更が発生する場合もあるため、最新の情報は公式ページのドキュメントをご確認ください。ただし、ひとつのオンラインサービスであるDuneの仕様が変わったとしても、そこで使われているSQLの構文や知識は、他のサービスやデータベースでも通用する普遍的なものですので、Duneを入り口としつつも、ぜひ汎用的なSQLの知識を身につけていってください。 セットアップ 図1. Duneのダッシュボード一覧とアカウント登録画面（ https://dune.com/ ） Duneの公式ページにアクセスし、右上のSign upまたはSign inボタンから、アカウント登録またはログインをおこないます。アカウント登録には、ユーザネームとメールアドレス、パスワードの設定が必要です。ユーザネームは、クエリやダッシュボードを作成した際の作成者として表示されます。 アカウント登録後、 アカウント設定ページ でアイコンや各種SNSアカウントの連携、自己紹介文の追加が可能です。 また、MetaMaskなどのウォレットアプリをインストールしている方は、ウォレットアドレスとDuneアカウントを連携させることで、パスワードを使わずウォレット認証でDuneにログインできるようになります。 基本機能 Duneの基本機能として、他ユーザの作成したダッシュボードやクエリを検索できるDiscover機能があります。ダッシュボードやクエリにはタグ付けやお気に入り登録ができるため、ジャンル別のダッシュボードや人気のクエリなどを探すことができます。また、他ユーザの作成したクエリを自身のワークスペースにフォークしてきて、独自のクエリとして実行したり書き換えたりすることも簡単にできます。 クエリエディタ クエリエディタは、オンライン上でSQLクエリを記述し、実行するための機能です。公開されているクエリをForkしてくるか、画面上部のCreateボタンをクリックすることで、自身のクエリエディタを開くことができます。 図2. クエリエディタの表示例 エディタウィンドウでは、SQLの予約語やテーブル名などを補完してくれるオートコンプリート機能や、クエリの一部のみを選択して実行する選択実行機能などがあります。 また、クエリの一部をパラメタ化して実行時に決定できるようにしたり、特定の時刻やイベントに応じてクエリを再実行したりする機能もあります。 さらに、ChatGPTなどのLLM（大規模言語モデル）を応用した機能として、SQLクエリの内容を英語で説明してくれる機能や、英語の文章からSQLクエリを生成してくれる機能なども提供されています。 クエリの結果画面では、データを表形式で表示するだけでなく、棒グラフや円グラフなどで可視化する機能も備えています。 これらのクエリの結果を複数組み合わせて、ひとつのテーマで分かりやすくデータを表示させる機能がダッシュボードです。 図3. ダッシュボードの表示例 これらの機能は、アカウント登録さえすれば無料で使うことができますが、一部の機能はリソース制限があり、有料プランや有償のクレジットを購入することで追加のリソースを利用することができます。例えば、無料プランでは自分だけしかアクセスできないプライベートなクエリやダッシュボードの作成数に制限があったり、分析結果をCSV等でダウンロードできる数に制限があったりします。複雑なクエリを高速に実行するために実行エンジンのサイズをアップさせるためにもクレジットの消費が必要で、無料で手に入れられるクレジットを使い切った場合は、追加の購入が必要です。 また、独自のデータをアップロードして分析に活用したり、あるクエリの計算結果を永続化して再利用したりするには、有料プランの利用が必要です。 有料機能の詳しい内容については、 公式のPlansページ をご確認ください。 データテーブル クエリエディタの左側に、「Query Explorer」「Data Explorer」「Version History」といったアイコンが並んでいます。デフォルトではData Explorerが選択されており、Duneで提供されているデータセットとして、「Essentials」「Raw」「Decoded projects」「Spells」「Community」といったカテゴリが存在します。 図4.データテーブルのカテゴリ関係図 まず、「Raw」データは、本連載の第2回 ビットコインの仕組みや、第3回 イーサリアムの仕組みでご紹介したような、ブロックチェーンのデータ構造そのものに近いブロックやトランザクションのデータを示します。 しかし、Ethereumのような汎用的なスマートコントラクトの実行基盤では、トランザクションの中身はコンピュータが解釈しやすいバイナリ形式になっていることがあり、人間にとっては扱いにくいデータです。そのようなデータをプロジェクトごとにデコードして人間にも理解しやすい形にしたものが「Decoded projects」データです。例えば、OpenSeaやUniswapといったブロックチェーンサービスの仕様ごとに、オンチェーンデータがデコードされ格納されています。 さらに、それらのデータセットを組み合わせて、汎用的に使いやすいデータセットとして提供されているものが「Spells」です。例えば、NFTプロジェクト全般の取引情報を集約した「nft.trades」といったテーブルがあります。余談ですが、Duneではクエリを記述する分析者のことを「ウィザード（魔術師）」と呼び、記述されたクエリを「スペル（呪文）」、クエリのコレクションを「スペルブック（呪文書）」と呼んでいます。これらの「Spells」を生成するクエリは、Dune公式やコミュニティメンバーによって作成・管理されています。 また、公式のオンチェーンデータだけでなく、ブロックチェーン以外のオフチェーンデータを組み合わせてデータ分析をおこないたい場合もあります。例えば、ブロックチェーン上のアドレスに対するサービス名やユーザ名などのラベル付をおこなった「addresses」テーブルなどがあります。Duneやコミュニティによって提供されたオフチェーンデータを「Community」から利用できます。 上記のさまざまなデータセットから、特に頻繁に使用されるデータセットを集めたものが「Essentials」になります。 Hello Query それでは、クエリエディタから最初のクエリを作成し、実行してみましょう。サンプルとして、データテーブルのカテゴリから「Essentials」を選び、nft.tradesのテーブルを探します。テーブルの右横に並ぶプレビューのアイコンにフォーカスすると、このテーブルの中身のサンプルを表示してくれます。 図5. nft.tradesテーブルのサンプルデータ 今回は、サンプルとなるクエリをAIによって自動生成する体験をしてみましょう。テーブルのアイコンの中から「Wand（魔法の杖）」というボタンをクリックすると、クエリエディタの上部に「Using nft.trades, 」というフォームが追加されるでしょう。Duneの生成AIの場合、クエリ対象となるテーブル名は文章中で明示してあげる必要があり、このようなテンプレートが用意されています。 試しに、「Using nft.trades, what was the daily trade volume of opensea」という文章に変更し、OpenSeaの一日あたりの取引総額を計算するクエリを生成してみましょう。OpenSea ※1 とは、Ethereumブロックチェーンなどで発行されたNFTと呼ばれるデジタルデータをオンチェーン上で売買できるマーケットプレイスサービスです。「Generate SQL」ボタンを押してしばらく待つと、クエリエディタに自動生成されたSQLが入力されます。生成されるSQLは確定的ではありませんが、筆者の例では下記のようなクエリが生成されました。 コード1 . OpenSeaの一日あたりの取引総額を計算するクエリ（自動生成） SELECT   DATE(block_time) AS trade_date,   SUM(amount_usd) AS daily_trade_volume FROM nft.trades WHERE   project = 'opensea' GROUP BY   DATE(block_time) ORDER BY   trade_date DESC クエリエディタの「Run」ボタンを押してこのクエリを実行すると、図6のような実行結果が得られました。 図6. コード1.の実行結果 ※1 OpenSea ビジュアライズ この実行結果を、グラフでビジュアルに確認してみましょう。「New visualization」のタブを選択し、「Line chart」を選んで「Add visualization」ボタンをクリックすると、自動的に図7のような折れ線グラフが生成されると思います。 図7. 実行結果の折れ線グラフによる可視化例 図7のグラフを見ると、所々で急激な取引額の増加が見られます。これが、取引件数の増加によるものなのか、一取引あたりの取引額の増加によるものなのかを確認するため、取引件数を計算するカラムを追加してみましょう。 さきほどのWandの文章フォームを「add column of daily trade count」と書き換えて、「Generate SQL」から「Edit SQL」に切り替えて実行してみます。 コード2 . 取引件数のカラムを追加したクエリ（自動生成） SELECT   DATE(block_time) AS trade_date,   SUM(amount_usd) AS daily_trade_volume,   COUNT(*) AS daily_trade_count FROM nft.trades WHERE   project = 'opensea' GROUP BY   DATE(block_time) ORDER BY   trade_date DESC SELECTとFROMの間に、「COUNT(*) AS daily_trade_count」という記述が追加されました。この記述が、日別の取引件数を計算するコードのようです。 このクエリを実行し、さきほどの折れ線グラフのY軸に追加してみましょう。クエリを実行すると、「daily_trade_count」というカラムが結果に追加されます。これを、Line chartの「Y column 2」に指定します。これだけだと、Y軸のスケールが違いすぎて取引件数のグラフがほぼ見えないため、「Y-axis options」で「Enable right y-axis」を有効化し、2つのスケールを利用できるようにします。さらに、画面最下部の「Series」パネルで、「daily_trade_count」の「Y-axis」を「Right」としてあげると、図8のような折れ線グラフが表示されます。 図8.取引件数・取引額による折れ線グラフの表示例 このように、Duneの機能をフルに活用すれば、ブロックチェーン上のデータを好きな形で加工してビジュアライズする工程が簡単に実装できます。 ただし、AIの機能に依存しすぎては、生成されたSQLの正しさに確信が持てず、想定しない挙動となった場合の修正も困難です。また、どのようなデータテーブルを組み合わせる必要があるかは、いまのところ人間が明示的に指定してあげる必要があります。 Duneを使いこなしてオンチェーンデータ分析をおこなうためにも、本連載の後半で、SQLの基本構文に関する知識と、オンチェーンデータのデータ構造についての知識を身につけていきましょう。 基本的なSQL構文 コード1.～2.で示したSQLクエリをサンプルとして、基本的なSQL構文について解説します。 SQLの構成要素は、基本的に「文（statement）」「句（clause）」「式（expression）」の3要素があります。句は「節」とも表現されますが、ここでは句に統一します。式はさらに細かな構成要素に分けることができますが、SQLクエリの大まかな構造を理解する上では、まず「文・句・式」のレベルで理解することをおすすめします。 図9. サンプルクエリにおける文・句・式への分解 文 (Statement) SQLにおける文は、クエリを実行可能な最小単位です。複数の文が存在する場合は「；（セミコロン）」で文を区切りますが、Duneのクエリエディタのように基本的に1つの文しかないようなケースではしばしば省略されます。 文の例として、UPDATE文やDELETE文なども存在しますが、Dune上でデータ分析をおこなう上で登場するほとんどの文がSELECT文なので、まずはSELECT文を覚えておけば問題ありません。 句（Clause） SQLにおける句は、文を構成する要素であり、文における意味の最小単位として考えることができます。例として、SELECT句やFROM句、WHERE句などがありますが、SELECT句は「どんな情報を表示したいか」、FROM句は「どこからデータを取得したいか」、WHERE句は「どんな条件でデータを絞り込みたいか」といった意味を定義する役割を持ちます。 多くの句単独では文にはなれないので、例えばFROM句のみのクエリやWHERE句のみのクエリは、クエリエンジンで実行できません。SELECT句のみのクエリは、単独でSELECT文としても解釈できるので実行可能ですが、多くの場合は「SELECT ～ FROM ～ WHERE ～」の3つの句がセットで用いられます。 コード1.～2.で利用されているその他の句として、AS句は「カラムに別名を付与する」、GROUP BY句は「レコードをグルーピングして新しいテーブルを作る」、ORDER BY句は「レコードを並び替える」といった意味があります。 どのような順番で句を使用できるかは、文の構文として決められており、例えば「FROM ～ SELECT ～」といった順で書かれたクエリはエラーとなります。 式（Expression） SQLにおける式は、句を構成する要素であり、ある単一の値（スカラ値）やテーブル（リレーション）を返す表現です。 例えば、「1+1」という表現は2を返す式ですし、コード1.～2.の中の例では「DATE(block_time)」は日付を返す式、「SUM(amount_usd)」は引数の合計値を返す式、「nft.trades」はテーブルを返す式、「project」はprojectカラムの中身を返す式、「‘opensea’」は文字列のopenseaを返す式、「project = ‘opensea’」はTRUEやFALSEといった真偽値を返す式です。 特に、TRUEやFALSEを返す式を、特別に述語（predicate）と呼びます。クエリの構成要素を考える上では「文・句・式」の3要素でも十分なのですが、第4回 ビッグデータ分析のためのSQL基礎でも解説したとおり、SQLは関係代数と呼ばれる演算を実装した言語であり、この関係代数は集合論と述語論理をベースに設計されています。そのため、SQLを学ぶ上でも、この述語の概念を理解することが重要となります。 次回予告 今回の記事では、Duneのサービスの特徴や機能を紹介し、はじめてのクエリを実行する手順を示しました。また、文・句・式といったSQLの基本的な構成要素について解説しました。 次回の記事では、データ分析で役立つSQLの構文を紹介しつつ、引き続きオンチェーンデータ分析の演習をおこなう予定です。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習 1 The post 【第5回】Ethereumデータ分析演習 1 first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第4話です。 今回はまたまたまーくーの学び直し！、今や古典といっても良い？書籍「基本から学ぶソフトウェアテスト」を読んで、初版から20年以上たった今でも活かせる内容があるのか？ないのか？会話形式でお話させて頂ければと思います。 最後まで楽しんで読んで頂ければ幸いです！ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 ソフトウェアテストの流れに、流れて、流れて・・・一日が街に恵む日差しで干からびそうになっている今日この頃です。 くまねこ QA業界経験1x年のエンジニア。 アスファルトのキラキラを追いかけていたところ、干からびかけているまーくーに話しかける。 イラストby くまねこ まーくー、どうしちゃったんでしょう…？今日も二人のやりとりをお楽しみください！ 学び直し！の道は長く険しい？？？ あっ、まーくーさん。お疲れ様です。だいぶカラカラになっているようですが…どうしたんですか？ もう、ほんと心がカラカラだよ テストって、覚えることが多くて大変だよなぁって思ってたんだけど、我らが神？の本（ 知識ゼロから学ぶソフトウェアテスト ）を読んでいたら、こんなことが書いてあって・・・ ソフトウェアというものは四つの仕事しかしない。なので君らはその四つのふるまいをテストすれば良いのだ。 知識ゼロから学ぶソフトウェアテスト とか、 （前略）おいらたちテストの技術の進化は非常に遅いし、学んだ技術が陳腐化しないというのは非常に楽なことなんだよ 知識ゼロから学ぶソフトウェアテスト とか、すごーく簡単なもの的にかいてあるんだけど、今でも全然簡単ではなくて・・・ なるほど…僕も「しっかりと理解してやれているかい？」って言われると自信が無いですね… でも、泣き言ばっかり言ってられないし、陳腐化しないのなら20年以上前に神の師匠が書いた本が、確か家の本棚にあった気がしてて・・・いっそのことそれを読んでやれって思ってるんだよねー 前々回 、アジャイルソフトウェア開発技術者検定試験に挑戦した時の気持ちを思い出していきましょう！背水の陣！バックウォーターフォーメーション！タフになれって風が吹いてますよ！ ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 基礎から学ぶソフトウェアテストとは 「 基本から学ぶソフトウェアテスト 」という本は、本の紹介ページによると「世界で最もたくさん読まれているソフトウェアテスト/品質保証の実践的な教科書です。」らしく、神の師匠Cem Kanerさん他が書いているんだよね。 すごいですね…まーくーさんが今持っているのがその本なんですね。どんな感じの内容になっているんですか？ 目次は ↓ みたいな感じで、テストの基本編、テスト技術編、テストのプロジェクトやテストチームの管理、付録としてよくあるソフトウェア不具合まで載っていて、460ページ以上ある辞書みたいな教科書なんだ(笑) 目次 第1部　基本編 　第1章　テストの進め方 　第2章　テストの目的と限界 　第3章　テストの種類と位置付け 　第4章　ソフトウェアエラー 　第5章　障害の報告と分析 第2部　テスト技術編 　第6章　障害管理システム 　第7章　テストケースの設計 　第8章　プリンタ（およびその他デバイス）のテスト 　第9章　ローカライゼーションテスト 　第10章　ユーザマニュアルのテスト 　第11章　テストのツール 　第12章　テストの計画とドキュメント 第3部　テストプロジェクトやテストチームの管理 　第13章　開発全体におけるテストの役割 　第14章　ソフトウェアの不具合に対する法的責任 　第15章　テストチームの管理 付録　よくあるソフトウェア不具合 知識ゼロから学ぶソフトウェアテスト おおお…まさにバイブル！すべてはここにあり、ですね。でも今回でこのボリュームを学び直すには、少し大変じゃないでしょうか。（少しづつ進めてほしい気持ち…ニヤついてみよう…ニヤニヤ） さすがにね、いっぺんに全部は・・・（私も無理）今回は古典と言ってよい基本から学ぶソフトウェアテストの第1部第1章、第2章を読んで、学んでいこうと思う！ Yeah～! \ /（訳：気持ちが通じた～！） 序文を読んで まずは序文からですね…ふむふむ。本書は、受入テストは別として、命に関わるようなソフトウェアについては対象外として記載がありますね。命に関わるようなソフトウェアだと、プロジェクトのプロセスとか厳格になってきますよね。本書の対象はそれ以外のソフトウェアテスト、という理解で読み進めた方が良さそうですね。 あ、そこ気付いた？そういう場合は他の本をお勧めしている(笑)。また面白いのが、 この本が対象にするのは、必ずしもみんながルールを守らない、または守るつもりがない、もしくは守る必要がないときのテストの進め方だ 知識ゼロから学ぶソフトウェアテスト って述べているんだよ。厳密にルール化して開発していて、それに則ってテストが出来るなんてそうそうないよね。どのプロジェクトでもルールはあるけど、より良くしようとか、まだルール化できていないとか、暗黙知とかがそれぞれにあって、把握するのに労力が必要だけど、それを前提としてくれているところがユニークだと思った。そういった状況下でも応用可能な視点で書かれてるんだろうな、と期待させてくれるよね。 確かに…「こうあるべき！」という内容だと、実際の現場にうまく当てはまらなかったりして逆にカオスになっちゃう話とか、聞いたことあるかもです…。そういう意味でも、今回の学び直しによって、現在の業務に活かせる学びがありそうでワクワクしてきました！Exciting！ さっそく、第1部の第1章から読み進めましょう！ OK！Come on！↷ 第1章　テストの進め方を読んで 第1章は「テストの進め方」について、簡単なプログラムに対する初期テストを題材に説明されているね。テストの段階という単位で説明がされているんだけど、書籍発行時の50年前の論文も参照して書かれていて歴史を感じると同時に、冒頭に書いた「学んだ技術は陳腐化しない」という神の言葉が思い返されるね…。 そうですね。実際にテスト業務を担当している立場からすると、テストの第一段階で「当たり前のテストから始めること」というところが基本にして真髄だな、と感じました。考え抜いた複雑なテストを早くやりたいところですが、まずはテスト対象のプログラムの「当たり前」のことがしっかりと動作しているかを確認し、徐々に複雑なテストを実施するっていうことは、私たちもやってましたが改めて大事なんだなぁって。 そうだねー。「当たり前」のところが動作してこそ、複雑なテストが意味を成すものね。複雑なテストとから実施して不具合が出てしまった場合、原因も掴みずらいし、手戻りが発生してしまうからね。 また、境界値テストの重要性についても書かれていて、JSTQBのFLで取り上げられている技法ですし、改めて学び直しておきたいです。 「境界値分析」をテスト設計に取り入れる 初期テストという条件だからかもしれないけど、即興的にその場で考えたテストを行う、というところも興味深かったね。本能を信じて「くさい」部分をテストするなんて、ちょうど 前回 くまねこさんが話していた探索的テストにも通じる考え方なんじゃないかな…。 確かに！なんだか、古来から伝わる伝説の技のようです。エンシェント！（ニヤニヤ） そうだね！（しまった、変な方向に誘導してしまった まぁ楽しそうだからほっとこう笑）第1段階はここまでにして、第2段階の話もしてみようか。 ここでは、不具合に関する記載がメインですね。報告した不具合に対する開発回答の捉え方の所は、現場でも参考になりそうです。例えば開発からの回答が「修正しない」だったとしても、ユーザーから見たら途轍もなく重要であることが伝わっていない可能性もあるから、そこは伝わるまで手を尽くす必要がある。開発とのコミュニケーションが大切ということを、ここでも改めて認識することができました。テストのメンテナンスや再テストなど、テストサイクルを繰り返していく上でのポイントも、参考になりました。 そうだね。現在はAIも登場してきて、色々とソフトウェアテストを取り巻く環境が変わっていく所だと思うけど、開発者やステークホルダーとの関係を良好にすることは、より良い品質の製品を作っていくためには大事だよね。（よし、第1章をきれいに仕上げた…！） Yeeeaaah～! \ /（訳：まーくーさん良いこと言ったぁ～！）この勢いで、今日は第2章までいけそうですか…？（今日はここまで…ここまで…祈！） オゥーライ！第2章までいくよ！ Yeeeeeeaaaaaah～! \ /（訳：うげぇえええ～！） 第2章　テストの目的と限界 第2章は「テストの目的と限界」ですか…ちょっとセンセーショナルなタイトルですね。。。 ここで述べられているのは、まず「完全なテストは出来ない」し、「プログラムの正当性の証明も出来ない」ということ。そのうえでテストの目的として、「不具合の検出」、「不良の修正」を挙げているね。詳しい戦略とかは、後段の章で述べるみたいだけど。 「完全なテスト」については、「全入力テスト」「全パステスト」「設計上の問題の全件検出」は不可能であると説明されていて、「完全なテスト」が不可能である時点で「プログラムの正当性の証明」も完全には出来ないと述べている。 ふむふむ。この辺りの考え方は、ソフトウェアテストのテスト7原則の「全数テストは不可能」「テストは欠陥があることは示せるが、欠陥がないことは示せない」「「バグゼロ」の落とし穴」に通じる考え方ですね！ 個人的にはテストに関するバイアスについての以下の説明が、ふむふむとなったよ。心理的なバイアスで、不具合に気付かなくなるってのはテスト管理の面でも気を付けなきゃだよね。 プログラムは正常に動くと期待すると、プログラムは正しく動くように見える。と言うより、バグを見逃してしまう。プログラムは動かないと考えると、不具合を見つける可能性は高くなる。バグを報告すると罰せられるなら、不具合を見逃してしまう。報告しなくなるのではなく、不具合に気付かないのだ。 知識ゼロから学ぶソフトウェアテスト ふむふむふむふむ。 あっ…（また始まった…？） ふむふｍ…これは確かにそうですね。「プログラムは動かない～」のところ、エラー推測テストはこの考え方に近いのかな、と感じました。テスト担当者の心理的な面も書かれていて、共感できました！（あれっ…まーくさん、なんでちょっと意外なリアクションなんでしょ？） オゥーケイ！第2章はこのぐらいにしようか！（良かった。今回はちゃんと考えてただけだった笑） はーい！（干からびていたまーくさんもテンション上がって潤っている～！） まとめ 基本編の最初の部分を読んだだけだけど、テストの進め方の「当たり前のテストから始める」や「完全テスト」は不可能といった、現在の考え方のベースになったであろう記述が多々あって、古典とは言え学び直しにとても有効そうだと感じたね。 そうですね。まだ序盤の序盤ですが、今までの我々の経験や知識は、なかなか陳腐化しないということが改めて理解できて良かったです。 とはいっても、時代を経るにつれ変わるところ変わらないところがあるはずだから、今後もしっかりと読み進めていこう！ちなみに・・・第2章「テストの目的-不良の修正」に出てくる、 テストの担当者はプログラムを破壊するつもりでテストするが、大局的には建設的な仕事である。鍛え上げるために、しごいているようなものだ。 知識ゼロから学ぶソフトウェアテスト って記述を読んで、テスト対象のプログラムに対して、厳しくも優しくテストして行く気持ちは大事なんだよなって、再認識できたよ。 まさにULTIMATE CRUSH！ですね。ララ Yeeeeeeeeeeaaaaaaaaaah～! \ / 次回予告 今回はここまでにして、次回の記事はどんな感じにしようか？ 次回のまーくー＆くまねこは、 まーくー、JSTQB ALTM試験、本当に受けるの？どうでしょ！（仮） くまねこ、JSTQB FL試験を通り過ぎる！（仮） の2本でーす。 最後まで読んでいただき、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー ﾉｼ ﾉｼ ゆるっと♪シリーズ 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ The post ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ first appeared on Sqripts .

はじめに 前回は、BDDを構成する3つのプラクティス「発見(Discovery)」「定式化(Formulation)」「自動化(Automation)」の概要を紹介しました。 今回以降は、 第1回 の記事でも用いた自動販売機を題材にして、前回の記事で紹介した、「BDDを用いたプロセス」を行ってみます。 本記事では、「発見(Discovery)」の部分までを、具体例を交えつつ説明します。 1. ユーザーストーリーを選ぶ ユーザーストーリーマッピングなどを用いて、予めユーザーストーリーを作成しておきます。 そして、次Sprint以降で開発する可能性が高いユーザーストーリーをピックアップします。 今回は、自動販売機に関する以下のユーザーストーリーをピックアップします。 タイトル ：顧客が自動販売機で飲み物を購入する As a ：顧客の立場で、 I want ：自動販売機から飲み物を購入したい so that ：店舗に行かなくても飲み物をすぐに得られるように 2. 要件ワークショップ 1で選んだユーザーストーリーに対して、要件ワークショップを行います。「要件ワークショップ」という言葉は、組織によっては「リファインメント」「スリーアミーゴス」などと呼ばれたりします。 「発見(Discovery)」のフェーズでもある要件ワークショップでは、ドメインを構造的に理解していく協調作業を行います。その際には、 明確な具体例を使用することが重要 です。 要件ワークショップでは色々なやり方があるのですが、今回は実例マッピングを用いてみます。 実例マッピング 発見(Discovery)を行う活動として「実例マッピング(Example mapping)」というものがあります。 詳しいやり方については、実例マッピングの考案者であるMatt Wynneが説明している「 Introducing Example Mapping （邦訳： 受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」 ）」や、私が解説している スライド や 記事 を参照ください。 ここからは、今回の題材である「顧客が自動販売機で飲み物を購入する」というユーザーストーリーに対して、実例マッピングを作成していきます。 手順0. 対象のユーザーストーリーを記載する 対象のユーザーストーリーを黄色の付箋で貼ります。 手順1. 具体例を1つ記載する 手順0で記載したユーザーストーリーを行うような具体的な例を考え、緑色の付箋で貼ります。例えば以下のような感じです。 例えば以下のような感じです。 手順2. 具体例が成立するためのルールは何か考える 手順1で緑の付箋に書いた具体例が成立するためにはどのようなルールがあるか考えます。 もしも思いつかない場合は、別の具体例（緑の付箋）を書いてみると良いかもしれません。 今回の場合、以下のようなルールが考えられそうです。 自動販売機に投入できる硬貨がありそう 選んだ飲み物は出てきてほしい 飲み物を買うとお釣りが出てきそう（連続購入はできなさそう） これらの考えを元に青色の付箋を記載していきます。 手順3. 文章のリファクタリングを行う 実例マッピングを書いていく中で、言葉が揃ってないことに気付くことがあります。その際はTDDでのリファクタリングと同様に、言葉のリファクタリングをしていきましょう。 例えば今回の場合、以下のようなことが気になりました。 ・「購入する」と「買う」という単語が存在している。どちらかで揃えられそう。 ・「買う」という言葉自体が、どのような振る舞いを表しているのか分かりづらい。何をもって「買う」という状態を表すのかはっきりさせた方が良い これらを元に、実例マッピング内に書いた文章をリファクタリングした結果が以下の通りです。（太字＋下線が変更した部分） 手順4. ルールを簡潔に表現している具体例を書く 手順3で作成したルール（青色の付箋）を簡潔に表現できる具体例（緑色の付箋）を記載します。 例えば、以下のような感じです。 手順5. 疑問点が出てきたら、赤い付箋で残しておく 実例マッピングを作っていく際に、その場では解決できないものが出てきたら、疑問点として赤い付箋に残しておきます。 例えば、以下のように置きます。 疑問点は疑問点として書き出しておき、要件ワークショップの時間や頭のリソースを疑問点の解消に費やさないことが大切です。 手順6. 手順1〜5を繰り返す ここまで説明した手順を繰り返します。 なお、手順通りの順番でなくても良いです。例えば、文章のリファクタリングは都度行っても良いですし、ルール（青色の付箋）を最初に書いて、ルールを表現する具体例（緑色の付箋）を書いても良いです。 実例マッピングを行うことのメリット 実例マッピングを行うことで色々なメリットがあります。 メリット1. 「Unknown unknowns（知らないことを分かっていない）」ものが明確になり、他の状態へシフトできる 前回の記事で紹介したラムズフェルド行列において、今まで、どんなことが「Unknown unknowns（知らないことを分かっていない）」状態（ラムズフェルド行列の右下）だったのか明確になります。 疑問点として赤い付箋に残しているものは、「Unknown unknowns（知らないことを分かっていない）」状態から「Known unknowns（知らないことを分かっている）」状態（ラムズフェルド行列の右上）へとシフトできています。 また、具体例として青い付箋に残しているものは、「Unknown unknowns（知らないことを分かっていない）」状態から「Known knowns（知っていることを分かっている）」状態（ラムズフェルド行列の左上）へとシフトできています。 メリット2. 開発開始までに解決しなければならない課題が明確になる 疑問点（赤い付箋）が解決しないまま開発開始しようとする行為は、要件が固まっていないまま開発開始を試みているのと同義です。 開発開始前にPOやビジネス関係者と話し合って、赤い付箋の解決に向かうべきという指針を立てることができます。 メリット3. ユーザーストーリーやルールの大きさが適切か把握することができる 今回の例では、青い付箋が3枚程度、緑の付箋も最大で3枚程度になりました。 しかし、これらの付箋の枚数がもっと多かったりすると、ルールやユーザーストーリーの内容を再考した方が良いということが分かります。 例えば以下のように、緑色の付箋が非常に多くなってしまった場合。 これは、いくつもの具体例を示すことで、やっと1つのルールを表現していることになります。つまり、それだけルールが複雑になってしまっていることが示唆できます。 このようになってしまった場合は、複雑になっているルールをいくつかのシンプルなルールに分けることを検討しましょう。 別の例として以下のように、青色の付箋が非常に多くなってしまった場合。 これは、いくつものルールを用いることで、やっと1つのユーザーストーリーを表現していることになります。 このままですと、ユーザーストーリーが複雑であるため、プランニングの際に考えるストーリーポイントも大きな数になる恐れがあります。 このようになってしまった場合は、ユーザーストーリーをいくつかの小さなユーザーストーリーに分けることを検討しましょう。 メリット4. ルール（青い付箋）は受け入れ基準として使うことができる ルール（青い付箋）は、Scrum等でよく使われる「受け入れ基準(Acceptance Criteria)」に転用が可能です。 例えば、今回の自動販売機の例の場合、青い付箋で書いた以下のものが受け入れ基準の候補となります。 自動販売機に投入できる硬貨が決まっている 選んだ飲み物が自動販売機から出てくる 飲み物を買うとお釣りが出てくる おわりに　〜協調作業を伴う「発見(Discovery)」はBDDで最も大切〜 今回は、要件ワークショップの中で行う「発見(Discovery)」のプラクティスとして実例マッピングを紹介しました。 前回の記事でも書いたように、協調作業が行われる「発見(Discovery)」がBDDの中で最も大切です。 またここまでの説明から分かるように、「発見(Discovery)」のフェーズにおいて、「自動テストを書くかどうか」は全く論点ではありません。 一旦、自動テストのことは頭の片隅に置いておいて、ビジネス関係者と協調することを大切にして「発見(Discovery)」のプラクティスを行ってみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング The post TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング first appeared on Sqripts .

いよいよ本連載も終盤にさしかかってきました。 これまでは テスト自動化ツールの選び方 テスト自動化の普及の仕方 テスト自動化の学び方 などについて説明してきましたが、今回と次回はタイトルにもあるように、テスト自動化とテスト設計について考えていきます。 筆者の見てきた範囲では、テスト設計をはじめとしたテストプロセスとテスト自動化とは”別物”のように考えられることがあるように思います。 しかし、テスト自動化についても当然テスト設計を含むテストプロセスが関係してきます。 自動化対象のテストを用意する際の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 .