第122回： テストツールの種類
≡ はじめに
「ASTERセミナー標準テキスト」の188 - 189ページについてです。
前回は、息抜き回ということで、「コンサルタントが描く”図”・”グラフ”・”表”」について書きました。今回は、「テストツールの種類」についてです。
テストツールというと、テストを自動的に行うツール（例えば、SeleniumやRanorex）を思い浮かべる人が多いと思います。私もJSTQBのFLシラバスを読む前は、そう思っていました。また、1996年にシステム検証センターという部門に異動した時の最初のミッションは「プリンターのテストを自動化せよ」でした。
当初、MS-Testを使っていた人がいたので、その辺を参考に後継商品のVisual Testでプリント操作の自動化を行いました。
その後、「Windowsだけでなく、Machintoshからのプリントも自動化したいね」ということになり、一つのスクリプトでWindowsの自動化とMachintoshの自動化を行える100万円くらい野心的な商品を見つけて5本購入しました。ところが、そのステキツールを使う前に購入先のベンダーが倒産してしまい、（将来のことを考えて）結局使わなかったり、、、かなり紆余曲折していました。
（ツールベンダーが無くなるプロジェクトリスクについて、その当時は全く想像もしていませんでした）
そこで、ツールベンダーに依存しすぎてはいかん、自分たちで1から作ろうといって作ったツールが第一回のJaSSTで発表した『ダイナミックに操作を補完するテスト自動化について』です。
これは、自動化対象の「操作」を「その操作を実行できるプレ状態」と「その操作を実行後のポスト状態」のセットで持つというアイデアを実装したものです。
この機構によってテスターは「文書Aをプリントする」と書くだけで、「文書をプリントする操作」が呼び出され、そのプレ状態をポスト状態としてもつ「プリントダイアログを開く操作」、さらにはその前の操作となる「アプリケーションを開く操作」が再帰的に検索されて呼び出され、一連のシーケンスを構築後、実行することができました。
この仕組みは割と上手くいって、一部のファンには18年後の今も使われているのですが、、、。今なら素直にAutifyを使うかなあ。（あっ、関係者ではありません。単に楽しげなツールなので興味があるだけです）
補足です。「ツールベンダーに依存しすぎてはいかん」と書きましたが、1990年代にテスト技術について知りたかったら、ツールベンダー（例えば、Mercury）の技術者をつかまえて聞くというのが最高の方法でした。
私も大変お世話になりました。（もちろん今でもツールベンダーに素晴らしいエンジニアの方はたくさんいらっしゃいます！）
今回のnoteでは、テストの実行だけがテストツールではないという話を書きます。
具体的なツールについては、以下の「テストツールまるわかりガイド」をチェックするとよいです。非常に便利です。
なお、どのツールでも【使いこなせば】劇的に品質が向上し、コストダウンを実現します。逆にいうと、買っただけで使わなければ、何も変わりません。
したがって、ツールを使える（覚悟を持ったエンジニアがいる）なら、ROIとか迷わずにどんどん導入するほうが良いです。いずれのツールもコスト効果よりも品質効果が大きいのが一般的です。
ツールを売る側は買っただけで（＝ 勉強いらずで）効果が出るようなツールを目指し、ツールを買う側は（トレーニングやツールの保守業務など）買った後のことを考えて買うことが大切です。
※とはいえ、体験してみないとわからないことが多いので、無理をしてでも体験してみることをお勧めします。（西堀榮三郎先生が『石橋を叩けば渡れない』という本をお書きになったのは二十数年前ですが、なにごともチャレンジすることが大切と思います）
≡ テストツールの種類
まずは、キャッチイメージを再掲します。
こちらのページは、タイトルに1/2とあるように前半の3種類が書いてあります。後半についてもこのnoteで説明します。
前半は「テストマネジメント支援ツール」、「静的テスト支援ツール」、「テスト設計・実装支援ツール」の3種類です。使う順でしょうか？
それぞれについて説明します。
ここで、いずれも「支援ツール」であることに注意してください。
「支援」とは、「手作業や汎用のソフトウェアでもできないことはないけれど、専用のツールを使うと、ずっと楽にできるよ」といった意味です。
ですからテストツールの導入に際して、その費用対効果について上司から質問を受けることがよくあります。
ツールを使いこなせるようになれば、大きな費用対効果が期待できるのですが、初回で費用対効果が出ることは稀です。ゆえに、そこが普及のボトルネックとなり、ツール推進者の悩みどころだったりします。
その点、ハードウェアのツール（工具や治具/ジグ）は（通常は素手ではできないことばかりなので購入や導入の）説得が不要です。ちょっと羨ましいですね。
ところで、「治具」と書くと、「冶具（サンズイではなくニスイ）ではないのですか？」と質問を受けることがあります。サンズイが一般的です。また、元々は、jigの当て字ですので、こだわらなくてよいです（「冶具」も正しい）。
■ テストマネジメント支援ツール
テキストには、
テストマネジメントツール、アプリケーションライフサイクルマネジメントツール（ALM）、要件マネジメントツール、欠陥マネジメントツール、構成管理ツール、継続的インテグレーションツール
とあります。「テストの仕事をマネジメントする」ための支援ツールと、「テストウェアの管理」を支援するツールが並んでいます。
どのツールも開発組織全体で使用することを検討するとよいです。特に最後の「継続的インテグレーションツール」はQAが環境を整える場合もありますが、多くのケースでは開発者に任せる方がベターです。
「継続的インテグレーションツール」は一度導入すると何年も変えずに使い続けることが多いですから、導入時は最新の動向をよく知っている人（コンサルタント）に構築の指導をしていただくことも検討しましょう。もちろん、自分のチームに、開発環境の構築が好きなエンジニアがいたら越したことはありません。
ツールの中には、「アカウント数 × 利用期間」に応じて課金されるサブスクリプションモデルのものもあります。そのような場合は、部門長や役員といった使わない人のアカウントを取らないことが大切です。一定期間（3ヶ月程度）1度もアクセスがないアカウントに対して利用継続の必要性について確認を取るのもよいでしょう。また、退職や異動に伴い使用しなくなったアカウントについてはシステムごとに取り扱いが異なる場合がありますので注意（セキュリティや情報オーナーの面の注意）が必要です。
なお、ここに挙がっているツールの多くは、関係者が少人数だったり、管理対象のデータ（例えば欠陥数）が少ない間は、Excelの方が便利です。また人の出入りが多いチームでは、Excelであれば、教育の手間がかからないというメリットもあります。
もちろん、会社全体で同じツールを使用するメリットもありますから、例え小さなプロジェクトであったとしても、早めにExcelから専用のツールに移行するメリットもあります。
■ 静的テスト支援ツール
テキストには、
レビューを支援するツール、静的解析ツール
とあります。「レビューを支援するツール」は使ったことがありません。レビュー指摘結果は上述の「欠陥マネジメントツール」で一緒に管理することで十分でした。レビューのメトリクスも議事録で問題ありませんでした。
私が使ったことがないだけで、複数のレビューの進捗管理や、レビューの進め方の改善を行うためのデータ収集などに役立つものと思われます。
「静的解析ツール」は主に開発者が使用します。
「静的解析ツール」は使用する言語やOSによって使えるものが限られます（特に組み込み系では注意が必要です）。
無償のツールにも使いやすいものがたくさんあります（Windowsなら「かぞえチャオ！」も便利です）し、コンパイラのオプションでワーニングレベルを上げるだけでもよい情報が得られます。
有償のツールですと、Coverity社のツールや、「QAC」とか「Parasoft C++test」といった有名どころ。リファクタリングを進める上では、「Lattix」と「Understand」などのツールが欠かせません。
サブスクリプションモデルで提供しているものを使用すれば、初期投資を抑えることもできますが、そんなに多くの「静的解析ツール」があるわけでもないので自分のチームに合ったものを導入して使い倒す方が良いと思います。
■ テスト設計・実装支援ツール
テキストには、
テスト設計ツール、モデルベースドテストツール、テストデータ準備ツール、受け入れテスト駆動開発（ATDD）、ツールや振る舞い駆動開発（BDD）ツール、テスト駆動開発（TDD）ツール
とあります。「テスト設計ツール」と「モデルベースドテストツール」はテスト技法を実装したもの、例えば、ペアワイズツールの一つである「PICT」や原因結果グラフという技法を実装した「CEGTest」などのことです。有償のツールも数は少ないですがあります。
そうそう、ベリサーブ社の「GIHOZ」も今後の成長が楽しみです。
「テストデータ準備ツール」は地味ですが、役に立ちます。
例えば、大量の顧客データを使用したときの振る舞いをテストしたいときに、本物のデータを使うと情報漏洩の危険があります。かといって、一件一件手入力で作るには膨大な工数がかかります。そんな時に、本物のデータをいい感じに加工するツール（Delphixとか）やゼロからテストデータを作るツールがあると非常に便利です。
テスト設計でテストケースを作ることは一番大切ですが、良いテストデータを効率的に作成することは二番目に大切です（ときには一番大切なことも！ 機械学習のテストとかテストデータの品質が命ですよね）。
残りのツールはTDDなど、開発時の支援を行うツールです。開発戦略に合わせて開発者に使ってもらいます。
後半の（2/2）では、「テスト実行と結果記録の支援ツール」、「性能計測と動的解析の支援ツール」、「特定のテストに対する支援ツール」の3種類が書かれていますので、それぞれについて説明します。
■ テスト実行と結果記録の支援ツール
テキストには、
テスト実行ツール、カバレッジツール、テストハーネス、ユニットテストフレームワークツール
とあります。テストツールのど真ん中という感じがします。テスト実行ツールは免許制にした方が良いと思っています。
例えば、Seleniumの3級、2級、1級、初段、２段、、、とか。初段を持っていないと初期構築は任せられないとか決めた方が良いと思います。
出来の悪い自動スクリプトは負の資産だからです。
第三者検証会社はすぐにでも社内資格制度を作ると良いと思いますし、世の中にもう少し、自動化を行えるテストエンジニアが増えてきたらその資格をオープンにして資格ビジネスをすると良いと思います。
ユニットテストフレームワークは開発者に自由に選んで貰えば良いです。
テスト実行ツールについては次回以降のnoteで詳しく説明します。
■ 性能計測と動的解析の支援ツール
テキストには、
性能テストツール、モニタリングツール、動的解析ツール
とあります。テスト実行ツールに含めて同様に考えることをお勧めします。性能テストツールを使うにはパフォーマンステストのノウハウが必要です。
■ 特定のテストに対する支援ツール
テキストには、
データ品質の評価、データのコンバージョンとマイグレーション、使用性テスト、アクセシビリティテスト、ローカライゼーションテスト、セキュリティテスト、移植性テスト
と、「こんなものもあるよ」が並んでいます。これらのツールはそれを使いこなすための知識が必要となりますので、外部ベンダーを利用するのも手です。
特にセキュリティテストは知識の陳腐化が速いのでセキュリティのエキスパートにお任せすることを（ツールの購入よりも）先に検討した方が良いです。
そのような専門家を抱えているベンダーにはノウハウが溜まっていますし、高価なセキュリティテストツールを使った評価をしてくれるからです。
≣ 終わりに
今回は、「テストツールの種類」について書きました。
まずは開発者が使うテスト関連のツールを整備すると良いです。CI／CD環境、TDDのフレームワーク、静的解析ツールの3つは必須です。
次は、ブラックボックステストの自動実行、テストマネジメント、テスト設計の順番でノウハウを持った人を雇って、半年くらいで一気に整備してしまうと良いです。
数回前の、欠陥マネジメントのときに「会社を超えて欠陥管理をするならクラウドが良い」と書きました。
その後、「Codecov」の件があったので、“開発ツールをクラウドで使う危険性について再考が必要か”とも思いましたが、今のところ意見は変わりません。
次回は、「テスト自動化の利点とリスク」です。今回の種類でいうところの「テスト実行ツール」の深掘りです。
この記事が気に入ったらサポートをしてみませんか？