2020/01/08
Tricentis Accelerate 2019 in Vienna に参加してきました
Author
奥村 和彦Kazuhiko Okumura
11/12 – 11/14 にオーストリアのウィーンで開催されたTricentis主催のイベントTricentis Accelerate 2019に参加してきました！
イベントの概要は一緒に参加した澤田が書いたブログをご覧いただき、私からはプリセールスエンジニアの視点でイベント報告を行います。
Tricentisの挑戦
まずは、Tricentisの基調講演やブレークアウトセッションを聴いて、特に興味深かった話をまとめました。
テストのスピードとアジリティを高めることを考える
ソフトウェア開発における「品質」と「スピード」の関係は日本でも度々話題にあがりますが、当然ながら品質を犠牲にするという選択肢はありません。
その考えはTricentisも同じです。彼らはカスタマーサクセスのためにテストが重要であると考えています。
そしてテストのスピード、特に「継続的テスト活動」のスピードを上げることを最大の挑戦と捉えていて、Accelerateにおけるその挑戦の答えとしては以下のように受け取りました。
- テストケースの作成スピードを上げる。
- テストケースのメンテナンス性を上げる。
- リスクを基に本当にテストケースだけに絞る。
プログレッションテストとリグレッションテスト
イベント最終日の基調講演では、Tricentisの創業者であり現在はCSO (Chief Strategy Officer)であるウォルフガング・プラッツ氏の例えにとても共感を持ちました。
彼は「リグレッションテストはスポーツジムのようなものだ。なぜならジムで定期的に体を鍛えておかないと、いざ運動といったアクティビティを行おうとしたときにケガをするからだ。」と言い、
ソフトウェアの新機能をアクティビティに例えて、リグレッションテストが無かったら製品は機能しなくなる。と話しました。
またリグレッションテストは既存機能に対する品質を維持するものであることに対し、新しい機能に対するテストのことを「プログレッションテスト」と話していました。
この「プログレッションテスト」と「リグレッションテスト」の考え方については、その後のブレークアウトセッションでも話がありました。
プログレッションテスト
顧客の新たな要望に応える新機能を市場に素早く投入する。なのでテストをシフトレフトする。
それには、SeleniumやAppium、BDD (Behavia Driven Development: 振る舞い駆動開発)と言ったスクリプトベースな技術でテストを行うとアジリティが良いそうです。
リグレッションテスト
リグレッションテストはすなわち既存機能の品質を維持するためのテストなわけですが、プログレッションテストで利用したスクリプトベースはテストコードのサイズが大きく、それを減らすのも難しい傾向になります。
つまり、過去に開発したテストコードが蓄積されることでリグレッションテストに時間が掛かってしまいます。
これを解消するために、リグレッションテストではビジネスプロセス視点で、モデルベースドによる自動テストを採用することがテストケースのメンテナンス性につながると説明していました。
ビジネスのリスクをカバーするテストケースに絞って回帰テストを行う
みなさんは「ソフトウェアテストのピラミッド」の例えをご存知でしょうか？
テストのレベルには、ユニットテスト → モジュール・コンポーネントテスト → インテグレーションテスト → E2Eテスト のようにテストの名称は違うかもしれませんが、フェーズやテストの対象によって実施するテストが異なると思います。
自動テストがほとんど利用されていなかった以前では、特に最後の方の出来上がった製品を評価するようなE2Eテストに時間を掛ける傾向があり、テストのボリュームが逆ピラミッドの形のようになっていました。
それがアジャイル開発や自動化テストを取り入れ始めたことで、ユニットテストやモジュールテストで基本的な品質を評価するようになり、インテグレーションテストやE2Eにも自動化テストを導入して、手動テストを本当に必要な最小限にして逆ピラミッドからピラミッドに変化させるという例えです。
Tricentis Accelerateでは、継続的テストのスピードを上げる目的で、ピラミッドの下層にあたる ユニットテスト や モジュールテストの量を減らすことで、ダイヤモンド型に変化させるという話が幾つか挙がっていました。
ではそういった、下層のテストを減らしつつ高品質なプロダクト開発を維持するためにはどうしたらよいのでしょうか？
カギはリスク分析
その方法の答えは、リスク分析です。
どういう事かというと、リグレッションテストのテストケースに紐づく要件にビジネスリスク度合いを関連付けて継続的テストを進めていくことで、重大なビジネスリスクに直結するテストケースが見えてくると説明していました。
TricentisではAIを活用して、ビジネスリスクのうちハイリスクに分類されるのは全体の80%であり、このリスクをカバーするだけならテストケース数を20%まで削減できるという分析結果が出たそうです。
これら分析は、ビジネスプロセスに着目したリスクベースドなテスト設計を行うことで実現可能となるそうです。
日々の継続的テストで実施すること
もう一つ、継続的テストでやるべきことを2枚の写真で簡単に説明します。
1つ目はコードをコミットしたときに行うテストの流れです。これらのテストは理想的な部分も多いですが、このような流れでやると良いということでした。
2つ目では、1つ目のコードコミットのタイミングでのテスト実施が難しい、負荷テストやE2Eテストの実施タイミングについての提案です。
負荷テストであればデイリーベースで実施し、E2EであればSelenium, AppiumおよびTricentisのモデルベースドな自動化テストツールToscaなどで分散実行することを挙げていました。
パートナー企業によるTricentis製品の導入事例
次にTricentisのパートナー企業の事例紹介セッションでの話も2つほどご紹介します
アジャイル開発でテスト管理が直面している問題点
世界的にも、これからアジャイル開発にシフトしようと取り組み始めている企業はまだまだ多く、シフトする理由のTop3は以下の通りだそうで、これは日本企業でも同じと思います。
- 74%: Softwareのデリバリーを加速させたい
- 62%: 優先度の変更を管理する能力を強化したい
- 51%: 生産性を向上したい
そしてアジャイルを採用した結果、（ビジネス価値を提供するソフトウェアのデリバリーに）失敗したケースも多く、その理由の半数が「テスト活動に起因した高品質なソフトウェアを提供できなかったこと。」だったそうです。
このセッションでは、アジャイル開発のテストが直面している問題点ベスト5 (以下参照)に対して、Tricentisのテスト管理ツールであるqTestで解消できることを説明していました。
- 手に負えないほど組織構造がサイロ化している
- 探索的テストが活用されず、UAT(受け入れテスト) も貧弱である
- テストの自動化が集中管理されていない
- 規制された職場で働いている
- レポートの見える化
アジャイル開発におけるテストが抱える問題点Top5であっても、qTestの各種アプリケーションおよびJiraとのリアルタイム連携といった機能によって解決することができ、アジャイル開発を成功に導くことができます。
大規模なシステムのリプレースでのテスト
こちらは保険会社のコアシステムの移行プロジェクトで実施したテストの事例紹介セッションでした。
このコアシステムは、いわゆるWebの三層アプリケーションに DBジョブを実行するバッチを組み合わせたよくある構成で、また保険会社が利用しているので「プロセスが複雑」「要件・機能がハイリスク」「ビジネスルールが多い」といった課題がありました。
今回の移行プロジェクトは、ウォーターフォール型でプロジェクトの開始からカットオーバー・プロジェクトの完了までに2年を掛けて以下のようなフェーズで進めたそうです。
- パイロット
- ワークショップ
- UIテスト
- DBテスト
- バッチテスト
- カットオーバーテスト（UAT）
- カットオーバー
- プロジェクト完了
※各フェーズの期間は3か月で、UIテストのみ半年。
各フェーズでは、要件に対して特定 → 整理 → 測定 といった作業で、リスク分析を行いハイリスクの要件からテストを進めていき、最終的なリスクカバレッジは90%以上となったそうです。
もちろんテスト実行もTricentisのToscaを使って自動化し、1000以上のテストケースを自動化しました。
ちなみに、要件管理や情報共有にはJiraとConfluence、CI/CDにはJenkinsを利用したそうです。
結果として、リスクベースドなテストケース設計やテストの自動化によって移行プロジェクトは予定通り進み、成功したとのこと。
移行後のシステムはアジャイル開発を採用して機能追加を行っていくので、今後はアジャイル開発におけるテスト管理の取り組み、探索的テストの導入、レポーティングやモニタリングの拡張といったことを進めていくため、話してはいませんでしたが恐らくqTestを導入することになるんだと考えています。
継続的テスト向上への挑戦は続く
最後にAccelerateを終えて、Tricentis社がこの先に見据えていることと、私の感想を述べて終わりにします。
ロードマップ
今後のTricentisのロードマップを聞いて、特に気になった点を３つ挙げます。
qTestとToscaの親和性を更に向上させる
qTestは元々アメリカのQASymphonyが開発していたテスト管理ツールで、Toscaを開発していたTricentisと2018年に吸収合併された経緯があります。
そのためqTestとToscaは、まだまだ連携性が弱いと感じる部分があり、両方に触れている私としては「こっちのこの機能が、あっちでも使えると良いのになぁ」と思う点が幾つもありました。
そのため今後は、お互いの製品で共通して利用できるような機能を分解・リビルドするような取り組みが始まるようです。
既にレポーティング機能においては、qTest Insightsの強力なレポーティング機能を更に拡張したような、Tricentis製品の統合的なレポーティングツールであるTricentis Analyticsがリリースされています。
来年にはテストケース設計やテストデータマネジメントに対しても統合的な機能がリリースされるようで、「テスト管理ツールのqTest」+「テスト自動化ツールのTosca」で、みなさんのソフトウェアテストをもっと強力に支援することができます！
SeleniumやAppiumと既存製品を融合させる
みなさんの中では既に、E2EテストでSeleniumやAppiumを利用されているかもしれません。
同じくE2Eテストの自動化ツールであるToscaはコードレス(Code-less)で自動化するため、コードベースのSeleniumやAppiumとは真逆に位置すると思われがちです。
Tricentisは決してそのような考え方ではなく、むしろToscaとSelenium/Appiumは同居できる存在で前述したプログレッションテストもコードベースで進めるべきだと話しています。
それを証明するかのようにSelenium/Appiumを取り扱ったブレークアウトセッションも幾つかありましたし、Tricentisも今後Selenium/Appiumと連携した動きを進めていくようでした。
AIをもっと活用していく
「AIでテストケースを何も無い所から自動作成する」が出来たらいいのですが、流石にそれは難しいと思うので、今回のイベントでは作成した多くのテストケースをAIで分析して、リスクカバレッジを維持したままテストケースを削減する取り組みを行っていることはお話させて頂きました。
その他にもテストケースをよりスピーディーに作成するために、”NEO”と呼ぶNeural Optical engineを利用して画面上のオブジェクト（部品）の位置を特定し、人の声を認識してオブジェクトを用いたテストケースを作ることが出来るようでした。
例えば「BDDでストーリーを語るだけで、そのままテストケースが作成できるようになるのかな？」と思いましたが、実際にテストケースの作成効率が上がるまでにはまだまだ時間は必要かなと感じました。
NEOのデモンストレーションが気になった方はこちらの基調講演動画をご覧ください。 (17分位から)
感想
ソフトウェアテストに関して持っている課題については、日本と世界でそこまで差は無いんだなと思いつつも、TricentisはGartnerのマジック・クラドランドのソフトウェアテスト自動化において唯一5年連続でリーダーに位置づけられているベンダーですので、AIやBIといった分析技術を活用することで、高品質を維持しながらテストのスピードを更に速くするという目標に対して1歩進んでいるという印象を受けました。
今回、Tricnetis Accelerateに初めて参加して、Tricentisの考えや文化を肌で感じることが出来たのは自分にはとても刺激になりました。
Tricentisのマインドを日本のソフトウェア業界に広めることが私やリックソフトの使命なんだなと大げさながらも責任感みたいなものを感じました。
最後に残念というか悔しかったこととして、自分の英語によるコミュニケーション能力の低さがあり、Accelerateの登壇者や参加されていたエンジニアと面と向かって話をすることが出来なかったことがあります。
来年のTricentis Accelerate(2020年10月予定)でもっと多くの情報を得られるようにこの点も頑張っていきたいです。
テスト管理ツールについてご興味ありましたら、お気軽にお問い合わせください
製品についてはこちらをご覧ください。
