はじめに
翔泳社さんから出版されている「Web APIテスト技法」を読んだので、個人的に興味のあったポイント、気になったポイントをまとめてみます。
第3章 品質とリスク
3.1 品質の定義
ここでは、そもそも品質とは何か？という問いかけから始まっております。真面目に考えると難しいかもしれませんが、こちらの書籍では非常に簡潔に、かつ、納得感のある解が紹介されています。
品質とは、ある大切な人にとってのある時点での価値のことである。
上記の通り、本当に突き詰めるとその通りだなと思いました。
例えば、以下のような形で
- 私にとって、とあるUIが非常に使いにくいと思っていても他の人にとってはそうでないかもしれない
- 以前まで使いづらかったこのUIも1年経過してそこまで気にならなくなった
品質というのは個々人の主観的／流動的な概念だということになります。
3.2 品質に影響をおよぼすリスクの特定
ここでは、品質に影響をおよぼすリスクを特定するにはどうしたらよいか？ということが紹介されています。
究極的には、リスクの特定には懐疑的なマインドセットが必要になる。
つまり、「懐疑的なマインドセットを持ち自分の思い込みを捨てて考えることが重要」ということです。
- 検索結果が重要な情報だということを確かめられるか?
- 検索機能が想定通りに動作しなければどうなるか?
- どのような検索演算子をサポートするか? それはなぜか?
この種の問いを立てて得られた回答を検討すると、リスクを特定するための手がかりが得られる｡懐疑主義は、与えられた状況について否定的になったり悲観的になったりすることではない。
懐疑的なマインドセットは必要だけれども、ネガティブになるということではないということですね。
第5章 APIの探索テスト
5.3.2 異常の判断方法
探索テストを行った際に、バグとして起票すべきか否かをどのように判断するかというお話です。テスト設計書に基づいてテストを行っていれば、期待値に記載のある通りにならなかったらバグとして起票すればよいですが、探索テストではこうでなければならないという基準がないため、このような問いが生まれます。どうするか？答えは簡単で、仕様書、設計書を確認する、有識者に聞く、というものが考えられます。答えは簡単ですが、なぜこの章を取り上げたかというと、本書籍では以下のように表現されており、テストオラクルという言葉を初めて聞いたため書き留めております(JSTQBでも表記はあるらしいのですが完全に失念しておりました)。
テストオラクルを使えばこれは簡単に克服でき、自分の期待や他者の期待を裏切るイシューを見つけられるようになる。
テストオラクルとは、判断のために使える情報源のことで、こちらから更に抜粋すると、
テストオラクルは「テスト対象の実行結果と比較可能な具体的なテストデータや期待結果が掲載されている情報元」
ということになります。つまり、要件定義書、設計書、仕様書の類はもちろんのこと、議事録やチャットでのやりとりなんかもテストオラクルとなります。
第7章 テスト戦略の確立と実現
7.2.1 現場のテスタビリティの理解
テスト計画を立案する際に、テストを実施するうえでの制約の洗い出しが重要で、洗い出しを行うためにまずは現場のテスタビリティ（テストを行う総合的な能力、条件）を理解しましょうというお話です。ここでは、テスタビリティを理解するための「10個のPモデル」というものが紹介されています。
●People(人)
テストのしかたは、テストをする人々のスキル、知識、マインドセットの影響を受ける。個人個人のテストスキルが低ければ、それらの人々のテストする能力も低い。
●Philosophy(行動指針)
Peopleは個人の能力とそれがテストにおよぼす影響に注目したが､Philosophyはチーム全体としての信念や姿勢に注目する。たとえば、チームが品質重視の思想とテストの価値をあまり評価していなければ、テスト戦略の実現は難しくなるだろう。
●Product(プロダクト)
プロダクトがどのような作りになっているかとどのようなテクノロジーを使っているかもテスタビリティに大きな影響をおよぼす。デプロイが難しく、アクセスしにくく､たびたびクラッシュしているようなプロダクトは、テストツールの実装のしやすさに深刻な影響を与え、テストをぶち壊しにする。
●Process(プロセス)
チームは管理の目が行き届く小さな規模で新リリースを送り出そうとしているか､それとも大規模なリリースですべての機能を揃えて出そうとしているか｡ 仕事の成果を届けるプロセスもテストに影響を与える。リリースがまれで大量の変更を含むようなら、オートメーションのメンテナンスに影響をおよぼし、遅れているテストへの対応に追われ、優先度の高いリスクをすべてテストできているかを確認しづらくなる。
●Project(プロジェクト)
プロジェクトの期間と資金もテスト計画の策定で大きな役割を果たす。プロジェクトの納期が短ければ、特定のテストアクティビティを実現する時間が確保できないかもしれない。実施のために訓練が必要なテストアクティビティがあった場合(People で指摘した問題)、チームメンバーを訓練する時間と予算があるか。
●Problem(問題)
ソフトウェアで解決しようとしている問題の理解ということである。ユーザーがシステムをどのように使っているかを理解すれば、問題の理解も深まる。どちらかの理解が欠けていれば、テストし損なう部分が残るだろう。
●Pipeline(パイプライン)
たとえばオートメーションのようなテストアクティビティを実現しなければならない場合、プロダクトをビルドして本番環境にデプロイするパイプラインのどの部分でそのアクティビティを実施するか。そもそもパイプラインがあるか。プロダクトが通過するパイプラインの知識は、テストをいつどこで実施すべきかを決める上で役に立つ。
●Productivity(生産性)
チーム全体としてのイシュー発見能力(生産性)に影響を与えるもののことである。このPの面白い点は、流動的なことだ。企業文化のように生産性に長期的な影響を与えるものもあれば、組織的な病理、会議の回数と時間、精神衛生のように生産性に短期的な影響を与えるものもある。これらすべてに対して計画を立てることはできないが、将来テスト計画に影響を与える可能性のあるものを知っていれば、あらかじめそれらの問題の解決方法を考えたり、それらを回避する計画を立てたりすることができる。
●Production issues(本番環境のイシュー)
本番環境に対処が必要なイシューが少なければ、テスト部隊の能力をほかの分野に振り向けられる時間が長くなる(逆に、イシューの少なさはフィードバックループの貧弱さを表しているかもしれないが)。同様に、本番環境でイシューが見つかったときにすばやく解決できる体制になっていなければ、テストの機会に影響がおよぶかもしれない。本番環境のイシューが起きる頻度とその対処方法がわかっていれば、テストに使える時間を確保できるようになる。
●Privity(積極性)
テストのコンスタントな改善にチーム全体がどれだけ開かれているか。テストについて考え、改善するために、メンバーにどのような機会が与えられているか。フィードバックとフィードバックへの対応は、テスト戦略とテスト計画の成否を大きく左右する。フィードバックのために使える手段がすでにあるか、それとも新しくそのようなものを作らなければならないか。
テスタビリティについて考えることは過去にもありましたが、経験則からくるものをベースにしていたこともあり、このモデルは参考になりそうだなと思いました。
その他
- JMeterのGUIを使ってAPIのパフォーマンステストをする際は、結果表示ツリーリスナーはオフにしておこう。このリスナーはリソースを大量消費するのでパフォーマンステストに影響を与えることがあります(これはJMeterでも推奨されています)
最後に
冒頭で述べた通り、あくまで「個人的に興味のあったポイント、気になったポイント」をまとめてみました。読む方によっては、そんなこと常識、、、、と思われるかもしれませんがその点はご容赦頂ければ幸いです。
以上です。