読者です 読者をやめる 読者になる 読者になる

>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

しんすく流 テスト戦略策定手法 v1.0.2

思いがけずソフトウェアテストという技術に触れてからはや10年が経ちました。あーでもない、こーでもない、と試行錯誤を繰り返しながらようやく自分なりのテスト戦略、ある製品のテストすべてを「任せた!」と言われた時に僕ならこうする、という型が出来てきましたので、まとめたいと思います。

いちばん大事にしているのは、品質定義とその水準の共有とテスト設計までのトレーサビリティです。

長いわりにオムニバスでは読めない形式となっておりますので、またどこか別の形にまとめ直したいと考えています。文章にできるところを全部書くとこんな感じ、というもはや自分用メモです。万が一読破した方が居られましたら是非 @snsk まで「読んだよこのやろう」と飛ばして下さい。謝ります。

お品書き

  1. 任意の品質モデルを選択して、対象製品にとっての特性に「言い換え」る
    • 「PQM:プラクティカルクオリティモデル」の作成
  2. 「言い換え」た特性の優先度、及びどんなメタ水準を達成すればよいか考える
  3. そのメタ水準を満たすことを確認するためにどんなテストが必要かを考える
  4. 優先度に沿って網羅基準と設計方式と自動化方針を考える
  5. 設計、実装、自動化、自動実行 or 手動実行の計画を考える
  6. やる

1.任意の品質モデルを選択して、対象製品にとっての特性に「言い換え」る - 「PQM:プラクティカルクオリティモデル」の作成

「品質」が一意に定義できないのはご存知の通りなので、とっかかりとしていくつか既に存在する「品質モデル」や「テスト観点」の中から一番対象の製品にフィットしそうなものを選択します。迷ったら ISO9126 でOKです。また、別の選択肢として、GQM等を用いて組織、現場自ら定義する方法もあります。

言い換える

「品質モデル」を選んだ場合は直接言い換えることが可能ですが、「テスト観点」を選んだ場合はその観点がどんな品質特性に向けたものなのかを一度咀嚼してから言い換える必要があります。また、9126は非機能要件に対するモデルなので、機能要件に対するテストは別途定義する必要があります。その点FURPSはFEATURE SETとして個別に定義されているのでわかりやすいですね。また、この時ひとつの特性に対して複数の言い換えがありうる事に注意しましょう。例えば「資源効率性」を言い換えるとき、メモリ使用量なのかCPU効率なのか、はたまた非揮発性メモリの使用量なのか、さらにはこれら全てを包括する概念として利用するのか、は選択次第です。

この時のポイントは「全部やらない」ことです。もちろんリソースが潤沢にあるプロジェクトなら当該モデルで定義されている特性全てについて次以降のプロセスを充てることもできるかも知れませんが、水準の設定やテスト設計や実装が想定できない場合もあります。

たとえば、ISO-9126ではすべての主特性の子に「標準適合性」がありますが、いま相手にしている製品に、「効率性」の標準適合性(業界標準、規約、法律等)があるでしょうか?モデルはモデルなので、合わないと感じたら切り捨ててOKです。最初は勇気がいると思いますが、この先が出来ない、と感じたらそれを正直に書いて「やらない」事を選択しましょう。この選択を共有できていれば、どこかのだれかが発明した水準やテスト設計技術によりカバーされることがあります。進めなくなってしまうことが最悪なので、思い切って削りましょう。なれないうちは3個〜5個だけでも考えただけ充分です。

これを「PQM:プラクティカルクオリティモデル」の作成と呼称することにします。既存のクオリティモデルをベースに特性の取捨選択を行いながら、実製品におけるモデルに「言い換え」ながら変換していく作業です。

2.「言い換え」た特性の優先度、及びどんなメタ水準を達成すればよいか考える

一般的な開発モデルではコストと期限は一定ですので、選んだ特性の中でも優先度を設定する必要があります。対象の製品についてモデル化された各種品質特性の中でいちばん大事だと思うものは何か?ビジネスモデル、競合製品、自社の強み等々を鑑みながら、ステークホルダー一同と合意することが重要です。ここは本当に調整力が必要なのでプロジェクトマネージャと一緒に行うことを奨めます。彼らにとっても自分たちの成果物が果たして成功したのか失敗したのか、明確にわかる基準作りになるので喜んで協力してくれるはずです。また、ここで設定するのは「メタ水準」までです。前節で作成したプロダクトクオリティモデルの要素ひとつひとつが、具体的にどんなことを満たせば”可”となるのか?を抽象的に表現します。

