IT情報システムは、いまや企業活動だけでなく社会活動のあらゆる場面で使われています。
企業内での業務基幹システムをはじめ、企業間取引を効率化するBtoBシステム、
企業と消費者を結ぶBtoCシステムなど形態は様々・・・
私たちは、このようなエンタープライズシステムが停止するようなトラブルはもとより、あらゆるユーザーの視点に立ち、
ユーザーが何を問題と考えるのかを見極め、それらを測定可能な品質として定義し、テストを進めます。
また、開発の上流工程から参加することで、下流のテスト工程だけでなく開発全体の効率化を図ることが可能です。
サービスフロー
テスト工程の構築から、メトリクスを使ったリリース判定基準の策定までお任せください。
 |
|
 |
1：テスト全体計画開発プロジェクトの最上流でテスト全体計画書を作成します。どのような方針、アプローチでテストを行い、品質の確認を行うか、テスト工程を構築し、それぞれの工程ですべきテストの内容を定めます。スケジュール、人員、工数、機材、テスト実施環境など、テストに必要なリソースについても検討します。 |
 |
２：上流ドキュメントのレビュー要件定義書（仕様書）など、テスト設計の情報源となる上流ドキュメントのレビューに、テスト担当者の立場で参加します。上流ドキュメントとしての品質、およびテスト可能か、テストが効率的に行えるかの観点でレビューを行います。このことにより、スムーズなテスト設計が可能になります。 上流工程の改善 |
 |
 |
|
|
３：テスト計画テスト設計者にテストの目的や方針が的確に伝わるよう、テストの種類毎にコンセプト図を作成します。
|
 |
４：実装中の品質状況把握設計・実装の進捗状況やテスト結果を確認します。また、開発者によるテストが済んだソフトウェアから先行してテストを実施することにより、もし品質が悪かった際に、大きな手戻りやテストが始められない事態とならないようにすることができます。 |
 |
５：テスト設計テストエンジニア自らレビューに参加した上流ドキュメントに基づき、テスト設計を進めます。最適なテスト技法を使用することにより、テストケース数の低減を目指します。テスト設計が済むとテストケースを作成します。 |
 |
６：テストチーム移行判定開発者によるテストとテストエンジニアによるテストの境界で、このまま次のテスト工程に進んでよいかを確認するために移行判定を実施します。どのような移行判定を実施すればよいか、何をもって合格とするのかの基準をあらかじめ策定しておきます。開発者に事前に知らせておくことで、よりスムーズなテスト工程の移行が期待できます。 |
 |
 |
|
  |
