『テストの7つの原則』 〜 パート⑦ final 〜
はじめに
現在、アプリ開発者としてプロダクトの持続的な成長や
ユーザーへのコミットに寄与するためにも、
SDLC全体を見渡して開発をすること、
および、それにはテストに関する体系的な知識が必要だと考え、
それを効率良く学べるJSTQB Foundation Levelの資格試験の勉強をしていました。
この記事ではそこでの学びをアウトプットしたと思います。
今回はその中でも「テストの7つの原則」の一部について
記事にしたいと思います。
なお今回は集大成として
欠陥ゼロの落とし穴
こちらの原則について記事にしてみようと思います。
欠陥ゼロの落とし穴とは
前提を疑う
まずはこちらの絵を見てください。
(出典:https://share.google/A3Zt3rxJNuMnn7TZM)
この絵が指し示すのはユーザーすらも本当に欲しいものが何なのか、それが分かっていないような状況はありえる、ということです。
いや、それが実は大半かもしれませんが、往々にしてこの絵が指し示すような結末は起こり得る、ということです。
それを上手く汲み取れずにミスコミュニケーションを続けてしまうと、開発は失敗に終わってしまうのでしょう。
しかも恐ろしいことに、まるでお笑い芸人のアンジャッシュさんのズレ漫才が如く、互いがミスコミュニケーションに気付かずにいることでそのズレもどんどん大きくなり、取り返しのつかない事態に陥ってしまうのでしょうね。。。
故に要求分析・要件定義といったいわゆる上流と呼ばれる開発フェーズにおいては、このズレの要因を念頭においてゴールやスコープを明確に定める必要があると思われます。
それは時としてユーザーが言っていることすらも疑う、ということです。
言葉に出来ていないものを掴んでユーザーが本当に欲しかったものを作る必要がある、ということです。
そのためにもそもそも論に立ち返ったり、『なぜ？』と繰り返しの問答をしてみたり、思考のフレームワークを駆使しつつもクリティカルに考え続けることで、
実は大掛かりな開発をせずとも簡単に実現できる代替案があった、
といったような展開も引き寄せることもできるからです。
そしてこのズレに早期に気付いて解消するためにも、要件分析や要件定義の段階で繰り返しレビューを行う必要があると思われます。
これは早期テストの原則に則るということであり、ウォーターフォールかアジャイルかを問わず、否、アジャイルなら尚更それを活かして早期テストのサイクルを回していく必要があると思われます。
ウォーターフォールは言わずもがなですが、アジャイルだからといって、否、アジャイルだからこそ開発がデスマーチにならないためにも、このフェーズをいい加減にせずに何度もレビューをしなければならないのでしょう。。。
それをしなかったらいくらクリーンな設計をしてクリーンなコードを書いても、テストで品質を保証しようとも、To Beからはズレてしまっているので手戻りやデグレが何度も発生してしまい、プロダクトはリリース出来ず、例え出来たとしても欠陥だらけであり、泣きっ面に蜂な開発チームを一層疲弊させてしまうのでしょうね。。。
プロダクトリスクやプロジェクトリスクを過小評価しないで、リスクの分析とコントロールをしないといけない、ということかと思われます。
別の手法を用いる
要求分析・要件定義をしっかり行っても上手く行かないこともあります。
たとえば実施するテストスイートをまとめた資料があったとして、それをなぞるようにテストを実行したとしましょう。
振る舞いテスト駆動開発風に『Given』『When』『Then』形式で書かれているとしましょう。
仮に個々のテストケース自体は同期していたとしても、それがMECEであるとは限りません。
そのテストケースに書かれている『Given』や『When』とは違うことをした場合、想定された『Then』とは異なる結果になるかも知れません。
テスト担当者がいつも同じであれば尚の事で、テストケースにある通りにテスト実行をしてしまうことで、欠陥を見過ごすこともあるのです。。。
開発者がテストもやっている場合はより一層この危険が付き纏います。
故に今までとは違うテスト技法を用いる必要にあります。
上記の例で言えば探索的テストやエラー推測などの経験ベースのテスト技法も駆使することで品質を保証していく必要にあるかと思われます。
productに対してどんなテストが足りていないかは『テストの四象限』を用いることで分析も出来るので、まずはproductやチームが置かれた状況を分析して、包括的なテストを実施しなければならないかと思われます。
欠陥ゼロ≠いい感じのアプリ
上記で列挙したことを回避したとしても、それで問題が解消されたかというとそうとは限らりません。
テストが機能テストに偏っていたり、いわゆる上流フェーズで非機能要件を定められていない場合、本当の意味でユーザーが実現したかったことを実現出来ていないかも知れません。
欠陥こそないかも知れませんが使い勝手が悪くてレスポンスが遅く、セキュリティホールだらけと言った具合のアプリを求める人もいないからです。。。
上記に同じく、これもまたしっかりと要件を定めること、そのレビューを繰り返してMECEにすること、それを満たすような非機能テストを行なったり、または外部の専門家に依頼すること。
こう言ったことの積み重ねにより良いproductができ、プロジェクトも上手く行き、ユーザーにもより良く価値をコミットすることが出来るのだと思われます。
参考
Discussion