mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

私の思うQAの全体像 ver.2

前作:私の思うQAの全体像 - mhlyc -practice

いただいたアドバイスをもとに見直しました

 

計画する

なにはともあれ計画をします。

理由は、あらかじめ計画を立ててその通りにやることで安心したいからです。

計画のインプット

計画のインプットにはなにがあるでしょうか。思いつくものを挙げてみます。

  • お客さんが「この日までに納品してよ」と言った締め切り(納期)
  • 上の人が「うちの予算はこれでやるから」と言って決めた予算額
  • 受注するよって言った時点で「少なくともこれはやるよね」ってお客さんと合意した要件
  • 試したい新技術とか施策とか。開発フレームワークとか開発環境を含むことも。RubyでやるとかJavaで作るとか
  • 「検索したら待てるのはせいぜい5秒くらい」「ログインして同時に使える人数は50人くらい」とかいう非機能的な要件

計画通り作ることの難しさ

決まってるものがあるからそれを間違いなく達成するものを作ればいい話なんですけど、世の中システム開発にはリスクがつきものです。

  • 採用しようとした技術じゃ実現できなかった
  • 技術力が足りなくて作るのに時間がかかる
  • 思ったよりバグが多い
  • 要件全部出したかなぁと思ってたけどすげぇ大事なのが漏れてた

こういうことに後から気づいた場合、遅ければ遅いほど致命的なダメージになります。

  • 技術力のある人をアサインしたいけどオファーが急すぎて誰も来てくれない
  • 要件を実現できない開発フレームワークで8割くらいもう作っちゃってて、まるごと捨てて作り直すはめになる
  • 設計書作る時点でレビューしてれば気づくようなことを、そのまま実装しちゃってテストで気づく。コードに手を入れるので影響範囲の調査や再テストの工数がかさむ

こうなると品質もなにもあったもんではないし炎上間違いなしなので、こうならないように色々策を考えます。

  • コアメンバーとなるエンジニアには早めに声をかけよう
  • 技術力の足りないメンバーには勉強会やセミナーに参加してもらってスキルを向上させよう
  • 設計工程でレビューして出せる指摘はなるべく早めに出そう
  • 要件は、モック作って持ってったりして都度お客さんに確認しよう

要するに先々起きそうな問題を事前に察知して対策しておこうということです。そういう意味で類似のプロジェクトでの取り組みとか過去の障害事例は参考にします。

計画通り作っていることの確認

計画通り作っていることの確認はべつに誰がやってもできます。計画に書いてることを書いてる時期にやってればそれでいいし、放置されてたら「放置されてるよ」といえばいいだけなので。タスク管理してシステムにアラート送らせるしくみにして自動化してもいいと思います。

技術的な問題への対処

とはいえ、機械的に解決できない問題もあります。技術的に解決できそうだけど、調査しないとわからないとか、そもそもその技術を選ぶことでどんな問題が発生しそうかわからないなど。

そういったところにはQAが関与して、選ぶ技術と選んだ結果が作り方にどう影響するか、テストは増えるとか減るとか、実現したい要件は実現できるのかなどを開発と議論します。例えばAWSを採用するのと自前でサーバ立てるのでは技術的な保証の範囲も変わってくるでしょう。

実際に作ってるものの品質が大丈夫か

ここまでは主にプロセスの話をしてきましたが、もちろん作ったものそのものを見る必要もあります。いくら決めた計画の通りに作っていても、ダメダメなものが出来上がっていることはあり得るので。

ウォーターフォール型開発ではテストレベルごとにプロダクトが品質レベルに達しているかどうかを確認していきますが、そもそもここでいうテストレベルというのは「製品の結合度合い」とか「管理上の都合」で分けられています。

結合度合いのレベルについては、モジュール単体でテストするとき、モジュール間の呼び出し関係が出来上がって組み合わさってからのテスト、システム基盤にアプリを載せた段階でのテスト、システムとして全体を組み上げた段階でのテストなどが挙げられます。

管理上の都合というのは、例えば開発チームでシステムテストをするのと顧客による受け入れテストをするのでは、統合度合いとしては同じですが目的が異なりますし、管理上分けた方が都合が良いです。第三者検証に委託したあとに再度同じテストレベルでテストするということもあるかもしれません。

JSTQB的にはシステムの統合度合いで分けたものをテストレベル、管理上の都合で分けたものをテストフェーズと呼んでいるようです。

 

話は戻りまして

テストレベル(場合によってはテストフェーズ)ごとに確認したいことを明確にしながらテストしていくのがよいと私は思っています。

テストレベルの定義を行う際にはもちろんテストレベルごとに確認すべきテストの観点をまとめます。例えばシステムテストの段階ではモジュール間のインタフェースはすでに保証されたものとして、システム全体が統合されて初めて顕在化するような不良を見つけたいということになります。テストレベルごとにテストしたいことを明確にすることで、行なっているテストや摘出している不良が目的に沿っているか確認できるようになりますし、是正の判断基準にすることもできます。

プロセスとプロダクトの確認で品質は保証できるのか? 〜企画の重要性〜

正しいプロセスで正しいプロダクトを作っていれば、品質は保証できるように思えます。 

ただ、ここで品質をどう捉えるかという話があります。

結局、これまで話した内容は計画ありきのものであって、そもそも企画がダメでしたとか、要件から漏れてましたみたいなことがあったら丸ごとダメになってしまいます。

例えば「バグのないつまらないゲーム」とか、「半年前にリリースしてたら流行ったかもしれないアプリ」とかです。

なので少なくともQAは市場のニーズやその予想、また他社プロダクトに対する優位性がどこにあるかわかっておく必要があります。

QAはUXや企画を考えるところからも参画すべきです。なぜなら価値のあるユーザ体験を考えることは保証したい品質が何なのか考えることと同義だからです。

カスタマージャーニーマップを作ってみたり、企画のブレスト、想定ユーザのコンテキスト分析、試しにちょっと作ってみる、ユーザテストをするなど、企画をブラッシュアップするための取り組みは多くあります。(もっとも、ここから関与できるQAは珍しいかもしれませんが)

企画の段階から良いものを作っていなければそのあとどんなに素晴らしいテストをしても振り出しに戻ることになります。

まとめ

QAの役割は以下の通りです。

  • 先々のことを先読みして、良い感じの計画を立てる(適宜見直す)
  • 計画に沿って開発しているかチェックする
  • 開発してできた成果物の品質を測る
  • 企画そのものがイケてるかどうか判断する。イケてないならイケてる企画を検討する手伝いをする

ご意見・ご感想お待ちしております。