ソフトウェアを開発するとき、プロジェクトマネージャー（PM）は決められた「納期」、「コスト」の中で、できる限り「品質」を高めようとします。モノづくりでは、開発工程が花形とされ、フォーカスされがちですが、品質を高めるときにテスト工程は欠かせません。ソフトウェアテストのフローや技法について知見のある方も徐々に増えてきましたが、それでも品質が上がらない・・・というご相談は多くあります。 「テストが重要なことは知っている」「テストの技法は知っている」という方に、もう一押しのソフトウェアテスト工程のポイントを解説 していきます。 ソフトウェアテストはなぜ必要なのか 現代ではソフトウェアに触れずに生活するのは難しいほど、数多くのソフトウェアが存在しています。ソフトウェアテストは、利用者が安全・快適にソフトウェアを利用できるように、必ず行わなければなりません。それは、新規開発、機能拡張などの派生開発、バグ改修、最近ではレガシーシステムからのマイグレーションなど、どのような開発でも同じです。しかし、顧客ニーズの変化は早く、ソフトウェアは複雑化し、リリースまでのスピード感も求められるようになりました。 ソフトウェアの開発において、納期短縮を図る際、まず頭に浮かぶのはテスト工程の削減という方も多いと思います。では、決められた「納期」と「コスト」を守れば、顧客は満足してくれるでしょうか。おそらく「品質」が悪ければ、クレームになるでしょう。バグが多ければ、BtoBの場合は信用低下や契約解除、BtoCの場合は顧客離れに繋がります。例えば、定額制のアプリケーションを新しく追加して、「画面が固まる」「起動しない」「アプリケーションが落ちる」といった現象が頻繁に発生していたら、次回契約更新時に継続するでしょうか？ 特別な理由がない限り、契約終了となるはずです。 一度離れた顧客に再契約・再利用してもらうのは、新規顧客の開拓をするよりも難しく、労力がかかります。 そのため、BtoB、BtoCに関わらず、どのような開発でもソフトウェアテストは必要なのです。 テスト工程が軽視されがちな理由 テスト工程というと「新人がやるものだ」「下請け会社にやらせればいい」と、開発工程に比べて軽視されることも多い のではないでしょうか。新人の方がテスト工程を担当する場合、ほとんどが「上流工程のドキュメントに書いてあることが満たされているか」を確認するためのテストを行い、完了としているのではないかと思います。これは一例ですが、異常系（イレギュラーな動作）まで全て網羅されているようなドキュメントを作成するのは現実的ではなく、ドキュメントベースのテストでは異常系のテストが不十分になりがちです。 しかし、異常系のテストで見つかるバグは多いのです。 異常系のテスト観点を持っている新人さんはなかなかいないので、テストでバグが検出できず、市場に流出、その後、改修対応に追われ、次期開発のスケジュールが遅れます。このような「テストの悪循環」に陥ってしまうと抜け出すのは大変です。 そもそも開発者は、開発が好きだから開発をしている はずです。品質の高い開発をすることは意識できても、「品質を高めるテスト」はやりたくない人がほとんどでしょう。これをネガティブに考えれば「開発者はテスト工程を軽視している」となりますが、「開発工程を重視している」というポジティブな見方もできるのではないでしょうか。 そこで、より品質の高い開発をするのに必要になってくるのが、テストエンジニアという職種です。テストエンジニアを主体とするテストチームを作る企業も増えてきましたが、開発者とテストエンジニアではそもそもの考え方が違うのです。（もちろん、テストが重要だと考えている開発者の方も多数いますが、そういった考えからテストエンジニアに転向する方も少なくありません。）開発工程で品質を上げたい開発者、テスト工程で品質を上げたいテストエンジニア、上手く協力ができたら良い開発ができると思いませんか？ 「誰が」テストするかでプロジェクトの成否が分かれる テストの担当者はある程度の独立性を確立すると、より効果的にバグを発見できるとされています。テストにおける独立性の度合いを以下に示す（独立性の低いレベルから高いレベルの順に列挙）。 独立したテスト担当者不在（開発担当者が自分のコードをテストするのみである）。 開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者（開発担当者が同僚の成果物をテストすることもある）。 組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織。 顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある特定のテストタイプを専門に行う独立したテスト担当者。 組織外の独立したテスト担当者。オンサイト（インハウス）またはオフサイト（アウトソーシング）で作業する。 ※「テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03」より一部抜粋 開発の担当者が自分でテストをしようとすると、思い込みからテストの抜け漏れが発生してしまうこともあります。そこで、テストの担当者をできるだけ独立させ、開発者とは異なる技術的視点を持つことで、開発者が行うテストで検出するバグとは異なるバグを検出できる可能性が上がります。また、開発の担当者とテストの担当者を分けることは、開発スピードの向上にも効果があります。 特にフェーズを区切った派生開発や、バグ改修など、開発とテストが並行で進行する場合、それぞれの担当者が作業を進められるので開発スピードが格段に上がります。もし、開発の担当者がテストまでしていたら、テストが終わるまで次の開発に移れません。また、前述した通り、 開発者はテストが好きではないのです。納期に追われているテストが嫌いな開発の担当者がテストまで担当していたとしたら…バグに気付かず開発が進んでしまいそうですよね。 意外かもしれませんが、 ソフトウェアテストは、技法やプロセスだけではなく、テストを行う体制も重要 なのです。あなたが関わる開発プロジェクトのテスト体制はどの程度独立しているでしょうか？レベルをひとつ上げるだけでも、品質向上に繋がるかもしれません。 まとめ 「マイグレーションとは？リホスト、リライト、リビルドの違いと手法が一挙にわかる！」と題しまして、ご説明してまいりました。 それぞれの手法の違いと併せて、マイグレーションプロジェクトの難しさと、そのポイントも併せてお伝えできたかと思います。 バルテスでは「マイグレーション品質向上支援サービス」をご提供しています。難度の高いレガシーシステムのマイグレーションプロジェクトに対し、仕組み化された テストサービス による品質向上を実現します。システムマイニングツールを活用し、現行システムフローを可視化し、マイグレーションを進めていきます。また、マイグレーション経験者を中心とした品質管理支援担当者（QMO）がプロジェクトに入り、品質活動を強力に推進いたします。詳しくは「マイグレーション品質向上支援サービス」や下記資料をご覧ください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post ソフトウェアテストが重視される理由と成功のポイント first appeared on VALTES テストサービス .

