ソフトウェア開発プロジェクトにおいてプロジェクトマネージャーや関係者が直面するお悩みは、リソース制約の中でのスケジュールプレッシャーや様々な要件変更要求への対応を余儀なくされるなど、多岐にわたります。どのように課題に対処していくのがよいのでしょうか。 プロジェクト品質マネジメントのポイントを解説します。 プロジェクト品質マネジメントの失敗とは？ プロジェクト品質マネジメントの勘所を探る前に、過去に発生した障害の事例を紐解いてみましょう。記憶に新しい障害事例もあります。何か、教訓や成功のためのヒントはないでしょうか。 プロジェクト品質マネジメントの失敗事例 全国銀行データ通信システム（全銀システム）の障害（2023年）により大手金融機関など10金融機関で約250万件の送金が滞る障害が発生。 機器更新により処理量が増え、メモリ不足に陥った。事前のテスト不足の可能性もある。 「COCOA」接触情報の通知されないバグ（2021年） 陽性の登録者と１５分以上の接触があった場合に利用者に通知するシステム。陽性者と接触したにも関わらず通知されない不具合が発覚。 原因は、2020年９月に実施したバージョンアップの影響。 銀行のATM障害（2021年） 大規模なシステム統合プロジェクトにおいて、ATMの障害発生。取引が一時できなくなる状況が発生。2021年に８回以上の障害が発生。 システム統合とテストの不備に起因。 いずれも、大規模なプロジェクトにおける障害です。利用者数が大きく、資産や人命にかかわる障害のため影響範囲も大きいものでした。 未然に防止するためには、プロジェクト品質マネジメントのうちの何が不足していたのでしょうか？ 品質管理・テスト管理の考え方のコツを取得！ プロジェクト品質向上編 プロジェクト品質マネジメントとは？ プロジェクト品質マネジメントとは、プロジェクトの成果物やプロセスが所定の品質基準を満たすように管理するプロセスのことです。 ソフトウェア開発におけるプロジェクト品質マネジメントの最初のステップは、品質計画の策定です。 ソフトウェア開発におけるプロジェクト品質マネジメントの流れ 品質計画の策定 プロジェクトの品質計画を策定します。この計画は、プロジェクトのゴール（品質目標、品質基準、品質管理プロセス、テスト戦略など）を定義します。 品質基準の設定 品質計画に基づいて、プロジェクトで達成するべき品質基準を設定します。品質基準は、成果物やプロセスをどのように評価するかを定義したものです。 品質保証 品質保証は、プロジェクトが品質目標を達成するためのプロセスと活動を含みます。プロジェクトの品質マネジメントプロセスが適切に実行されて、品質基準に沿っていることを確認します。つまり、「満たすべき要求事項が満たされている」という事実を証明するための一連の活動が品質保証です。 品質管理 品質管理は、品質を直接的に向上させる活動です。プロジェクトの進行中に品質を監視し、問題を特定し、改善策を実施するプロセスです。例えば、品質チェックリストの作成、テスト、品質監査、問題の追跡と修正などが含まれます。 品質テスト 品質マネジメントには、システムやソフトウェアのテストが不可欠です。ユーザーテスト、結合テスト、パフォーマンステスト、セキュリティテストなど、さまざまなテスト活動が品質確保に役立ちます。 フィードバックと改善 プロジェクトの品質に関するフィードバックを収集し、問題を特定したら改善策を導入します。過去のプロジェクトからの教訓やベストプラクティスを活用して次のプロジェクトの品質をより向上させていきます。 品質報告 プロジェクト品質に関する情報（プロジェクトの品質状況と進捗、教訓など）を適切なステークホルダーに報告します。 ソフトウェア開発プロジェクトにおける品質マネジメントに取組むことで、品質計画やリスク管理など時間とリソースもそれなりに必要になります。「ちょっと大変だなぁ」と思われたでしょうか？しかし、市場に製品やサービスがリリースされた後で障害発生したときの影響はどのようなものがあるでしょうか。 利便性の低下 顧客満足度の低下 口コミの影響 競争力の喪失 顧客の離脱 製品やサービスの障害発生による影響を最小限に抑えるためにも、適切な品質マネジメントを行うことで品質向上やリスク削減が狙えるでしょう。ソフトウェア開発プロジェクトにおける品質マネジメントとその実行をサポートし、プロセスの改善と品質を確保するには監査の活用も有効です。 テストの専門家が体系化した3つのメニューから構成された ソフトウェアテストの教育サービス ソフトウェア品質教育サービス「バルカレ」のご紹介 ソフトウェア開発におけるプロジェクト品質マネジメントの監査に関連する規格 ソフトウェア開発プロジェクトにおけるプロジェクト品質マネジメントの監査に関連する規格がありますので、いくつかご紹介します。 プロジェクト品質マネジメントの監査に関連する規格 ISO 9001: ISO 9001 品質マネジメントシステムに関する国際標準です。ソフトウェア開発プロジェクトにおいて、ISO 9001の要件を遵守することにより、品質マネジメントの基準が確立されます。この規格は、プロセスの改善、品質目標の設定、顧客満足度の向上などを促進します。 ISO/IEC 12207: ISO/IEC 12207 ソフトウェアライフサイクルプロセスに関する国際標準です。この規格は、ソフトウェア開発プロセス全体を包括的にカバーし、品質マネジメントに関連するプロセスや要件を提供します。 ISO/IEC 15504 (SPICE) ソフトウェアプロセスの評価と改善に関する国際標準であるISO/IEC 15504は、ソフトウェア開発プロセスの品質と成熟度を評価するための枠組みを提供します。これにより、プロジェクトの品質マネジメントを向上させるためのガイダンスが提供されています。 CMMI (Capability Maturity Model Integration): CMMI ソフトウェア開発プロセスの成熟度を評価し、向上させるためのモデルです。CMMIはプロセスの改善に焦点を当て、品質マネジメントに関連するベストプラクティスを提供しようとするものです。 ITIL (Information Technology Infrastructure Library): ITIL ITサービスマネジメントに関するベストプラクティスのセットで、品質マネジメントとサービス品質向上に関連するガイダンスを提供します。特にソフトウェアの運用および保守において役立つことがあります。 これらの規格は、プロジェクトに適切な規格を選択し、実装することで、品質マネジメントを強化し、プロジェクトの品質向上に貢献する可能性があります。プロジェクト品質マネジメントと品質監査は、いずれも品質向上とリスク削減に対するメリットがありますが、追加のコストや時間が必要になります。プロジェクトへの要求やリスクに応じて、適切な対応を行うことが大切です。 まとめ 冒頭で紹介した障害発生事例では、要因として「テストが不足していた」というものがありました。要因はそれだけではないと思いますが、「品質テスト」は顧客に商品やサービスが提供される前の、最後の砦として重要な位置付けにあります。 プロジェクトにおいてどのようなリスクがあるかは、個々のプロジェクトによって異なりますが、そのプロジェクトに応じた品質計画、そして、その計画に応じた品質テストが必要になります。 弊社は、テストの専門会社として多くのプロジェクトへの参画を通じてお客様の開発プロジェクトのご支援を行っております。ソフトウェア開発プロジェクトにおける品質改善について、ぜひご相談ください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 事例から学ぶプロジェクト品質マネジメント first appeared on VALTES テストサービス .

シナリオテストってよく分からなくないですか？実は、シナリオテストの悩みを解決するヒントが、演劇や映画などの「物語」にあります！ 「演劇？映画？ソフトウェアテストに物語は何も関係ないのでは？」 と思われるかもしれません。しかし、「物語」の仕組みを紐解くと、「シナリオテスト」でどのようなシナリオをテストすれば良いのか、その考え方が分かります。なぜ、シナリオテストのヒントが演劇や映画の「物語」から得られるのか？シナリオテストでは、どのようなテストをすれば良いのか？ シナリオテストのポイントを物語という面から解説いたします！ シナリオテストってよく分からなくないですか？ シナリオテストとは、その名の通り、シナリオで行うテストのことです。 しかし、いざシナリオテストのテストケースを作成しようとすると、どのような「シナリオ」のテストを作成すれば良いのか分からず、戸惑ってしまいませんか？シナリオテストは、開発においてほぼ必ずと言って良いほど行われるテストであり、品質の良いシステムが開発出来ているか確認する重要なテストです。シナリオテストのことをよく分からないままテストを実行しても、良い品質には繋がりません・・・。 なぜ、良い品質に繋がらないのでしょう？その理由は、よく分からないままテストケースを作成しようとした時に出現する、ハマりやすいワナが存在しているからなのです。 テスト技法入門ガイドブック シナリオテストでよく陥ってしまうワナ では、シナリオテストには、どのようなワナが潜んでいるのでしょうか。シナリオテストは大事なテストです。そのため、よく分かっていないながらも、テストを担当する以上、しっかりとしたテストケースを作成しなければいけません。そうした場合、以下のような方法でテストケースを作成することが多いかと思います。 「前任者が作成したテストケースを真似して作成している」 「各機能のテストを順番に操作するように繋げている」 このような方法でテストケースを作成してしまうのは非常に良くないです。このふたつには、以下のような心理が働いているからです。 「 （なんとなく・・・） 前任者が作成したテストケースを真似して作成している （から、どうしてその内容で検証しなければいけないのかが分からない） 。」 「 （なんとなく・・・） 検証する各機能を順番に繋げている （から、内容が機能テストと同じになってしまう。シナリオテストなのに機能テストと同じ内容を検証することになってしまうが良いのだろうか？） 。」 つまり、よく分からないながらも、しっかりとしたテストケースを作成しようとしたのに、結局「なんとなく」テストケースを作成してしまったのです。なんとなくテストケースを作成してしまうと、「そのテストケースで何を検証したいのか」という意図がなくなります。よって、作成したテストケースがシナリオテストとして有効なのか示せなくなります。 「このテストケースは、シナリオテストとして本当に妥当なのだろうか・・・。」 結果、シナリオテストとして適切なのか分からなくなり、不安に駆られてしまうのです。不安に駆られないようにするためには、「シナリオテスト」とは何なのかを理解し、意図を持ってテストケースを作成できるようにならなければいけません。 ソフトウェアテストの設計 シナリオテスト編 そもそも「シナリオ」って何？ 「シナリオテスト」を理解するためには、「シナリオ」について知る必要があります。そもそも「シナリオ」とは何なのでしょうか？言葉の意味を調べてみると、 「シナリオ」とは「台本」という意味です。つまり、「シナリオテスト」とは「台本に沿って行うテスト」とも言えますね。 「台本」という言葉を聞くと、演劇や映画などを連想しませんか？「台本」は、舞台で繰り広げられる物語を、演劇や映画として表現するためにあります。 「台本は舞台で繰り広げられる物語を表現するためのもの」 実は、これはテストにおいても同じなのです。テストの舞台となるのは開発した「システム」や運用する「サービス」です。システムやサービスにも表現したい物語があり、それを実現するために台本（シナリオ）が必要となるのです。 台本（シナリオ）を用意するにはシステムの物語が必要！ 「システムで実現したい物語」 とは何なのか？これはとても単純で、 「システムを使うことで達成したいこと」 、つまりシステムの目的です。演劇や映画と同じように、 「システム（舞台）があって、ロール、権限（登場人物）があって、システムを使って何か変化（イベント）が起こる」 という物語が存在します。 物語の通りに進行するか、物語の進行を妨げる不具合が無いかを確認するのがシナリオテストなのです。 具体的な例として、ECサイトを物語風にまとめてみますと、以下のようになります。 　 ・舞台（システム） ⇒　フロントエンド、バックエンドなど 　 ・登場人物（ロール、権限など） ⇒　フロントエンド：エンドユーザー バックエンド：管理者など 　 ・物語（システムで達成したいことと、途中で起こるイベント） 舞台はフロントエンド。商品を購入したいエンドユーザーがその思いをかなえるため、ECサイトにアクセスする。欲しい商品を見つけられたものの、そのままでは購入できないようだ。エンドユーザーは愕然としたが、その瞬間目の前に会員登録が出現した。 「会員登録を行えば商品を購入することができるのか？」 目の前に出現した会員登録に、エンドユーザーは戸惑いを隠せなかったが、商品をどうしても購入したいため、会員登録を行うことを決意する。何か代償があるのでは無いかと覚悟したが、特に何もなく会員登録を終えられたのは幸いだった。会員登録をした結果、手間が掛かると思われた購入処理は円滑に進み、無事商品の購入に成功。購入した商品は無事翌日に届いたのであった。 購入した商品は何故無事に届いたのだろうか？実は裏（バックエンド）では、「エンドユーザーが商品を購入した」という情報が自動的に商品管理者の手に渡るようになっていたらしい。商品管理者はその情報から、エンドユーザーの元に商品が届くよう手配を行っていたことが後になって判明する。 台本（シナリオ） フロントエンドにアクセスする。 商品検索ページで商品Aを検索する。 検索結果に表示された商品Aを選択し、商品Aの詳細画面に遷移する。 商品Aをカートに入れた後、購入処理へ進む。 「会員登録をして購入する」ボタンから、会員情報入力画面に遷移する。 必要な情報を入力し、「会員登録」ボタンを押下し、会員情報入力確認画面へ遷移する。 「確定」ボタンを押下し、会員登録を完了させる。 会員登録を完了すると、購入確認画面に遷移する。 「購入確定」ボタンを押下して、購入を完了する。 マイページへ移動する。 購入履歴に商品Aの購入が追加されていることを確認する。 「商品管理者」権限でバックエンドにアクセスする。 「商品A」のデータが「出荷手配完了」となっていることを確認する。 いかがでしょうか。台本（シナリオ）は物語がベースになっていることが分かるかと思います。 まとめ 「シナリオテストとは？物語の仕組みから考えてみる」と題して説明してまいりましたが、いかがでしたでしょうか？本記事のタイトルを見た時点では、 「物語からシナリオテストのヒントを得る？そんなバカな・・・」と思われたかもしれません。 しかし、シナリオテストが良く分からない理由やシナリオテストが難しい背景がわかり、有効なシナリオテストを行うためのポイントがご理解頂けたと思います。 効果的なシナリオテストを作り上げるために、陥りがちなワナに気を付けて、システムの物語を考えてみましょう！ 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post シナリオテストとは？物語の仕組みから考えてみる first appeared on VALTES テストサービス .

