どしろうと製作所:WebLogどしろうと製作所:WebLogどしろうと製作所のBlogバージョンです。「どしろうと製作所」のHPの記載内容とはあまり関係無いです。気が向いたときのみ更新します。みずの以前紹介した「テストカタマリー」と呼ぶ謎の記法を活用したテスト設計を行うためのプロセス案を紹介します。前回は機能に対応するテストの検討を紹介しましたが、今回は機能以外のテストに対しての検討を紹介します。注:こちらのシリーズは以前のテストカタマリーの記事を読んでいることを前提としており、テストカタマリー自体の説明は本シリーズでは省略します。記事のまとめはこちら。今回はちょっと長めです。■「機能」だけに着目したテストでは...テストベースに記述の内容が「機能」項目が中心であったとしても、機能だけに着目してテストを実施してしまっては当然問題が発生する可能性があるでしょう。性能面での検討が不足している場合や、連続稼働を行った際に不具合が出てしまうといった場合が想定されます。このように、前回紹介した「機能」だけに着目したテストは必要な検討ですが、それだけでは不十分な場合も多く、機能以外に対しての検討も行う必要があります。「カラオケシステム」のテストベースでは次のような記述が確認されます。・(ねらい)今後利用可能なハードウェアの追加を考慮すること・(気がかり)前機種で演奏やり直しや中止時にノイズの影響がみられる・(機能外要求)前回のモデルを全ての性能で上回ること...などなどなお、カラオケシステムにおけるテストベースから抜き出した項目は以下にまとめましたので参考に提示しておきます。テストを行う際には、少なくともこれらの確認を行う必要があるでしょう。実際にはテストベースに記載されていない項目や、複数の文書に散らばっている場合も多いため、ステークホルダから直接確認することや、複数の資料から抜き出したりする必要が発生します。機能外要求や気がかりを減らすなどの品質面で確認したいことを仮に「品質要素(仮)」とでも呼んでおきます。これらは、先ほどテストベースから抽出したような「ノイズの影響がないこと」や「性能を上回ること」というような内容が含まれるはずです。「これをテストしなければいけない!」という項目となります。上記の「性能を上回ること」のような表現では具体的に何をテストすべきか?はわかりづらいです。ここで、品質面で確認したいことを実際にテストできるような概念やキーワードに対して、階層構造や関連の整理をすることで、テストがやりやすく品質で確認すべき基準も明確にする...ということはできないでしょうか。->操作レスポンス」のような内容となります。こちらの表現であれば、テストすべき内容が見えてきます。カラオケシステムの全体に対してこれらの項目を整理した例を以下の図で示します。こちらの分類結果につきましては、仮に「ブンルイー」図とでもしておきましょう^^こちらの整理においては、上位に品質特性を設定する整理方法が「好み」ですのでそうしております。実際には、組織標準の整理方法や、ステークホルダが分かりやすい整理をするのがよりよいでしょう。■品質要素(仮)のテストカタマリーへの割り当て導出されたブンルイー上の品質要素(仮)項目ですが、これらは何処かでテストを実施して確認を行う必要があります。※「これをテストしないといけない!」という項目ですので...今回シリーズで紹介しているプロセスでは、既に機能に対しての整理を行っておりました。(前回の記事参照)ブンルイー内の品質要素(仮)の中には、とある機能に着目して確認すると効果的なものが存在します。「予約をする」や「検索をする」といったユーザインタフェースが関係しそうなものであれば「異常値->入力値異常」や「性能効率性->操作レスポンス」などが関連しそうです。ここで、機能に対して整理したテストカタマリーに対して、品質要素(仮)を割り当てることで「ここでこの確認を行わないといけない」ことを明確化することができます。上記図の表現を活用することで、テスト要求の全体像を確認しながら「ここでXXの品質を確保しよう」という議論やレビューでの抜けを確認することがやりやすくなると考えております。UMLモデリングツールのastah*を用いることで、こちらのブンルイーの内容を管理しながらテストカタマリーへの割り当てを俯瞰するようなこともできますのでお勧めです。■カラオケシステムにおけるテスト要求の全体像カラオケシステムのテストベースに対して、テスト要求の全体像を整理した結果を例の1つとして示します。上記のカラオケシステムにおけるテスト要求では、機能と同時に確認できる品質要素(仮)項目を割り当てた上で、機能と確認しきれなかった要素を個別にテストカタマリーとして定義しています。上記のカラオケシステムの検討結果に対しては、「テスト要求パターン(リンク)」の概念も活用しておりますので、興味のある方はリンク先の内容も確認ください。上記の検討結果以外に「リスク」と想定されるものや「過去の不具合」から確認すべきものがありましたら追加しても良いでしょう。(今回の例では、テストベースに対応している部分だけまとめています)結果として、今回は単純に「機能」と「機能外要求」の要素でシンプルに分割した表現となっております。実際には組織で良く使用され多くの人が理解しやすいような分割方法や、今後の拡張性などを考慮した表現があるはずですので、より「しっくり」来る整理を考えてみると良いでしょう。■実際の検討例(共創プロセス)今回の検討は、ステークホルダとの調整が無い条件でテストベースからすべてのテスト要求を導出しているわけですが、実際にはテストベースのみから検討を行うということは殆どありません。ステークホルダと直接インタビューを行いながら「気がかり」となる部分や必要となる品質要素(仮)の抜けを確認したり、合意を取りながら進めていくことでよりステークホルダ間で「納得感のある」テスト全体像を考えることができるとよりよいです。「テストで気になる部分」をステークホルダ間で共有しつつ、全員の気になる部分を付箋で提示しながら整理していくという方法もあります。(気になる人はVSTePの手順を確認して貰えると良いでしょう)この際、1つ1つの付箋にテストカタマリーとなりそうなものや、品質要素(仮)の対象となるものを出しながらモデルとして分類・整理していくこととなります。ステークホルダが集合して付箋を用いながら検討するこちらの方法は、実際には発注者・受注者の関係もありますので難しい場合も多いと思われます。その場で全員の気がかり事項を共有しつつ、テスト要求の全体像に対して合意を取ることができるため、実施することができると効果が出やすい方法です。こちらの方法は複数のステークホルダが共に集まって創る...というプロセスであるため、コッソリと「共創プロセス」と呼んでいる方法となります。このようなステークホルダが集まって検討する場合においては、前回紹介したテストベースから機能を整理する...という方法よりも、全員の気がかり事項がより共有できて、全員が納得できる整理方法を用いる方がより「納得感」が高まり、全体像に強い合意がなされることが多いです。合意がされた後に違和感を感じて修正することが難しくなるので注意です!■テスト要求のビューの変更テスト要求は上記で示したように「機能」と「機能外要求」でまとめてみましたが、この表現はステークホルダの興味に応じて変更しても良いでしょう。テスト実施時には順序を考慮しながら進めているはずです。・リスクの高いものは早めに確認を行う・単体機能⇒複数の機能組合せで確認をする・開発のイテレーションが異なるので、あとのタイミングでテストする...など、そのような「順序」を表現することもできます。上記の順序を表現したビューは、存在しているテストカタマリーは同じですが、テストを実施すべき順序を表現している内容となります。これらはテスト要求の全体像に対する「ビューの変更」という扱いをしております。このように、ビューを切り替えることでステークホルダの興味に応じた表現を行うことや、抜けを確認することに役立つと考えております。「ビュー」を用いながらテストカタマリーのリポジトリを育てていく手順は、テストの抜けを減らすことに有効だろうと考えております。以上でテストカタマリーの記法を用いてテスト要求の全体像を明確化する手順と一例についての説明は終了となります。この全体像については、表現方法は様々なものがありますので、各自で納得できる整理を行っていただければと思います。これ以降の作業のフィードバックを受けて全体像も順次成長していくものであると考えております。次回は、「予約をする」などの個々のテストカタマリーから具体的にテストケースを作ることができるよう詳細化する作業を紹介します。