皆さんが書いているテスト報告書に顧客は満足していますでしょうか？テスト報告書をこれから書く皆様にぜひ知って頂きたいポイントをご紹介いたします。報告書を受け取る側の思いにも触れた、 テスト報告書をこれからのプロジェクトに活かすテンプレートについて解説していきます。 何かのヒントを得て頂ければと思います。 テスト報告書のサンプル・テンプレートをご紹介 一言で『 テスト報告書 』と言っても、各企業、各案件、各業種により、色々な種類/特色があるかと思います。 今回はあくまで テストでの実施結果に主眼を置いて記載した「〇〇テスト仕様書兼結果報告書」と対象のテスト工程全体に対し、不具合分析や提案推奨事項を記載した「サマリレポート」の2種のテンプレート について、説明していきます。 ① 〇〇テスト仕様書兼結果報告書について 【サンプル】〇〇テスト仕様書兼結果報告書 〇〇テストの仕様書と実施結果が合わさった形のフォーマットになります。※テスト結果報告書の位置づけになりますが、このフォーマットはあくまで実施結果LOGとしての位置づけとなります。 テスト観点：ソフトウェアが正しく動作するかを確認するための着眼点(切り口)を記載 前提条件：テスト実施する前提条件を記載 実行手順：テスト実施する詳細な手順を記載 入力値：テスト実施する際の入力する値(パラメータ)を記載 期待値：テスト実施した結果で想定される期待値を記載 実行日(再実行日)：テスト実施(再実施)した実行日を記載 実行者(再実行者)：テスト実施(再実施)した実行者を記載 結果判定：テスト実施した結果と期待値を比較しての結果判定を記載 不具合管理No.：不具合起票チケットNoや不具合管理Noを記載 ② サマリレポートについて 【サンプル】サマリレポート　※目次ベースになります。 「〇〇テスト仕様書兼結果報告書」の実施結果の集計、分析並びに、対象のテスト工程全体に対してのレポートです。テストの期間、各ステータスの件数や、発生インシデントおよびその状況からの分析に加え、テストの中で抽出した次開発における推奨、提案事項を記載します。 1. 概要                    1.1 ご依頼内容の要約     1.2 テスト結果の全体像 　1.2.1 実施したテストの内容 　1.2.2 テスト期間、スケジュール 　1.2.3 テスト項目数と結果 　1.2.4 インシデント件数 　1.2.5 テスト完了判断の結果 　1.2.6 納品物 一覧 2．詳細報告・分析結果 　2.1 テスト実施状況         　　2.1.1 テスト実施・インシデント検出の推移（PB曲線） 　　2.1.2 テスト項目消化状況 詳細 　2.2 インシデント状況 　　2.2.1 機能別インシデント状況 　　2.2.2 ステータス別インシデント状況 3．全体総括、ご提案・推奨事項 　3.1 全体総括 　　3.1.1 テストの進捗 　　3.1.2 テストの結果 3.2 提案・推奨事項         　　3.2.1 提案事項 　　3.2.2 推奨事項 テスト報告書で失敗するテンプレートと成功するテンプレートの違い これまでに説明させて頂いた2種のテスト報告を見て頂くと、違いを感じる方がいるでしょう。どちらのテンプレートの方が 「 テスト報告書をこれからのプロジェクトに活かすテンプレート」だと思いますか？どちらを見たいと思いますか？ ※もちろん、報告書を受け取る役割や立ち位置によっては①を貰った上で、②はご自身で作成するので、①で十分と言う方もいらっしゃるかと思います。そういった方は、下記はご自身が作成時の参考として見て頂ければと思います。下記にテスト報告書で失敗するテンプレートと成功するテンプレートの違いについて、述べたいと思います。 『失敗するテンプレート』⇒　①〇〇テスト仕様書兼結果報告書 　・テスト実施結果のみしか記載がないため、それ以上の情報は読み取るのに時間を要する。 　・サマライズされているわけではないため、全体完了しているのか、 残項目がどの程度あるのか、読み取るのが難しい。 　・課題があるのか、順調に完了したのか、次案件で何を改善すれば良いかが見えない。 　・スケジュールの遅延等、課題も把握が難しい。 　・不具合の傾向が見えず、次Phaseへの移行有無も把握が難しい。 『成功するテンプレート』⇒　②サマリレポート 　・予実記載があるため、PJで何が発生し、どんな課題があったのかが理解、把握が可能。 　・分析結果から、次PJに活かすための改善施策を検討可能。 　・経営層への報告資料としても流用が可能。 テンプレートはあくまでテンプレート、そこに案件特性や状況に応じて、必要な項目を追加します。もしくは不用項目を削減し適切な報告書に仕上げて頂ければと思います。 テスト報告書をこれからのプロジェクトに活かす3つのポイント ではテスト報告書をこれからのプロジェクトに活かすためには、どのようにすればいいのでしょうか？3つのポイントでまとめてみます。 １．提案・推奨事項の内容をPJメンバー全員で確認し、抜け漏れや追加事項がないかを確認する。 　⇒品質改善は一部メンバーだけでは達成できないため、全員参加が必須です。 (状況により、経営層を含めた認識合わせも重要な要素となります) ２．提案・推奨事項においても、優先度をつけた上で、手間が多くかかる項目よりも、 　　取り掛かりやすく、効果の高いものから優先的に対応する。 　⇒手間がかかるものからの着手の場合、途中で施策が断念してしまう可能性があり、 　　まずは小さい所から成功体験を積み重ねることが重要です。 ３．テスト報告書の中で、次プロジェクトで対応する提案・推奨事項の詳細化と 担当部署、担当者を明確にし、次案件スタート時の計画に盛り込む。 　⇒次案件への導入を早期に実現し、PDCAが回る体制構築検討も重要です。 まとめ 「テスト報告書をこれからのプロジェクトに活かすテンプレートとは？」と題しまして、ご説明してまいりました。IT業界はDX対応や企業のIT投資意欲の高まりのため、IT開発人材が不足気味です。 よって、どの企業も下流で人を入れて何とかすると言った過去のやり方では通用しなくなっています。つまり、 上流からの品質改善や案件内での課題の見える化や、早い段階でのリスクの洗い出しなどに、企業の多くは興味を持っているのです。 このような部分にダイレクトな効果を発揮するためにも、今回説明させて頂いたテスト報告書を活用してみませんか？そして、実績からの分析結果を踏まえ、上流からの品質改善を見据えたシステムづくりを目指してみてはいかがでしょうか？ 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト報告書をこれからのプロジェクトに活かすテンプレートとは？ first appeared on VALTES テストサービス .