システム開発においては、常にプロジェクトQCD必達は追い求められます。しかし、度々起こる仕様変更や、予期しないトラブルの発生などにより、大きくプロジェクトの計画から逸脱してしまうこともあります。そのようなときには、どうにかテスト期間を短縮できないか、テスト項目をさらに圧縮できないか、と検討することもあるのではないでしょうか。 しかし、やみくもにテスト項目を削減すると、本来は削減すべきではないテスト項目を削減してしまうことになりかねません。そして、市場に欠陥を流出させてしまう可能性につながります。こういった事は避けたいものです。どうにかしてテスト項目を削減したいけど、どれが大事なテスト項目なのかを、判断するのは難しいと感じているのではないでしょうか。 こういったときに「リスクベースドテスト」の考え方を取り入れることで、優先度の高いテストが何かを見極められるようになります。「リスクベースドテスト」とは、「リスク」に基づいてテストの優先順位や範囲を決定する、ソフトウェアテストのアプローチの一つです。 そもそも「リスク」ってなに？　まずはテスト計画段階からリスクを洗い出そう 「リスクベースドテスト」に触れる前に、そもそも「リスク」の定義についてみてみましょう。「リスク」とは、は様々な定義がされていますが、簡単に言うと、「心配事」です。これから起こりそうな心配事を頭の中で「こんなことが起こりそうで、少し心配だなぁ…」と思っているだけではなく、机上に取り出して、目に見える形から始めます。 まずは、「リスクが管理された状態」をめざします。リスクが管理された状態とは、どういうことでしょうか？ ＜リスクが管理された状態＞ リスクが文書化されている リスクが分類されている リスクの発生確率と発生した際の影響が評価されている リスクへの対応策が検討されている リスクへの対応実施後の経過観察が行われている 新たなリスクの抽出ができる テストの計画段階から様々なリスクが見え隠れしているはずです。これらを「リスク管理表」などに整理します。一人の担当者だけでリスクの洗い出しをすると、内容に偏りがでることがあります。立場や役割によって、心配事のネタは違うので、様々な立場の人を巻き込むのが大切です。すでにプロジェクトの「リスク管理表」がある場合には、テストに関係するリスクがあるかどうかを見ることも忘れずに行います。 ＜リスクを洗い出す際のポイント＞ リスク抽出は、リスク管理担当者やPM/PLだけでなく、プロジェクトメンバー全員で行う。 既存のプロジェクト「リスク管理表」がある場合、テストに関係するリスクかどうかを判断。 ＜リスクを洗い出す方法の一例＞ 以下は、リスクを洗い出すときに参考になる方法です。時間をかけずにリスク抽出する方法として、週報会などの場で付箋を数枚ずつ渡して、その場でリスクを書き出してもらうと、５分くらいであっという間にリスク抽出ができるのでおすすめです。（ブレーンストーミングに近い方法） 抽出されたリスクは文書化して、プロジェクト内で共有するようにします。 手法 説明 ブレーンストーミング ビジネスやプロダクトに責任を持つステークホルダーと開発者、品質担当者、マネージャ、リーダー、メンバーなどが数人のグループを作り、ブレーンストーミングを行い、リスクを洗い出す。 アンケート 関係部門、メンバーにアンケートを実施。その結果からリスクを洗い出す。 チェックリスト 過去に発生した問題に関するチェックリストを用意。状況が該当するかをチェックする。膨大化したチェック項目は形骸化を生みやすい点に注意。 RBS(Risk Breakdown Structure) リスクが見えるレベルまで要素を分解して構造化。 リスクベースドテストの流れ 以下は、リスクベースドテストの全体の流れです。（図参照） リスクの抽出 はじめに、テスト計画をおこないますが、その中では、まずリスクの洗い出しを行います。すでに分かっている既知のリスク、それに加えて、プロジェクト特有のリスクを整理します。抽出されたリスクは、性質の異なる「プロジェクトリスク」と「プロダクトリスク」を分類して管理すると良いでしょう。 リスクの評価と優先順位付け リスクは、その発生確率と発生した場合の影響度を評価の軸とします。 影響度については、ビジネス上の機会損失などによる具体的な損失額や、発生した場合に掛かるリカバリーコストなどを基準にする場合もあります。 リカバリコストの例…データ漏洩、不正アクセス、認証の脆弱性が発生した場合の対応コストなど ビジネス上の機会損失の例…収益への影響、顧客の信頼度、市場シェアの喪失など リスクの対応策を策定 優先度の高いリスクから対応策の検討を行います。 項目 内容 例：地震リスクへの対応 リスクの回避 リスクそのものを無くす 地震が多い所から移転 リスクの分散 悪影響を及ぼす範囲を狭め、 トータルのダメージを軽減する 地震に備えて重要インフラを 地方に分散 リスクの軽減 リスク顕在化する確率や 顕在化した時のダメージを低く抑える 地震に備えて免震構造に改築 リスクの転嫁 リスク顕在化した時のダメージを他に負わせる 地震保険に加入 顕在化時の対策 リスク顕在化した時の対策を予め準備しておく 地震に備えて避難訓練 リスクの受容 リスクがあることを受容して腹をくくる － リスクのテスト戦略策定 プロジェクトリスクは、コンティンジェンシープラン（事前対応策・行動手順）も含めて検討を行うとよいでしょう。プロダクトリスクは、リスク低減策として、どのようなテストを実施する必要があるか検討し、テスト戦略およびテスト計画に反映します。例えば、DB変更にともない、COBOLからJavaへのプログラムの変更を行うケースがあります。この際に性能劣化が発生するリスクが見込まれる場合、以下のようなテスト戦略が検討できるでしょう。 1.単体テストで各処理の性能検証を行う（オンライン/バッチ） 2.システムテスト後に非機能テストとして性能テストを実施する テスト設計 テスト設計の手法はさまざまあります。ここでは、弊社でよく活用するテスト設計についてご紹介します。テスト設計では、テスト対象について以下の３つに分割して考えます。これらを組み合わせていくことで、ヌケモレが起こりにくいテスト設計を実現します。 どのテスト対象の“機能（要素）”に対して どのようなテストの“観点” （確認する内容）を どの“条件／入力値”で行うのか リスクの監視、再評価 対策がきちんと効いているか、リスクが低減されたか、それを監視する。もしくは状況が変わってきているのであればリスクの再評価を行う。 新たなリスクの抽出 新たなリスクがあれば、リスク抽出、評価・分析を行う。 リスクベースドテストの活用事例を見てみよう リスクベースドテストを取り入れた際の効果は、プロジェクトによって、または対象システムによって大きく異なります。図は、行政や企業からの各種証明書を管理するサービスのテストプロジェクトに、リスクベースドテストを取り入れた際の事例です。（図参照） リスク管理表と実際の不具合検出を比較すると傾向はほぼ一致しており、重要度高(RED)のエリアから55%の不具合が検出されました。ただし、重要度中（YELLOW）からも欠陥検出率が高かった機能がありました。このように、傾向をデータとして収集することも、リスクベースドテストを適用すべきプロジェクトを見極める第一歩になります。 まとめ 事例紹介では、事前のリスク評価・分析と実際の傾向が一致した事例をご紹介しましたが、傾向が一致しなかったプロジェクトもあります。組織内でデータを収集して、どういったテスト対象には適用可能なのかを把握していくことが大切でしょう。まずは難しいことは考えずにやってみよう！という気持ちで、最初のステップである「リスクの洗い出し」から取り組んでみましょう。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post リスクベースドテストを取り入れてみよう！ first appeared on VALTES テストサービス .

ソフトウェアテストにおいて、効率的にバグを見つけていくことは非常に重要になります。なぜなら、ほとんどの場合リソースの関係ですべてのテストを実施するのは非常に難しいからです。では、どのような方法を用いてテスト数の調整をすればよいでしょうか？ そのようなときに役立つのが、テスト技法の境界値分析です。しかし、同値分割法と考え方が似ているのでなかなか理解できないという方もいらっしゃると思います。境界値分析と同値分割法の違いを説明しつつ、特に境界値分析に焦点を当てて解説をしていきます。 境界値分析と同値分割法の考え方 境界値分析と同値分割法を理解していただくために、まずは”同値パーティション”の考え方を説明します。同値パーティションとは「同じ出力結果になる値のグループ」のことです。以下の例を使って一緒に考えていきましょう。 1～20までの正の整数が入力可能で、それ以外の数値は入力不可。 このシステムを数直線で表すとこのようになります。 1～20は”入力可能”という同じ出力結果を持つ値の集合なので、同値パーティションと定義できます。逆に0以下または21以上は”入力不可”という同じ出力結果を持つ値の集合なので、無効同値パーティションと定義できます。(ここでの”無効”はシステムにとっての無効を指します)「同値分割法」というテスト技法では各パーティションから代表値を1つ以上テストすることで、出力結果が違うすべてのパーティションを最低1つは確認したという保証ができます。 今回であれば、無効同値パーティションから”30”・有効同値パーティションから”15”というような値をテストすることができるでしょう。しかし、実際には離れた無効同値パーティションを1つに括らず、パーティションの塊ごとに代表値を出す場合が多いです。「境界値分析」はこの同値パーティションの考え方を用いるという点では、同値分割法と同じなのですが、「出力結果に変化が起こる境界値をテストする」ということが前提となります。境界値とは①異なる同値パーティションになる境界となる値　②その隣にある値のペアのことです。 今回のケースであれば、下記の4つの境界値となります。 無効同値パーティションから同値パーティションの最初の境目になる「0と1」 同値パーティションの最大値から無効同値パーティションの境目になる「20と21」 すべての値をテストする場合、21以上の数字が無限にある以上膨大なテスト数になります。しかし同値分割法や境界値分析を使用するとバグを狙いながら効率よくテスト数を削減できます。 同値分割法と境界値分析を比較すると以下のようになります。 同値分割法では各パーティションの代表値を適当に選ぶので、境界値である必要はない →境界値分析では必ず”境界値”をテストする テストする値の数は境界値分析の方が多くなる傾向にある 今回の例では同値分割法を用いると最低2つまたは3つの値、境界値分析では4つの値では、境界値分析の使いどころはどこでしょうか？ 境界値分析の使いどころ なんで境界値なの？ 使いどころを知っていただくために、なぜ境界値を狙っていくのかを説明いたします。今までの文章にもありましたが、「以上」「以下」「まで」などの表現は同値パーティションの境界を示していますが、これらの言葉は誤って解釈される場面が多くあります。例えば、開発前に「18歳以下は未成年、それ以上は成年とする」という要件がありました。しかし、コーディングする人が「17歳までは未成年、18歳以降は成年」と誤って解釈しプログラムを作ったとします。 それぞれの内容を数直線で書いてみると、このようになります。 言葉の解釈の齟齬により赤い〇で囲った境界値が変わってしまいます。もしこの仕様を同値分割法でテストした場合、10や20などの境界値以外の値を選ぶとバグに気づくことができません。しかし、境界値分析でテストすると18の値でバグを検出できます。つまり今回のように出力結果に違いが出る場合に境界値分析の利用ができます。 例えば、ECサイトでの販売期間や商品の購入制限などさまざまです。 例B）ECサイト　購入制限に関するシステム 購入可能数は1～100まで、それ以外の数を入力時にはエラー表示 →境界値は「0,1,100,101」なのでその値をテストする ここまでの説明で「やったー、テスト数をらくらく削減できる！」と思ったかもしれませんが、ちょっと待ってください！ テスト数は削減できればできるほどよい？ これまでは同値分割や境界値分析で、効率的なテスト削減についても焦点を当てました。しかし”削減する”という行為が必ず良いというわけではありません。なぜなら、削減するとその分バグを検出できる可能性は低くなるからです。例えば、先ほどの購入可能数を定義しているプログラムが1～100の出力結果を個別で設定している場合、すべての数が境界値になります。つまりバグがある場所はランダムに存在しています。 一般的にバグがある箇所には偏りがあるといわれていますが、ある数か所だけですべてのバグを見つけられるわけではありません。したがって、できる限り多くのバグを取り除くためにはそれ相応のテスト数が必要になります。 では、どのようなシステムにテスト数を多く見積もるべきなのでしょうか？それは「不具合があるとリスクが非常に大きくなるシステム」です。以下の図で例を示します。 このようなシステムの場合にはたった1つのバグでも致命的な損害を引き起こす可能性があります。いずれの場合も企業にとっては大損害になり、利用した人が巻き込まれる可能性が非常に高いものです。このようなシステムではできる限り多くのバグを検出する必要があるので、全数またはそれに近いテストをすることが大事になります。ここでテスト数を削減してしまうと、大きいリスクが残ったままになってしまいます。 以上の具体例だけではなく「複雑」なシステム・「新規」のシステムも多くのバグが含まれているので注意が必要です。各システムにおけるリスクや重要度を踏まえながらテスト数を調整し、重大なバグは取りこぼさないようにしましょう。 まとめ 「境界値分析とは？同値分割との違い」をテーマにして、ご説明してまいりました。テスト技法を活用することによってリソースとのバランスを取りながら効率的にテストを行うことができます。しかし、各技法の違いや目的を理解しておかないと本来の力を発揮することができません。テスト対象のシステムの重要度を踏まえながら、適切なテスト技法を用いて、品質の高い製品づくりを目指してみてはいかがでしょうか？ 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 境界値分析とは？同値分割との違いを解説  first appeared on VALTES テストサービス .

ソフトウェアテストの中には大きく分けて、スクリプトテスト(scripted testing)とアンスクリプトテスト(unscripted testing)があります。要はテストケースを作成するかしないかの違いです。 ここではunscripted testingであるモンキーテストについて深堀りし、アドホックテストとの違いについて書いていきたいと思います。 モンキーテストとアドホックテストの違いとは？ 2023年現在、私がクライアントからよく依頼されるテストが下記のケースです。 「新しいOSでモンキー的にテストしてほしい」 「特殊な端末で、モンキーテストを行ってほしい」 このような「モンキー」や「モンキーテスト」という言葉で依頼されるのです。「モンキーテスト」という言葉は日本人にもなじみ深い言葉の組み合わせなので、「unscripted testing = モンキーテスト」のような公式が頭の中にできているのではないかなと思って依頼を解釈します 。私は、その場合はモンキーテストというよりはアドホックテスト的な操作を実際には行いますが…。モンキーテストとアドホックテストの違いとは、実施者のテストをするアプリケーションに対する見識の深さの違いと言えるのではないでしょうか。では、実際のモンキーテストの定義はどういうものなのでしょうか？ モンキーテストの種類 モンキーテストとアドックテストの大きな違いは、実施者のそのアプリケーションに対する見識の深さの違いと説明しました。モンキーテストの場合、そのアプリケーションについてよく知らない人が行うことが多いようですが、アドホックテストの場合はそのアプリケーションのことをよくわかっている開発者やテスターが行います。余談ですが、自分の場合はアドホックテストを行った場合はドキュメントとして記録を残すことが多くなります。 しかし、サイトによっては残さないのが普通、と記載されているものもありましたので、状況に応じて対応するのがいいかと思います。世界版のwikipedia（ https://en.wikipedia.org/wiki/Monkey_testing ）によると、モンキーテストと一言に言っても、2種類に分けられるようです。モンキーテストの2種類とはスマートモンキーテスト(smart monkey)とダムモンキーテスト(dumb monkey)です。要は「賢い猿がやるか」「間抜けな猿がやるか」の違いと言えるのはないでしょうか。 スマートモンキーテストの(賢い猿が行う)場合、アプリやシステムへの一般的な知識を持ち、自分が今何をしているかを認識し、システムを壊すつもりで操作し、出てきたバグを報告する、というものです。具体的な操作としては、画面の空白部分をたたいたり、環境依存文字をひたすら入力したり、ランダムにボタンを押してみたり…のようなものが思い浮かびます。対して、ダムモンキーテストの(アホな猿が行う)場合、アプリやシステムについての一般的知識がなく、行う操作について有効無効の分別もつかず、自分が今何をしているかも認識できていない状態で操作する、というものです。 具体的な例は、もはやテスト対象を投げるとか、放置するとかまでが入るのではないかと想像できます(実際は投げたりまではしないと思いますが…)。ダムモンキーテストの場合、スマートに比べ発見できるバグは少ないですが、重要なバグを発見することができるという特徴があります。 モンキーテストの良い点と悪い点 モンキーテストの良い点としては、既成概念にとらわれないバグを見つけることができるという点があります。また、テストをスクリプト化(テストケース化)しないので実行までに時間がかからない、テストに精通した人でなくとも実行可能、があるかと思います。対してモンキーテストの悪い点としては、バグがあまり見つからないことがあり、バグが見つかったとしても再現するのが難しい場合があるという点です。また解析が困難で時間がかかる場合があるがあると考えられます。 自分の実感としても、何もわかっていない人に操作してもらうと、思わぬバグが出てくることがあります。ただし、再現手順がわからない場合も多いです。やり方を聞いても「なんか出てきたんですよね…。」というような場合です。よく聞く「何もしてないのに壊れた」というものです。起票ができないので開発者側との連携に時間もかかります。仮に(操作方法不明的な感じで)起票できたとしても、開発者も再現できないのでどう修正すればいいかわからないという事態に陥ることは容易に想像ができます。 まとめ 「モンキーテストは本当に猿が行うテストなの？アドホックテストとの違いも解説」と題して、ご紹介してまいりました。モンキーテストはテストケースを使わないという点でアドホックテストと似ていますが、本質的には違うものであることがわかりました。モンキーテストとアドホックテストの共通する点としては、テストケースを使わない点です。違う点としては、実施者のアプリケーションに対する見識の深さです。いずれのテストも、手法の一つなので、それだけを行ってテスト済と判断することは少ないと思います。 ここでは取り上げませんでしたが、探索的テストという手法もアンスクリプトテストの仲間として存在します。気になる方は検索してみてください。通常のスクリプト化したテストありきで、モンキーテストの特性を理解し、効率的なバグ(インシデント)の発見を行いたいものですね。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post モンキーテストは本当に猿が行うテストなの？アドホックテストとの違いも解説 first appeared on VALTES テストサービス .