ただ、「言い換え」や「メタ水準の設定」自体を任せるのは酷ですので、たたき台ぐらいは作っていってあげて、そこから議論すると経験上スムーズに進みます。自社開発の継続プロジェクトに対して13個ぐらいの特性と水準の設定、及びその合意でだいたい3日間ぐらいかかります。根詰めれば2日ぐらいでしょうか。もちろんステークホルダーが拡がるほど時間が掛かります。しかし、これ以上重要な箇所はないと断言できるぐらい大事なプロセスですので充分に時間を掛けましょう。

3.そのメタ水準を満たすことを確認するためにどんなテストが必要かを考える

テストエンジニアのみなさん、おまたせしました。ここから大活躍です。何が、どれぐらい満たされていれば「良い」かが前節までで既に判明していますので、それをエレガントに検証する仕組みを考えます。

「何が」を「網羅」する

この節に丸投げされた課題がこれです。狭義のソフトウェアテストは出来るだけ手数を少なく「網羅」することが技術です。そのためには対象の「何が」の領域から説明可能な括りを以ってテストを仕掛ける範囲を限定する必要があります。

「テスト」と聞いてまっさきにその対象として浮かぶのは「機能」かと思われます。機能が想定通りに動作すること、を「良い」とした場合、どこまでが「機能」で誰の「想定」なのかを慎重に詰めていくフェーズになります。例えばスマートフォンのメールアプリケーションであれば、「日本語入力」自体はOS自体の「機能」として用意されているものですから、ここを敢えてテストする必要はありません。しかし、入力の対象となるコンポーネントがそれを受け付けていなければメールアプリケーションとしての価値の根幹を揺るがす事態となってしまいます。さらに、インストール直後に起動する場合もあれば、他のアプリケーションとの連携で起動する場合、想定している文字数に達したままサスペンドから復帰した場合、等々つらつら考えていくとあるひとつの「機能」に対して「環境」という網羅基準が出来上がりました。

もうひとつぐらい考えてみましょう。選んだ特性に「時間効率性」があり、それぞれ「通信速度」「UI遷移速度」などを挙げたとします。「通信速度」を「何が」とおくと「網羅」はまず「送信」「受信」に分かれ「送信」の環境として、プレーンテキスト、マルチパート種別、弱電界時、SMTP/IMAPトランザクションエラー時の復帰速度、等々が挙げられます。「UI遷移速度」はそもそもUI遷移を全て洗い出す事自体が難しい場合がありますが、その場合はここでは「UI遷移」という「何が」のみを定義して、「網羅」をテスト技法が担保してくれる基準に任せてしまうのもアリです。

これを前節で言い換えた特性ひとつひとつに繰り返していきます。しかし、まだここでテストを「実装」してはいけません。寸止めです。こういう観点で、ここを網羅しよう!と決められれば(もっと良いのはそれをステークホルダーにレビューしてもらえれば)この節はゴールです。

4.優先度に沿って網羅基準と設計方式と自動化方針を考える

なんと、この節でもテストの「実装」は行いません。ウズウズしてると思いますがもう少しの辛抱です。ここでは、前節までで設定できた網羅基準に従ってテスト設計の方式を考えます。よく聞くテスト技法が登場するのはここからです。

前節で先送りにしたメールアプリケーションの「UI遷移」を考えてみましょう。メールアプリケーションは「UI遷移」の網羅が難しい代表的なアプリケーションです。ちょっと想像してみましょう。起動して最初の画面からいったいいくつ選択肢があるでしょう。そこからメール受信の画面に遷移し、メールをひらく、返信する、転送する、添付ファイルをみる、お気に入りに保存する、振り分けする、振り分けされたメールのみを表示する… これが交互に遷移可能と考えると普通の人間の頭には入りきれませんので、前述の「テスト技法が担保してくれる基準」に頼ることにします。「よし!ある画面とある画面の2画面をちゃんと行き来出来れば良いことにしよう」と決められればペアワイズが使えます。「"画面"、ではなく"行いたいこと"に基準を置いてそれが出来れば良いことにしよう」と決断できればユースケーステストが使えます。

こうして設計方式が固まったら次に、遠い昔に策定したはずの「優先度」を引っ張りだしてこれらの設計方式に与えるパラメータとします。大抵のテスト技法には「それどこまでやりますか?」的な"厚み"のパラメータを与えることができます。例えば同値分割におけるクラシフィケーションの粒度もこの"厚み"の決定に他なりません。どの特性を"どこまで"やるか、その厚みの決定に優先度を利用します。

それ、自動化できませんか?

