いよいよこれが最後の章になります。
一通り本書に目を通してから学習しているのですが、ここは得意なパートです。
というのもテストツールに関する調査をしたことがありますし、同僚がやっているのを間近で見たことがあるからです。
ところで、 JSTQBにはシラバスが存在します。シラバスって大学とかで聞かれるような言葉ですが、授業計画の意味です。
ですが、JSTQBのシラバスは充実しており、各項目について詳細な内容が記載されています。
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
JSTQBのFoundationレベルについては、本があります、その先のAdvanced レベルについてはこのシラバスで勉強することになるでしょう。
テストツールの考慮事項
ソフトウェアテストのツールには様々な種類があり、またはテストプロジェクト全体を通じて、以下のようなものが挙げられます。 - テストに直接利用されるツール - 例えば、テスト実行ツールやテストデータを生成するツール、テスト結果を比較するツールなどが該当します。 - 要件、テストケース、テスト手順、自動化テストスクリプト、テスト結果、テストデータ、欠陥などをうまく取り扱うツール - テスト実行のモニタリングとレポートのためのツール - 調査と評価に利用できるツール - テストに役立つあらゆるツール
テストに役立つあらゆるツールは、表計算ツール、つまり、ExcelやGoogle SpreadSheetなども含まれます。
実際のところ、Google SpreadSheetが最適解な気がしています。
テストシナリオ、どうにかならんのかと言われたこともあるのですが、作成しやすさ、履歴管理、その後の確認結果の書きやすさを考えると結局スプレッドシートがいいのです。
ただ、最善策とは思いがたくもどかしさの上で、何か便利になるのではないかと思いがちです。
既製のテストシナリオ管理ツールを使ってみたが、使いづらかったとか、実際に使ってみたことがあるのですが、良い点もあるものの柔軟性に欠いてしまうし、お金出してまで使うツールかというとそうでもありませんでした。
テストツールの分類
テストツール導入の目的
テストツールの使用には特定の目的が存在します。テストツール導入の目的は、ツールをテストマネジメントやテスト実行などに適用することで効果や恩恵を受けることです。テストを支援するツールは状況に応じて以下に示す目的の1つ以上を持っています。
- 手動で行うと大量のリソースを必要とする反復作業を自動化することによって、テスト活動の効率を改善する
- テストプロセス全体を通して、手動で行うテスト活動を支援することによって、テスト活動の効率を改善する
- テストの一貫性や欠陥の再現性を高めることで、テスト活動の品質を改善する
- 手動では実行できない活動（例えば、大規模な性能テスト）を自動化する
- 例えば、大量のデータの比較を自動化、または動作のシミュレーションをすることにより、テストの信頼度を向上させる
手動では実行できない、といえば負荷テストでしょう。1万人のユーザーがアクセスしたら、レスポンスに問題ないかといったテストを行うために1万人のテスターを集めるわけにはいきません。
JMeterやLocustというツールが思い浮かびます。実際にJMeterで負荷テストしたら、これじゃお客さん使えないぞ、なんてことがわかったことがあります。
開発会社のプロが負荷テストツール7つをレビュー | 負荷テストツール「Hedgehog」 | 株式会社アストレア
負荷に耐えきれない場合は、アーキテクチャの見直しなどが必要になります。そういった意味でも負荷テストは早めに確認を行なっておきたいテストです。
ツールは、目的、価格、ライセンスモデル（有料、オープンソースなど）、使用している技術といった様々な基準で分類できる
有償の製品から、無料で配布されている製品、オープンソースも存在しているため、目的にあったツールを選択することが、テストプロジェクトの生産性に大きな意味を持ちます。
テストツールの中には、テスト実行結果に影響を及ぼすものがある
テストツールにはテスト結果に影響を与えるものがあります。同じ目的で利用するツールでも、ツールの特性の影響でテスト結果となる数値に違いが出る場合があります。これをプローブ効果と言います。
初めて聞きましたね。プローブ効果なんて言葉。
テストツールの中には、一般的に、テスト担当者より開発担当者に効果の高いものもある
これは静的解析ツールなどのことですね。 SonarQubeやCode Climateのような製品があります。
テストとテストウェアのマネジメントの支援ツール
テストプロジェクトのマネジメントのためのツール。テストマネージャーに限らず、テストプロジェクトを円滑に遂行するための様々なツールが存在します。またテストマネジメント用のツールは、すべての開発ライフサイクルでテストプロジェクトの作業に利用することが可能です。
テストマネジメントツールとアプリケーションライフサイクルマネジメントツール(ALM)
テストマネジメントツールは、テストプロジェクトのマネージャーやリーダーを支援するためのツールです。テスト要件のマネジメント、テスト実績や欠陥のマネジメントを行うことなどが目的となります。テストの要件とテストケースのトレーサビリティを確保することにより、作成したテストケースがテスト要件を満たしていること、またはテスト実行、故障発見と改修実績などの実績をマネジメントすることによりプロジェクトのリスクを把握することができます。
で、具体的に何よ、と思ったら、TestLinkが例に挙げられていましたが、古い記事しか出てきませんでした。
要件マネジメントツール
要件マネジメントツールの目的はプロジェクト要件のマネジメントです。要件と仕様は一貫していなければなりません。要件マネジメントツールはそれら要件の作成と変更や、関連する別の要件やテストへのトレーサビリティを確保する際に使用します。また、ドキュメントのIDやバージョン、作成・承認などの担当者のワークフローなどを提供するツールもあります。
で、またTestLinkが紹介されています。最近では、 WordやGoogle Documentでも承認のフローが用意されています。
欠陥マネジメントツール
欠陥マネジメントツールは欠陥の総合的なマネジメントを目的とします。故障の属性情報、例えば概要、発生日、アプリケーションのバージョンや、サーバーやOSなどの環境情報、故障がユーザーへ与えるインパクトなどの情報の登録を行います。
RedmineやBugzillaなどがあります。とあります。Redmineは人気のツールで、以前の職場ではRedmineだらけで困ったことがあります。似たような画面なのに、URLが違うで。
今はSaaS全盛期なので、SaaSのチケット管理ツールを使うことが多いですね。
なんでもいい気がします。ただ開発と足並みを揃えるべきだと感じています。
意味がわからないのが 開発はGitHubのIssueで管理しているのに、不具合をJIRAで管理しているとかありました。二重起票という無駄をしているのです。その無駄が無理を生み、ムラを生んでしまうのです。
構成管理ツール
要はGitやSVNのことです。
作成したテストスクリプトなどもバージョンコントロールの対象となるのです。
今はテストコードによる自動テストも行われますが、基本は同じリポジトリに入っているものです。なので、テスト活動だけを対象としたツールではありません。
継続的インテグレーションツール（開発）
ソースコードを定期的にビルドや自動テストを行う開発手法です。CIとか言われたりします。
これまでは、Jenkins一強でしたが、クラウドの広まりとともに、GitHub ActionとAzure DevOps、Circle CIなどがあります。
今の職場では込み入ったことをするためにJenkinsをメインで使っているのですが、GitHub Actionで簡単なチェックをしたりもしています。
静的テストの支援ツール
静的テスト支援ツールの目的は開発プロセスの早い段階で多くの欠陥を見つけるための支援です。具体的には、レビューを支援することによりレビューの精度を上げたり、ソースコードの静的解析を行い、コーディング規約が守られているか、到達不可能なコードが存在しないかなどのテストを行うことにより、問題を早期に発見し、高い費用対効果を挙げることができます。
とありますが、静的解析ではJSTQBでいう欠陥を見つけることはほぼ困難だと思います。コーディング規約が守られているかの確認のメリットはコードの保守性という開発効率に寄与するものではないかなと。
レビューツール
レビューツールの目的は主にレビューの精度の向上です。レビューの実施のログとしてレビューの開催情報やその種類、参加者、指摘事項やコメント、レビュー対象となるドキュメントやコードなどの情報を記録し、共有することでレビューを効果的に実施します。
オンラインレビューを支援するツールなどもあり〜と書いてありますが、今はオンラインでレビューするのが主でしょう。
ReviewBoardというツールが紹介されていますが。これもまた古いツールですね。Wordで古臭いフォーマットで形式だけのレビューをやっているところもあります。
ソースコードのレビューとなるとGitHubなどのPullRequestの形式になるでしょう。
テスト設計とテスト実装の支援ツール
テスト設計とテスト実装の支援ツールは、テスト対象に対する入力となるテストデータを生成したり、GUIを使用してテストケースを生成することなどを行います。
ツールを使うことにより保守性が高い作業成果物にすることが可能です。また、これらのツールはテスト実行と結果記録の支援ツールと連携して、テスト実行や結果記録を支援する他のツールに出力結果を提供したりすることができます。
テスト設計ツールでいうとべリザーブ社はGIHOZという提供しています。これはかなりいいんじゃないかと思います。
ここまでのテストができる余裕がないのと、その条件の組み合わせでどうなる性質のアプリケーションではないです。状態遷移が複雑すぎて、それを書き起こすのにも無理があるので。なのであまり使ってはいません。
振る舞い駆動開発ツールはテスト駆動開発ツールとほとんど変わりません。
テスト実行と結果記録の支援ツール
テスト実行ツールは、リグレッションテストなどのテスト実行を自動または半自動で実行することを目的とします。
夢のツールですね。ただ、現実的に、アプリケーションの変更によりメンテナンスが必要になったりしますので、うまく機能しないのが実情です。
テストハーネスは、テスト対象の呼び出しや結果を検証する機能を提供します。テスト対象のモジュールを呼び出すプログラムを「ドライバ」と言います。またテスト対象のモジュールから呼び出して結果を確認するためのテストモジュールを「スタブ」と言います。
以前の職場で、このテストハーネスをうまく活用している人がいました。バックエンドのWebAPIを開発する上で、画面からAPIを呼んでテストするためのドライバとなるWebページを用意していたのです。
それに習って、僕も開発しているWebAPIが連携先のサービスが想定したレスポンスを返してくれるスタブを作って動作確認したりしていました。
ユニットフレームワークテストはJUnitなどのいわゆるテストコードと言われるものですね。ここまで手が出せるQAがぼくの求めるQAです。
性能計測と動的支援ツール
性能計測は、先述してしまいましたが、JMeterのような負荷テストを行うツールです。
JMeterにはアプリケーションのリソースをモニタリングする機能もあります。開発ツールのUnityですと、Unity自体がProfilerを提供していますね。
ここまで見ると、QAもこうしたProfilerなどを使いこなせないとならないんだよなあと思わされますね。
動的解析ツールは、ソースコードの実行中に発生する欠陥を検出する目的で使用します。具体的には実行時のメモリー割り当てや解放に関する問題や、マルチスレッドのアプリケーションにおけるスレッド間の並列処理に起因する問題を検出したりします。テスト担当者よりもソースコードの開発担当者が使用する場合が多いようです。
例としてvalgrindが挙げられています。こちらは検索してみると新しい記事が検索されますので現役といって良さそうです。
特定のテストに対する支援ツール
全般的なテストプロセスを支援するツールに加えて、特定のテストの問題を支援するツールも存在します。
データ品質の評価とは、例えば本番稼働している業務システムのデータを越と環境で使用するときに、システム利用者の個人情報など、テスト環境での使用に問題があるようなデータをマスキングしてダミーのデータに置き換えた際に、検索できる状態になっているか確認したり、新しく作成したデータベースにデータ移行する際に、格納位置や形式などが適切に格納されているかツールを使用して検証しみ明日。
システムの刷新によるデータの移行や、目的の異なるアプリケーションにデータを流用する場合などは、アプリケーションによってデータの構造が異なるのでツールを使用して移行先のデータ構造に合わせた変換をします。
マイグレーション周りは難しいです。他社から乗り換えでも発生しますし、同じ会社のシステムでも新しいシステムの乗り換えでも発生します。他社だったらともかく、同じ会社でもデータ構造が全然違うのでとても大変なのです。もうとにかく新しいシステムを作るので精一杯で、移行されることなどさっぱり考えられてないからです。
使用性テストのためのツールなどを使用してユーザーがアプリケーションを使用している状況などを記録します。種収支たユーザーの使用状況を基にユーザーにとって使用しやすいUIが提供できているかといった分析を行います。
そういう経験はないのですが、使用性を確認するとなるとWebだとLighthouseというツールがありますね。
アクセシビリティテストとは、高齢者や障害者でも使いやすいコンテンツになっているかを確認するためのテストです。例えば、 Webアクセシビリティの規格やガイドラインの要件を満たしているかなどをテストします。QAの奥深さはこうした様々な観点で評価できる点ですね。
ローカライゼーションテストは、たとえば翻訳したアプリケーション内のテキストの翻訳に不備がないかなどを確認します。これは、QAがやるかというとまた別な気がします。今の職場のシステムは英語対応していますが、QAがやるというより英語に詳しい人に翻訳してもらうことが多いです。
セキュリティテストツールは、ソフトウェアのセキュリティを評価するために用いるツールです。Nessusなどがあります。
移植性テストとはソフトウェアの移植性を評価するためのテストです。移植性テストでは、複数のサポート対象プラットフォーム、たとえば、ハードウェア環境やOS、ミドルウェア、動作プラットフォームで動作するか確認します。
これが地味にかったるいテストです。デスクトップアプリケーションですとWindowsの新しいバージョンに対して確認していました。ただ、今はWindowsも自動アップデートされるようになり、常に最新版を使うことが多くなり難しくなりました。ただ、古いアプリケーションだとWindows8などの古いOSもサポートしなければならず、頭を抱えたこともあります。
WebだとChrome、Firefoxといった各ブラウザで動くかの確認も必要でしょう。ある程度はもう諦めてもらうしかないのかなと思っています。
テスト自動化の利点とリスク
テスト実行を支援するツールを使う潜在的な利点
- 反復する手動作業の削減と時間の節約ができる
- 一貫性や再実行性が向上する
- 評価の客観性が向上する
- テストに関する情報へのアクセスの容易性が向上する
テストを支援するツールを使う潜在的なリスク
- テストツールの効果を過大に期待する
- テストツールを初めて導入する場合に要する時間、コスト、工数を過小評価する
- 大きな効果を継続的に上げるために必要な時間や工数を過小評価する
- ツールを使うために作成するテスト資産やツールが生成するテスト資産をメンテナンスするために必要な工数を過小評価する
- ツールに過剰な依存をする
- ツール内にテスト資産のバージョンコントロールを怠る
- 複数のツールの運用が適切になされない
- ツールベンダーに潜むリスクを想定しない
- ツール自体に潜むリスクを想定しない
- ツールに対する当事者意識が明確ではない
いいですね。以前の職場に自動テストに夢を見て、過大な期待をしてしまうマネージャーがいるので叩きつけたいです。
テスト実行ツールとテストマネジメントツールの特別な考慮事項
テスト実行ツールは自動、または半自動でテスト実行します。
テスト実行ツールを使って成果を上げるためには、テストスクリプトの作成やテストデータの作成など自動実行のための準備に想定以上のコストが必要となってしまうことが少なくありません。
スクリプト作成を効果的にするため、以下に示す2つのアプローチを駆使します。
- データ駆動方式
- キーワード駆動方式
- キーワードと一部のテストスクリプトを関連づけてテストケースを作成する。キーワードがクリックなどに紐付く
この辺りは言葉だけでは難しいですね。実際にやったことがないと想像がつきにくい印象です。
要はそれなりにメンテナンスコストがかかるということです。なので、小さいチームでは効果をあげづらいと思います。それなりの規模のチームで、それなりに大きな規模のアプリケーションをテストするときに使えるものになるのではないでしょうか。
小さな工数で大きな仕事ではなく、それなりの工数を使ってより多くのテストを行う。それがテスト実行ツールの立ち位置かと。
テストマネジメントツール
テストマネジメントツールはテストプロジェクトに関係するデータのインポートやエクスポートを目的とした汎用的なインターフェースを提供している場合や、レポート出力の機能を持つ場合があります。
独自フォーマットでドキュメントを作成する組織も多いので、テストマネジメントツールを使用するために、プロジェクトの成果物のフォーマットに合わせたツールのカスタマイズが必要となる場合もあります。
独自フォーマットって、そういう組織にはいたくないですね……。しかし、そういう経験はあります。
ツールの効果的な使い方
ツールを選択する際の基本原則
組織向けにツールを選択する際の基本原則
- 組織の成熟度、長所と短所を評価する
- ツールを活用するためにテストプロセスを改善する機会を識別する
- テスト対象で使用する技術を理解して、その技術と互換性のあるツールを選択する
- 組織内ですでに使用しているビルドツールや継続的インテグレーションツールとの互換性と統合の可否を明らかにする
- 明確な要件と客観的な基準を背景にツールを評価する
- 無料試行期間があるかどうかを確認する
- ツールベンダー、もしくは無料ツールのサポートを評価する
- ツールを使用するためのコーチングおよびメンタリングに関する組織内での要件を識別する
- ツールに直接携わる担当者のテストスキルを考慮して、トレーニングの必要性を評価する
- 様々なライセンスモデルの長所と短所を考慮する
- 具体的なビジネスケースに基づいて、費用対効果を見積もる
組織の成熟度にCMMIが紹介されていますが、CMMIを導入しているという組織にいたことがあります。しかし、とても機能している組織として成熟しているとは思えなかったので、あまり間に受けないことにしています。
とはいえ、CMMI自体が謳っていることは間違ってはいないとは思います。
このあたりは決裁権のある人は必ず知っておくべき点ですね。
無料試行期間があるかどうかは、試すして導入を判断しなさいという意図を感じます。使えったら使うんだみたいなトップダウンをするなよな、ということです。
サポートも大事です。昔は、小さい規模のチームで予算も何もないので、OSSのツールを使うしかありませんでしたが、有償のツールを使い、サポートに問い合わせできるのは楽です。正直、サポートが悪い、回答が遅いなあと思うこともあるのですが、どれほど調べても解決できないことをサポートに教えてもらえたり、時間短縮になっていることはあります。
しかし、こうしたサポートはケチりたがるのが実情です。予算オーバーしそうだから、サポート切れないかみたいな話になった記憶があります。
ツールを組織に導入するためのパイロットプロジェクト
コンセプトの証明によって、ツール導入効果が認められて、ツールの選定が完了した後は、小規模のパイロットプロジェクトで試行を始めるのが良いでしょう。ツールがうまく適用できなかった場合でも被害が少なくて済むからです。
ただし、パイロットプロジェクトでうまくいったからといって、組織の中にはツール導入による効果を得られないプロジェクトがあったり、余計に工数がかかってしまうなどのリスクがあることは否めません。
これらのリスクを最小限にするためにもパイロットプロジェクトで様々な角度からツールの導入の効果を測定する必要があります。
パイロットプロジェクトでは、以下の点を重点的に確認していきます。
- ツールに関する知識を深め、強みと弱みを理解する
- 現状のプロセスや実践しているやり方にツールをどのように適用するか評価する。そして何を変更する必要があるかを特定する
- ツールやテスト資産の標準的な使用方法、管理方法、格納方法、メンテナンス方法を決める
- 期待する効果が妥当なコストで実現可能かどうかを見極める
- ツールによって収集およびレポートさせたいメトリクスを理解し、メトリクスを確実に記録しレポートするようにツールを設定する
かなり建設的な進め方でいいですね。普通はこんなことせず、エイヤで導入ですが。
パイロットプロジェクトではありませんが、大きい規模のプロジェクトのあるメンバーはツールの導入検討のため、プロジェクト全体ではなく、自身の管掌している業務について導入して検証していたことがありました。
ツール導入の成功要因
ツールの効果を持続できるよう組織内でツールを展開するには、以下のような取り組みが必要になります。
- ツール未使用の部署にツールを順々に展開する
- ツールが適用できるよう、プロセスを調整、改善する
- ツールのユーザーに対し、トレーニング、コーチング、メンタリングを行う
- 利用ガイドを定める
- ツールを実際に使用する中で得られる情報の集約方法を実装する
- ツールの利用状況や効果をモニタリングする
- ツールのユーザーサポートを提供する
- 全てのユーザーから、得られた教訓を集める
ノウハウをどこかに蓄積するのはできることですが、やはり、順々に展開するという部分。
日本人というか、日本人のエンジニアの気質的な部分で、こういう広めたり、教えたりしていくことに消極的な部分に感じます。自分もそうです。
こうした活動が組織をより良くするという認識があれば、進んですべきことは自明の理ですよね。
自分にとってもメリットはあります。自分が休んだり、別業務にかかりきりになったりしても、他のメンバーがやってくれたりするのですから。
とはいえ、人はたくさんいても、それを教えても運用できそうな能力の人がいない、困ったということはあります。
利用状況をモニタリングすることも大事ですね。また、最悪使われていないツールについては諦めることも大事だと思っています。サブスクリプション方式で費用対効果の悪いツールに毎年お金を払い続けるのはもったいないですから。
と、第6章が終わります。
そして、これでJSTQB学習が終了しました。
とはいえ、これで終わりではありません。きちんと身についているか、そして試験に合格できるか、になります。
それでは終わりではなく、学んだことを業務に活かせるか、そこまであって意味があるのです。