システム開発において、要件定義は特に重要な役割を担う工程です。要件定義の段階で必要な要件が定義がされておらず、不十分な状態で開発工程まで進んでしまうと、その開発プロジェクトが失敗する確率はかなり高まります。要件定義での失敗がプロジェクトの失敗に起因する、という認識は広く一般的に知られております。 それでも要件定義の作りこみが甘くプロジェクトが失敗に終わる、という方々が絶えないのは、要件定義がそれだけ難しいということではないでしょうか。 上流工程のひとつである要件定義について、解説していきます。 成功プロジェクトにするための要件定義とは？ そもそも「要件定義」を正確に理解している方は少ないのでないでしょうか。要件定義とは、システム開発工程の1番最初に行われる工程です。システム開発のその後を決定づけるため、成功プロジェクトへの鍵となるのが要件定義です。要件定義とは、「依頼元のクライアント」または「社内」の要求に対して、開発者の視点で要件を取りまとめたものになります。そのため、要求の時点で漏れが発生すると、「要件定義」を修正するといった事も少なくありません。 要件定義の進め方は大きく5ステップに分かれます。 【要件定義の進め方　5ステップ】 １．解決したい課題と目標を明確にする 依頼元からのリクエストが実現できるものであるか リクエストに対して、明確に数字で説明できるのものは数字で説明する 要求の要件化が困難な場合、依頼元と速やかに協議の場を調整する ２．システム全体の構成を明確にする 外部システムとの連携を考慮する場合、制約事項などを予め理解しておく 他社、自社の責任分界点を明確にしておく インフラの維持に掛かる費用などを予め算出しておく ３．機能要件／非機能要件を定義する 業務量に応じたリクエスト/レスポンスのデータ量を理解しておく 機能要件が他の機能要件に影響があるか否かを理解しておく 個人情報の取り扱いなどを行う場合、法務と予め検討しておく ４．スケジュール／予算／プロジェクトメンバー／コミュニケーション方法を定義する 組込製品の場合、機器の原価と台数を理解しておく ステークホルダーが多い場合は、予めコミュニケーション方法を相談しておく テスト環境を開発＆テストチームと共有して利用するか否かを検討しておく ５．要件定義書を作成する 要求定義の番号とトレーサビリティが取れているか 各ステークホルダーが理解できるような内容になっているか 実現できない要件となっていないか このような要件定義の流れに沿って、システム開発者の視点からユーザーの要求、要望を確認することが重要なポイントとなります。ユーザーと開発者の間で要求が明確化され、抜け漏れがない状態にできるよう、意志疎通を図る必要があるでしょう。また、要件定義の担当者がシステム開発のイメージを掴むだけでは、要件定義とは言えません。ドキュメントを作成することで、プロジェクトの関係者にも共有することが大切です。プロジェクトを成功させるためにも、的確な要件定義を目指していきましょう。 でも・・・、営業がよく耳にする現場の声 バルテス社は、ユーザー企業、ベンダー企業、開発部門、情報システム部門、業務部門、と業種業界部署に限らず、幅広い分野にて支援を行っています。営業としても様々なお客様と打合せを重ねてきました。そんな中よく耳にするお困りごとの1つとして、 プロジェクトがスケジュール通りに進まない、という声があります。 進行中のプロジェクトにおいて、テスト工程で不具合が多くてプロジェクトが大幅に遅延、リリース時期に間に合わない、といった内容がとても多いです。 よく耳にするお困りごとの2つ目として、 プロジェクト体制に起因する失敗が挙げられます。 ソフトウェア開発の現場において、俗人化やリソース不足は昔から根強く残る課題ではないでしょうか。 上流工程に着目した意見として、次のようなケースが挙げられます。 担当者によって成果物の記載粒度が異なる 複数の担当者によって整合性の取れない成果物が完成し、後々不具合の作りこみにつながる スケジュールに余裕がなく成果物を作りこむ時間がない このようなご相談をよくいただきます。プロジェクトがうまく進まなかった方々の多くは、「要件定義が甘かった」と口にします。そもそも要件定義はどうして必要なのか、何をもって要件定義は成功といえるのか、現場の中で共通認識が取れていないことも多くあるのではないでしょうか。何をもって要件定義は成功といえるのでしょうか。 現場で役立つテストプロセス標準化 ここまでの説明で、要件定義の難しさは十分に伝わったのではないでしょうか。では次に、要件定義から品質の向上につなげるために何を行うべきなのかご紹介していきます。弊社では3つのアプローチにて、要件定義のご支援を行っております。 1つめは 「品質戦略マップ」 によるご支援です。これはプロジェクトが立ち上がるタイミングで、各開発工程において、いつだれがどのような品質基準をどのように担保していくか、という観点から戦略を定義していく手法です。こちらはあくまで現場ファーストの手法です。開発プロジェクト全体を通して、各工程に品質基準を設けることで各工程にて定義することを明確にするものです。今回の要件定義の場合、要件定義としてのゴールを戦略的に基準を定めておくことが必要です。例えば、「システムとして達成すべき性能が定量的に定められていること」などが一例となります。 2つ目は 「仕様書インスペクション」 です。これは要件定義にとどまらず、上流工程で作成される成果物、ドキュメントを品質の観点からレビューするサービスです。上流工程でドキュメントを作成する際、どのようなものをどのように作っていくか、という観点が主軸となります。バルテス社はその中で、下流工程でどのようなテストを実施するのか、開発の各工程でどのような品質基準を設ける必要があるのか、上流工程から品質向上の支援を行います。要件定義の場合ですが、要件の考慮漏れがないか否かを確認したり、あるいは例外的な処理について考慮されているかなどを軸に確認を進めます。 3つ目は 「ソフトウェア品質教育」 です。ここまで色々と説明しましたが、そもそも知識が不足している、チーム内の共通認識が取れていない、ということもあるのではないでしょうか。バルテス社はソフトウェア品質セミナーを18コース保有しており、開発側の立場、ユーザー側の立場、２軸で品質向上を目指す内容を展開しています。開発企業の立場からシステム開発の品質を向上させるには、要件定義から機能設計へどの様に移行するべきか、上流工程ではどのように品質管理を行うべきか、といった内容を盛り込んでいます。逆に、ユーザー企業の立場からシステム開発を発注する際、どのように要求を発注するべきか、開発者の作成したドキュメントをどのようにレビューするのか、という観点でもコースをご用意しております。 このような3つのアプローチを主軸に、様々なお客様にマッチするような上流工程のご支援をしてきました。バルテス社では「現場で役立つ」ことを前提にした上流工程のご支援をしております。 まとめ 「できるの？できないの？成功プロジェクトへの要件定義　奮闘物語」と題して説明してきました。要件定義はプロジェクトの成功への鍵となる工程です。ソフトウェア開発における品質の向上を目指す際、どのように要件定義を進めていくのか、今一度考えてみてはいかがでしょうか。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post プロジェクトを成功に導く、現場で役立つ要件定義の進め方　奮闘物語 first appeared on VALTES テストサービス .

昨今プロダクト開発における検証の重要性が高まりつつある中、さまざまな企業・開発チームで困っていることに「テスト仕様書」の作成があるはずです。ノウハウがないから何を書いたらいいのかわからない！作ったはいいけど別のメンバーがうまく使えない！そんな悩みを解決するためのテスト仕様書の書き方のヒントがここにあります。 テスト仕様書のサンプルダウンロードもできますので、現場でお困りのみなさんは是非ご一読ください！ テスト仕様書って何？記載すべき内容とは 「テスト仕様書」は現場によっては「テストケース」と呼ばれたりもしますが、そもそもこれってなんでしょう？プロダクト開発の現場では要件定義～リリースまでに、規模の大小こそありますが必ずテストのステップがあります。 「テスト仕様書」とはこのテストのステップにおけるチェックリストを含む資料だと思ってもらえればOKです。 そう修学旅行や遠足に行くときに忘れ物が無いか確認するアレですね。簡単な話でテストにおける旅のしおりがテスト仕様書ということです。本記事では「テストケース」と区別するために「テストケース」の集まったファイルを「テスト仕様書」と定義して話を進めていきます。 もちろん旅のしおりですから、チェックリストであるテストケース以外にも様々なドキュメントを内包している必要があります。テストを開始するまでのスケジュール情報、環境設定・環境使用における注意ポイント、データの集計シートなども入っていることもあり現場によって内容はだいぶバラつきがあると思います。本記事ではテスト仕様書に含まれるさまざまなドキュメントの中で、メインのドキュメントといえるテストケースの作成に焦点をあてて話を進めていきます。 その他のドキュメントについてはテストケースの実行が滞りなく進行できるように補助的なものとして、必要に応じた内容のものを付け加えてあげるようにしてみてください。それではテスト仕様書のイメージがついたところで中身について考えていきましょう。本記事をご覧になっている皆さんの中にはきっと、「テスト仕様書ってどんな項目を設ければ効率的に適切なテストになるのだろう？」というお悩みの方も多いのではないでしょうか？そこでまずはバルテスが普段作成するテスト仕様書の内容で最低限抑えるべき項目は以下の通りです。 【テスト仕様書で最低限抑えておきたい項目】 テスト概要 実施条件 実行手順 期待結果 各項目について一つずつ簡単にご紹介します。 テスト概要 これは端的に言えばテスト手順ごとの「タイトル」だと思ってください。テストの実施作業において、一連の手順によって何を確認するのかが一目で分かるかといった考え方は非常に重要です。テストの作成時点でケースの重複や不足を防いでくれたり、テスターが実施内容を確認しやすくなるためコミュニケーションエラーが減ったりするメリットが期待できます。 実施条件 ソフトウェアのテストでは様々な条件の考慮が欠かせません。例としてデータ取込のテストを考えてみましょう。データの形式は？データのサイズは？一度にいくつのファイルを取り込む？システム側の取込方式は？内容によるデータの選別は？といった形で一般的な機能に関してすぐに思いつく条件だけでもだいぶ数がありますね。こういった条件の中でも「前提条件」としてテストケースの手順を開始する前に整えておくべき、スタートラインを定義するものです。 実行手順 こちらは実際にテスターがシステムを操作する内容を一つずつ記載したものです。内容は「具体的」「簡潔」を意識することでより良いものになります。開発エンジニアがテスト仕様書を作成する際、ノウハウのありなしに関わらず実施手順を雑に記載しがちです。システムへの理解度が高いことによって抽象的に記載してもなんとなく伝わってしまうのが原因の大半です。このような記載になっているテスト仕様書は良いものとは言い難いです。 期待結果 「実施条件」を基に「実施手順」を流した結果として、「何を確認したいか」を明確に記載する箇所です。実施手順と同様でテストのノウハウが乏しい開発エンジニアによって「わかりにくい」記載が発生しやすい箇所になります。 「わかりにくい」から考える、テスト仕様書の上手な書き方 では次に 「わかりにくい」に焦点を当てて、よりよいテスト仕様書の作成について考えていきます。 結論から言って、テスト仕様書においての「わかりにくい」原因のほとんどは「抽象的で曖昧な記載」です。これを読んだ皆さんは「？・・・まぁ、それは確かに、わかりにくそうですね。」といった感じでしょう、そんな当たり前のことを言われても困るといわんばかりの顔をするはずです。しかし皆さんが無意識にやっている可能性があるので一緒に考えてみましょう。 皆さんがテスターを行った際こんなテストケースに出会ったことはありませんか？ ・テスト概要：アカウント登録時の入力機能Aの処理結果確認 ・実施条件　：画面Xを表示していること ・実施手順　：1.プルダウンを選択する 　　　　　　2.テキストボックスへ入力を行う 　　　　　　3.確定ボタンを押下する 　　　　　　4.画面Yの結果表示を確認する ・期待結果　：画面Yに表示される機能Aの処理結果が正しいこと。 一見するとしっかりと最低限の記載内容を抑えたテストケースに見えるかと思います。ただこのままテストを行うとテスターは様々な確認作業が発生してしまいます。最初に 「実施手順」で2か所の確認です。 まずプルダウンでは何を選択するべきでしょうか？プルダウンを利用していることから項目が複数あると予測できます。実際に複数ある場合には「プルダウンから○○を選択する」と選択対象を明記すべきです。またテキストボックスへの入力内容も特に指定されていません。実施手順を見たテスターは任意の入力でいいのか、特定の文字列や入力制限をパスできる内容の入力なのか迷うはずです。 「テキストボックス“△△”へ○○と入力を行う」と指定するのがベストですね。または「テキストボックス“△△”へ任意の有効値で入力を行う」など、テスト結果に影響が出ない範囲程度で幅を持たせることもひとつの手です。そして 「期待結果」にも皆さんが意外とやりがちなミスを一つ紛れ込ませてみました。 早々に答え合わせをしてしまいますが「処理結果が正しいこと」の記載が良くありません。この期待結果はテスター側からすると結果記載が大変になる原因で、非常に面倒に感じる記載なんです。では何が良くなかったのでしょうか？それは何をもって「正しい処理結果」とするのかが記載から読み取れない点にあります。 今回の用意したテストケースではアカウント登録での入力機能の確認をモデルにしいています。この手の機能では処理結果として「次項目の入力欄が表示される」「入力内容の確認画面へ遷移する」「不正入力にエラーメッセージを出す」などが多いかと思います。例として記載した内容と「処理結果が正しいこと」どちらの方が実施作業に適した記載であるか一目瞭然ですね。さて、ここまでで「わかりにくい」について発見と確認を行ってきました。すべて「抽象的で曖昧な記載」に起因していました。 意外と指摘されないと、違和感を感じにくい記載になっていたのではないでしょうか？作成者自身では気づきにくい＆言語化して伝えるのも分析が手間なので、皆さんそのままにしがちなんです。ここまで分かってしまえばあとは簡単ですね！ 「抽象的で曖昧」を「具体的で明確」な記載に変更すればいいんです。 ここで気を付けたいポイントです。「具体的だけど冗長」になっていないか、ここに注意して記載を行っていきましょう！具体的な内容であったとしても、冗長な記載になっていると読み違えや解釈違いが発生します。 こういったミスはテスト結果にも影響を及ぼすことになるため、最悪の場合会社が傾くような大損害や人命への被害が起きることだって考えられます。テスト屋さんと呼ばれる人たちは、こういった細かいところからヒューマンエラーを減らすための取り組みを行っています。余談ですが、冗長な文章の対策として私が普段気にしていることを記載しておきます。これらはやっているうちに自然と身に付いてくるはずですので、テスト仕様書を作成する際に頭の隅にでも置いておいてください。 【冗長になっていないかの判定基準】 一呼吸の間に同じ助詞が登場していないか？（の、は、が、に、を、へ） 「、」は1個までになっているか？ 一呼吸で読める文字数が40字以内になっているか？ まとめ 本記事ではノウハウが無くてもすぐに使える、「テスト仕様書の書き方」を「わかりにくい」へスポットを当てて考えてきました。紹介したポイントのまとめは以下の通りです。 【テスト仕様書作成のポイント】 「テスト仕様書」は「テストケース」がまとまったもの 最低限「テスト概要」「実施条件」「実施手順」「実施結果」を記載 記載する際は「具体的で明確」を意識した読みやすい一文を心がける ソフトウェアの開発はプログラミングを扱えることももちろん重要です。しかしそれと同じ分だけ作成したものに対する十分な検証が必要です。バルテスでは今回の紹介内容はもちろん、効率的に不具合を検出するためのテスト仕様書を作成いたします。第三者検証サービスを始めとして、品質向上を目指すすべての方々に向け各種サービスを展開しておりますのでお気軽にお問い合わせください。本記事が皆様の品質向上への手助けとなれば幸いです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト仕様書の書き方　プロが考えるすぐに使えるポイントを教えます first appeared on VALTES テストサービス .

令和の時代に入り、アジャイル開発という手法がソフトウェア開発の主流となりつつあります。開発スタイルはウォーターフォール型とアジャイル型では考え方が異なるというのは周知の事実ですが、 アウトソーシング(業務委託)のQAエンジニアはいかにその流れに対応するべきか、を筆者なりに解説したいと思います。 ※ここで「アジャイル開発」はスクラムでの開発をイメージしています。また、QA(クオリティアシュアランス)はテストエンジニア、QAエンジニアの総称とします。 アジャイル型組織のQAの役割とは？チーム一丸の理由 結論としては、 アジャイルではソフトウェアのリスクのコントロール全般がQAの役割です。 対してウォーターフォールでは各工程で段階的に決められた基準に沿ってを品質を担保することが主な役割でした。ここではウォーターフォール型とアジャイル型におけるQAの役割の違いを身近なものに例えて論じていきたいと思います。 ウォーターフォール型ははっきりと各フェーズが分かれています。要件定義、設計、コーディング、テスト工程が明確に分かれて存在し、ソフトウェアの品質を段階的に積み上げていくイメージです。QAの参画目的としてテスト工程の段階で「テストをしてリリース前の品質を担保する」ことが役割でした。 対してアジャイル型は、ソフトウェアを適切なビジネススピード、タイミングで限られた期間およびリソースの中でリリースすることを目的とし、設計からリリースまでをチーム一丸となって役割を全うするものです。ウォーターフォール開発では、比較的規模が大きいプロジェクトで適用され、それぞれが独立（PM、開発、QA）して個々の役割を果たしていました。 一方でアジャイル開発ではチームを細分化し、個々のチームがプロジェクトの状況にあわせて柔軟に対応できる体制となります。チームを細分化することで、ウォーターフォールのように個々の役割の壁を越えて、プロジェクト成功の為に、開発者とQAが密にコミュニケーションを取ることでチーム一丸となれます。 テスト実行しかやってくれないテストのアウトソーシングがダメな理由 テストを最後の工程でしか行わないと何が問題かというと、何かあったときに多大なるコストがかかる点です。テスト/改修など製品開発のピークを後半に作ることをシフトライト(shift right)と言います逆に、開発の段階からテスト、検証を少しずつすることをシフトレフト(shift left)と言います。アジャイルで目指すべきはシフトレフトですが、その理由をここで論じていきたいと思います。 テストを最後にまとめて行った場合、下記のリスクがあると言われています。。 【テストを最後にまとめて行った場合のリスク】 リリース日までに全部のテストが終わらず、深刻なバグが残ったままリリースされる可能性がある 設計段階で発見すべきだったバグを見つけてしまい(仕様の考慮もれ等)、修正に多大な時間と費用がかかる そもそもテスト実行が止まってしまうほどの大きなバグがあり、開発は急ぎで対応、テスターには待ち時間が発生する 普通に考えると壮大なリスクがあるのですが、現代でもテストを最後にまとめて行うスタイルをよく目にします。しかも、サイトによっては、最後にテストをまとめてやった方が品質は良くなる、と書いてあるものまであるぐらいです。テストは最後に行うもの、という固定観念はなくしましょう。今こそマスターヨーダの教えである「You must unlearn what you have learned.」が大事ではないでしょうか。塾講師でアルバイトをしていた経験を例に上げたいと思います。中三の生徒が受験を控えて勉強していますが、二次関数のグラフが書けません。 よくよく話を聞いてみるとそもそも中一の内容である比例のグラフが書けないのです。よって比例、一次関数、二次関数のすべてを再度勉強して理解しないといけないことがわかり、多大なる勉強時間と費用がかかってしまったという例です。この事例はソフトウェア開発にも当てはまるのではないでしょうか？設計段階で仕様の不備があったまま開発を進めてしまい、テストをしたらバグとして指摘され、設計段階に戻って修正する必要が出てくるのです。 受験を控えた生徒に対しては「なんで中一の内容を理解してなかったんだよ」と指摘できる人はたくさんいるかもしれません。しかしテスト中に設計段階の仕様バグを見つけても「なんで設計段階でそんなミステイクを犯してるんだよ」と指摘できる人はどのくらいいるでしょうか。指摘するだけ時間の無駄だし、そもそも指摘できるような立場ではないし、それよりも早く修正してしまおう、と考える人が多い気がします。 アジャイル型組織でQAがやるべきこと 「シフトレフト」、アジャイル型組織でやるべきことは、これに尽きます。 プロジェクトのキックオフからチームの一員として、リスクを早い段階からコントロールするのがアジャイル型開発でQAがやるべきことなのです。とはいえ、具体的には何を意識してシフトがレフトなQA活動を行えばいいのでしょうか？ここで業務受託者(アウトソーシング)という立場で意識しているQA活動をご紹介したいと思います。 【QA活動のポイント】 チームのメンバー間で信頼関係を構築する 開発者に議論してもらう 定期的に振り返りを行い、よかったことや改善点を全員で考える 1つ目の信頼関係についてです。 信頼関係の構築は、何よりも最初にすべきことです。 理由は、指摘を行う業務委託のQAという立場上、信頼なくしていい指摘はできないからです。「郷に入っては郷に従え」という言葉をまず実行しましょう。理由は、それができていないと、仮に正しい指摘をしたとしても、伝わるまでに時間がかかる可能性があるからです。チームメンバーの名前を覚えることは当たり前のマナーです。さらにやるべきことは、プロジェクトが立ち上がった背景、発注元の社長の経歴や会社を立ち上げた理由などを理解し、リスペクトすれば信頼関係の構築の近道なのです。 2つ目の議論についてです。時折、質問や指摘をした際に、開発者とマネジメント層で議論が始まることがあります。まだエンジニアとして駆け出しのころ、筆者は「余計なことを言ってしまったか・・。」と反省している時期もありました。ですが、逆にこういう状態になると健全な状態であると言えます。何が言いたいかというと、開発をしながらも議論が活発なプロジェクトは、テストを行ってもバグがほとんど出ないのです。理由はチームであらゆる可能性を考慮できているからです。 開発者に議論をしてもらえるような指摘や質問をする、というのがアジャイル型QAの大事な仕事と言えます。 テスト観点のレビュー依頼も早ければ早い方がいいでしょう。プロジェクトの初めの方でじっくり議論してもらうことこそが、シフトレフトに他ならないのです。3つ目の振り返りに関してです。ウォーターフォール型開発だと行わないことの一つに、振り返り(スプリントレビュー)があります。この振り返りはチーム全員で行い、発言することが大事です。 アウトソーシングという立場上、あまり発言しない人も見かけますが、「ここではあれはよかった(感謝)」、「これはちょっと改善してほしい(依頼)」といった意見を共有して、次のスプリントに向けた前向きな議論を行いましょう。開発側からQAに対しての意見もあるでしょう。また、なぜあのタイミングであの判断をしたのかみたいに気になっていることもあるのでしょうし、気になった点を改善して、よりよいプロジェクト運営にしたいものです。 我慢をため込むことはアジャイル開発において美徳ではないのです。 まとめ ソフトウェアテストのプロフェッショナルはテストを行ってバグを出すだけでOKな時代は終わりました。アジャイル開発という手法が日本でも主流になりつつある今、アウトソーシングのQAとして最高の品質保証を行うために、このような点に気を付けて柔軟に対応していきたいものです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post アジャイル型組織でQA(クオリティアシュアランス)のあるべき姿 first appeared on VALTES テストサービス .

