品質管理
戦略的なテスト計画とユーザー目線のテスト実施でサービス品質を確保
ソフトウェア開発におけるテストは、際限のない取り組みです。
限りある時間と予算の中で、より高品質なアプリケーションを早く市場にリリースできる形にすることを重視し、
不具合検知を超えた広い視点からのテスト活動により、継続的なサービス品質向上を実現します。
ユーザー目線の品質管理
品質管理で担保すべきはソフトウェアが「動く」ことではなく、「使える」ことです。
当社ではさらに「使いやすい」を実現するため、ベースとなるシステムテストから、
ユーザーを想定したシナリオテスト、ユーザビリティテストを交えて、確かな品質を担保します。
異なる視点からのテスト
- System Test
システムテスト機能の定義動作を担保
機能仕様書に基づく、システムテスト。
定義仕様に対するテスト率は100%です。機能が、意図通りに動作することを担保します。 - Scenario Test
シナリオテスト想定される運用を担保
業務フローを基に、日々の運用に沿った一連の動作を確認するシナリオテスト。
定義された運用シナリオの実現を担保します。 - Usability Test
ユーザビリテテストユーザー視点の品質を担保
利用ユーザーにとって使いやすいシステムかの観点で、テスト者がターゲットユーザーになりきり、UI/UX、モバイル互換性、使用性、性能等のテスト項目を検証します。
それぞれのテストを支える独自
ノウハウ
- for EC
テスト観点EC特化のオリジナル観点
デザインやUX、SEO、セキュリティ、保守性、データ移行など様々なECサイトならではの視点を盛り込んだ独自のテスト観点項目。
- for Package
システム特性パッケージの特性観点
豊富な構築経験から得た、挙動特性やパッケージ標準不具合データ、プラグイン情報を基に作られた、そのシステムだからこそ確認すべき観点。
開発と独立したテスト体制
当社では、開発チームから独立したテスト専門のチームが要件定義からプロジェクトに参加することで
ユーザー/運用者の視点をインプットした状態で、効率的かつ公正なテスト活動を実施します。
シフトレフトによる品質向上と工期短縮
テストチームは、要件定義書やデザイン、各種設計書などの開発成果物が作成された時点から精査作業を行うとともに、効率的なテスト戦略立案/設計のインプットとします。
早期段階から第三者的かつユーザー視点のレビューを挟むことで、要件や設計の誤認識による大きな手戻りや未然のバグを防ぎ、品質の向上と開発全体の期間短縮を図ります。
迅速なサービスリリースを可能に
開発者が開発と並行してテストをする形ではないため、段階的に一連の動作シナリオが通る形でシステムの完成度を高めます。
そのため、お客様にて早期にシステムに触れていただける状態となり、サービスリリース準備等も前倒しで進めていただくことが可能となり、迅速なサービスリリースを支援します。
時間効果を最大化する戦略的なテスト計画
限られた時間の中で、最大限のサービス品質を確保するため、戦略的なテストを計画します。
テスト設計の流れ
要件把握
テスト設計者は要件定義に参加したり、各種開発ドキュメントのレビューを行うことで、テスト設計の基となるサービス要件、業務要件、機能要件を把握します。
機能重要度による
リスク評価
要件を基に、サービスにおける各機能の重要度を評価し、機能実装難易度を加味しリスク分析を行い、結果を基にテストリソースの配分を行います。
通常ECにおいては、「会員登録できる」「購入できる」「お金の誤差を生じる不具合がない」ことなどが、最も重視されます。
※下記「重大度別の不具合分類」参考
テスト設計
リスク評価の結果を基に、テスト設計を行います。
お客様の業務フロー、機能仕様、当社の持つ観点リストなど、多様な観点を組み合わせて各種テストに対してシナリオ/ケースを設計し、最大効率で最高品質を担保します。
※テスト設計者は全員JSTQB認定テスト技術者資格保持者です。
重大度別の不具合分類
Severity（重大度）
説明
例
S1
当社の提供する製品/サービスの全ての機能が使えない、極めて使用が限定される状況。もしくはそれに準ずる状況で、かつ、当社より回避策も提示できていない状況。
- ・会員登録不可
- ・全商品購入不可
- ・情報漏えい
S2
当社の提供する製品/サービスの全ての機能が、一時的もしくは部分的に使えない状況で、想定された日常的な業務フローにおいて通常業務を妨げる問題かつ、当社より回避策の提示もできていない状況。
- ・CSV登録エラー
- ・買取商品登録エラー
- ・顧客の退会情報移行ミス
S3
事前に想定されていた制限による問題で、お客様に対して当社より回避策が提供できている状況。
- ・サーバーのスペック不足
S4
ユーザーへの影響度が極めて低い、または特異的な状況において発生する問題
- ・デザイン崩れ
- ・ブラウザバックエラー
S5
当然に備わる機能に関するお客様と当社双方の想定漏れによる問題（≠実装漏れ）
- ・ドキュメントにも何も書いていない
- ・要件定義でも協議されていなかった件
- ・当社でも気づくべきだった漏れ
実装漏れ
実装漏れによって発生した問題は1～5のレベルにて評価する
テスト時間と不具合減少
一般的にテストにかける時間と検出される不具合は比例関係にあるとされ、テストに時間をかければかけるだけ不具合は減少します。しかし、無限にテストを行うことはできないため、目標を定めてテストを実施します。
不具合率：構築する機能の仕様数に対しする不具合が確認される仕様数です
テスト時間：製造工数に対するテスト工数割合を示します
不具合は機能不具合のみならず、仕様不具合なども含みます
規模に合わせて対応可能な多様なテスト
当社では、サイトの規模やご予算に応じて、多様なテストに対応させていただきます。
仕様確認テスト
システム機能要件書に定義された「仕様」に基づき、システムが仕様内容通りに実装されているかを一項目毎にすべて確認します。
組合せテスト
組合せ条件の多いフォームや注文手続き等のテストにおいて、直行表やペアワイズ法を用いた組合せテストを実施します。
デシジョンテーブルテスト
複雑な条件や制約のある機能に対し、ロジックの整理と確認を同時に行い、ルールを網羅的にカバーするテストを実施します。
UI確認テスト
デザインデータとの整合性、入力値による崩れ等を確認し、各デバイス/ブラウザごとに想定されたUXが担保できているかを確認します。
負荷テスト
ツールを利用し、実際のアクセスを想定しながら、性能テストを実施します。
テスト自動化
ECにおける日常的に通るかつ重要度の高いフローを一部自動化し、継続開発の際のテストの効率化と定時実行による早期検知体制を構築します。
