テストにも単一責任の原則？

最近、技術教育の一環でテストエンジニアとプログラマに同一の課題を出して、プログラマにはテストコードとプログラムを、テストエンジニアには、テストケースを作成してもらっています。

すべてのコードとテストケースを私一人でレビューをしています。

その中で、テストケースに、確認事項が色々と記載されていることがたまに見受けられます。

一つのケースに対して、一つの確認内容というように、プログラミングの世界にある単一責任の原則が成立します。

例えば、一つのケースに対して、複数の項目を確認する内容になると、やはり判りにくく、どこがNGだったのかが判らなくなってしまいます。

プログラミングでも単一責任の原則が成り立つように、テストにも単一責任の原則が成り立つと最近感じます。

テストエンジニアにもモデリングは必要

今日、久しぶりに、プログラム経験の少ない人とテストエンジニアにテストの基礎的な内容の研修を行いました。

その中の説明の一つに情報（データ）がどのように流れていくかをしっかりと考えてテストケースを作成することの重要性を説明しました。

そのときに、テストケースを作成する上では、モデリングまでいかなくてもデータがどのように流れていくかを考える図などを描く能力は必要だなと思います。

それが、シーケンス図やオブジェクト図までいかなくてもそれらしいものは描く能力が必要であると思いました。

なぜ必要かというと、共通の図化したものがあれば、誰が見てもわかるので、共通の言語になるからです。

これらが、情報（データ）が色々なところで活用するようなシステムでは必要な納涼苦であると思います。

テストコードとテストエンジニア

以前から、テストエンジニアがテストコードを書けるようになったほうがいいとこのブログ上で書いてきました。

実際に、私がテストエンジニアが書いたテストケースを元に、テストコードにすべて登録した場合と、テストエンジニアがテスト実施を2R行った倍の時間を比較したところ、約3時間程度短縮することが実証されました。

ただし、これには注意しなくてはならないことがあります。それは、テストコードが正しく記述されているかを必ず検証する手間があること・テストケースの全体像を把握しておかないと、重複するようなケースが発生することがあります。

上記の改善案としては、かならず、テストコードが正しいかを検証すること・全体像をまずは把握してから実装することが必要になります。

本来のテスト駆動開発とは違う意味合いで使用していますが、非常に簡単にできるので広めていこうと思います。

それ以外にもこれを実施するためにはViewの処理が正しく行われているというのが前提なので、最初にViewの確認をしておかなければなりません。

メリットとしては、テストコードを登録しておくので、テスト時間が短縮される・開発者がデグレを引き起こしたときにすぐにわかることがあります。

テストケースでわかる思考の中

テストケースのレビューをしていると、大体その人がどのような思考でテストケースを作成しているのかがわかるようになってきます。

例えば、仕様を熟知していないや、テストケースを作成していて、頭が整理できていないなどは特によくわかります。

レビューをするときには、仕様を簡単に説明してもらい、自分の頭の中で、こういった確認内容やテストケースが必要であるというのを判断します。

そこから差異がある部分を確認して、説明をしてもらっていると、なんか矛盾するなということでヒアリングをします。

大体、このような手順を繰り返していると、どこが問題なのかが見えてきます。

マインドマップで一所懸命に思考を整理しようとしていてもメインブランチからブランチの作成が間違っているので、大体は整理できていなかったりします。

ついでにソースコードがある場合にそれを見ると、そのような箇所はソースレビューで引っかかるところになります。

思考を整理することや仕様を熟知をするのは非常に難しいことですが、それがあって初めてテストケースができることなので、重要にしていかなければならないところです。

エラー推測って重要だな

ソフトウェアのテストの書籍を読んでいたり、アーキテクチャの書籍を読んでいたりすると、ソフトウェアのテストではエラー推測、アーキテクチャ関連だとバグについてなどとよく書かれています。

技法と呼ぶ人もいれば、そうではないと賛否両論意見が分かれると思いますが、私はこれは重要であると考えます。

プログラムを作成する立場から考えると、今までの経験やノウハウを生かしながら、プログラミング作業をする。