テストプロセスの標準化はソフトウェア開発における重要なポイントです。ソフトウェア開発の現場において、担当者によってテストのやり方が異なる（属人化）、テストのボリュームが大きすぎて対応しきれない（リソース不足）、網羅性の担保ができておらず品質に不安が残る、といったテスト・品質面の課題は多いのではないでしょうか。 そのような課題に対する解決方法として、テストプロセスの標準化が挙げられます。標準パターンを整え、現場に合わせた運用するための方法について解説 していきます。 テストプロセスを標準化したい！ そもそも「テストプロセス」を正確に理解している方は意外と少ないのではないでしょうか。テストプロセスとは、ソフトウェアテストを進める際の一連の流れを指します。JSTQB（※）に準じて、 「テスト計画とコントロール」「分析と設計」「実装と実行」「終了基準と評価とレポート」「終了作業」の５つに分類 され、プロジェクトの規模や内容によって最適化されるのがテストプロセスです。 ※JSTQBとは日本ソフトウェアテスト資格認定委員会の略称です。国際的なソフトウェアテストの認定団体（ISTQB）に加盟しており、世界共通のテストウェア資格認定を運営しています。 テストの工程は、ソフトウェア開発において約1/3の割合を占める工程 です。この割合はソフトウェア開発コストにおける大きな部分となり、軽視できません。そこで、テストプロセスを標準化することで、ソフトウェア品質の向上を目指すお客様は大変多くいらっしゃいます。しかし、テスト計画から設計、実行、終了作業までの各工程を完璧に定義、実施することはかなりハードルの高い作業となります。ソフトウェア開発における品質管理の重要なポイントとなる、テストプロセスの標準化はどのように進めるべきなのでしょうか。テストプロセスの標準化を進めるにしても、通常業務の傍らテストプロセスを整備するのは安易ではありません。 また、テストプロセスの標準化がミッションとなる際も、どこから着手するべきかわからない、作成したプロセスの精度が判断できない、といった課題が生じてくるのではないでしょうか。当社におきましても、お客様と打ち合わせを行うと、テストプロセスの標準化を進めたい、というご要望を大変多くいただきます。では、限られたコスト、期間、リソースの中で、最適なテストを実施していくためのテストプロセスを社内標準として構えたい、というご要望に対して、どのようにテストプロセスの標準化を進めていくのがよいでしょうか？ でも・・・営業がよく耳にする現場の声 当社バルテスでは、ユーザー企業、ベンダー企業、開発部門、情報システム部門、業務部門、と業種業界部署に限らず、幅広い分野にてご支援を行っております。中には既に自社のテストプロセスを標準化している、といったお客様ももちろんいらっしゃいます。しかし、標準化されたテストプロセスを問題なく運用し、高品質の状態で開発を終了する現場はかなり少ないのではないでしょうか？現場の皆様から 第1の課題として挙げられるのは、テストプロセスの形骸化 です。 社内において標準化されたテストプロセスはあるが、実プロジェクトへの適応が難しく、結局開発を優先してしまう。標準化に則ってドキュメントを作成するが、有用性の低い内容になってしまう。担当者によってテストプロセスへの意識が低く活用されていないなど、多くの形骸化のお悩みを耳にしております。第2の課題として挙げられるのは、 ソフトウェア開発プロジェクトにおいて、全く同じ現場は1つもない という点です。つまり、同じ社内、同じ部署でも最適なテストプロセスはプロジェクトによって異なり、いくつものパターンが必要になってまいります。 そのため、標準化されたテストプロセス自体が、そもそも現場に適応しておらず、プロジェクトの妨げになってしまう場合もございます。そもそもテストプロセスはどうして標準化が必要なのか、会社としての方針と実務を行う現場の間で共通認識が取れていないことが多くございます。一概にテストプロセスを標準化し社内標準を設けましょう！といっても、手法も要望も実情もバラバラな現場において、これほど難しい標準化はないのではないでしょうか。 現場で役立つテストプロセス標準化のパターン ここまでの説明で、テストプロセスの標準化は沢山の課題があり難しいという印象を受けたかもしれません。ですが、やはりソフトウェア品質の向上にテストプロセスの標準化は欠かせません。ではどのように標準化を進めていくのが良いのでしょうか。弊社では2つのアプローチにて、テストプロセス標準化のご支援を行っております。テストプロセス標準化のパターンをご紹介いたします。 【テストプロセス標準化のパターン】 1つ目は 「品質戦略マップ」によるご支援 です。これはプロジェクトが立ち上がるタイミングで、各開発工程において、いつだれがどのような品質基準をどのように担保していくか、という観点から戦略を定義していく手法です。こちらはあくまで現場ファーストの手法であり、開発プロジェクト全体を標準化することで、テストプロセスまで整えていく方法となります。 ※「品質戦略マップ」の詳しい説明は こちらのページ をご覧ください。 2つ目は当社のテストメソッドである 「QUINTEE」によるご支援 です。弊社は限られたコスト、期間、リソースの中で最適なテストを実施するために、「QUINTEE」という体系化されたテストプロセスを確立しております。 ＜ QUINTEE支援の進め方＞ テスト計画の段階でスコープを固めることでブレないテストを実現。 様々な技法や観点でテスト設計の抜けもれを防止。 段階的テスト実施による効率化とドキュメントの資産化。 次のテスト戦略にもつながるテスト報告。 といった流れで、実プロジェクトを抱える現場から標準化を進めていく方法となります。 ※「QUINTEE」の詳しい説明は こちらのページ をご覧ください。 これまで上記のテストプロセス標準化の2パターンを主軸に、様々なお客様にマッチするようなテストプロセスを標準化してまいりました。当社は「現場で役立つテストプロセス」を念頭に標準化のご支援をしております。 まとめ 「テストプロセスの標準化 できるの？できないの？奮闘物語」 と題して、ご説明してまいりました。テストプロセスの標準化は「標準化すること」を目的としてしまってはいけません。理由は、現場に沿わないプロセスが構築されてしまい、結果として運用されなくなってしまうからです。 テストプロセス標準化は目的ではなくあくまで手段の一つです。 ソフトウェア開発における品質の向上を目指す際に、ぜひ解決方法の1つとしてテストプロセスの標準化にも取り組んでみてはいかがでしょうか。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テストプロセスの標準化できるの？できないの？奮闘物語 first appeared on VALTES テストサービス .

一般企業の情報システム部門の担当者として、大規模システム開発を担当する機会はあまりないと思います。しかし、その日は突然やってきます。今まで小規模改修案件の担当はしたことはあっても、基幹システム更改やWebサービス全面リニューアルなどの大規模システム改修で品質を上げるのは大変です。そしてリリースまで持っていくにはどうしたらよいか、右往左往してしまうのではないでしょうか。規模が大きければ大きいほど、プロジェクトの関係者も増え、どのように進めたらよいのか？どのようにコントロールしたらよいのか？そもそも、どこから手を付けていけばよいのか？ プロジェクト全体でどのように品質を作っていくか？疑問はたくさんあります。 そこで一般企業が品質を上げるためのテスト計画の立て方を解説していきます。 大規模システムの品質はどう向上させるの？ あなたは、一般企業の情報システム部門の担当者として、大規模システム開発を担当することになりました。多くの顧客が利用しているシステムのため、経営者からも高い品質を求められています。システムの品質が悪ければ、最悪、顧客離れにもつながります。様々なサブシステムが連携してサービスを提供しているため、開発はマルチベンダーです。さて、あなたはどのように経営者が満足する品質を作り上げますか？このような状況を解決するために、どのように品質を作り上げていくかを解説していきます。 開発工程は一般的には以下のような工程で進みます。 【開発工程の進み方】 　要件定義→基本設計→詳細設計→製造（コーディング） 受入テスト←総合テスト　←結合テスト　←単体テスト 一般的には「要件定義」を情報システム部門で担当し、基本設計から開発ベンダーに委託することが多いと思います。その後、総合テストまで開発ベンダー主体で進め、最終的に受入テストを情報システム部門で担当します。実際にシステムを操作して、システムが正常に動作するかを確認することが多いでしょう。これが小規模改修案件であれば、品質を上げるには受入テストで事細かに確認することで対応可能かも知れません。しかし、大規模システム開発では受入テストだけで品質を上げるには限界があります。 そのため、 プロジェクト全体を通して計画的に品質を上げる対応をする必要があります。つまりテスト計画の立て方が重要なポイントなのです。 そこで作成するドキュメントが「テスト計画書」です。テスト計画書は「全体テスト計画書」と「個別テスト計画書」に分かれます。「全体テスト計画書」では、プロジェクト全体の品質向上のための計画を記載し、個々のテスト工程（単体テスト・結合テスト・総合テスト・受入テスト）に対して、工程ごとの「個別テスト計画書」を作成します。 なぜテスト計画を立てるの？ システムの品質を上げるために、なぜテスト計画が必要なのでしょうか？例えば、ちょっとした機能のスマートフォンアプリのテストであれば、いきなりアプリ上で様々な操作をすることで一通りの機能を確認できるかも知れません。しかし、大規模システム開発ではそうはいきません。設計、製造、テストで、様々な会社や人が作業を分担して１つの大きなサービスを構築します。つまり、 担当範囲や対応方針を明確に指示する必要があり、品質を確立するために必要な情報を「テスト計画書」で明確にする必要があるのです。 テスト計画を作成するための手法として、ソフトウェアテストの国際規格（ISO/IEC/IEEE29119）では、「テストへの要求事項」をプロジェクト計画などから参照し、「テスト要件」を整理することと記載されています。 　テストへの要求事項（インプット） 　　プロジェクト全体の計画や方針 　　プロジェクトのコストと時間の制約 　　システム要件 　　該当する規制基準 　　既知のリスク 　　開発計画におけるテストの位置づけ　など テスト要件（アウトプット） 　　テスト対象 　　テスト範囲 　　テストベース 　　テストの背景、目的・目標、重点項目 　　テストへの期待　など 上記の要件をまとめるために「テスト計画書」を作成します。「テスト計画書」は当該テスト工程の担当者が参照するだけでなく、他の関係者も確認します。どのようなテストを行うのか、共通認識をプロジェクト全体で持つことができるのです、 品質特性を活用した全体テスト計画の勘所 ここで、プロジェクト全体の品質を向上・コントロールするための勘所を解説していきます。大規模システム開発では、単体テスト・結合テスト・総合テスト・受入テストと段階を踏んで品質を積み上げていく必要があります。基本的な考え方は、テストの粒度を小さいものから大きなものに徐々に上げていきます。イメージは以下の段階となります。 受入テスト：業務単位のテスト 総合テスト：システム全体のテスト 外部結合テスト：サブシステム間を連携したテスト 内部結合テスト：モジュールを結合させたテスト 単体テスト：個々のモジュール単位で細かくテスト 単体テストの細かい粒度のテストから、品質を積み上げていき、最終的な業務単位の大きなテストにまで粒度を引き上げていきます。そのためにテスト工程毎に「テスト計画書」を作成し、テストの方針を決めます。なぜなら、どの工程でどのようなことを確認するのか、役割分担を最初に決めなければ、各工程でバラバラな方針を立ててしまうからです。大きな観点での漏れや、逆に冗長過ぎる確認を行うことで無駄なコストが発生する可能性もあります。 そこでお勧めする手法が 「全体テスト計画」時点で「品質特性」を基に各工程の役割を整理する ことです。最初に工程別の役割分担を整理することで、大きな観点の漏れや冗長過ぎる観点を調整できます。具体的な役割分担の決め方として、「ISO/IEC25010ソフトウェアの品質モデル」に定義されている「品質特性」を利用することができます。 「品質特性」とは、８つの特性で定義され、各々の特性に対して計３１の副特性が定義されています。 主特性 副特性 定義 機能適合性 機能完全性 機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。 機能正確性 正確さの必要な程度での正しい結果を，製品又はシステムが提供する度合い 機能適切性 明示された作業及び目的の達成を，機能が促進する度合い。 性能効率性 時間効率性 製品又はシステムの機能を実行するとき，製品又はシステムの応答時間及び処理時間，並びにスループット速度が要求事項を満足する度合い。 資源効率性 製品又はシステムの機能を実行するとき，製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い。 容量満足性 製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。 互換性 共存性 その他の製品に有害な影響を与えずに，他の製品と共通の環境及び資源を共有する間，製品が要求された機能を効率的に実行することができる度合い。 相互運用性 二つ以上のシステム，製品又は構成要素が情報を交換し，既に交換された情報を使用することができる度合い。 使用性 適度認識性 製品又はシステムが利用者のニーズに適切であるかどうか 習得性 明示された利用状況において，有効性，効率性，リスク回避性及び満足性をもって製品又はシステムを使用するために明示された学習目標を達成するために，明示された利用者が製品又はシステムを利用できる度合い。 運用操作性 製品又はシステムが，それらを運用操作しやすく，制御しやすくする属性をもっている度合い。 ユーザーエラー防止性 利用者が間違いを起こすことをシステムが防止する度合い。 ユーザインタフェイス快美性 ユーザインタフェースが，利用者にとって楽しく，満足のいく対話を可能にする度合い。 アクセシビリティ 製品又はシステムが，明示された利用状況において，明示された目標を達成するために，幅広い範囲の心身特性及び能力の人々によって使用できる度合い。 信頼性 成熟性 通常の運用操作の下で，システム，製品又は構成要素が信頼性に対するニーズに合致している度合い。 可用性 使用することを要求されたとき，システム，製品又は構成要素が運用操作可能及びアクセス可能な度合い。 障害許容性 ハードウェア又はソフトウェア障害にもかかわらず，システム，製品又は構成要素が意図したように運用操作できる度合い。 回復性 中断時又は故障時に，製品又はシステムが直接的に影響を受けたデータを回復し，システムを希望する状態に復元することができる度合い。 セキュリティ 機密性 製品又はシステムが，アクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。 インテグリティ コンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを，システム，製品又は構成要素が防止する度合い。 否認防止性 事象又は行為が後になって否認されることがないように，行為又は事象が引き起こされたことを証明することができる度合い。 責任追及性 実体の行為がその実体に一意的に追跡可能である度合い。 真正性 ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。(本人確認) 保守性 モジュール性 一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように，システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。 再利用性 一つ以上のシステムに，又は他の資産作りに，資産を使用することができる度合い。 解析性 製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること，欠陥若しくは故障の原因を診断すること，又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。 修正性 欠陥の取込みも既存の製品品質の低下もなく，有効的に，かつ，効率的に製品又はシステムを修正することができる度合い。 試験性 システム，製品又は構成要素について試験基準を確立することができ，その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。 移植性 適応性 異なる又は進化していくハードウェア，ソフトウェア又は他の運用環境若しくは利用環境に，製品又はシステムが適応できる有効性及び効率性の度合い。 設置性 明示された環境において，製品又はシステムをうまく設置及び／又は削除できる有効性及び効率性の度合い。 置換性 同じ環境において，製品が同じ目的の別の明示された製品と置き換えることができる度合い。 上記の品質特性をどの工程で検証するかを組み立てていき、プロジェクト全体で過不足なく、バランスを取ることが大事です。例えば、以下のように各テスト工程で重点を置く品質特性（大きな観点）を決めていきます。 【重点を置く品質特性】 　単体テストでは、設計書通りに正確に動作する「機能正確性」 　内部結合テストでは、モジュールを結合させて機能の集合を確認する「機能完全性」 　総合テストや受入テストでは、システムの目的が達成されるかを確認する「機能適切性」 機能面以外でも、処理速度や負荷などの性能効率性、システム運用が適切に行われるかを確認する保守性を決めていきます。どの環境で動作させるかの移植性などのシステム全体の観点を、工程別の確認事項としてプロジェクトの最初（全体テスト計画）に整理することで、個々のテスト工程での検証観点が明確になります。システムによっては、検証対象外の特性もあるかと思います。その場合は対象の特性を「検証対象外」と明確にすることも大事です。 一般企業側の情報システム部門の担当者が、開発側のテスト方針を「品質特性」により指示や調整を行います。そして開発側での品質の積み上げ方を明確にしてもらいます。その方針を持って、最終的に受入テストで必要な確認をしていけばよいのです。このような作業を繰り返していけば、品質を「積み上げる」ことが可能となります。また、副次的な効果として、「コストの最適化」にも役に立ちます。「品質特性」ごとにどの工程で検証するのかを最初に決めるため、複数の工程で同じようなテストを実施するケースを防ぐことができます。結果的に無駄なテストコストを掛けずに進めていけます。 まとめ 「テスト計画の立て方とは？　品質を上げるための勘所（一般企業向け）」と題しまして、ご紹介しました。大規模システム開発での品質の「積み上げ方」の勘所を説明してまいりました。品質は誰か一人の力で上げられるものではありません。 品質は様々なステークホルダと協力し、分担することで、一歩ずつ「積み上げていく」ものです。 すべてを自分一人で抱え込むのではなく、チーム全体で協力することを論理的に組み立ててみてはいかがでしょうか。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト計画の立て方とは？　品質を上げるための勘所（一般企業向け） first appeared on VALTES テストサービス .

