『テストの7つの原則』 〜 パート③ 〜
はじめに
現在、アプリ開発者としてプロダクトの持続的な成長や
ユーザーへのコミットに寄与するためにも、
SDLC全体を見渡して開発をすること、
および、それにはテストに関する体系的な知識が必要だと考え、
それを効率良く学べるJSTQB Foundation Levelの資格試験の勉強をしており、
そこでのインプットを記事にしたいと思います。
今回はその中でも「テストの7つの原則」の一部について
記事にしたいと思います。
なお今回は
早期テストで時間とコストを節約
こちらの原則について記事にしてみようと思います。
早期テストで時間とコストの節約とは
開発をしているとこんなシーンに遭遇することがあります。
『また出戻りだよ。。。』
『それ、聞いてないよ。。。』
『えっ、これが欲しいんじゃないの。。。』
『うわっ、リグレすごい。。。』
『デグレした、あちこちバグだらけ。。。』
『もー、ちゃんとしてよ。。。』
『もー、こんなん嫌や。。。』
etc...
こう言うのって付き物なのでしょうが、
やはり極力避けたいですよね😅
『何事も早め早めに』
『備えあれば憂いなし』
この考え方ってテストにおいても有効なのではないでしょうか。
シラバスではレビューも含めて[1]
『レビューもテスト(静的テスト)の一部』
として紹介されていますが、
要求分析・要件定義と言ったいわゆる上流フェーズからきちんとテストをしていれば、
防げた問題も有りそうよね🤔
あの時のきっちりかっちりみっちりなやり取りが、
結果としては後々の要らぬ苦労を無くすことができて、
ステークホルダーみんながwin-winになるので、
開発においては早い段階から様々なテストを入れておきたいところですね。。。
または、早めにレビューを受けておく、ないしはそれを行うことで、
みんなの認識の不一致を早めに見つけて修正を行うこともできるので、
結果としてより良い結果になりやすいと言ったこともあるかとは思います。
『ただとはいえ現実は...』
と言ったこともありますよね😅
多分このあたりのコントロール方法についてや、
コンテキスト特有の問題もあるかと思われますので、
それは別のメスの入れ方が求められているのかも知れません。。。
参照
-
ここでのレビューはコードレビュー以外にも要求分析、要件定義、ユーザーストーリー作成といったフェーズで作成される成果物に対するレビュー（これで本当にいいんだっけ？）や、仕様書に対するレビュー、設計に対するレビュー、テストに対するレビューなどの様々な意味を持ちます。 ↩︎
Discussion