７：テスト実施最も不具合の多く潜んでいると予想される部分から、最も効率のよい手順を検討した上で実施します。 |
８：テストサマリレポートテスト実施で収集したデータを分析し、結果を報告します。 バグ情報を活用したテストの効率化が可能です
|
|
９：リリース判定基準策定バルテスのテスト実績データと、ご提供いただく過去の開発プロジェクトの開発データ、不具合データ、ドキュメント、プロジェクトの記録等から、リリース判定基準の策定を支援します。 |
●産業別
電力、交通、通信、行政・自治体、金融、保険、医療、建設、不動産
製造、ロジスティクス（物流・輸送・運輸）、流通、卸、小売など
●システム種別
基幹業務、ERPパッケージ、SCM（サプライチェーン・マネジメント）、
EC（電子商取引）、会計・経理、人事・給与、販売管理、生産管理、文書管理、帳票・印刷、
ネットワーク管理、運用管理、セキュリティ管理、ストレージ／バックアップなど
バルテスではソフトウェアテスト専門会社として、さまざまな分野のテストを行っています
オフサイトテスト
ソフトウェアテストソリューション
上流工程からテストを始めることで解決できる事があります
エンタープライズシステム開発において、テスト工程がうまくいかないというお客様の声をよくお聞きします。その原因の多くは、テストを始めるのが遅いことにあります。もともと計画されているテスト工程の期間が短いばかりか、上流工程の遅れによって、さらにテスト工程が圧迫されている開発現場が多いようです。
エンタープライズシステムが取り扱う「業務」は、開発エンジニアやテストエンジニアにとって、馴染みの少ないものです。開発やテストにあたって必要な業務知識の習得に、本来の作業時間以上に時間を取られることも珍しいことではありません。余裕をもったスケジュールであることが求められています。
一方、エンタープライズシステムの開発期間は、要求定義から本稼働までの期間で見ると半年以上と比較的長く、そうした時間を確保しやすい状況にあります。
にも関わらず、基本設計、詳細設計を終え、実装前後になって、ようやくテスト計画やテスト設計に着手している場合があるのは、開発エンジニアがテストを兼任していたり、テストスケジュールをテスト実行の開始日からの逆算でスケジュールを立てているからではないでしょうか。これでは品質を段階的に高めていくようなテストは困難です。
十分なテストをしようと思えばテスト工数が増え、コスト増になるのではないかと思われるかもしれませんが、そうではありません。上流工程からテストを始めることでコストを増やさずに、十分なテストが可能になります。
まず、要求定義書、要件定義書、基本設計書といった開発仕様書のレビューに、テスト可能性やテスト容易性などテスト側からの視点で指摘を行います。ここでテストエンジニアが行うレビューは、記載内容の正しさなどをすべて詳細に確認するわけではありませんので、断続的な事前レビューとレビュー会議への参加だけでよいのです。仕様書がリリースされる毎に、レビューに数日間かけるだけで済みます。
次に、開発仕様書が出来上がれば、次の開発工程に進めるのと並行して、その仕様書に対応するテスト計画、テスト設計、テストケース作成などの作業を行います。後で行っていたテスト作業の時期を前倒ししているだけですので、テスト工数は増加するわけではありません。これまでは開発エンジニアがテストも行っていたため、開発作業を終えてからでないとテスト作業が行えなかったので時期が限定されていましたが、開発者とは異なるテストエンジニアがテスト作業を行うことで、開発とテストの並行作業が可能になります。
担当者の声
お客様にとっての「当たり前」をいかに素早く体得するかが、
テストプロジェクト成功の鍵
エンタープライズシステムと一口に言っても、それぞれのシステムが取り扱う業務は多種多様で、テストする内容も大きく異なります。特にエンタープライズシステムのテストでは、ソフトウェアテストに関する知識やノウハウだけでなく、その業務や業界の慣習といった知識も必要になります。
私はこれまで、一つの製品に長くかかわるというよりは、基幹システム、パッケージソフト、組込機器など、数年単位でさまざまなソフトウェアのテストに従事してきました。自分が経験したことのない分野のテストを担当する場合には、そのソフトウェアの、ひいてはそのソフトウェアを利用されるお客様にとっての「当たり前」をいかに素早く体得するかが、テストプロジェクト成功の鍵になっていますので、いつも責任を感じます。
新しい知識の多くは、その業務のスペシャリストであるお客様から教えていただいています。テストを成功させるために、臆することなくお客様を質問攻めにしてしまい、ご負担をおかけし反省することもあります。しかし、私の投げかける質問の中には、私が経験した他の分野では当たり前のことが、お客様の分野では考えもしなかったことが含まれており、それが業務の効率化や使い勝手のよいシステムの構築につながることも少なくありません。そうしたことを余すことなくテスト計画やテスト設計の中に落とし込んでいくのが私の仕事と考えています。
開発者でもシステムの利用者でも他の誰でもないテストエンジニアという第三者だからこそ提供できる、新しい気付きによってよりよい品質の実現に貢献できるのが、この仕事のやりがいになっています。
ぜひ、そのシステムを一緒にテストさせて下さい。
エンタープライズ
ソフトウェア
テストエンジニア
田中英和