『「 テスト自動化 」それは、朝起きればテストが終わっている、ただ一つの手順ミスも犯さない、もちろんエビデンスの取得もぬかりない。そんな夢と希望が詰まった話である。』とは、限らないのが現実のお話です。テスト自動化を実践するには導入までのコストや技術障壁など、導入~運用に至るまで様々な課題が存在します。では、どのように取り組めば適切な費用対効果、投資効果が得られるのでしょうか。 本記事では、弊社での実績・お客様実体験をもとに、 テスト自動化の失敗例と成功例、からうまくいく事例とうまくいかない事例をご紹介させていただき、テスト自動化を成功に導くカギを探っていきます。 なぜテストを自動化するのか？ 恐らくこのブログを読んでくださっている方々の多くは、テスト自動化の導入を一度は検討、もしくは導入しているが課題感がある、という背景をお持ちでしょう。では、皆様にご質問です。「なぜ自動化したいのでしょうか？（したのでしょうか）」人の手を使って作業をしていたところの工数を減らす、おおよそこのような理由でしょうか。ほかにも「人的ミスを減らす」「エビデンスを自動で取る」という目的もあるかもしれません。 では、なぜ工数を減らしたいのでしょうか。リソースを他にまわしたいからでしょうか。であれば、自動化導入後あるべき姿は明確です。今までテストに充てていた工数が他プロジェクト ないしは他作業に充てられる状態が理想の姿となります。浮いた工数を自動化の保守・メンテナンスに充てていては、本末転倒です。このような状況ではテストは自動化できても目的は達成できたと言い切れません。 テスト自動化を推進するにあたり、大切なのは導入目的をしっかりと定義することです。あるべき姿を明確にし、そこから逆算し戦略的に導入する必要があります。「テストを自動化すること」そのものが目的ではないはずです。その先にある、本質的な目的を整理することがプロジェクト 成功への第一歩となるはずです。そこで弊社でのお客様との実体験をもとに、 テスト自動化のうまくいく事例とうまくいかない事例をご紹介させていただきます。テスト自動化を成功に導くために、どのような工夫をしているのでしょうか。 ここが難しい！テスト自動化　うまくいかない事例２選 見切り発車で自動化を推進した場合、どのようなことが起きるのでしょうか。それではテスト自動化がうまくいかなかった失敗事例を２つご紹介します。 【テスト自動化がうまくいかなかった失敗事例】 １．既存テストケースの自動化 あるお客様では、定期的なリリースを計画しているプロジェクトにて既存テストケースの自動化に取り組みました。その際、「失敗」してしまったポイントは以下２点です。 ・自動化対象の選定とKPIの設定を十分に行わなかった 　⇒一度しか使わないケースまで自動化 　⇒重要度の低いものまで自動化 ・テストケースが属人的 　⇒“暗黙の了解”から制約事項の記載漏れが発生 結果、このPJでは「テストの自動化」こそ実現したものの、想定以上の工数オーバーにより、期待以上の効果が得られない結果となりました。 ２．大規模基幹システムのマイグレーション 前述したケースとは違い、こちらのお客様では大規模基幹システムのマイグレーションのプロジェクトでテスト自動化を試みました。先程の事例のようにテストを繰り返す場面ももちろんですが、膨大な数のテストケースを抱えるPJもまた、テスト自動化に取り組まれることが多いケースの１つです。 このプロジェクトでの「失敗理由」は以下２点です。 ・膨大な量（20万ケース）のテストケースを人海戦術で自動化 ⇒大人数で一斉に自動化を行ったため、大量のコピースクリプトが発生 ・メンテナンス性が考慮されておらず、再利用できるスクリプトではなかった 実装したスクリプトは正常に機能し、こちらも「テストの自動化」は成功しました。マイグレーション前後での現新比較を自動で行い、移行自体は成功したようです。一方で、前述したように保守性に欠ける仕組みとなってしまいました。中長期的な視点を欠き、コスト増につながってしまったプロジェクトでした。これらの事例を基にすると、「対象の選定・質」「メンテナンス・保守性」などが原因として浮上しそうです。では、これら解決するにはどのような取り組みが必要でしょうか。 それでは次章に、うまくいった事例を基に、成功させるポイントについて考察していきます。 うまくいくテスト自動化のポイント まず、テスト自動化がうまくいった成功事例を2つ紹介いたします。 【テスト自動化がうまくいった成功事例】 １．パッケージ製品のマスターテストケース自動化 このお客様は自社パッケージをユーザー向けにカスタマイズし、納品していました。そのため、既存機能の部分については納品前に、似たようなテストを繰り返し行っていました。（当社ではマスターテストケースと呼んでいます） 以下に挙げる3点をキーワードに本プロジェクト は進んでいきました。 ・限られた期間での自動化実装 ・テスト対象範囲の明確化 　⇒全テストケースの内、2/3を自動化範囲に選定 ・メンテナンス性を考慮し、キーワード駆動型を採用 結果、テスト実行にかかっていた工数を1/3に削減することに成功しました。 ２．チャットボット用FAQの自動化 本事例の対象システムはチャットボットFAQです。お客様は金融系の業界で、質問と異なった回答（誤った商品・金額、申込できない商品など）を提示してしまうリスクを防ぐべく品質向上に注力していました。その中で、課題に挙がったのが「膨大なテストケース数」です。想定される質問と回答の組み合わせが膨大すぎ、スクリプトの作成にコストと工数がかかりすぎるのが目下のお悩みでした。 この自動化プロジェクト を成功に導いたポイントは以下3点です。 テスト自動化対象範囲と目的を明確化して最適なシナリオを作成 目的に合わせ、ベストマッチするデータ駆動型テストを採用 データ駆動型テストの適用により、最小限のスクリプトで多くのテストケースを自動化 結果、テスト期間を1/10に短縮、コストを1/3に抑えることに成功 しました。いかがでしょうか。全く異なる業界、システムでの自動化事例でしたが共通点は「準備」です。実装前に、対象範囲の選定、テストケースの自動化適合性、 プロジェクト特性に合わせたツール選定（もしくはツールの適合性）など様々な視点から調査を行うことが自動化を成功に導きます。他にも損益分岐点の算出も有効です。自動化は繰り返し使えば使うほどコストメリットが出ますので、何回繰り返せばイニシャルコストを回収できるのかを考えてみましょう。 当社ではこのような「準備」を「フィージビリティ・スタディ」と呼び下記のようなレポートを作成し、『自動化を戦略的に導入すること』を推奨・ご提案しております まとめ 「テスト自動化　うまくいく事例とうまくいかない事例をご紹介」と題しまして、ご紹介してきました。いかがでしたでしょうか。ここまで、失敗例・成功例を題材に、いかにしてテスト自動化を成功に導くかを探ってまいりました。昨今、システム規模の拡大や複雑化、複数プロジェクトの並行稼働等、IT業界はリソースが逼迫しております。自動化できる部分はどんどん自動化していくべきだと私は思います。そして、人の手によって価値が生み出せる（自動化できない）仕事に注力し、より良いIＴ社会が実現できればと願っています。テストの自動化に取り組む皆様にとって、このブログが少しでもヒントになれば幸いです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト自動化　うまくいく事例とうまくいかない事例をご紹介 first appeared on VALTES テストサービス .

ソフトウェア開発において、テストは欠かせない工程です。テストを効率良く進めるためには様々な工夫が必要ですが、その一つとして重要なものがテストケースです。 良いテストケースを使うことでどのようなメリットが得られるのか。逆に、悪いテストケースを使うとどのようなデメリットがあるのか。 いくつかの例を使って解説します。 テストケースって何のためのもの？ テストをどのように進めるのかを記載した指示書にあたるものがテストケースです。テストでの指示とはどういうものでしょうか？まず、テストの対象は何なのか？ネットショッピング、飲食店の予約などのWebサイトなのか？あるいはプリンター、複合機などのオフィス機器なのか？ 例えば、テストの対象がネットショッピングのWebサイトであった場合、テストで使ってよいサイトのURLは？ログインするためのアカウントは？何をテストすればいい？サイト全体なのか、あるいは商品検索、カートへの商品追加など特定の機能のテストなのか？操作した結果、どのような挙動になるのが正しいのか？様々なパターンがあると思います。 テストの指示書であるテストケースには、 テストの対象 テストの観点（何を確認するのか？） テストの操作手順 期待結果 などが記載される必要があります。しかしながら、テストケースの記載内容があいまい、分かりづらく、間違っていたりすると、 テスト対象ではない箇所をテストしてしまう 操作手順を間違って、期待結果通りにならず、誤って不具合と判定されてしまう テストしたい箇所が正しくテストされず、不具合を見逃してしまう など、予期せぬ結果になり、せっかく時間をかけて行ったテストが無駄になってしまうこともあります。テストするべき対象に対して、正しくテストを行いましょう。そのための必要な情報を記載した指示書にあたるのが、テストケースです。 悪いテストケースとは？ 良いテストケースを作るために、まずは悪いテストケースの例をいくつか見ていきましょう。 No 実施手順 期待結果 結果 1 商品を検索する 検索できること 2 カートに入れる カートに入ること 【例1 悪いテストケース1】 上記のテストケースの場合、悪い点はどこなのでしょうか？ 対象システムは？ 対象システムの接続先（URL）は？ Webブラウザでテストする場合、どのブラウザを使えばいい？ 最初にログインは不要？ 「商品を検索する」という手順は、ジャンルから選択していくやり方と、キーワードを入れて検索するやり方など複数あるが、どれのこと？ 「カートに入ること」という期待結果は、商品は何でもいいので一つ入れば良いのか？ 結果には何を書けばいい？ など、確認したいことがたくさん出てきます。 質問・回答に時間もかかりますし、質問しないでテストを行うと、どのレベルまでテストされたのかが不明のままになってしまう可能性が高くなるのです。 No 実施手順 期待結果 結 果 1 1.以下URLに接続する    https://www.xxxyyy.co.jp/ 2.ログイン画面で以下のアカウント／パスワードを入力して、「ログイン」ボタンを押す 　アカウント：testaccount1 　パスワード：testpass 3.左のメニューから「商品検索」ボタンを押す 4.「商品検索」画面、「商品名」フィールドに以下の文字を入力して「検索」ボタンを押す 　文字列：「ソフトウェアテスト」 ・ログイン画面が表示されること ・商品検索画面が表示されること ・検索結果の中に「ソフトウェアテスト」という文言の入った以下の商品が含まれていること 　「ソフトウェアテストの教科書」／カテゴリ：書籍 　「はじめて学ぶソフトウェアテスト技法」／カテゴリ：書籍 ・検索結果の中に以下の商品が含まれていないこと 　「スマートフォンケース（赤）」 結果欄には以下の何れかを記載すること OK / NG / 再確認OK / QA / 保留 / NT / N/A 【例2 悪いテストケース2】 上記のテストケースの悪い点はどこなのでしょうか？手順は明確になり、テスト対象を間違えることは無さそうです。結果欄に記載する内容も明確になりました。ただ、期待結果が途中の結果も含めて複数記載されています。商品検索画面は表示されていますが、検索結果は期待通りにはならなかった場合、結果欄にはどのように記載すればいいのでしょうか？ 期待結果が全てOKではないので、NGと記載することになりそうです。不具合の改修を担当する開発者は、どこまでがOKで、どこがNGなのかが不明な場合があります。そのため テスト実行者にヒアリングするか、あるいは開発者が再度同じテストを最初から行い、確認する必要があるでしょう。 効率良いテストになるとは言えませんね。 良いテストケースの書き方と粒度 悪いテストケース例で述べたことを注意し、さらに以下の考慮を加えると、良いテストケースになります。 【良いテストケースの書き方】 テスト観点（何を確認したいのか？）を明確にする 前提条件を明記する 事前に対象画面にアクセス可能なアカウントを用意しておく、価格がxx円以上の商品データをxx件作成しておく 正しいテストを行う上での事前準備を明確にして、テストミスを防ぐ テストした環境、バージョンを明記する これにより環境、対象ソフトウェアテストのバージョンの差異により結果が異なる場合も正しく状況が把握出来る 実施日、実施者を明記する テスト実行者に後から状況を確認したい場合に、誰に確認すれば良いのか明確になる テスト実行者が結果に対して責任を持つという点でも効果がある 不具合の情報（不具合管理システム、Excelなどで別途管理している場合の不具合のID）を記載する 不具合が解消された際にどのテスト項目を再確認するべきかが明確になる テスト結果の集計が出来るような工夫をしておく テストの進捗管理に使える、社内及びお客様への日次、週次などの報告用に使える この他にも、テスト項目の粒度にも注意を払う必要があります。 No 実施手順 期待結果 結果 1 商品を検索する 検索できること 　 2 カートに入れる カートに入ること 　 3 1.以下URLに接続する    https://www.xxxyyy.co.jp/ 2.ログイン画面で以下のアカウント／パスワードを入力して、「ログイン」ボタンを押す 　アカウント：testaccount1 　パスワード：testpass 3.左のメニューから「商品検索」ボタンを押す 4.「商品検索」画面、「商品名」フィールドに以下の文字を入力して「検索」ボタンを押す 　文字列：「ソフトウェアテスト」 ・ログイン画面が表示されること ・商品検索画面が表示されること ・検索結果の中に「ソフトウェアテスト」という文言の入った以下の商品が含まれていること 　「ソフトウェアテストの教科書」／カテゴリ：書籍 　「はじめて学ぶソフトウェアテスト技法」／カテゴリ：書籍 ・検索結果の中に以下の商品が含まれていないこと 　「スマートフォンケース（赤）」 　 上記は悪いテストケースの例で提示した3件のテスト項目です。 No.1とNo.2はかなりざっくりと記載されており、No.3は手順が細かく記載されています。No.1とNo.2は極端な例ですが、複数のテスト項目の粒度が全く統一されていない例になります。完全に粒度を統一するのは難しいですが、ある程度の統一感を意識することで、テスト実行者にとっても分かりやすくなります。また勘違いなどから起こるテストミスを防ぐことにもつながります。テストケースを作成するテスト設計者にとっても、テスト実行者からの質問対応が減り、また、進捗確認を行う上でも、より正確に消化状況を把握できます。 【良いテストケースの粒度】 実施手順は、複数の似たような手順がある場合、そのどちらなのかを明確にする。 期待結果は、結果を確認して、OK / NGなどの結果を残したい単位にしていく。 このような内容が、良いテストケースの粒度を考える上でのポイントになります。 まとめ 「テストケースって何？悪いテストケースと良いテストケースの違い」と題しまして、ご説明してきました。 テストケースは、ソフトウェアテストを行う上での指示書 です。誰が、何を、いつ、どの環境で、どのような目的で、どのようにテストしたのかを明確に出来るように意識するのは大事なポイントです。また、テスト実行の進捗管理、状況報告も意識して、集計表も用意しておくことが重要です。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テストケースって何？悪いテストケースと良いテストケースの違い first appeared on VALTES テストサービス .