デジタル化の加速に伴い、開発スピード向上を目指す中で、 アジャイル 型の開発手法を取り入れるプロジェクトは少なくありません。一方で基幹システムの見直し等を始めとした大規模プロジェクトにおいては、まだまだウォーターフォール型の開発が主流です。ここではウォーターフォール型開発の”下流工程”と呼ばれるテスト工程のご紹介と、各工程のエッセンスについて解説をしていきます。 テスト工程とは 一般的なウォーターフォールモデルのテスト工程の種類には、下記の４つがあります。 【テスト工程の種類　ウォーターフォールモデル】 ・単体テスト(ユニットテスト) ・結合テスト(インテグレーションテスト) ・総合テスト(システムテスト) ・ユーザー受け入れテスト(UAT) 一口にテストと言っても、それぞれの工程で行うべきテストの目的や内容は異なり、どの工程が欠落しても品質にとってよくありません。失敗や炎上を起こさないためには、すべてのテスト工程に細心の注意を払う必要があります。 単体テスト(コンポーネントテスト)とは 概要 ユニットテストやモジュールテストとも呼ばれます。プログラム内部をテストすることが一般的であり、操作画面(インターフェース)を介さない場合がほとんどです。このような背景から「ホワイトボックステスト」にてテストを実行するケースが多くなります。 主な担当 SE・PG(ソフトウェア開発者) 重要なポイント モジュール単位・コンポーネント単位でテストを実行するため、”原因の特定”や”修正”が容易になります。ソースコードと仕様・設計に乖離がないか、意図した通りに動作出来ているかなど判断も早くなるため、開発全体のバグ修正コストは低くなります。最近ではツールを活用した自動化によるテストも多く、開発者の負担を減らせるケースが増えてきました。 気を付けたいポイント 開発者自らテストを行うため、「問題ないだろう」という主観や作業負担から、テストが省略されてしまうことがあります。単体テストを充分に行わないまま次工程へ進めてしまうと、単体テストで見つけるべき不具合が残ったままとなり、次工程のテストを阻害や、修正コストが膨らむ恐れがあります。 結合テスト(インテグレーションテスト)とは 概要 単体テスト工程の次は結合テスト工程に進みます。モジュール間のインターフェース構造や結合部の動作について、正しく機能しているかテストします。一般的には基本設計工程で設計された範囲とし、サブシステム内の不具合がないことを確認します。このため、基本設計書をもとに「結合テスト仕様書」が作成される場合が多いです。外部システムと連携がある場合は「外部結合テスト」の実行を、結合テスト工程で行うこともあります。 主な担当 SE・PG、テストエンジニア(設計者・実行者) 重要なポイント 「実装された機能が、しっかりとデータの受け渡しを行えるか」という観点が大切になります。テストパターンを洗い出し、優先順位を決め、どのような手段でデータを流すのかを決めていきます。また、テストの範囲をどこまでとするかも、しっかりと決めておく必要があります。通常、結合テスト工程からはブラックボックステストとなり、第三者によるテストも有効に働きます。 気を付けたいポイント 単体テスト工程と総合テスト工程の間に位置するため、結合テストの粒度や量はプロジェクトによって大きく異なります。ゆえにテストパターンの抜け漏れが発生しやすく、逆に無駄なテストが発生しがちなのも、この工程の特徴です。テストの目的と範囲をしっかりと定義することはもちろん、テスト設計のプロセスにも特に気を配る必要があります。 総合テスト(システムテスト)とは 概要 結合テスト工程の次は総合テスト工程に進みます。システムテストとも呼ばれます。システム全体の機能・非機能要件が満たせているかをテストします。要件定義書や業務フローを元にしたシナリオテストや多端末テスト、外部システムとの連携テスト、パフォーマンスやセキュリティなどの非機能的なテストなど、あらゆる角度でテストを行います。実際のシステム利用を想定してテストを実行するため、通常は本番環境と同等の環境を用意して行います。 主な担当 テストエンジニア ※SE・PGが行うこともあります。 重要なポイント 総合テストは、クライアントによる受け入れ前の、いわば最終試験に位置します。システムそのものの有用性を確認する工程になりますので、広い範囲と高い抽象度から、具体的なテスト方法を考えていく必要があります。特に非機能要件は専門性も高まるため、総合テストは外部委託するケースも増えています。必要となる要員スキルも多様になり、環境、機材の準備も増えていくことから、入念な準備と計画が大切となります。 気を付けたいポイント 環境準備の不足、あるいは結合テスト以前の不具合が健在化することで、総合テストが進められないケースもあります。また、外部システム担当者や、専門的なテストチームの参入などにより、プロジェクトそのものが混乱してしまうことも少なくありません。重要なポイントでも記述していますが、しっかりとした準備と計画が必要です。 ユーザー受け入れテスト(UAT)とは 概要 開発チーム（SIerなど）からクライアント（発注者)にシステムを受け渡し、実際にシステムを利用するユーザー目線でテストを行います。UATや運用テストと呼ばれることもあります。システムが要求通りに利用できるかどうかの確認を、ユーザーの立場で行うという点が、他のテスト工程とは大きく異なるポイントです。業務利用のシステムであれば、実際にユーザー部門でメンバーを選出し、テストを行うこともあります。 主な担当 クライアントのシステム部門担当者 クライアントの業務部門担当者 テストエンジニア 重要なポイント テストの観点は要求を満たせているかどうかという、高い抽象度で置かれるため、テストの目的や受け入れ基準の設定はしっかりと行う必要があります。また、テストを進める上で発生する要求との乖離が、仕様上の不具合なのか、追加要求なのかという切り分けにも慎重を要します。普段、開発業務やテスト業務を行わない立場の人がテストを行うため、テストをしっかりと推進、コントロールすることも重要です。 気を付けたいポイント ユーザー受け入れテストは運用開始の直前で行われるため、摘出された不具合や問題点の改修は容易ではないこともあります。運用を始められるかどうかの最終判断を行う工程となりますので、重要なポイントでも記述した通り、受け入れ基準の明確化が大切です。また、基準を見極めるためのテスト方針や設計も重要になっていきます。 まとめ 「テスト工程とは？各工程の解説とポイントを整理します！」というタイトルでご説明してまいりましたが、いかがでしたか？　一概に「テスト」といっても、工程ごとのアプローチは様々であることをご理解いただけたかと思います。テスト工程では、それぞれテストの計画、観点、技術が異なってきます。ただし最も大切なのは、「全工程を通し、どのようにテストを積み立てていくか」だと思います。何を目的に、何に対して、どうやってテストをしていくかという全体像があり、そして工程という概念に繋がります。 当社バルテスでは年間2600プロジェクト以上ソフトウェアのテストを専門に行っております。さまざまな業種・業態・職種におけるシステムやITサービスの導入時、及び運用時の品質向上につなげています。ソフトウェアの検証や品質にお悩み・課題がございましたらお気軽にご相談ください。 当サイトでは、テスト技法を学びたい方、アジャイル開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト工程とは？各工程の解説とポイントを整理します！ first appeared on VALTES テストサービス .

