『テストの7つの原則』 〜 パート⑥ 〜
はじめに
現在、アプリ開発者としてプロダクトの持続的な成長や
ユーザーへのコミットに寄与するためにも、
SDLC全体を見渡して開発をすること、
および、それにはテストに関する体系的な知識が必要だと考え、
それを効率良く学べるJSTQB Foundation Levelの資格試験の勉強をしていました。
この記事ではそこでの学びをアウトプットしたと思います。
今回はその中でも「テストの7つの原則」の一部について
記事にしたいと思います。
なお今回は
テストはコンテキスト次第
こちらの原則について記事にしてみようと思います。
テストはコンテキスト次第とは
これは
テストには唯一普遍的なアプローチは存在せず、
状況が異なれば求められるテストもまた異なる、
と言うことを指し示す原則になります。
。。。
『まぁ、当たり前のことだよなぁ〜』
そんな風に感じられる原則ですが、
ではどんな時にこの原則が当てはまるのか、
これを考えてみようと思います💪
具体例 〜その①〜
例えば以下の2つのプロダクトがあったとします。
- 工場などで使われる産業用機器
- アパレル用品を販売するECサイト
前者の振る舞いをテストで保証するとしたら、
それは正しく機能すると言った機能的側面は勿論のことですが、
人命に関わるような重大な事故が起こらないようにする
これが特に重要視されるのではないでしょうか？
そして、
もしそのような事態に陥りそうになったら緊急停止するようにする
と言ったこと(フェールセーフ)が重要視されるのではないかと思われます。
一方で後者の方でしたらユーザーアクセスに対してどれだけ耐え得るか、
と言ったパフォーマンスの方(負荷テスト)がより求められるかと思われます。
またはクレジットカード情報なども扱うことになるので、
セキュリティ周りの脆弱性診断なども求められてくるでしょう。
このようにどんなプロダクトを開発するのかによって求められるテストも異なるのです。
具体例 〜その②〜
テストは開発するプロダクトの質的側面だけでなく、
プロジェクトの開発手法によっても異なります。
例えば...
- アジャイル開発(インクリメンタル、イテレーティブ)
- ウォーターフォール開発(シーケンシャル)
上記の開発手法を例にとってみます。
前者の場合はその名の如く何度も開発のサイクルを回すので
テスト自動化がなされることが望ましく、
CIに組み込んでリグレッションテストを自動化するなどが有効かと思われます。
一方で後者の場合は、
プロジェクトのより早期のフェーズでのレビューを徹底することで
出戻りのリスクを最小化するといったシフトレフトアプローチがより求められてくるものと思われます。
このようにプロジェクトでどんな開発手法を導入するのかによっても求められるテストは異なるのです。
参考
Discussion