「オンプレミスからクラウドサービスへの切り替えを検討しているが、オンプレミスからクラウドサービスへ変更すると何が違うの？」と頭を抱える企業様も多いのではないでしょうか。最近は、「ハイブリッドクラウド」として、オンプレミスとクラウドサービスの双方のメリットを活かすといった運用を行っている企業もあります。今回はクラウドサービス運用後に課題となるポイントをご紹介いたします。 運用上で大きな課題となる点を抑えておこう オンプレミスとクラウドサービスの違いは？といっても、通信料が掛かるといったものから様々な違いがあります。今回はサービス導入後に課題となる点を大きく3つに絞りました。 【サービス導入後の３つの課題】 リプレース後の様々なギャップ（パフォーマンスなど） 予期しないサービスの障害 APIの変更による外部システム連携の影響 １と２については、公正取引委員会の「クラウドサービスの取引実態に関するアンケート調査結果」でも挙げられています。それではサービス導入後の３つの課題を詳しくご紹介していきます。 1.リプレース後の様々なギャップ（パフォーマンスなど） リプレース後にオンプレミスとの機能差、パフォーマンスの違いなどにより、　以前のシステムより使いづらくなることがあります。 2.予期しないサービスの障害 クラウドサービス自体の障害により提供するサービスを一時的に停止せざるを得ないといったケースがあります。このような事象を事前に理解した上で、クラウドサービスの運用を検討しておく必要があります。 3.APIの変更による外部システム連携の影響 「APIが変更されることを失念して、そのまま本番環境に反映されてしまった」または「システム連携先の他社にAPIの変更を伝え漏れてしまった」といったケースがあります。APIを用いて外部システムとの連携を行うことでより効率化させることがクラウドサービスのメリットの1つですが、クラウドサービス提供側のAPIの変更により、思わぬトラブルに繋がることもあります。「APIの仕様が変更されるかもしれない」ことも想定しておく必要があります。さて、このようなサービス導入後の問題が起きた場合、または起こさない為に何をすべきでしょうか？ リプレース後の様々なギャップ 「システムへのリソースの割り当てが行われておらず、オンプレミスよりも処理速度が劣化する」、「複数のクラウドサービスを利用し、複雑なシステム構成となった結果、不具合改修に時間が掛かる」といった課題が運用後に発覚するケースをよく耳にします。では、運用前に対応できる対策について解説します。 オンプレミスとクラウドサービスのシステム双方をテストし、比較できる状態にしておく 「現（現在の環境）新（新しい環境）比較と言われるものです。これは運用前にテストを行うことで、運用後に発生する問題を低減させることができます。ただし、気を付けるべき点としては、「必ずしも現在の環境が正しい」という事はない点です。よくあるケースとしては、現新比較時に現在の環境による潜在問題が検出される場合もある為、注意が必要となります。 クラウドサービスのカスタマイズ性がオンプレミスほど十分ではない為、一部の機能が利用できなかった 特にオンプレミスからクラウドサービスに変わる為、対応できるエンジニアのスキルも変動します。予め、プロジェクト立ち上げ時にクラウドサービスに精通したエンジニアを起用することで、クラウドサービスの拡張性、カスタマイズ性を事前に把握できます。また、実装およびテストを行う際にも、クラウドサービスの利用に伴う変更点として、開発チームおよびテストチームへ周知しておくことが望ましいです。このように、リプレース後の様々なギャップについては、運用前にテストを行うことで課題を低減させることが可能となります。よって、開発スケジュールに予め組み込んでおくことをお勧めします。 予期しないサービスの障害 オンプレミス利用時も同様に起こりえますが、オンプレミスとの大きな違いとして、障害の内容によってはクラウドサービス提供事業者に問い合わせも発生します。結果として、問題解決に至るまでの多くの所要時間を必要とする場合があります。また、クラウドに精通していないインフラエンジニアが携わった場合、2次障害に至るケースも少なくありません。予期せぬサービス障害が発生しても、2次障害を発生させないため、以下のような対策を行う事をお勧めします。 予期しないサービス障害発生時に、システムがどのような挙動になるかを理解しておく プロジェクトのテスト工程に予期しない障害発生時のテストをあらかじめ計画しておくことでサービス障害発生時に意図しないシステム挙動になっていないかを確認することができます。プロジェクトの日程上、なかなか時間が取れない場合であっても、本件の確認は必須です。 障害発生時の運用マニュアルを作成しておく 稼働しているメンバーが不測の事態で不在になった場合を想定し、運用マニュアルを作成しておくことが望ましいです。マニュアルがない状況下で障害対応をした結果、2次障害が発生するケースも少なくありません。このような事態とならないように、事前にマニュアルを整備しておくことで、2次障害リスクを低減させることができます。 サービス運用前に障害を意図的に発生させた上で、保守運用チームを含めた障害発生時の事前訓練を行う サービス運用前にリハーサルされている企業様は少ないのですが、リハーサルとして、実際の障害発生時のフローを一通り行うことをお勧めします。なぜなら、現行の定めた運用フローに課題がないか否かの確認を行うことができるからです。できれば、避難訓練などと同様に1年に1度訓練しておくことが望ましいです。クラウドサービスの障害については、各社が予期できる内容ではないとも言えます。障害が発生し大きな問題に発展しない為にも、事前に「障害発生」を想定した運用をプロジェクトの計画に組み込んでおきましょう。 APIの変更による外部システム連携の影響 クラウドサービス間を繋ぐために、APIを使用されている企業も多いと思います。APIについては、開発としても非常に使い勝手がよい反面、仕様変更および連携先のAPIの仕様によって、対象システムの挙動が変化します。そのため、考えられる課題としては、以下となります。 利用していたAPIの廃止 利用していたAPIの変更 利用していたAPIの廃止について は、API廃止時の想定外処理を事前に実装に組み込んでおくことで、大きなトラブルの発展を未然に防ぐことができます。一方で、利用していたAPIの変更ですが、「10桁の文字数」から「20桁」または「5桁」に変更されるといった可能性がある為、未然に防ぐのは非常に難しいと言えるでしょう。 まとめ オンプレミスからクラウドのリプレースまたは、リプラットフォーム（異なるクラウドへの移管）などをご担当される方は非常に不安を感じられるとは思います。運用後に発生するリスクを今一度理解しておくことで、より良いサービス運営に活かして頂けますと幸いです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post クラウドサービス運用後の3つの課題とは？対策を考えてみよう first appeared on VALTES テストサービス .

昨今「アジャイル型」を採用している開発チームが増えてきています。エンジニアの皆さんが「アジャイル開発」と聞いたら、気になるのはやはりメリットとデメリットなのではないでしょうか？今回はそんな アジャイル開発のメリット・デメリットについて、テスト会社ならではの視点から分かりやすく解説 してきます。 アジャイル開発の特徴とは？ 「アジャイル開発ってそもそもなんだろう？」そんな疑問を持つ人は少なくないでしょう。アジャイル開発とは細かな機能単位に対して開発サイクルを、1週間から1か月程度の短い期間でくり返していく開発手法を指して使われるものです。もっと深く掘り下げると「アジャイルソフトウェア開発宣言」という文書のなかで以下のような考え方をする開発手法を「アジャイルソフトウェア開発」と呼んでいます。 【アジャイルソフトウェア開発】 プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を ここから分かるように、 「大事なのはユーザーのニーズに合わせて柔軟に対応すること」という価値観が根っこにある開発手法がアジャイル開発です。 みなさんがアジャイル開発の特徴ってなんですか？と聞かれると、こんなものがパッと思いつくはずです。 【アジャイル開発の特徴】 短い開発サイクルによるすばやい機能リリース チームの規模に合わせた適切なサイクル設定 要望や状況に合わせて柔軟に仕様変更を行う こういった特徴は、先ほど紹介した価値観に則した開発をおこなうための具体的な手法の部分といえるでしょう。サービス開発において「ユーザーのニーズに応える。」という価値観は外せないものであることは間違いありません。開発に関わるエンジニアのみなさんは表面上の特徴だけでなく、根底にあるものも意識してみてください。同じ作業内容でも方針や出来上がるものに変化が見られるかもしれません。 アジャイル開発時のメリットを「テストの視点」で考えてみよう メリット・デメリットは特徴に付随するものといっていいでしょう。まずは先ほど挙げた特徴をもとに、メリットから考えていきたいと思います。 【アジャイル開発のメリット】 短い開発サイクルによるすばやい機能リリース チームの規模に合わせた適切なサイクル設定 アジャイル開発ではスプリントと呼ばれるリリースまでの一連のサイクルが１～2週間程度で進んでいきます。しかしどんなプロジェクトでも同じ期間というわけではありません。プロジェクトの規模や開発対象の特性は重要です。またエンドユーザーになる顧客との関係性に応じて、適切と思われる期間を各チームが独自に決定して開発を進めています。こういった短いサイクルから生まれるメリットは、 発生した不具合やユーザーからの要望への対応が早い点です。 ウォーターフォール型の開発では要件定義～リリースまでをかっちりと決まった期間で行うことが一般的です。 つまりユーザー側から上がってくる不具合や要望に対して、アップデート版のリリースという形で対応するまでになかなかのラグがあったわけです。アジャイル開発ではその点を解消できており、優先度の高い不具合は次回のスプリントにまぜこむことで、1～2週間程度でユーザーに対して不具合の解消が実現できます。また新規のシステム開発についてもミニマムでの初回リリース後に定期的なアップデートを行っていくことができます。つまり、 すばやいビジネススタート ができるという経営的な側面からのメリットもあります。 要望や状況に合わせて柔軟に仕様変更を行う この特徴からは発生する手戻りが減るというメリットが考えられます。アジャイル開発では短いサイクルを回していく中で、ユーザーへより良いプロダクトを届けるため仕様の変更が発生する場合があります。ウォーターフォール型の開発であれば話が違います。こういった仕様の変更を行うには、各工程を少なくない工数をかけて再度仕様を検討する必要があります。しかしアジャイル開発では仕様の変更手順が変わらずとも、手戻りとして遡らなければならない箇所が少なくて済みます。 特徴はデメリットにもなる！　気をつけたいポイント アジャイル開発にはメリットばかりではなく、デメリットも当然あります。デメリットにもき気をつけて取り組んでみましょう。 【アジャイル開発のデメリット】 ドキュメントの作成が追い付かない 開発スピード・開発サイクルを意識するあまり ドキュメントの作成が間に合っていない プロジェクトがしばしば存在します。またそのようなプロジェクトに限って一部のメンバーに頼り切った、いわゆる 属人化 が起きている場合が多いでしょう。アジャイル開発においてもドキュメント作成は重要です。「担当者が休みなので」といった理由で作業が止まってしまうといった案件は、健全な状態とはいえないですよね。ドキュメントの作成を行わないと属人化が加速し、ドキュメントの作成を行うタイミングもどんどん失われていきます。そしてまた属人化が、、、といった具合に、負の連鎖が発生しやすく危険度の高い状態が生まれやすいのがデメリットといえます。 対応策としては早い段階でチーム全体が問題意識をもち、ドキュメントの作成をオペレーションとして組み込むなどの地道な対応を行うことが大切です。また作業を適切に切り分けて外部ベンダーを利用するといった場面でも威力を発揮するでしょう。実際、弊社がご支援している案件において、自社完結の開発を行うよりも低コストで済んだといった実例もあります。 スケジュール管理が難しい アジャイル開発ではユーザーストーリーごとにスケジュールを行う場合が多いです。しかし仕様変更やユーザーからの追加要望など様々な要因が差し込まれると、 スケジュールをコントロールするのが難しくなってしまうこと があります。特にスケジュールが厳しくなってくると、十分な検証期間が取れないままリリースを行ってしまいます。そして重大な不具合を取りこぼして、大きな損害を発生させてしまうことが想定されます。第三者検証の視点から見ると、アジャイル開発ではこういったコントロールの難易度が高いことから、テストまで手の回っていないプロジェクトが多くあるのも事実です。 開発メンバーがテストの作成まで行った場合、確認内容に偏りが生じたり、テストそのものに抜け漏れが発生してしまったりすることが多々あります。また開発メンバー自身の確認や、チームメンバー同士での確認は心理的な要因で対応そのものに甘さが生じてしまうものです。スケジュールが対策としてはスケジュール管理専門のメンバーを立てることや、アジャイル開発の経験があるプロジェクト管理者をアサインする方法があります。 まとめ 今回はアジャイル開発のメリット・デメリットをアジャイル開発の特徴を踏まえながら考えてみました。他の開発手法にはない「すばやさ」や「柔軟さ」といったメリットは、大きなアドバンテージを持つ一方で、「ドキュメントの作成不足に陥りやすい」「コントロールの難易度」などといったデメリットもありました。そんなアジャイル開発は、 ユーザーに対してより良いプロダクトを提供することを目的に始まった開発手法 です。デメリットの適切な対処法さえ理解して処理できれば、変化の激しい現代において一番妥当な開発方法ともいえるはずです。本記事が皆様のアジャイル開発の運用のヒントになれば幸いです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post アジャイル開発　テストの視点で考えるメリット・デメリットとは？ first appeared on VALTES テストサービス .

ここ数年で アジャイル 開発が広まり、小規模の新ビジネスの開発だけでなく、基幹系・大規模開発にまで広がってきています。その中で、システムの品質向上が課題となっていると思います。対策の1つとして「テストファースト」により、開発の前にテスト（ケース・コード）を実装して品質を確保していきますが、システムが提供するサービス全体の品質を確保するのは困難ではないでしょうか？ 今回は、 「テストファースト」の意味を拡張させ「シン・テストファースト」と題して、プロジェクト全体を品質面からリードする考え方を提示させて頂きました。 ご興味のある方は、ぜひ実践してみてください。 テストファーストとは？ 「テストファースト」という言葉は聞いたことがあると思います。テストファーストの情報を完結にまとめると、以下の内容になります。 テストファーストとは、先にテストケースやテストコードを準備して、それが通るように開発をする手法です。「テスト駆動開発」パターンの１つに挙げられています。 アジャイル開発において、あるスプリントで開発する機能を定義した際、先にテストケースやコードを実装しておき、そのテストが通るようにコードを書いていく手法です。 メリットとしては、バグを早期に検知できたり、機能設計⇒テスト設計と二度手間になりうる作業が一度に済んだりと、アジャイル開発に適している手法だと思います。 アジャイル開発における品質課題 「テストファースト」によるシステム開発のメリットはありますが、同時にデメリットもあると思います。ウォーターフォールのように要件定義⇒設計⇒開発と積み上げる方式と異なるアジャイル開発では、システム全体の品質のコントロールが確保できない課題に直面する場面が多いと思います。例えば、機能単位の品質管理には適していると思いますが、 テストファーストのデメリットとして、システム全体の品質を俯瞰的・網羅的に確保するには難しいのではないでしょうか？ また、非機能要件やユーザビリティといった機能レベルではない部分の品質の確保には適していないと思います。もちろん、「テストファースト」という手法でシステムのすべての品質を管理するのではなく、一般的な品質管理手法との組み合わせで対応すると思いますので、上記の例は極端な話ではあります。 「シン・テストファースト」による品質管理 今回は、「テストファースト」の意味を拡張させ、 プロジェクト全体の推進と品質管理に活用できる考え方「シン・テストファースト」を提起したいと思います。 方針 各工程で、品質管理で使われる手法を用いて、品質向上と同時にプロジェクト推進に貢献できます。品質管理面からのアプローチのため、広い意味で「テストファースト」という言葉を使わせて頂きました。 要件定義工程 開発するシステムがどんなサービスを提供するのかの業務要件はもちろん、非機能要件まで網羅する必要があります。いきなり要件をまとめようとしても、どこから手を付けていけばよいのかわからないという状況が多いのではないでしょうか。また、アジャイル開発であれば、動くものを作る作業が優先で、きちんと要件を整理するタイミングがないのではないでしょうか？このような状態で要件をまとめるために、テスト計画などで利用される「品質特性」を参考に、要件をまとめてみてはいかがでしょうか？ 「品質特性」とは、「ISO/IEC25010ソフトウェアの品質モデル」に定義されており、８つの特性で定義され、各々の特性に対して計３１の副特性が定義されています。 主特性 副特性 定義 機能適合性 機能完全性 機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。 機能正確性 正確さの必要な程度での正しい結果を、製品又はシステムが提供する度合い。 機能適切性 明示された作業及び目的の達成を、機能が促進する度合い。 性能効率性 時間効率性 製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間、並びにスループット速度が要求事項を満足する度合い。 資源効率性 製品又はシステムの機能を実行するとき、製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い。 容量満足性 製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。 互換性 共存性 その他の製品に有害な影響を与えずに、他の製品と共通の環境及び資源を共有する間、製品が要求された機能を効率的に実行することができる度合い。 相互運用性 二つ以上のシステム、製品又は構成要素が情報を交換し、既に交換された情報を使用することができる度合い。 使用性 適度認識性 製品又はシステムが利用者のニーズに適切であるかどうか。 習得性 明示された利用状況において、有効性、効率性、リスク回避性及び満足性をもって製品又はシステムを使用するために明示された学習目標を達成するために、明示された利用者が製品又はシステムを利用できる度合い。 運用操作性 製品又はシステムが、それらを運用操作しやすく、制御しやすくする属性をもっている度合い。 ユーザーエラー防止性 利用者が間違いを起こすことをシステムが防止する度合い。 ユーザインタフェイス快美性 ユーザインタフェースが、利用者にとって楽しく、満足のいく対話を可能にする度合い。 アクセシビリティ 製品又はシステムが、明示された利用状況において、明示された目標を達成するために、幅広い範囲の心身特性及び能力の人々によって使用できる度合い。 信頼性 成熟性 通常の運用操作の下で、システム、製品又は構成要素が信頼性に対するニーズに合致している度合い。 可用性 使用することを要求されたとき、システム、製品、又は構成要素が運用操作可能及びアクセス可能な度合い。 障害許容性 ハードウェア又はソフトウェア障害にもかかわらず、システム、製品、又は構成要素が意図したように運用操作できる度合い。 回復性 中断時又は故障時に、製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い。 セキュリティ 機密性 製品又はシステムが、アクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。 インテグリティ コンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを、システム、製品、又は構成要素が防止する度合い。 否認防止性 事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明することができる度合い。 責任追及性 実体の行為がその実体に一意的に追跡可能である度合い。 真正性 ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。(本人確認) 保守性 モジュール性 一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように、システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。 再利用性 一つ以上のシステムに、又は他の資産作りに、資産を使用することができる度合い。 解析性 製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。 修正性 欠陥の取込みも既存の製品品質の低下もなく、有効的に、かつ効率的に製品又はシステムを修正することができる度合い。 試験性 システム、製品又は構成要素について試験基準を確立することができ、その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。 移植性 適応性 異なる又は進化していくハードウェア、ソフトウェア又は他の運用環境若しくは利用環境に、製品又はシステムが適応できる有効性及び効率性の度合い。 設置性 明示された環境において、製品又はシステムをうまく設置及び／又は削除できる有効性及び効率性の度合い。 置換性 同じ環境において、製品が同じ目的の別の明示された製品と置き換えることができる度合い。 出典:「JIS X 25010:2013 (ISO/IEC 25010:2011) システム及びソフトウェア製品の品質要求及び評価(SQuaRE)ーシステム及びソフトウェア品質モデル」 「品質特性」にある要件に対する「テスト」を定義することで、要件定義の代わりになりうると考えられます。例えば、「時間効率性」のテスト要件を決めれば、性能目標を決められます。「使用性」の各副特性に対して、テスト要件としてどこまで求めるかを定義すれば、ユーザビリティに対する要件を定義できます。 設計工程 詳細な設計書を作成しないアジャイル開発では、各機能やオブジェクトの仕様（入力制限など）は曖昧なまま実装が進んでしまう状況が多いと思います。本来の「テストファースト」でも、先にテストケースを作成する運用となっているため、ここでテストケース作成（またはテストコードの設計）を行います。実際にこのような手法を採用した場合、テストケース作成側では期待値を明確にしたいので、詳細な仕様の確認をする必要があります。 その際、テストエンジニアが開発者に確認しながら、仕様を詳細化・具体化していく作業が期待されます。品質管理としての手法としては「仕様書インスペクション」が活用できると思われます。本来は開発側の設計書の曖昧さや整合性をチェックする手法です。しかし、そのノウハウは「テストファースト」のテスト設計でも活用できると思います。 テスト工程 要件定義、設計工程と、品質面から要件や仕様を明確にしてきています。それらをインプットとして、結合テストや総合テストのテスト設計を進めていくことができます。例えば、結合テストであれば、品質特性の「相互運用性」に対して整理した結果に基づき、テスト設計を進めることができます。また、総合テストでは、品質特性の「機能適切性」を基に、「明示された作業及び目的の達成を、機能が促進する度合い」の検証が可能となります。その他、非機能系のテストについても、様々な品質特性にて定義した内容からテスト設計を進めていくことができます。 例： 　 パフォーマンステスト ：性能効率性 　ユーザビリティテスト：使用性 　運用テスト：信頼性、保守性 まとめ システム開発には様々なアプローチや手法があります。その中で、開発対象に適したアプローチの判断は困難であると思います。今回は、「シン・テストファースト」と銘打ち、 テストファーストによる品質管理面からのアプローチの案の１つを提示させて頂きました。 皆様のプロジェクト推進時の引き出しの１つとして活用頂ければ幸いです。 当サイトでは、テスト技法を学びたい方、アジャイル開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post シン・テストファースト　品質面からプロジェクトをリードしてみよう first appeared on VALTES テストサービス .