テスト実行で必要になるテストデータですが、皆さんはどのように考えて作っていますか？テストエンジニアとしてのご経験が長くベテランの域に達している方からは「今頃何を言っているんだ？」と言われてしまいそうな内容ではあります。ですが、テスト担当者としてのご経験が浅かったり、急遽、テスト業務を行う必要に迫られた方に対して少しでもお役に立てることができればと考えてまとめてみました。 テストデータの作り方を解説 いたします。 テストデータっていつ作るの？ そもそも、テスト実行で必要になる資料や情報には何がありますか？テストケース（テスト項目書、テスト仕様書と呼ばれる場合も）と、テスト機材、テスト対象プロダクト、そして、テストデータが必要なものとして思い浮かぶのではないでしょうか。（他にも有りますが、本記事はこの内容で進めます）時々見かけるのですが、テストデータ有りきでテストケースの作成をしようとする方がいます。特殊な状況下において先にテストデータを作成するということもあり得ますが、 基本的にテストケースを作成してから（或いはテスト設計が終わった時点）テストデータの作成に着手するべきです。 なぜなのでしょうか？ テストケースは、テスト対象機能に対する確認観点に基づいて作る必要があるからです。テストケースはテスト設計で収集整理した情報の集大成と言えるものです。ドキュメントで書かれていることを実現させるために、必要なものがテストデータと言えるでしょう。 テストデータを作るときに考えること テストデータの作成タイミングは、テストケース作成後であると書きました。では、テストデータを作るときに、どの様なことを考えるべきでしょうか？私自身が、普段の業務においてテストデータを作るときに何を意識して、どの様な考え方を持ちつつ進めているのかまとめてみました。 ① 作り方 　 必要となるテストデータの作り方が正しいのか、きちんと確認した上で作成することが重要です。稀に、類似機能が存在するようなシステムである場合、似て非なるテストデータが完成してしまうという事態が起こり得ます。いざテスト実行に着手したときに意図しない結果となって混乱を招くことがあるのです。あってはならない状況ですので、事前確認をきちんと行うようにしましょう。 ② テスト環境の画面操作でそのまま作成しても良いのか？ 意外と頭から抜け落ちてしまうことが多いのですが、このような観点でも検討する必要があります。継続開発や機能追加などでは、このようなケースを考えなければいけない状況は稀です。しかしながら、新規開発プロジェクトの場合は、開発の進捗状況次第でテストの順番を変更せざるを得ない状況がしばしば発生します。テストの順番を変更することで、計画段階で想定していたテストデータの流用やテスト結果で生成されたデータを、次のテスト実行で使用するような場合は、想定が崩れてしまう可能性があります。 このような場合には「テスト環境でそのまま作成しても良いのか？」という問いを自分に投げかけつつ、プロジェクトメンバーと相談してみることをお勧めします。そもそも、未テスト状態の機能を用いて作成したテストデータが「正しい」という保証がどこにもないため、気にかけるべきです。状況次第では、データベースに必要な情報を直接インサートして対応することも検討が必要になります。或いは、一時的にデータベースだけを別の環境とつなぎこみ、臨時対応で進めなければいけない場合も考えられます。やはり、プロジェクトメンバーとの相談する必要がありそうですね。 ③ テストチームで作成できるのか？ テスト環境の画面操作でテストデータ作成ができない場合があります。このような場合、データベース等にレコードを直接投入するなどの対応が必要になります。こういった操作は、少しばかりデータベース操作の知見やサーバー操作に関する知識が必要になってきます。昨今、開発経験や知識が無い方に多いケースなのですが、データベース操作の知見やサーバー操作ができないという方も少なからず居ます。こういった方々から見ると、データベース操作の知見やサーバー操作などは、非常にハードルが高い作業になります。 簡単な操作であれば、ネット検索ですぐに解決できる場合もあります。しかし、基礎的な知識が無い場合「生兵法は大怪我のもと」という思考が働くため、二の足を踏んでしまいます。結果、必要以上に工数を要する場合もあるため、すぐに開発担当者に相談を持ち掛けたほうがよいでしょう。 ④ 洗い出した全てのデータを作成する必要があるの？ そもそも、必要なテストデータとして洗い出したものは、全て作成する必要があるのでしょうか？結論として、全てのテストデータを作成しなくても良い場合があります。なぜなのでしょうか？あるテストケース用に作成したテストデータが、そのまま同じ条件で流用できる場合があります。加えて、あるテストケースの実行結果がそのままテストデータとして利用できる場合もあります。この様な場合、洗い出したテストデータの全量を作成する必要がなくなります。 ⑤ 使い勝手を考えよう テストデータは、それがテストデータであることが一目瞭然である方が良いですね。また、どのテストケースで使うテストデータであるのかもすぐにわかる状態が望ましいです。稀に、実際の商用環境にて登場するような名称を付けて登録される場合もありますが、非常に紛らわしいため控えた方が良いでしょう。更に、テストデータ同士で非常に似た名称にしてしまうのもできれば避けるべきです。 ⑥ 予備のテストデータも検討した方がよい場合 容易に作成できないテストデータやインシデントの発生が見込まれるような機能で使うテストデータは、予め予備データを作成しておくべきです。また、テストデータを作成するときに開発担当者やその他部署に依頼が必要な場合も同様に、予備のデータも検討した方が良いでしょう。 ⑦ テストデータ一覧表を忘れずに作りましょう おそらく、これを作らずにテスト実行を遂行するということはほぼ無いと思います。ただ、小さな規模の場合において作成されない場合もあり得ます。しかしながら、もし、何らかの問題が発生して、後日改めてテスト実行を行う必要が出てきた場合必要です。規模が小さいからと言ってテストデータ一覧表を作成していない場合は、思いがけず余計に工数をかけてしまう結果になってしまうものです。規模が小さいからと言って作らないというのはお勧めできません。 テストデータを作成したあとにやること テストデータを「いつ」どのような考えを持ちつつ作れば良いのか、について書いてきました。 次に「誰が」作るのかを書いてみます。 各企業で異なると思いますが、テスト実行者が作成するのが望ましいです。理由は、テスト環境に慣れるためのトレーニングになる点やテストケースを事前に確認できるなどのメリットがあるからです。更に、テストケースに対する不備などがあれば、そのときに見つけられるかもしれません。テストデータの作成が終われば、最終的にテストケースを作成した人がテストデータの最終チェックを行いましょう。こうしておけば、テスト実行に着手したときにテストデータの不備で慌てて作り直しという状況も回避できます。 「後悔先に立たず」のとおりで、後から不備が見つかって、あの時にきちんとチェックしていれば・・・、という思いをしたくないですよね。そうならないように、きちんとチェックしましょう。 まとめ 「テストデータを作ろう！　作り方の基本思考もご紹介」と題しまして、ご説明してまいりました。 ソフトウェアテストというものが一般的になりつつある今でも、テストデータの作り方や考え方について説明してくれているような書籍なども少ない状況 です。また、テストデータの作り方や考え方について先輩方に質問しても、きちんとした回答を得られないかもしれません。それでも、必ず作らなければいけないものでもあります。そんなときに、ここで述べてきた内容があなたの助けになれば幸いです。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テストデータを作ろう！　作り方の基本思考もご紹介 first appeared on VALTES テストサービス .

