「その6」の続き、最終回です。
標準ダッシュボードとカスタマイズについて言及できればと考えていたのですが、「それっぽいダッシュボード」の作りこみに時間がかかりそうなので、やめておきます！
最終回は、偶然見つけたPractiTestのバグと、テスト管理ツールに対する考えをまとめておきます。後半、もはやPractiTest関係ない。
PractiTestの不思議なバグ
端的に言うと、「テストケースをインポートすると、謎の文字列が付加される」というものです。漢字を含むテストケースであれば再現性は高いので、PractiTest社側でも既知の事象とは思います。
インポートするテストケースはこんな感じ。ユースケース(笑)としては、これまでExcelで作っていたテストケースから、PractiTestにインポートしてみるというものです。つまりExcelファイルを自分で作っている（PractiTestからエクスポートしたものの再インポートではない）。
まず、インポート自体はあっさり成功。インポート機能ってぶっちゃけ、「2～3回は特定困難なエラーが出て、原因追及しながらようやく成功する」というイメージなので、さくっと成功するのは本当に安心感があります。
ですが、インポートした結果はこんな感じになります。
カギツカカギア？？？ 何語だ？
・・・よくよく見てみると、文字列の最後に漢字のフリガナが付加されているんですねえ。「鍵」「使」「鍵」「開」で「カギツカカギア」です。
Excelファイルに記録されたフリガナの情報だと思いますので、インポートしたExcelを調べてみましょう。PHONETIC関数で、文字列からフリガナを抽出すると、こんな感じ。
漢字の上についたフリガナが、余計に付加されてしまっているようですね。試していませんが、ほかのインポートでも同じことが起こるのではないでしょうか。
PractiTest社の方が読んでくれることを期待して、つたない英語で事象を残しておきます。
After importing tests from an xlsx file including Japanese "kanji" characters, unexpected strings are added after each text in imported tests.
These strings seem to be phonetic of the kanji characters.
これがバグなのか、何か意図しての作りで回避できるものなのかはわかりません。まあバグだとしても、元の文字列は残っているの で、インポートしたものを使いながら直せばいいでしょう。悪用の可能性は・・・うーん、あるかなあ？ Excelの読み仮名は修正できるので、そこに長大な文字列を埋め込んでおくとか？
ちょっと面白かったので、ご紹介でした。
テスト管理ツールにまだ足りなさそうなもの
個人的には、テスト管理ツールがテストについて万能である必要はない、と考えています。
たとえばイシューの作成はテストに関係する活動ですが、それを得意としているチケット管理ツールがすでに安定して運用されているのであれば、テスト管理ツールでがんばる必要はありません。両ツールで双方向の連携ができれば十分です。
自動テストも同様で、テスト管理ツールが自動テストを駆動する必要は必ずしもなく、自動テストシステムから情報を抜いてこられればいいと思います。
ソフトウェア開発ツール群において、わたしがテスト管理ツールに求める立ち位置は
- テストに関するアクティビティのうち、他のツールでカバーできないものを機能としてサポートする。
- 同、他のツールでカバーできるものは、APIなどを通じて情報を集めてこられる。
- 他のツールから情報をとるためのインタフェースをもつ。
といったところです。
b.は上で述べた通り。c.は、自分が他ツールからデータを集めるだけでなく、自分が他ツールに渡すこともできるべきということです。もちろんPractiTestは、両者をよく満たしていると思います。
ではa.はどうでしょう。
PractiTestに限らずテスト管理ツールがメインでサポートしているのは、「テスト実装」と「テスト実行」（イシュー管理を含む）です。逆に、JSTQBでいうところの「テスト分析」と「テスト設計」はカバーしているとは言いづらいでしょう。
「要求」を管理することはできますが、それはあくまでテストケースの導出元として関連付けを行い、テストのカバレッジを測定することが目的です。要求間の構造があるわけではなく、あくまでもテストケースとの親子関係のみ。
テスト観点の十分性や関連については別の何かで行うことが暗黙の前提であり、テスト管理ツールを適用する段階では、要求と観点がすでに十分に抽出・整理されていることを意図しているように思えます。
テスト設計も同様です。
「要求」と「テストケース」は関連づいていますが、その間をつなぐ「どのようにこのテストケースを導いたのか」「どのような網羅性があるのか」という情報をカバーできていないように思います。そこには、表だったり図だったりが入ってきがちなので、テキストだけだと心もとない部分ですよね*1。
ということで、テスト分析やテスト設計を統一的に扱えるツール*2がテスト管理ツールはに統合されたら、最強だと思います。
おわりに
以上、PractiTestという素晴らしいテスト管理ツールをネタに、テスト管理について自分の言いたいことを言うシリーズでした。無計画に始めたので構成も何もぐちゃぐちゃですが、直す気は特にありません。
最後に突然のフォローのようですが・・・、
PractiTestは、テスト管理ツールが標準的に備えている機能はもちろんのこと、現場で直面する課題を解決するための機能も含めて手堅く押さえた、充実したツールだと感じました。そもそも使い方に迷うことが少ない作りに仕上がっているのですが、公式Web、動画、オンラインヘルプデスクを整備して、「使うのを諦める」ことがないように工夫されています。おかげでこのシリーズも、だいぶ楽しむことができました。
すでにメジャーなツールなのでわたしが言うのもおこがましいですが、テスト管理ツール導入の際は有力な選択肢の一つになることは間違いないです！
PractiTest社のみなさま、トライアルさせていただきありがとうございました。