不具合の検出が後工程になればなるほど改修対応のコストがかかるというのが一般的な認識でしょう。そこで、できるだけ前工程で不具合をつぶして対応コストを下げ、品質を上げるためにテスト駆動開発(Test-Driven Development：TDD)の導入をしたいと考える方もおられると思います。 はたしてテスト駆動開発は品質の救世主となりえるのでしょうか。メリットとデメリットと合わせてテスト駆動開発についてご紹介します。 テスト駆動開発（TDD・ テストドリブン） とは テスト駆動開発（Test-Drive Development：TDD　テストドリブンとも言う）とは、テストファーストな開発手法です。あくまでも開発手法であり、品質を保証するためのテストではない点に注意が必要です。テスト駆動開発は以下の３つのステップを繰り返していきます。 【テスト駆動開発　３つのステップ】 Red：実装すべき機能要件を元にテストコードを書く Green：テストコードがPass（成功）するプロダクトコードを実装する Refactor：テストが成功する状態を維持しながら重複を取り除く(コードを美しくする） おそらく、この部分だけを切り取って見ると誤解を生じるのではないかと思いますので、少し補足します。 Red：実装すべき機能要件を元にテストコードを書く このステップで重要なポイントはテストコードを書く前に、何を実現(実装)すべきなのかを明確にしてテストパターンを書き出しておくという点です。「テストパターン＝実装するものリスト」と考えるとよいでしょう。もう一つ重要なポイントを挙げるとすると、前述の通り「品質を保証するためのテストではない」という点です。つまり「C0／C1／C2 カバレッジの網羅率を○○%にする」といった目的で行うものではないということです。※結果的に網羅することはあり得ます Green：テストコードがPass（成功）するプロダクトコードを実装する このステップではテストコードがPassとなる「最低限」のプロダクトコードを実装しますが、いきなりすべてのテストがPassするものを実装する必要はありません。「実装するものリスト」に対して一つずつ実装を積み上げていくようなイメージです。 Refactor：テストが成功する状態を維持しながら重複を取り除く(コードを美しくする) テストコードをPassするように実装を行うと、いわゆるコードが散らかった状態になります。このステップではそういったコードを見直していきます。熟練の方であれば初めから美しいコードを書くことも可能だと思います。しかし、このステップがある前提で「美しいコードを書かねばならない」という心理的プレッシャーからは一旦解放されましょう。 ただし、テストがPassした状態=動く状態 であるためこのステップを省かない(後に積み残さない)ように注意すべきです。リリースされ運用され続ければ当然仕様の追加・変更が発生し、コードが大きくなっていきます。大きくなればなるほど後の修正が大変になり、結局やらなくなるという悪循環を作らないようにしましょう。 テスト駆動開発のメリット・デメリット どのようなものでも必ずメリットとデメリットがあります。これから導入を考えている方はメリット・デメリットを合わせて検討する必要があります。 まずは代表的なメリットからご紹介します。 【メリット】 メリット①　実装する時点で不具合の検出が可能となり、後工程に不具合を持ち越しにくい テストと実装を平行に行っていくため、早期の不具合検出と解決が可能になります。また、「最低限の実装を行う」「リファクタリングによって実装コードが整理される」という点から簡潔な実装になることが期待できます。よって不具合が混入しにくくなります。このため、後工程に不具合を持ち越しにくいというメリットに繋がります。 メリット②　実装担当者の仕様への理解が深まる 「実装すべき機能要件を元にテストコードを書く」ためには要件を理解・分解する作業が必然的に発生します。この作業により担当者の要件への理解が深まり、実装途中での認識齟齬などにも気づく可能性が高くなります。 メリット③　コーディング時の心理的不安が軽減される 動作を確認するためのテストコードが用意された状況となります。よってプロダクトコードに手を入れた際に「プログラムを壊してしまう」「デグレードを発生させてしまう」という心理的負担の軽減が期待できます。「実装するものリスト」が明確になっているため、進捗を測りやすいという管理面でのメリットも期待できます。他にも細かいメリットはありますが、もちろん良い事ばかりではありませんのでデメリットにも目を向けてみましょう。 デメリットは以下のようなものがあります。 【デメリット】 デメリット①　工数がかかる 　本来のプロダクトコードの実装とは別にテストコードの実装を行う必要があるため、当然ながらその分の工数がかかります。　プロダクトコード実装の生産性が下がる、と言い換えた方が良いかもしれません。　また、仕様変更や追加開発の際にもテストコードの修正や追加が必要になります。 デメリット②　慣れるまで一定のストレスがかかる 新しい仕事の進め方を取り入れる場合、慣れて定着するまでは担当者に一定のストレスがかかります。導入を推進する管理者の方も同様でしょう。開発の現場に限った話ではなく、新しい仕事の進め方を取り入れる場合には同様の課題にあたることがほとんどだと思います。みなさんにも容易にご想像いただけると思います。 デメリット③　テストコードのレビューが必要になる 工数がかかるという点ではデメリット①に通じますが、正しいテストが実装されているかという観点でのレビューが必要になります。　テストコードを実装したものの、実は有効なテストではなかった、という事態になるとすべてが無駄になってしまいます。「テストしたつもりになってしまう」、というのが一番避けるべきかもしれませんね。 テスト駆動開発(で救えるもの・救えないもの テスト駆動開発の手法とメリット・デメリットについてご紹介してきました。この手法によって救えるもの(カバーできる品質)・救われないもの(カバーできない品質)についても触れておきます。 救えるもの すでにお伝えしていますが、開発のための手法であり品質を保証するための手法ではありません。またテストコードも単体テストのスコープであるため、いわゆる「単体テスト工程で検出するべき」と分析されるような不具合の検出が可能であることは予想できると思います。そもそも単体テストのカバレッジ○%を達成するといった目的で行うものではないという点にも注意が必要です。そう考えるとプロダクトコードの品質を高めることによりデグレードを防ぐことができる効果がある、といった方が良いかもしれません。 救えないもの 前述の通り、単体テストがスコープであるため、それ以降の結合テストやシステムテストでのみ検出できるような不具合は当然ながら検出できません。　テストコードを書いたからといってテストが不要になるわけではありませんので、適用範囲を見定めて導入することが重要です。 まとめ 「テスト駆動開発は品質の救世主となりえるか」と題して、TDDについて紹介しました。 【総括】 テスト駆動開発は開発手法であってテストではない テストコードを書いたからといってテストが不要とはならない 結局のところ、TDDだけでは品質の救世主にはなりえないと言えますが、 開発者の仕様理解度を高め認識の齟齬を防ぐ コードの品質を高めてデグレードの発生を防ぐ という点では品質向上への一助となるのではないでしょうか。テスト駆動開発を活用しながら、様々な取組みにより、システム開発の品質向上を目指していきましょう。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト駆動開発（TDD）は品質の救世主になれるのか？ first appeared on VALTES テストサービス .

リモートワークによるオンライン業務を中心とした企業様が継続して増加しております。オンラインによる アジャイル 開発で業務を進め、社内メンバーの満足度と開発の生産性を高めるはずが…意外とコストが掛かっている事実に驚いたプロジェクトマネージャーも少なくないと思います。生産性が思ったよりも上がらず、「アジャイル開発は失敗かな…」とあきらめていませんか。 見えない失敗からアジャイル開発の成功を考えてみましょう。 アジャイルが失敗する原因 アジャイルを適用したはずなのに… 「開発に特に問題もない」、「アジャイルの原則通りにプロジェクトを進めている」、「 テスト自動化 も導入している」なのに「なぜ失敗したのか？」と頭を悩まされている方もいるのではないでしょうか。アジャイル開発の「目に見える失敗」については既に様々な記事が出ておりますので、ここでは「見えない失敗」を紐解いていきます。 見えない失敗には共通点がある いくつものプロジェクトマネージャーに聞いた話を要約すると3つに集約されました。多くの方は以下の共通点は失敗と感じないかもしれませんが、経営層の目線で考えると「失敗」と見られる可能性があります。 【失敗の共通点】 コミュニケーションコストの増加 アジャイル開発には、柔軟に顧客の要望をキャッチアップできる為、ビジネスチャンスを逃さずにリリースできるメリットがあると思います。しかし、柔軟に変化を受け入れる一方で、「柔軟」な対応に対するコストがコミュニケーションに偏るケースがあります。特に、「ステークホルダーとの合意形成」、「情報共有に関する打合せ時間の増加」が障害となります。 また、最近はリモートによる業務も増加していることから、コミュニケーションツールによる不特定多数の方から発信される情報のキャッチアップも必要となります。そのため、本来行うべき開発業務が別の作業にリソースを割いている結果となっています。 リリース日程を決めずに開発を進めがち（着手スピードのみが意識される） 「より良いサービスを他社よりも早く提供したい！」と考えている企業様は少なくありません。経営層からも「早くリリースするように！」との台詞もプロジェクトマネージャーの皆さまなら一度は耳にしたのではないでしょうか。しかし、現場では「早くリリースせよ！　＝　まずは着手だけは早くして安心させよう」との気持ちが先行してしまいます。「XX月~XX月」、「XX月中」などのキーワードが並び、プロダクトバックログに期日間際のギリギリまで放置されているケースがよくあります。 放置した結果、期日間際の作業の為、手戻り作業が多発する　といった現場の声もよく聞きます。このような事象が「暗黙の了解」であると、現場で気づくのは至難の業です。 スピード感と情報量のバランスが悪い 当社にご相談いただく際に「スピード優先でやっています」とのお話をよく伺いますが、実はリリースが遅れがちといった現場を目にします。実は「実装すべき内容は決まっているんだけど…」という場合が大半です。しかし実情はチャットなどに情報が羅列されており、情報の交通整理といった見えない作業が必要です。情報量がスピード感を阻害しているのです。 プロジェクトマネージャーの皆さまは扱うドキュメントやツールがワードやエクセルから、スプレッドシートやチャットに置き換わった頃から薄々気づいていらっしゃるかと思いますが、要は情報整理の方法という作業工程に表れない「見えない要素」が「キモ」となります。このような「暗黙の了解」「見えない要素」の解説をさせて頂きましたが、少しご自身の現場に目を向けてみましょう。 まずは現場の分析からはじめよう 「日々の作業に追われて、分析と言われても…」となりますよね。そんな皆様に朗報です。分析のポイントをまとめてみました。 　情報量がコミュニケーションツールに集約されていないか？ ⇒情報量が適切な場所で管理されていることを確認するようにしましょう。 権限が特定の方に集中していないか？ ⇒チームリーダーだけ打合せ 量 が異常に多い など 「何かを解決する」といったゴールがない会議は一週間に何時間あるのか？ ⇒「ゴールがある会議＝何かを生み出せる」を前提としてみましょう。相談事項なども時間計算してみると、新しい発見があるかもしれません。 1つの合意形成を取るまでの時間はどの程度か？ ⇒情報共有を一元管理できており、誰でも検索すれば見つけられる状態であるか？ いかがでしょうか。色々と思い当たることはありませんか？ アジャイル開発の失敗を減らす3つの方法 合意形成と情報共有の時間を削減 「打合せ＝合意形成」の必要性の比重を重きに置く組織は多くあります。「合意形成の場を減らす」または「責任者に権限を委譲させる」などを行い、自走できる組織づくりをしましょう。 リリース日程が決まっていないものは「実装優先度」を低く位置付ける 「リリース日程が決まっている＝市場が期待している」ケースはよくあります。リリース日程が決まっている機能などは、ビジネスチャンスを逃さずに実装を優先させ、売上に寄与することができます。 スピード感と情報量のリバランスを行う 開発のスピードアップも取捨選択して、「スピード感を持って対応すべき実装」と「スピード感が不要な実装」を明確に分けるようにルール化しましょう。また、「スピード感を持って対応すべき実装」に対して、情報元を集約するなどを工夫してみてください。 まとめ 「アジャイル開発の失敗は「見えない失敗」にあり！」と題して、ご紹介してきました。 特にアジャイル開発ですと、コミュニケーションコスト、目的の情報を探すコストが非常に掛かります。当社の支援実績がある企業様を比較してみると、コミュニケーションコストが少ない企業と多い企業との差はおおよそ3～4倍となります。意外と無視できないコストであることが分かると思います。見えないコストの多くは、コミュニケーションなり組織文化に基づくものが占めており、改善が容易ではありません。「客観的に見ないと気付かない」ため、直近で中途採用された人材などにヒアリングしてみると気付かされる点があるかもしれません。 一度、ご自身の現場を振り返って、アジャイル開発について見直すきっかけにされてはどうでしょうか？ 当サイトでは、テスト技法を学びたい方、アジャイル開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post アジャイル開発の失敗は「見えない失敗」にあり！ first appeared on VALTES テストサービス .

ソフトウェアテストの技法にもさまざまな種類があります。そのうちの１つの「ユースケーステスト」。どのような場面で活用できるテストなのでしょうか？本記事では ユースケーステストの特徴から、ユースケーステストを設計する際のポイント・注意点を解説 します。 また、ユースケーステストと似たテストとして「シナリオテスト」を耳にしたことがある人も多いのではないでしょうか。はたしてユースケーステストとシナリオテストは同義なのでしょうか？ ユースケーステストとシナリオテストの違いについても私自身の経験を交え、解説 します。 本記事が効果的なテスト設計/実行の参考になれば幸いです。 ユースケーステストとは？ 「ユースケーステスト」とは、「ユースケース」をベースとした、ブラックボックステスト技法の１つです。ブラックボックステストとは、テスト対象のシステムの内部構造やプログラミングコードは考慮せず、テスト対象に何かしらの入力操作を行います。そして入力に対する出力（振る舞い）が仕様通りかを確認するテストです。では、テストのベースとなる「ユースケース」とはなんでしょうか？「ユースケース」を簡単に表すと「アクターと各システム間のやり取りを定義したもの」です。 ユースケースはシステムの機能要件を基に、アクターの操作・動きに対して各システムがどのような振る舞いをするかを整理し作成します。アクターとは、テスト対象のシステムを実際に使用するユーザーや外部のハードウェアなど多岐に渡ります。関係アクターやシステムが多いシステムのテスト（＝総合テストなどテスト工程の中でも後半のテスト）に活用したり、テスト前の仕様整理に活用したりすることができます。（私自身実際にテスト対象の仕様把握のため、簡単なユースケースを作成する場合があります。） ちなみに単体テストレベルではシステム間の連携についてテストしないため、ユースケーステストを活用することは少ないと思います。 ユースケーステストはユースケースを整理し終えた後、各ユースケースを実行する具体の操作手順を作成し、テストケースに落とし込むという流れで設計 します。 ユースケーステストとシナリオテスト、なにが違うの？ ユースケーステストと同義で扱われやすいシナリオテストですが、両者に違いはあるのでしょうか。ソフトウェアテストのテスト技術者資格制度であるISTQBの用語集では、ユースケーステストの同義語として「シナリオテスト」「ユーザシナリオテスト」が登場します。このため一般的にも同義で扱われることが多いようです。筆者の経験から、ユースケーステストとシナリオテストの違いを区別すると以下の特徴があると考えます。 【ユースケーステストとシナリオテストの違い】 ユースケーステスト ：システムの機能要件から整理したユースケースをベースとするテスト。 シナリオテスト ：ユーザー目線で洗い出した一連の操作シナリオをベースとするテスト。 前述の通りユースケースはシステムの機能要件から整理します。しかし、シナリオテストはユースケースだけでなくユーザー目線で考えうる一連の操作シナリオを洗い出し、洗い出したシナリオを基にテストケースを設計していくテストです。つまりシステムの機能要件に含まれていない操作を行うシナリオも、テストのベースとなりえます。ユースケーステストよりもシナリオテストのほうが、幅が広いイメージです。 また混同されやすい背景としては、シナリオテストにユースケーステストが内包されている場合があります。またユースケーステストがシナリオテストと似た形式のテストケースになりやすいという特性がある点が考えられます。 【実践編】 ユースケースを整理してみよう ここからは実践編として、ユースケースの整理方法をご紹介します。ご紹介する方法はユースケース一覧です。以下の表のように１ユースケース毎に整理します。 ID・ユースケース名 001　会員登録する 目的 会員登録画面で情報入力し、会員登録を完了させたい アクター ユーザー 事前条件 会員登録に使用するメールアドレスが未登録であること 事後条件 入力した情報で会員登録が完了すること 基本フロー 必須項目：登録ユーザー名を入力する 必須項目：住所を入力する 必須項目：電話番号を入力する 任意項目：性別を選択する 必須項目：メールアドレスを入力する 会員登録ボタンを押下する 会員登録完了画面へ遷移する 代替フロー ■任意項目：性別を未選択 4．必須項目：メールアドレスを入力する 5．会員登録ボタンを押下する 6．会員登録完了画面へ遷移する 例外フロー ■必須項目（メールアドレス）未入力のまま会員登録ボタンを押下 5．会員登録ボタンを押下する 6．「必須項目が未入力です」というエラー文言を会員登録ボタン下部に表示する 補足 ・登録済みのメールアドレスでは再登録できない ・電話番号は半角、電話番号以外の入力欄は全角でしか入力できない ▼ID・ユースケース名 ユースケースの内容が分かるよう、簡潔に記載します。 他ユースケースと区別できるようIDも付与すると良いです。 ▼目的 ユースケースで達成すべき目的を記載します。 この目的を基に後述のフローを整理していきます。 ▼アクター ユースケースを実行するアクターを記載します。ユーザー＝人の場合もあれば、システム名が入る場合もあります。 ▼事前条件 ユースケースを実行するために必要な事前条件を記載します。 ▼事後条件 ユースケース実行後に満たされる条件を記載します。 ▼基本フロー ユースケースの目的を達成するための基本的なフローを記載します。 各ステップに分岐が発生するかもしれませんが、後述の代替フローで整理するため、ここでは基本的なフローに限り記載します。 ▼代替フロー ユースケースの目的を達成できる、基本フロー以外のフローを記載します。 例では任意項目の入力なしで後続操作を進めるフローを代替フローとしています。 ▼例外フロー ユースケースの目的が達成できない、例外的なフローを記載します。 例では必須項目を入力しなかったために後続の会員登録ができない、というフローを記載しています。 ▼補足 補足事項を記載します。 例ではユースケースにかかわるその他の仕様を記載しています。 ◆整理のポイント システム要件に定義されている基本的なフローから整理すること 整理しながら代替フロー、例外フローが先に思い浮かんでしまうかもしれません。しかし抜け漏れ/手戻りが発生しないよう、まずは基本的なフローの整理から行いましょう。 必要な項目は任意で追加 上記の整理フォーマットはあくまでフォーマットです。テスト対象のシステムに合わせて必要項目は追加してください。上記の例では、ユーザーがユースケース毎に特定の1画面を操作します。以下のような欄を追加すれば、操作対象の画面をユースケース毎に整理することができます。 操作画面 会員登録画面 ユースケーステスト以外のテストを行う場合でも、この一覧はテスト対象の分析/仕様把握に役立つかと思います。ぜひ活用してみてください。 まとめ 「ユースケーステスト設計のポイント！シナリオテストとの違いは？」と題して解説してきました。 【本記事の総括】 　 システムの機能要件から整理したユースケースをベースとするテスト 　 シナリオテストはユースケースよりも幅広いシナリオをベースとするテスト 　 ユースケースの整理にはユースケース一覧を活用 　 ユースケーステストの設計/実行だけでなく、テスト対象の仕様把握にユースケース一覧が役立つ 　上記のポイントを基に、効果的なテスト設計/実行につなげてください。 　参照元URL ISTQB Glossary https://glossary.istqb.org/jp/search JSTQB-SyllabusFoundation_Version2018.J03 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post ユースケーステスト設計のポイント！シナリオテストとの違いは？ first appeared on VALTES テストサービス .

関係者間の合意形成が難航して、仕様を確定できない。変更点がドキュメントに反映されず、手戻りが生じた。頼りになるメンバーが、プロジェクトを離脱してしまった。実行環境の構築が遅れ、テストに着手できない。それなのに、サービス提供は遅らせられない…。システム開発プロジェクトには、スケジュールに影響する様々なリスク要因が存在します。 その終盤、リリースを目前に控えたテスト工程で、さらなる進捗遅延は許されません。だからといって、工程を短縮するためにテストケースを削減した結果、不具合を見逃してしまったら？テストの意味がありませんよね。このようなジレンマの中で、スケジュールを守りながら高品質なソフトウェアを開発するためにテストエンジニアは、様々なテスト技法を活用して効率的な検証を行っています。 そこで本記事では、 ソフトウェアテストの国際規格「ISO/IEC/IEEE 29119」の分類に基づき効率のよいテストに欠かせない、３種類のテスト技法をご紹介 します。 内部構造を検証する「構造ベースのテスト技法」：ホワイトボックステスト 別名「ホワイトボックステスト」とも呼ばれるこの技法は、テスト対象の内部構造と処理内容に焦点を当てる技法 です。「作った通りに動作しているかどうか」を確認する、開発者視点のテストと言えるでしょう。「カバレッジ（網羅率）」と呼ばれる指標を用いて、ソースコードのどの部分をテストしたのかを、定量的に表現できるメリットがあります。 代表的なホワイトボックステストである「制御フローテスト（制御パステスト）」では、ソフトウェアモジュールの構成要素（命令文、分岐構造、条件）に着目してカバレッジを計測します。デメリットは、100%に近い高カバレッジを達成しようとすればするほど、工数が増加してしまう点です。対策として、テスト対象の特徴やプロジェクトの状況に応じて、適切なカバレッジ基準を定めることが重要です。 また、仕様の解釈誤りやコーディングミスに起因する不具合の発見には、あまり適していません。したがって、期待結果を設定する際は内部構造だけではなく、きちんと最新の仕様にも準拠する必要があります。単体テストでの適用が一般的ですが、「内部構造を理解したうえで検証する」という意味で、モジュール間の結合テストでも使える技法です。 要求に応えられているかをチェックする「仕様ベースのテスト技法」：ブラックボックステスト 一般的には「ブラックボックステスト」と呼ばれます。その名前の通り、 内部構造を参照できないブラックボックスとみなして外から見たテスト対象のふるまいが、仕様に沿っているかどうかを重視するテスト技法 です。具体的には、テスト対象への入力と、入力に対する出力を検証します。「使いたいように使えるかどうか」に着目する、ユーザー視点のテストといえます。テスト設計の際にはデシジョンテーブルや状態遷移図、状態遷移表などを用いて、様々な角度からテスト対象を分析します。 その過程で、仕様の妥当性や考慮不足がないかを整理できる点がメリットです。加えて、実装時の解釈誤りやコーディングミスの検出も期待できます。一方、要件や仕様が明確になっていないケースでは有効な検証ができません。さらに、開発ドキュメントに反映されていない実装によって、引き起こされる不具合の発見も困難です。よって、最新の仕様に基づいたテスト設計が重要なポイントになります。他にも、チェックすべき入力データや出力、条件のパターンが膨大になりがちです。 同値分割や境界値分析、デシジョンテーブルの簡略化などのテクニックを用いて、いかに効率的に試験項目を圧縮できるかが、テストエンジニアの腕の見せどころといえます。アルゴリズムを用いて、自動的に組み合わせパターンを絞り込んでくれるツールも提供されています。その特徴から、単体テストから総合テスト、ユーザー受け入れテストまで幅広い工程で用いられます。また、機能テストに限らず非機能テストにも適用できる技法です。 スキルと直感がものをいう「経験ベースのテスト技法」：探索的テスト（アドホックテスト） 経験ベースのテスト技法では、担当者の経験を活用しながら、テスト対象の学習とテスト設計・実行を並行して進めます。そのため、 事前のテスト設計はそれほど重視されないケース が多いです。 不具合が潜む箇所を探るように試験を進める様子から、「探索的テスト（アドホックテスト）」とも言われます。 担当者の経験によって、開発者視点とユーザー視点どちらの検証も可能です。 経験ベースのテストの最大のメリットは、効率よく不具合を発見でき、スケジュールを圧迫しない点です。特に、過去のプロジェクトで蓄積された不具合情報を用いて、精度の高いエラー推測が可能な場合があります。またスキルと経験、業務知識が豊富なテストエンジニアの支援が得られるケースでは、テスト工数を削減する有効な選択肢になりえます。加えて、仕様確定が不十分な状況でも検証を進められます。 反面デメリットとして、担当者の経験やスキルに依存するので、期待したような効果が上がらないおそれがあります。また、テスト実行を優先する目的で、テストケースやドキュメントの作成が省略・簡素化されがちなので、ナレッジが属人化しやすい点にも注意が必要です。 経験ベースのテストだけでは、抜け漏れなく網羅的な検証を行うのは難しいことから他のテスト技法と組み合わせた補完的な適用がおすすめ です。 まとめ ここまで、ISO/IEC/IEEE29119の分類による３種類のテスト技法をご紹介してきました。それぞれの特徴や、活用シーンがイメージできたでしょうか？ メリット・デメリットを表にまとめると、次のようになります。 技法 特徴 メリット デメリット 構造ベースのテスト技法 （ホワイトボックステスト） 内部構造を検証 カバレッジを用いて、品質を定量的に評価できる ・カバレッジを達成するための工数が増加 ・仕様の解釈誤りから起きる不具合は発見できない 仕様ベースのテスト技法 （ブラックボックステスト） 入力に対する 出力の妥当性をチェック ・仕様の解釈誤りを発見できる ・幅広いテスト工程に適用できる ・非機能テストにも使える ・要件や仕様が明確でないとテストできない ・入力パターンが膨大になりがち   経験ベースのテスト技法 （探索的テスト・アドホックテスト） テストの設計・実行に経験を活用 ・テスト設計と実行を並行するため効率がよい ・仕様が不十分でもテスト可能 ・テスト担当者のスキル・経験に依存する ・ドキュメントが残されない場合が多い   参考 Foundation Level シラバス Version 2018V3.1.J03 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf 【この１冊でよくわかる】ソフトウェアテストの教科書【増補改訂第２版】 ISO/IEC/IEEE 29119　ソフトウェアテスト規格の教科書 単独のテスト技法のみで品質を担保するのは非常に困難です。そこで、 システム開発プロジェクトの状況に応じてテスト技法それぞれの特徴を理解し、適切に組み合わせた検証が大切 です。本記事がそのヒントになれば幸いです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト技法にはどんな種類があるの？メリット・デメリットをご紹介 first appeared on VALTES テストサービス .

大規模なシステム更改や、既存システムへの機能追加時など、システム開発を行った際にUAT（ユーザー受け入れテスト）の実施は必要不可欠なものです。しかし、「UATを実施することになったが、何をどうすれば良いのだろうか？」そんな悩み・疑問をお持ちの方も多いのではないでしょうか。 「そもそもUATって何をするの？」「テストは本業ではないし良く分からない」「どうすればUATを成功できるのだろうか」という疑問にお答えし、UAT成功のポイントについてユーザー部門の皆さまに向けて解説 します。 UAT （ユーザー受け入れテスト）とは？ UATについて理解するにあたり、まず受け入れテストから説明します。日本におけるソフトウェアテスト技術者資格認定の運営組織であるJSTQBでは、受け入れテストは以下のとおり定義されています。 「システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト」 ちょっと難しい表現で、特にユーザー部門の皆さまにとっては、分かりにくいですね。分かりやすく言い換えますと、 「要望したものが、そのとおりに出来上がっているかを確認するテスト」 と言うことができます。 システム開発を、住宅の建築に置き換えて説明してみます。皆さまが様々な要望を出して新しく家を建てたとした場合、晴れて我が家が出来上がった後、実際の建物を現場で確認することなく入居するでしょうか？外観は要望した通りに出来上がっているか、間取りは要望通りになっているか、窓は注文したものが付いているか、などおそらく確認されるのではないかと思います。システム開発もこれと同様で、自分たちが要望したものがその通りに出来上がっているかを確認することが必要です。 これが受け入れテストで、システム開発の中でも最後に行われることが多い工程です。さて、UATですが、「受け入れテスト」の前に「ユーザー」と付いているところがポイントです。受け入れテストには、誰が受け入れの確認をするのかによって、大きく３つの観点があります。 【ユーザー受け入れテストの観点】 システムの観点 システムの品質に問題がないか、システム要件に沿って確認する 運用の観点 システム運用部門が、出来上がったシステムを自分たちで運用できるか確認する ユーザーの観点 要望を出したユーザーが、要望通りのシステムが出来上がっているか確認する この中で、最後のユーザーの観点で実施する受け入れテストが、UAT（ユーザー受け入れテスト）です。システム開発においては、そのきっかけとなる誰かの要望事項があります。皆さまのユーザー部門においても、こんなケースはないでしょうか？ 新サービスを提供するために新たなシステムを作りたい 収益改善のために、この機能を追加したい お客さまからの苦情が多いので、この画面の使い勝手を改善したい このように、自分たちが実現したい要望を出して、システム開発を依頼していると思います。その結果出来上がったシステムは、自分たちの目線で確認して、その仕上がりで良いか確認をしなければなりませんよね。UATは、ユーザーの立場で、自分たちの日ごろの業務の流れやお客様の立場に立った操作に沿って、システムの仕上がりを確認します。「テスト」というと、スキルを持ったエンジニアがバグを見つけ出すものという印象が強いかもしれませんが、 UATは「ユーザー部門が主役である」というところがポイント です。 ユーザー部門は、テストに慣れていないという現実 「ユーザー部門が主役である」と書きましたが、実際に推進・実施される皆さまにとっては、UATに関わる機会はそう頻繁にあるものではないと思います。 【UATに関わらない理由】 社内のユーザー部門の大半が関わるような大規模なシステム更改は、7～8年に一度というようなサイクルでしかやってこない 毎年行われるような追加開発では、自部署に関係する案件がほとんどない、または担当として係わっていない などの理由で、UAT自体に馴染みがないというユーザー部門の方も多いのではないでしょうか。そのため、 UATを進めていくにあたって、「そもそもテスト自体に慣れていない」という現実が立ちはだかります。 実際にUATを進めていくためには、どんな作業が必要なのでしょうか。主に、以下のような5つの作業が挙げられます。 【UATを進めていくための作業】 テスト計画の作成 テストを実施する期間、スケジュールを決定する テストの開始・終了基準を設定する 問題発生時等の起票ルールや、連絡ルートを整理する テストシナリオの作成 UATで確認する事項を整理する 確認する順番について、業務フローをもとにして整理する テストケースの作成 テストシナリオをもとに、個々の画面で実行する手順を整理する 各手順を実施した結果、どのような結果を期待するのか（期待結果）を整理する テストの実施 操作した結果が期待通りであったか、期待と異なるかを確認する。 期待と異なる結果が出た場合は、操作手順や発生した状況をまとめて、開発担当者へ連携する。 日々の実施件数を集計して、進捗を管理する。 テスト結果報告書の作成 実施した実績（実施件数、OK件数、NG件数など）を定量的に記載する 発生した不具合事象について、定性的な評価を記載する 総合的に判断して、要望通りに出来上がっているか、UATをOKとして良いか判断する このような一連の作業を、日ごろテストに慣れていないユーザー部門の皆さまが主体的に進め、かつ成功に導くことは可能なのでしょうか？ UATを成功に導くための大事なポイント 「餅は餅屋」という言葉があります。物事はその道の専門家に任せるのが一番良いというたとえですが、UATにおいても同様のことが言えます。すなわち、ユーザー部門の皆さまは、日ごろの自分たちの業務に沿ってシステム動作の確認に専念することが、UAT成功のための大事なポイントです。 テストに慣れていないユーザー部門の皆さまが、UATで必要となる一連の作業すべてを行おうとするよりも、任せるところは専門家に任せるという考え方 です。 具体的には、ユーザー部門とシステム部門の協力が必要不可欠です。例えば、テスト計画の立案や各種書式の準備、システムの詳細な動作確認は、システム部門側で主体となって行うよう役割分担を整理します。また、複数のユーザー部署が関わるような大規模なシステム開発の場合はよくあります。その場合はUATの進捗や結果報告を部署横断で取りまとめた上で、システム部門へ連携する作業が多く発生します。 システム部門からユーザー部門に、テスト管理スキルを持った要員を提供し、ユーザー部門側にUATの推進を担う組織を一時的に組成することも、一つの案です。もう一点、「日ごろの自分たちの業務に沿ってシステムの動作を確認する」ためには、どのようにすれば良いでしょうか。これも、テストに慣れていないユーザー部門の皆さまにとっては、あまり馴染みがないと思います。ここでポイントとなるのは、要望を出したユーザー部門として、「何ができればOKか」という考え方です。具体的には、出来上がったシステムにおいて Must＝できなければいけないこと Never＝あってはならないこと の観点で確認する内容を抽出します。 銀行ATMに挿入された通帳に対して、明細を印字する場合を例に挙げてみましょう。 Must ：これまでに印字されている次の行から明細を印字する、ページの最終行まで印字したら改ページする Never ：印字済みの行に二重に印字してしまう、ページの最終行まで印字しても改ページしない というような観点を挙げることができます。このように、MustとNeverを併せて考えることで、UATで確認する内容を抜け漏れなく洗い出せます。 まとめ 「UAT（ユーザー受け入れテスト）成功のポイント　ユーザー部門のあなたへ」と題して、説明してまいりましたが、いかがでしたでしょうか。 UATを成功に導くためには、ユーザー部門の皆さまが主役となり、自分たちの得意分野に注力して作業を行える状況を作ることが重要です。 ユーザー部門とシステム部門の協力体制を構築し、得意分野ではMustとNeverの考え方で抜け漏れなく確認を行い、UATを成功に導きましょう。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post UAT（ユーザー受け入れテスト）成功のポイント　ユーザー部門のあなたへ first appeared on VALTES テストサービス .