知識ゼロから学ぶソフトウェアテストを読んでみた

継続的デリバリーを読んでいて、各フェーズのテスト方法とその内容を理解しつつも、テストに関して少し掘り下げたいなと思い、テスト技法に関する書籍を探した。

そもそも自分は、社会人になりたての頃に研修で学び、そこから適宜学習していったが、積極的に学んだ、といえるほどではない。それを踏まえ、再学習を目的として探していたところ、本書を見つけたので読んだ。

本書は、機能要件、非機能要件のテスト、ソフトウェアテストの運用、テストの自動化などについて、著者の知見にもとづいてまとめられている。

機能要件のテストは、主にホワイトボックステスト、ブラックボックステストについて。ブラックボックステストは著者にとって、もっとも重要で、もっとも時間を費やし、もっとも簡単なテストである、としており、テスト手法とテストする順番を説明している。

それとは別に「探索テスト」という手法も紹介。これは先ほどの2つのテストとは少し異なり、あるソフトウェアについて、ソフトウェアの学習、テスト設計、実行、報告を都度行ない、バグを見つけ出す、というソフトウェアテストの一つのスタイルのこと。

一方、非機能要件のテストは、著者いわく「妥協とあきらめの世界」とのこと。「非機能要件」という名のとおり、そもそも要件の定義が難しく、考え始めるときりがない。そこで本書では、非機能要件のテストで確認する対象を「機密性」「信頼性」「パフォーマンス」に絞って説明している。

次にソフトウェアテストの運用。テストプラン、人員計画、実施スケジュール、終了基準などの策定と、テストの実施、結果に基づく品質の判定などを紹介。品質判定のためのメトリクスでは、著者がMicrosoftに勤めていた時に使用していたメトリクスも紹介している。

テストの自動化は、著者はそもそも書くつもりがなかったらしい。しかし本書では1つの章となっており、そのタイトルは「テストの自動化という悪魔 -なぜ自動化は失敗するのか-」である。主にテストの自動化に関する注意点がまとめられている。

自分の知見と比べると、機能要件のテストについては自分の知見とほぼ変わらず。ただ、ブラックボックステストの順番は意識したことはなかったので、これをきっかけに本書で示された順番で進めるようにした。また探索的テストは、自分が担当するシステムの理解を深めるために行う方法とかなり似ている印象を受けた。

「非機能要件のテストは難しい」という経験は自分にもある。

以前、サイトが一定期間高負荷になることが予想されたため、それに向けてパフォーマンステストとチューニングを行ったことがある。

このとき悩んだのは何をもって十分なパフォーマンスが出ていると判断すればいいのか、という点。主に秒間に処理されたリクエスト数を基準にしたが、まずこの基準値をどうすればいいか悩んだ。

これを明確にしたところで、今度は顧客にその根拠などをどう説明するか、という別の問題もあった。

最終的には想定した高負荷に問題なく捌けるようにし、当日も問題なかった。しかし実際は、そもそも想定値が実際の負荷に対して大きすぎたため、提供した環境が負荷に対して過多になっていた。

セキュリティテストは、突き詰めるとソフトウェアのバグの発見とその対応、ということになる。個人的に主だった経験はないが、今年起きたOpenSSLの脆弱性やShellshockのように、ソフトウェアにまつわる様々な要因でその発見や対応が難しい、というのはわかる。

どちらも事前にわかればいいのだが、それを知る方法なんてないし、それがわかれば苦労はしないわけで。

非機能要件のテストは、どちらも少しずつ知見を広げるのが現実的なのだろう。

本書で意外だったのは、自動化に向かないテストに回帰テストをあげていた点。

本書によると、著者はかつてバグデータベースに登録された順にすべてテストを自動化したそうで、その後度重なるユーザインターフェイスの変更で自動化したプログラムが半分ほど動かなくなり、そのメンテナンス作業が主になってしまった。

その経験から回帰テストは自動化に向かない、としているが、ここで問題なのは回帰テスト自体ではなく、そのテストにユーザインターフェイスを使用していることではないだろうか。

そもそも、ユーザインターフェイスを用いたテストは自動化に向いていない。このことは継続的デリバリーで言及されており、継続的デリバリーではユーザインターフェイスに代わる実装レイヤ、もしくはウインドウドライバパターンの適用をすすめている。

しかし実装レイヤ、ウインドウドライバパターンの適用は、ソフトウェアの構成を変更しなければならないこともあり、適用自体が難しいこともあるだろう。それならば、回帰テストの内容をユニットテストやコンポーネントテストなどまで落とし込みテストする、というのも一案である。

とはいえ、これはテスト担当者だけでは解決できないこと。対応するなら開発者も積極的に関わり、協力して対応することになる。

ということで、自分の経験を踏まえつつ長々とまとめてみた。本書はテストエンジニアに向けて書かれた書籍だが、開発者の自分としても全体的に読みやすく、わかりやすかった。

テストエンジニアが初めて読む、また開発者が自分でテストするために読む書籍としてすすめたい一冊。

作業ノート