ソフトウェアテストの技法の中の一つに「シナリオテスト」があります。ソフトウェアテスト設計業務に携わる方が耳にして、まず頭に浮かぶのは「難しい、設計は避けたい…」というイメージではないでしょうか？機能テストとは違い、考えるポイントがいくつもあり、どこまで考えればカバレッジを確保できているのかも分からない。工数の見積もりも行いづらいのも「難しい、設計は避けたい…」と考えてしまう理由の一つかと思います。本記事ではシナリオテストの他のテストと比較した際の特徴や設計時の難しさ、そしてシナリオテストを設計する際のポイント・対策を解説していきます。  シナリオテストとテストシナリオをハッキリと定義します！ シナリオテストとは「システムテスト」におけるテスト技法のひとつです。「ブラックボックステスト技法」に分類されます。日本におけるソフトウェアテスト技術者資格認定の運営組織で各国のテスト技術者認定組織が参加しているISTQBの加盟組織であるJSTQBでは「ユースケーステスト」「ユーザーシナリオテスト」が同義とされています。しかし、そう言われてもよくわかりませんよね…。「なぜシナリオテストを行うのか？」から考えてみましょう。まず目的としては下記の３つが挙げられます。 【主なシナリオテストの目的】 　 業務が運用できることを確認したい 　 機能が連携していることを確認したい 　 システム構成に問題がないことを確認したい さらに、機能テストとの比較を行うため、ECサイトにおける例を示します。ECサイトのテストでも「会員登録」「商品購入」「決済」「在庫管理」などそれぞれの独立した機能をテストすることは”機能テスト”に分類されます。この機能を一括してつなげて行うECサイトサービスのテスト(例：「会員登録する」⇒「商品を選んで購入する」⇒「決済する」⇒「商品が発送される」)のようなものがシナリオテストと呼ばれます。 つまり、シナリオテストとはテスト対象の機能、システムが連動して動作した時、ユーザーの目的遂行を妨げる不具合を検出するテストです。またそれに似たような語句「テストシナリオ」はその一連の流れのことを言います。機能テストで言うところの「テストケース」にあたります。ここまで機能テストとシナリオテストとの比較を行ってきましたが一つ疑問が上がってくるかと思います。 「シナリオテストで各機能についてもテストを行うのであれば機能テストは必要なくてシナリオテストだけ行うのではだめなの？」 この疑問への回答は「だめ」になります。理由としては機能テストが未実施でシナリオに関わる各機能に不具合があると、テストシナリオの中の以降のテストケースが実施できなくなるからです。またテストの進行が止まってしまうことがあるため、前提条件として「機能テストが終了している必要がある」のが多くなるのも理由です。 もし、新しくテスト支援を導入する場合にはコツがあります。テスト計画など立てる際にシナリオテストを導入する必要があるとわかった場合は、できるだけ前段として機能テストも組み込むようにご提案いただけると株が上がりますよ^^ シナリオテストが難しい理由 さて、ここまでシナリオテストについて機能テストとの比較を通して説明してきました。ここまでの説明でなんとなく察していただいているかもしれませんが、シナリオテストは設計が難しいのです。理由は様々あると思いますが、「テスト観点が思いつかない」のが大きな理由と言えるでしょう。この理由をもう少し深堀すると、 「機能テストのテスト観点との違いが分からず、シナリオテストのテスト観点のイメージが漠然としていて思いつかない」 ということになるかと思います。 シナリオテストに盛り込む機能が多すぎて、さらにその機能も細かく設定されているケースがあります。各機能ごとの特性については把握済みでもそのつながり次第で別の機能や観点が必要になるケースもあります。そもそも機能が多いのにもかかわらず、仕様書が存在しないケースもあるでしょう。シナリオテストは様々なパターンがあるので、難しくなるのです。 テストシナリオ作成とその対策 シナリオテスト設計が難しいことへの対策は、 「シナリオテストのテスト観点を知ること」が大きなポイントです。そのために「シナリオテストのテスト観点の役割」と「機能テストのテスト観点との違い」を知る必要 があります。例えば、機能テストであるシステムがあって、その中の会員登録機能についてテストするとしましょう。テスト観点として以下のようなものが挙げられ、それぞれのテスト観点についてテストケースを作成し、テストを行います。 ＜例：機能テストテストケース＞ レイアウト：名前入力欄の配置/〒入力欄の配置 は仕様通りか 入力(文字数)：〒入力欄に8文字入力ができるか 入力(文字種)：〒入力欄に半角数字とハイフンのみ入力できるか それに対してシナリオテストのテスト観点では「機能毎のテスト観点の組み合わせ+テストしたい指針/方向性」によってテストシナリオを作成します。例として、ECサイト上の決済方法を追加し、その機能周りについてテストシナリオを作成するとしたら、以下のようなものが挙げられます。 ＜例：テストシナリオ＞ 通常会員で新規追加された決済方法で決済し、注文を行うと商品が無事にお客様へ届くか 法人会員で新規追加された決済方法で決済を行うと、法人割引は適用されるか 通常会員で新規追加された決済方法で決済し、注文後、返金を行うと返金が実行されるか テストシナリオを考えるプロセスは下記の３点に注意しましょう。 【テストシナリオを考えるプロセス】 そのシナリオをどのような観点でテストしたいのか(シナリオテストのテスト観点) そのためには各機能で何に着目すべきなのか それを踏まえてテストシナリオを作成 となるべきなのです。ここで押さえておきたいのが「機能テストのテスト観点との違い」です。主な違いは下記4点です。 【機能テストのテスト観点との違い】 対象/範囲が異なる 例：シナリオテストではECサイトの商品注文の流れにおいてフロントの機能もバックエンドの機能も見るが、機能テストではフロントの一部機能もしくはバックエンドの一部機能のみしか見ない、など 同じような観点もあるが捉え方が変わる 例：テスト観点として「ログ」があった場合、シナリオテストでは”任意のシナリオを行った際、行った一連の操作ログが取得できること”だが、機能テストでは”ログが取得できること”になる シナリオテスト特有の観点がある 例：運用シナリオの途中で特定のタイミングで処理や操作を行った時の動作が仕様通りであること（事前、事後、前日、当日、無断、直前、直後、D日経過後、Y年経過後など） シナリオテストでは確認しないテスト観点がある 例：「入力バリデーション」などが挙げられる。機能、画面が動作する前提でシステムを使う流れに着目するため 以上を踏まえたうえでテストシナリオを作成していきます。最終的にテストシナリオを抽出する際に、さらに押さえておきたいポイントを以下で説明します。 【テストシナリオで押さえておきたいポイント】 ①インプット資料がない場合はテストチームで作成すべし 機能毎のインプット資料はあるが独立して存在するだけの場合が多いのでその時はテストチームで業務フローに準ずる資料を柔軟に作成する。 ②シナリオは突き詰めると際限がないので十分なテスト粒度を見極めるべし 業務フローやテストパラメータを網羅しようとするとテストの量が膨大になってしまうため「機能及び業務要件が漏れなくテストできているか」「業務フローの分岐条件が考慮されているか」などについて着目し、テストの目的達成に適切な粒度を見極める。 ③シナリオテストはステークホルダへの影響が大きいため早めに関係者に相談すべし バッチ処理の実行、テストデータはどのチームが用意するのか、テストデータの用意にかかる時間はどうかを事前に確認する。 ④テストデータ作成は入念に テストケース作成後にテストデータの設計を行うと、制約条件によりテストできないテストケースを作成してしまう場合がある。テストシナリオパターンを作成する段階でテストデータの要件も抽出し、テストできないテストケースの作成を回避する。 ⑤テスト設計の意図を明確化する意識を持つべし シナリオテストは1つのシナリオ内のテストケース数が膨大になる場合がある。テスト設計をして成果物をお客様に見ていただくだけでは、そのシナリオの目的などテストの意図は、お客様には伝わらない。お客様が知りたいのはテストシナリオではなく、それぞれのテストシナリオの意図なので必ず一つ一つのテストシナリオに対して目的を明確にする。 ⑥プロセスの重要ポイントを抑えるべし シナリオテストはテスト設計プロセスにおいて多大な時間を費やすのでプロセスの重要ポイントを押さえて効率的に行う。 まとめ 「シナリオテストにおけるテストシナリオ作成とその対策」と題しまして、ご説明してまいりました。シナリオテストは機能テストに比べて条件が複雑になってくるため、難易度が高くなります。しかし弊社がここまで紹介してきたシナリオテストの観点をぜひ覚えておきましょう。押さえておくべきポイントを事前にしっかりと押さえて、シナリオテストの設計を実施してみてください。 また、シナリオテストの実行を行っている方は、ここまでお伝えしたポイントを押さえて、テストを実行してみましょう。そうすることで、次は自信をもって”シナリオテスト設計者”というワンランク上の存在にステップアップできるかと思います。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post シナリオテストにおけるテストシナリオ作成とその対策 first appeared on VALTES テストサービス .

