Qaas

QaaS PRESSQaaS通信

WEBサービスのテストにおけるポイント

2021.01.29
QaaS通信

こんにちは!
COOの松原です。

今回のテーマは、ズバリ「WEBサービスではどのようなテストが最適か?」です。
※あくまでUIをベースとしたブラックボックステストの想定です。

読むのが面倒な方向けに(笑)、結論を先に書きます。


ここから先は、順を追ってお話ししたいと思います。
昨今、WEB/クラウドサービスが急増していますが、開発の特徴として、
以下のような共通点があります。

「アジャイル的なアプローチの開発サイクルが多い」
「開発スピードが速い」
「仕様は開発が進むにつれて成熟していく(変更や追加が前提)」

そのため、従来のテストでは多くの割合を占めていた
「仕様ありきの、機能確認のテスト」の意義が低くなっています。
そもそも開発スピードが速く、仕様を成熟させながら進むこともあり、
この機能確認のテストとの相性はとても悪いのは頷けます。

ここまでの事情から、WEBサービスのテストで重要なのは次の3点と考えています。

WEBサービスのテストで重要なポイント

①ユーザーに提供する価値、UXを重視したテストを用いる
②機能特性によっては、ロジカルに網羅性を担保するテストも用いる
③開発と伴走するテストチーム構築を心がける

各ポイントの解説

①ユーザーに提供する価値、UXを重視したテストを用いる
テスト対象のサービス、プロダクトがユーザーに提供する価値、本質は何か?を理解し
これを中心としたテストをすること。
表層的な「機能」としてではなく、「サービス」「プロダクト」としてソフトウェアを捉えること。
品質特性は「合目的性」を担保し、テスト技法は「ユースケーステスト」を用います。

②機能特性によっては、ロジカルに網羅性を担保するテストも用いる
①のデメリットは、まさにその機能としてのカバレッジ(網羅性)を担保しにくい点にあります。
複合的な条件の組み合わせが結果に影響する場合や、ユーザーの資産(個人情報や金銭等)に
影響を及ぼす機能など、リスクの高い機能に対しては、その組み合わせの網羅性を担保する
必要性が高くなります。
①と併用するハイブリッドなアプローチが望ましくなります。
品質特性は「正確性」を担保し、テスト技法は「境界値分析」「同値分割」「デシジョンテーブル」や
「クラシフィケーションツリー」「ペアワイズ法」などを用います。

③開発と伴走するテストチームの実現(下請け気質ではなく)
これは完全にマインドですが、最重要ではないかと思うポイントです。
従来型のテストでは、内製/外注を問わず「待ち」「受け」のテストが主流でした。
それは、仕様やソフトウェアが完成した上で、品質確認を行うテストが主だったためです。
前述の通り、WEBサービスでは、そもそも仕様もソフトウェアも、テストを行う時点で
完成はしていないため、「攻め」のテストが必要になります。
つまり、要件や仕様検討段階から参加し、仕様設計自体はもちろん、積極的にテスト活動を推進する、
開発と伴走したテストチームの実現が不可欠になります。

ダラダラと書いてしまいましたが、読んで頂きありがとうございます。
あくまで一つの考え方、意見ではありますが、何かの参考になれば嬉しいです。

最後に、ソフトウェアテスト技術者の国際的な認定資格に「ISTQB」という資格があります。
試験は毎年2回行われており、次回は2月13日です。
弊社は、認定者が一定数以上在籍する企業として、Gold partnerに認定されています。

今話題のDXの推進等により、今後は一層のソフトウェア開発が増加します。
これに伴い、開発エンジニアの不足はもちろんのこと、よりレベルの高い
テストエンジニアの不足が、各プロジェクトにおいて重要な課題になります。

もちろん、これからの時代に必要とされるテストエンジニアには、
前述のような「知識」「技術」「マインド」を備えている必要がありますが、
当社がこのようなエンジニア達が集まり、切磋琢磨し合う企業になるよう、
今後も真摯に取り組んで参ります。

Share :
  • facebook
  • twitter
  • pinterest
  • linkedin

エントリー受付中!

PAGE TOP