はじめに

テスト業務を遂行していく中で、「ここ、こうだったらいいのにな〜」とか「もうちょっと、こうなればいいのに」思うことがあります。

特に、テスト計画・テスト設計といったテストプロセスにおいて、僕自身(QAエンジニア8年目)テスト業務に従事していく中で、いくつか困っている事があります。

僕のQiitaの初投稿は、その困りごとを何か新しい方法で解決できないか？その可能性についての概要を、書いていきます。
※技術的なことについては、後日書いていきます。

テスト業務で「困っている事」

1. 書式がバラバラっ！

各プロジェクト・各部署・各会社さんによって、テスト計画書やテスト設計書の書式がバラバラになっていることが多く、それぞれに書き分けなければいけないケースがあります。

テンプレートを用意されて(もしくは、自前で用意する)も、そのルールを覚えて書き分けるのに「Aというプロジェクトのときは、こう」「Bという部署では、この書き方は禁止」「会社Cさんでは、〇〇文字以内でフォントは〇〇で手順は簡潔に…」などによって、一見効率的に見えそうで、実はかえって時間がかかってしまう。

自前で用意したテンプレートがそのテスト業務に合わないために作り直したり、逆に使われなくなったり、なんてこともあります。

2. 仕様書がないっ！

これは、すべてのテスト従事者にとって一番困ること(開発者の方にとっても)であるのでは、と(笑)。

アジャイル開発の弊害とでも言いましょうか、アジャイルソフトウェア開発宣言による「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、」の部分の解釈を、「そうか、ドキュメントは作らなくていいんだっ！」と解釈してしまい、なんでもMTGやコミュニケーションツールで済まそうとする流れがあります。(こちらは、個人的に経験してきた中で思うことです。)

そのため、明示的に機能を定義したドキュメント(仕様書)が作成されず、5W1Hに落とし込んだり、テスト技法を用いて情報をまとめてテスト計画書やテスト設計書が作りづらくなる傾向にあること。

また、「言った言わない問題」「会話のログ収集」「裏取り(会話ログや他の人の話などを調査して、相手の話の裏を取る)」といった問題や、その実行にかかる時間が増えて、テスト業務に必要なドキュメント作成に時間がかかる、ということもあります。

3. 伝わらないっ！

最近では、開発側とテスト側で作成したドキュメントの内容に対する「バトル」は減ったのかなと感じます。これは、開発側の知識(使用しているプログラミング言語や構造、アルゴリズムなどなど)と、テスト側の知識(使用しているテスト技法、用語、テストプロセスなどなど)をお互いに認識し合う・勉強会などで知ることにより、解決しているものだと感じます。

問題なのは、「上位の方々」といった経営陣に対して開発したシステムやソフトウェアの説明です。

ITに関わる知識をある程度持っていれば良いのですが、無かった場合の説明が難しい。

開発したシステムやソフトウェアを「定量的に示す、定性的に示す」際にも、使う用語に気をつけなければいけなかったり、説明したとしても「では、その説明で何が言いたいの？」の突っ込まれたり、相手が相槌を打ってくれても後で「ここって、どうだったんだっけ？」と再度説明しなければならなかったり。

別に、説明自体が嫌ではないのですが、理解してもらえるために準備がどれくらい必要なのか、また時間がどれくらいかかるのか、といった所が悩ましいところです。

※この問題は、特にPM・PdMの方が悩んでいることなのかな？と思いました。

1日でも早く、システムの品質を高めてリリースするために「生産性、効率性、品質保証の向上」目指して、頑張って改善策を策定し提言して実行しても、なかなか効果が出てこない、かえって時間がかかってしまい、最悪リリースが遅くなってしまい、時間・お金・人のコストが高くなることが、扱う領域によっても異なりますが、間々あります。

何か、良い方法は無いか？

長々と前置きが長くなりましたが、僕自身QAエンジニアとして従事している中で困っている事の多くが、この3つなのではと考えています。私と同じように、テスト業務に関わっている方が共感してくれたら幸いです。

では、本題として「その困り事を解消する、何か良い方法はあるの？」というところを述べたいと思います。

それが、「TM技術を使った、MBT(モデルベースドテスト)」です。

TM技術って、何？

参考: 事業分析・データ設計のためのモデル作成技術入門

この書籍でかかれている、「T字型ER図」を使い開発するシステムやソフトウェアを「一枚絵」にして、そこからテスト計画やテスト設計を導出出来ないか？と考えています。

こちらの本を手にして読んだときに、「これだっ！」と稲妻が走ったのを覚えています。

内容としては、事業のプロセスを「モデル」というものに置き換え関連性を記述し、その関連性から分析をしていくというもの。

困り事のそもそもの原因は、「ドキュメントを書くときに、読み手を限定・もしくは想定して書いていたことにあるのではないだろうか？」ということを思いつきました。

なら「誰が見てもわかるような、そして説明できるような、そんなものを書けたらなぁ」と考え、事業分析・データ設計のためのモデル作成技術入門に出会い、読みました。

この技術とテスト技術を掛け合わせれば、解決できそうで、何か面白いことが出来そうだと考えています。

ベースとなっているのが、数学の「集合論」や「記号論理学」といった「数学基礎論」をベースにしているので、バックグラウンドとしても確度が高いものである思いました。

なので、この書籍以外の数学の参考書などを日々読み漁って勉強してる毎日です(笑)

MBT(モデルベースドテスト)って何？

参考: モデルベースドテスト(JaSST'07)

TM技術を取り入れようとした、もう一つのきっかけが上のリンクにあるテスト技法です。

日々のテスト業務の中で、既に取り入れてはいて(状態遷移図や直行表、デシジョンテーブルなど)、特にこれからのテスト設計ではこの手法をメインにして、出来ないかと考えています。

また、ノーコードで開発できるようになっている昨今では、その「ノーコード」の部分を「テスト業務」に適用できるのではないか？とも考えています。

ここから更に発展して、テスト自動化に繋げる手立てとしてとても参考になれるものであるとも考えています。

まとめ

今回は技術的な部分は、書けなかったのですが、これからのテスト業務の改善に必要な技術であると考えています。

なので、掲載した書籍や技法・他の書籍を読んで
学習したこと、また現場で技術的にどのように適用できそうかを、これからの記事で書いて行こうと思います。

※2週に1回は、記事を書けるように頑張ります！

ここまで読んでいただき、ありがとうございます。

では、また。