テストエンジニアに向いてる人とはどんな人ですかと面接などで聞かれる事があります。そもそも、テストエンジニアって皆さんどんなイメージをしていますでしょうか。テストを実行するだけの人？それだけではありません。テストを実行するだけの人はテスターと言われる事が多いでしょう。そこで テストエンジニアってどんな人が向いてるのかと、必要な資格についてご説明 していきます 。 テストエンジニアってどういう仕事をする人？ テストエンジニアとは、 対象の製品（パソコンのソフトウェアや家電製品、携帯電話やアプリなど）の品質を向上させる為に、テスト工程すべてにおいて実施する人です 。テスト工程も様々あり、テストエンジニアのスキルによって、役割が変わっていきます。テスト工程別にどんな役割や仕事なのかをご紹介します。 【テスト工程別の役割】 テスト計画 テスト対象の製品を理解し、テストする範囲や優先順位、どのようなテスト観点でテストを行うか、その計画を立てます。 テスト設計 テスト計画で決めたテスト観点をどのように確認するか、どんなテスト技法でテストケースを作成するかを決定します。 テスト実行 テスト設計で作成したテストケースを基にテストを行います。また、その過程で発生した不具合を報告します。 テスト結果報告 テスト実行の結果などテスト工程のまとめ、集計・分析をして報告するサマリレポートを作成・報告します。 以前は開発者がそのままテストまでを行う事が多かったですが、最近ではテストを専門で行う事もあります。 どんな人が向いてるの？ では、テストエンジニアにはどんな人が向いてるのでしょうか？まずは、 コミュニケーション能力 は必要だと思います。製品開発はひとりで行うものではなく、複数の人が関わっています。いろんな立場の人とコミュニケーションを取り、みんなで製品の品質向上を目指します。 文章から情報を読み取る力 も必要です。様々な資料から対象の製品の仕様を理解しなければなりません。テスト計画やテスト設計に必要な技術の一つだと思います。 根気強い事 も大事だと思われます。同じような作業や単純な作業もあります。途中で投げ出さない事、最後までやり遂げる意思が大事です。また、単純な作業に関しては効率的なやり方を考えれる人は自動化のテストエンジニアに向いてるかもしれません。 几帳面な人 も向いてると思います。テストケースの手順通りにテスト実施する事がとても大事です。もし、手順通りにいかなかった場合は不具合か仕様かは管理者が判断します。 技術的な面ももちろん必要ですが、まずはテストエンジニアに向いてるかどうかの判断をしてから必要な技術を身につければよいでしょう。 必要な資格とJSTQBを一気にご紹介 ここからは、テストエンジニアに必要な資格を一気にご紹介いたします！ ・ ソフトウェア品質技術者資格認定　 一般財団法人 日本科学技術連盟別（JCSQE）が主催する認定資格。 初級ソフトウェア品質技術者資格試験と中級ソフトウェア品質技術者資格試験があります。ソフトウェア品質知識体系ガイド SQuBOK Guideに記載されている内容から出題されます。 初級、中級ともに資格試験を受けるための受験資格はありません。初級ソフトウェア品質技術者に関しては、過去問題が公式サイトに公開されています。また、問題集が出版されていますので、そちらを参考にしましょう。 参照元URL： https://www.juse.jp/jcsqe/ ・基本情報処理技術者 独立行政法人情報処理推進機構（IPA:Information-technology Promotion Agency, Japan）で行われている。情報処理技術者としての「知識」「技能」が一定以上の水準であること事を認定している国家試験です。特定の製品やソフトウェアに関する試験ではなく、情報技術の背景として知るべき原理や基礎となる知識・技能について、幅広く総合的に評価します。基本情報以外にも多くの試験が用意されています。 応用情報技術者試験(AP)　～ ワンランク上のITエンジニア ～ ITストラテジスト試験(ST)　～ 経営とITを結びつける戦略家 ～ プロジェクトマネージャ試験(PM)　～ ITプロジェクトの成功請負人 ～ ネットワークスペシャリスト試験(NW)　～ ネットワーク社会を担う花形エンジニア ～ データベーススペシャリスト試験(DB)　～ ビッグデータ時代に求められる、データ志向の担い手 ～ エンベデッドシステムスペシャリスト試験(ES)　～ IoT時代に欠かせない組込みシステムの腕利きエンジニア ～ ITサービスマネージャ試験(SM)　～ ITサービスの安定提供を約束する仕事人 ～ システム監査技術者試験(AU)　～ 独立した立場でITを監査する御意見番 ～ 情報処理安全確保支援士試験(SC)　～ ITの安全・安心を支えるセキュリティの番人 ～ 参照元URL： https://www.jitec.ipa.go.jp/ IT検証技術者認定試験（IVEC）　 一般社団法人IT検証産業協会(IVIA)が認定するテストエンジニアの資格試験で、テストの実務を重視した試験です。キャリアレベルがレベル1（テスト実行者）からレベル7（研究者・上級コンサルタント）に分けられており段階的に試験を受けるようになっています。2018年春期試験から「知識試験」と「実務試験」の区分が無くなり、区分を1つに統合されております。過去問や解答例もHPにあるので、そちらを参考に受験してみてはどうでしょうか。 参照元URL： https://www.ivia.or.jp/item43 JSTQB認定テスト技術者資格 JSTQB（Japan Software Testing Qualifications Board）とは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織となります。その資格認定制度が「JSTQB認定テスト技術者資格」です。この資格は、ISTQBを通じてISTQBと連携している海外のテスト技術者資格と相互認証がされています。そのため、テスト技術における、唯一の国際資格と言えるでしょう。 試験はFoundation Level（FL）、Advanced Level（AL）テストマネージャ、およびAdvanced Level（AL）テストアナリストを実施しています。ALに関しては、FLの取得と業務経験3年以上の経歴がないと受講できません。FLに関しては、公認研修コースや問題集もあるため、そちらを参考に受験してみてはどうでしょうか。参照元URL： https://jstqb.jp/ なお、バルテス社では入社後に合格をサポートする社内研修があります。もちろん、社外向けにもeラーニングの講座も用意しております。気になる方は受講してみてはどうでしょうか？ 参照元URL： https://www.valtes.co.jp/education/elearning/ まとめ テストエンジニアはテストを実行するだけの人（テスター）ではありません。対象の製品（パソコンのソフトウェアや家電製品、携帯電話やアプリなど）の品質を向上させる為にテスト工程すべてにおいて実施する人です。テスト工程も様々で、「テスト計画」「テスト設計」「テスト実行」「テスト結果報告」などがあり、それぞれの工程毎に必要なスキルが変わってきます。 どんな人がテストエンジニアに向いてるのでしょうか？テストエンジニアに向いてない人は少ないと思います。重要なスキルや必要なスキルはあるとは思いますが、まずは製品の品質を向上する事を念頭に行動することが重要ではないでしょうか。必須ではないですが、必要だと思われる資格はたくさんあります。 ソフトウェア品質技術者資格認定 基本情報処理技術者 IT検証技術者認定試験 JSTQB認定テスト技術者資格 バルテスでは、JSTQBのFLに関しては社員全員取得を目指し、2022年現在では社員の92％が保有しております。必要資格を保有していなくても、JSTQBに関しては社内研修にてレポートしております。バルテスに入社しなくてもeラーニングの講座も用意しております。テストエンジニアに向いていて、テストエンジニアに興味がある方は、弊社バルテスにお問い合わせお問い合わせください！テストエンジニアに必要なスキルやノウハウが詰まった資料もダウンロードダウンロードできます。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テストエンジニアってどんな人が向いてるの？必要な資格は？ first appeared on VALTES テストサービス .