テストエンジニアの立場から考えると、このあたりは怪しそうだなというようなやはり経験やノウハウが生かすことができます。

エラー推測の簡単な例としては、データが0個やなしといったものは非常にエラーが出やすいということがあります。

知っているか知らないかで質の向上といった面では大いに役に立つものだと思います。

ある意味私達の仕事は芸術家（職人）のようなものなので、経験やノウハウといったものが重要になってきます。

根本は同じ考え

現場の仕事がバリバリ進む ソフトウェアテスト手法 高橋 寿一,湯本 剛 技術評論社 このアイテムの詳細を見る

かなり前に、出版された本で、私も持っていましたが、しばらく人に貸していたので、すっかり内容を忘れていましたので、朝出社すると、始業開始時刻の前に読んでいます。

読み返していると、普段、テストエンジニアやマネージャとして行っていることは間違っていなかったなということがわかりました。また、広く色々なことが書かれているので、非常にためになります。

ただし、テストケース作成のところで、状態遷移テストの自動化など一部どのようにするのかが詳しく書かれているわけではないので、疑問に思うことはあります。

私の勝手な考えですが、高橋 寿一さんの考えは非常に私は好きな考えで、根本にあるのは高橋さんには失礼かもしれませんが、同じであると思いました。

テストエンジニアのあるべき姿

テストケースの作成指導や、自身でテストケースを作成している際に、同値分割や境界値分析を用いて、行います。

ここで、私なりの疑問があります。

それは、コレをテストエンジニアがテストケースに盛り込んでいきますが、本来これはプログラマがテストを行う時点で、確認がされているし、ここでバグが入っていることは少ないのではないかと思います。

プログラマのテストで漏れることもあるでしょうが、少ないと思います。

テストケースの作成の基本は少ない項目数でより多くのバグを発見することなので、テストエンジニアは、プログラマ以上に、処理を考えながら、処理の漏れや考慮不足をついたテストケースを作成するのがあるべき姿ではないかと思います。

では、なぜ、書籍などでこのようなことが記述されていないのかが疑問が残ります。

答えはわかりませんでした。

テストではアーキテクチャを理解することも必要

今日、ある製品のテストをしていると、レスポンスが非常に遅いのと、その製品の特徴をある程度把握していたので、ある操作をしたらエラーになりました。

そもそもこの製品の特徴として、すでにアーキテクチャの時点で機能追加などが非常に厳しくなってきたので、何かしら出るだろうなと思い、操作したら案の上エラーが出ました。

テストをする上で、製品の特徴をつかむだけ泣く、アーキテクチャ的な視点も必要になってくるなということが最近わかってきました。

ただし、プログラミングの知識も必要であるし、実際に自分がプログラミングをしてみて気がつくことがあるので、中々これは厳しいなと思います。

違和感がある

ソフトウェアテストにおいて、バグ数を、K/LOC当たりで何件程度というものを指標の一つとしているのが、どうしても私の中で違和感があります。

なぜなら、ソースコードの行数というのは、短く書けば可読性が悪くなる場合があるし、長く書けば、もう少し短くできるだろうと考えます。

つまり、ソースコードの行数というのは、長く書くことも短く書くこともできるということです。

一つ例をあげると、新人プログラマが作成するコードの行数と、ベテランのプログラマが作成するコードの行数というのは同じものを作成したときに、差というものがあります。

まあ指標の一つなので、たいしたことは無いのかもしれませんが、やはりコレを指標に加えるのは違和感があります。

HAYST法は難しい?

最近、HAYST法を勉強して非常に難しいなと思います。正直私の頭では理解できないのが正直な感想です。

線点図がでてきたり、色々な数式が登場してきて、実際にどうしたらいいのだろうかと思っています。

実際に自分で具体的な事例で試したり、色々なことを調べていないので、まったくわかりません。

ただ少し調べた結果によると、自分で試して見ないとわからないなと思います。

まだまだ始めたばかりでわからないことだらけですが、少しでもバグが減ればいいなと思います。