「なるほど。優先度の高いものを"厚く"するのだな」と考えた方、正しいです。正しいのですが、"厚み"="コスト"と考えるのは早計です。設計方式を考えたら次にそれが自動でテストできないかを考えましょう。「なるほど。自動化できればコストはゼロと考えられるわけだ」と考えた方、間違いです。自動化で軽減できるコストは「2回目以降の"実行"」のみです。もっと正確にいうと"チェック"のみです。あらゆる抽象表現や空気を理解できる人間様による"実行"とキカイによる"チェック"ではその質に天と地ほどの差があります。…あるのですが、あるのですが、ここまでしっかり考えられたテストであればあとは期待結果との差を"チェック"するだけ、という実装になるテストケースも相当数あることでしょう。人間様によって充分に考えられた"テスト"を"チェック"にまで落とし込めれば、かつ長期間に渡ってお客様に価値を提供し続ける予定である製品であればあるほど"チェック"を自動化した際の費用対効果は跳ね上がります。

自動化?自動実行?
「自動化」と「自動実行」は「テスティング」と「テスト」ぐらい違います。つまり、「自動化」はテストを自動化するために考えるべき全ての検討、開発及びその実行を含み、「自動実行」は「自動化」された上での実行の様子のみを指します。


充分考えて"チェック"にまで落とし込めたか?答えがYESなら自動化しない手はないです。この節で一緒に考えておきましょう。

5.設計、実装、自動化、自動実行 or 手動実行の計画を考える

ここまでで、「何を」「どれぐらい」「どうやって」「あわよくば自動化」が揃いました。もうほとんど勝ったも同然です。あとひと頑張り、プロジェクトの状況にあわせて具体的な計画に落として行きましょう。ここでの注意点は設計と自動化のコストを見誤ることです。何も考えていないテストの計画は

「んー。この機能のテストがだいたい1000個ぐらいになりそうだから(根拠なし)、作るのに10日(根拠なし)、1人1日100個実行できるとして(根拠なし)、20日!(ぐだぐだ)」

となりがちですが、テストの設計に掛かるコストはコードのそれと同じく、実際に設計するテストエンジニアにしかわかりません。逆に設計まで終えればそれによってテストケースがどれぐらいになりそうという数字はかなり正確に出ますので、実装が手作業であれば見積りも割と正しく出せることでしょう。

自動化に掛かるコストは”要求がかなり具体的に判明しているシステムアーキテクチャ設計とその実装”とほぼ同じぐらいと考えて頂ければ外れません。設計と同じく、アーキテクトに聞かないとわかりません。なお、前節で少し触れた自動化に掛かる主なコストは以下のとおりです。

  • 自動化の前に掛かるコスト
  • 自動化の後に掛かるコスト
    • システムの保守(特に適応保守)
    • 投入データのメンテナンス

6.やる

おめでとうございます。ここまで来てようやく「わかりやすい」生産活動が行えます。計画やプロセスフローに沿ってテストを仕上げて行きましょう。しっかり考えられたテストとその実行結果は、テスト対象の成果物を「知って」もらうために、どんなステークホルダーに対しても充分な説得力を持っていますので、プロセスを進める過程で生まれた中間成果物はちゃんと管理しておくことをおすすめします。

テスト計画を実際に落としていくなかで遭遇するトラブルとしては以下のような変化があります。

仕様変更

一気通貫型の開発プロセスにおいては大打撃となりますが、近年はこれを最初から想定するプロセスが主流です。では、テストプロセスにおいてはどのように対応すればよいのでしょうか。ここまでみなさんは順を追って「何を」「どれぐらい」「どうやって」「あわよくば自動化」を考えてきたはずです。仕様変更であれば大抵「何を」の変更になるはずですが、残りの3つは他の特性から流用することができるかもです。正直なところ、アジャイル開発プロセスにどのように上層のテストをフィッティングさせていくかはまだ議論の途中ではありますが、どのようなプロセスであれ先に挙げた4つのポイントが変わることはありませんので、これを如何に軽量化するかを考えてみて頂けると、よろしければ一緒に考えて頂ければ幸いです。

開発遅延

自動化領域を広げるチャンスです。手動でやろうと決めたテストをなんとか"チェック"に落とし込めないか、再検討してみましょう。開発が遅れることでテストの実行時間を縮められるのはチームにとって計り知れない貢献となるはずです。楽しいですね。

おわりに

お疲れ様でした。まさか全部読まれました?まじですか。僕の代わりに仕事してくれませんか。とにかくいちど書き上げないことには、ブログ開くたびに「書きかけかよ」と自分に責められてたのをようやく脱しました。少し日をおいてちょこちょこ過不足を補いたいと思いますので、たまに覗いてみて頂ければ幸いです。…会って聞いたほうがはやいっす。

あとはこれらの過程を具体的に実行するための補助となる表現やツールの整備ですねー。品質特性を分解する表はあるので、いずれ公開したいと思います。

ご指摘と改版履歴