システム開発のプロジェクトにおいて、ソフトウェアの品質評価は必須の作業と言えます。その際に使われる指標の一つである「テスト密度」について、「使ってはいるが、使っているだけになっている」「効果が良く分からない」という方もいるのではないでしょうか。これから品質評価を行う方、品質評価に迷いがある方に向けて、 「テスト密度」を効果的に活用する手法をご紹介します。 テスト密度とは？ テスト密度とは、システムを新規に開発した場合や、既存のシステムに対して機能追加を行った際に、実行するテストの量が十分であるかを測定・評価するための指標の一つです。 必要なテストの量が実施されているか、テストの量に不足がないか、テストを無駄に多く実施していないかを判断する目安となります。 テスト密度の計算式は、次の通りになります。 【テスト密度の計算式】 テスト密度＝テストケース数÷開発規模 このように表され、開発規模あたりのテストケース数を算出します。「テストケース密度」「試験密度」という名称が使用される場合もあります。開発規模は、評価するソフトウェアのプログラムの行数（SLOC：Source Lines Of Code、LOC：Lines Of Code）や機能の規模（FP：Function Point）を使用します。プログラムの行数については、例えば1,000行単位でカウントするKStepsを使用する場合があります。 テスト密度は、テストを実行するより前に目標値として設定し、テストの実行中や実行完了後には目標値と実績値を比較して評価を行います。目標値には幅・範囲を設ける場合が多く、±○○％のように上限・下限の値を設定します。 例としては、次のようなものが挙げられます。 【テスト密度の目標値例】 ・作成されたテストケース数：4,500 ・開発規模：1,000KSteps ・目標テスト密度4.0 ・目標範囲±20％ この場合のケースを考えてみましょう。この場合、テスト密度は、4,500（テストケース数）÷1,000（開発規模）＝ 4.5です。目標値として±20％の範囲を適用すると、 目標値下限 ＝ 4.0×（1－0.2）＝ 3.2 目標値上限 ＝ 4.0×（1＋0.2）＝ 4.8 で、3.2～4.8の範囲となります。このような場合、作成されたテストケース数から算出したテスト密度4.5を、目標値の3.2～4.8と比較すると、目標の範囲内に収まっていると言えます。テストからソフトウェアの品質を評価する指標として代表的なものは、他に「バグ密度（バグ発生率）」があります。テストを実行した結果で検出したバグの件数をもとに評価を行うための指標で、計算式は以下のとおりです。 バグ密度＝バグ検出数÷開発規模 ただし、ソフトウェアの開発においては、テストをただ実施すれば良いというものではありません。また、数値の比較をただ行っていれば良いというものでもありません。 テスト担当者や品質分析の担当者は、「テスト密度」「バグ密度」に代表される指標を活用して、テスト期間中やテスト完了後に適切に品質を評価し、その結果によって対応策の要否を判断する必要があります。 「テスト密度」と「バグ密度」はどちらも重要な指標ですが、次に「テスト密度」に絞ってご説明していきます。 密度による評価が形骸化しているという問題 テスト密度の目標値は、開発マニュアル等で定められた社内の基準値があればそれを適用し、プロジェクトの特性を考慮して決定します。 社内の基準値がない場合は、IPA（独立行政法人　情報処理推進機構）が公開している「ソフトウェア開発デー分析データ集に、「テスト工程別のテストケース数と検出バグ数」が掲載されていますので、参考にしてみましょう。 ソフトウェア開発分析データ集： https://www.ipa.go.jp/digital/chousa/metrics/index.html 「ソフトウェア開発分析データ集」で公開されているデータは、「新規開発」「改良開発」「再開発」ごとに分類されているものや、「金融・保険業編」のように業種別のデータもあります。みなさま自身のプロジェクトに適したものを参考にすると良いでしょう。実際のプロジェクトでは、設定した目標値と実績値を比較して分析を行うわけですが、皆さんの開発現場では以下のような事象や感想はないでしょうか？ 密度や目標値による比較を、開発マニュアルに沿って、ただ実施するだけになっている 実績値による密度が目標値の範囲外になっても、何か理由付けをして結局OKにしている 設定している目標値が妥当なのかが分からない 例として、各テスト工程の完了時に、テスト密度やバグ密度を使用した定量的な評価と、その評価結果に対する所見を併せて記載して報告するケースを挙げます。 定量的な評価に対する所見には次のようなケースがあります。 テスト密度が目標値の下限を下回っているが、修正の影響範囲が限定されていたためであり問題ない テスト密度は目標値の範囲内であるため、テスト結果は妥当である テスト密度が目標値の上限を上回っているが、多数の画面に同じ内容の修正が入ったためであり問題ない このように、どのような結果であっても何かしら理由を探して「妥当である」と結論付けるだけになっていて、分析の効果を感じられていない状況です。 これは、テスト密度を使用した測定・評価を実施しているものの、その活用が形骸化してしまっているという問題です。背景には何があるのでしょうか？あらかじめ設定した目標値と、対象のソフトウェアの目標値を比較すると、次のような結果が見られます。 実績値が目標値の下限を下回る（実績値 ＜ 目標値下限） 実績値が目標値の範囲内である（目標値下限 ≦ 実績値 ≦ 目標値上限） 実績値が目標値の上限を上回る（目標値上限 ＜ 実績値） このようないずれかの結果となります。そして、それぞれの結果については、以下のことが言えます。 １ はテスト密度が低いため、テストが不十分である可能性があります。テストケースに抜けている観点がないか、確認が必要です。 ２ はテストの量は妥当な範囲に収まっていると言えます。 ３ はテスト密度が高いため、必要以上にテストを実施している可能性があります。無駄に実施しているテストケースがないか、確認が必要です。そして、上記のような内容は分かるものの、それが妥当かどうかの判断がつかない場合があります。「何をどこまでテストすれば良いのかが分からない」という状態ですので、注意しましょう。 何をどこまでテストすれば良いのか テスト密度を算出して、目標値に対する乖離は分かったものの、テストの量が十分かどうか分からない。このような場合は、どうすれば良いのでしょうか。 テスト密度は、品質を評価する道具の一つととらえ、様々な視点と併せて評価を行うことが必要です。 例えば、同じシステムの過去プロジェクトとの比較や、社内の同種・同規模のプロジェクトとの比較など、相対的に見て妥当と言えるかどうか判断する方法があります。 また、テストケース作成に入る前の段階で、目標値の範囲に対してテスト密度が上回りそうか・範囲内になりそうか・下回りそうか、予測を立てておくことも有用です。この際は、過去のプロジェクトに対する今回のプロジェクトの特性を考慮します。しかし、それでも「何をどこまでテストすれば良いのかが分からない」という壁が立ちはだかります。 これについては、テストの網羅性を可視化して判断を行います。具体的には、システムを俯瞰してテストの抜け漏れがないか、各機能に対して必要なテストケースが設定されているか、を表形式で表して確認します。以下は、テストを実施する機能と観点での例ですが、丸印の代わりに重要度（A・B・C）を付けると、テストケース数が妥当かどうかの判断を行う一助となります。     表示確認 入力確認 動作確認     画面レイアウト 文言 フォーカス オブジェクト 文字種 文字数 未入力 ＤＢ操作 メール送信 画面遷移 排他制御 ファイル出力 機能1 画面1-1 C C C C C C C － － B － － 画面1-2 C C C C － － － B A C B － 画面1-3 C C － C － － － － － C － C 機能2 画面2-1 C C C － B B B A － B A － ・・・                         テスト密度についても、システム全体だけではなく機能ごとやサブシステムごとに算出し、上のようなテストの網羅性と併せて確認すると、十分なテストを行えているかを客観的に判断できるようになります。テスト密度は、その数値による評価と併せて、「何をどこまでテストするのか（したのか）」の確認が必要です。 まとめ テスト密度とその有効活用について説明してまいりましたが、いかがでしたでしょうか。テスト密度は、品質を評価する道具の一つととらえ、「何をどこまでテストするのか（したのか）」と併せて評価を行うことが必要です。今回はテスト密度に絞ってお話ししましたが、プロジェクトの目的を考慮して適切な「道具」を使いこなして、プロジェクトを成功に導きましょう。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テスト密度って何？　何をどこまでテストすれば良いの？指標や有効活用方法を解説 first appeared on VALTES テストサービス .

システム移行の手法として、 マイグレーション が注目されています。マイグレーションとはどのような意味であり、ユーザーが求める要望やメリットとは何があるのでしょうか？そしてよく耳にするマイグレーションの手法であるリホスト、リライト、リビルドの違いも知りたいところです。本記事では、 マイグレーションとは？の意味を知ったうえで、リホスト、リライト、リビルドの違いを詳しく解説 していきます。一挙にマイグレーションのすべてがわかるお得な記事です！ マイグレーション（migration）とは？　まずは意味を知ろう マイグレーションを学ぶ前に、まずユーザー企業が考える理想の基幹システムについて考えてみましょう。理想の基幹システムには「コストを抑え、安定した現行システムの移行に加え、新しい要件を実現できること」を求めているのではないでしょうか。つまり、 現行システムの良いところを残して安定した移行を目指し、新しい要件も実現して、安く導入したいということ です。 ユーザー企業がマイグレーションで要望する４つのポイント 現行システムの資産を活かしたい 安定したシステム移行 移行コストを抑えたい 新しい要件も追加し、導入メリットを増やしたい マイグレーションは、現行システムをベースとするため、様々な制約があります。よって新しい業務要件がたくさん実現できるわけではありません。ただし、出来る限りのメリットを出していきたいのが実情です。このバランスをとるために、マイグレーションにはいくつかの手法が存在します。 ではマイグレーションにはどんな手法があるのでしょう？まずリホスト、リライト、リビルドの違いから理解してみましょう。読めば、一挙にわかりますよ！ リホスト、リライト、リビルドの違いとは？　 マイグレーションの手法の中で、 よく耳にするのが、リホスト、リライト、リビルド です。それぞれの違いを解説していきましょう。 リホスト アプリケーションやプログラムには手を加えず、IT基盤を入れ替える手法です。機器の保守切れやスペック向上のために、ハードウェアを新たに入れ替えるケースが該当します。リホストのみで実現できるマイグレーションは少なく、大規模なマイグレーションプロジェクトの1次フェーズとして実行されるケースがあります。 よく似た言葉で「リプレイス」「リプレース」がありますが、こちらはより広義な意味を持っており、リホストそのものを指すこともあれば、現行アプリを新規アプリに入れ替える行為を指すこともあります。 リライト アプリケーション機能はそのままで、プログラムを新しい環境に合わせて、旧言語から新言語へ最適に書き換える手法です。例えば、VBで書かれた現行プログラムを、Javaなどの新しい言語に書き換えるようなケースがリライトと呼ばれています。後述の「リビルド」と比較すると、短期間/低コストで実現できますが、業務要件の変更は行えず、自由度は下がります。 よく似た言葉では「コンバージョン」がありますが、こちらも広義な意味を持っており、リライトそのものを指すこともあれば、プログラムやデータ、ファイルを書き換える手段を指すこともあります。 リビルド 現行のシステムを廃止し、新たにシステムを再構築する手法です。基本的にはスクラッチ開発と同義にはなりますが、現行システムの資産から業務仕様をベースとするほか、データのみ移行するといったケースもあります。要件定義を含めてイチから開発するため、業務要件も変更しやすく、自由度は高まります。一方で、相応のプロジェクト期間とコストを要する点は抑えておく必要があります。ERPパッケージシステムを新たに導入することも、リビルドに含むことがあります。 リホスト、リライト、リビルドの違いを理解いただけたでしょうか？ それでは、マイグレーションに関して、もう少し掘り下げた説明をしたいと思います。 マイグレーションプロジェクトは難しい 前述した「ユーザー企業がマイグレーションで要望する４つのポイント」を思い出してみましょう。リホスト、リライト、リビルド、そのどれをとっても、すべての要望を満たす手法はありません。要望のトレードオフをかけながら、どの手法を採用するか、あるいは組み合わせるかを慎重に検討する必要があります。基幹システムのマイグレーションとなれば、プロジェクトに関わるステークホルダー（利害関係者）も非常に多くなり、プロジェクト発足の難易度は大きく跳ね上がります。 また、プロジェクトを遂行する上でも様々な問題が潜みます。ここでは、よくある問題やリスクについてアプローチをしていきます。 １．現行システムの仕様や要件が不明確 レガシーシステムで見られがちな問題のひとつに、「開発設計書が揃っていない」点が挙げられます。併せて、現行システム構築に携わったメンバーも残っておらず、有識者の確保も難しいため、現行システムそのものが「ブラックボックス」化するケースがあります。現行資産の活用という観点に対して、大きく阻害する要因のひとつになります。 ２．コストの肥大化 プロジェクトが進むにつれ、追加要件や現行システムの改修反映といったインシデントが発生します。また、OSのアップグレードや周辺システムの仕様変更など、外的要因による対応コストの増加も考えられます。これらは、プロジェクトが長期に渡れば渡るほど、発生する可能性が高まっていくものです。 ３．リソース管理が難しい 大規模プロジェクトになれば、特に人的資源のコントロールには困難を極めます。人材の調達はもちろん、プロジェクトマネジャや有識者を中心とした属人化や、負担箇所の集中も起こりがちです。 上記が影響し、プロジェクトが中断、または中止するケースは多くあります。マイグレーションプロジェクトの難しさについて、理解いただけたのではないでしょうか。 マイグレーションを迎えるために 「現行システムを新しいシステムへ移行する」と一口で表現するのは簡単ですが、その実態はとても大変な活動です。入念な準備と計画が必要であることはもちろんですが、その中で、現行システムの仕様や業務フローを明らかにすることが大切です。これには、 システムマイニングのツールを活用し、現行システムの仕様やフローを把握する方法 もあります。また、 特にボリュームが膨らみがちなテスト工程において、マンパワーで解決しようとしない仕組み化 も併せて検討したいところです。 まとめ 「マイグレーションとは？リホスト、リライト、リビルドの違いと手法が一挙にわかる！」と題しまして、ご説明してまいりました。 それぞれの手法の違いと併せて、マイグレーションプロジェクトの難しさと、そのポイントも併せてお伝えできたかと思います。 バルテスでは「マイグレーション品質向上支援サービス」をご提供しています。難度の高いレガシーシステムのマイグレーションプロジェクトに対し、仕組み化された テストサービス による品質向上を実現します。システムマイニングツールを活用し、現行システムフローを可視化し、マイグレーションを進めていきます。また、マイグレーション経験者を中心とした品質管理支援担当者（QMO）がプロジェクトに入り、品質活動を強力に推進いたします。詳しくは「マイグレーション品質向上支援サービス」や下記資料をご覧ください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発やマイグレーションのテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post マイグレーションとは？リホスト、リライト、リビルドの違いと手法が一挙にわかる！ first appeared on VALTES テストサービス .