HCL OneTest - Working to Make Maintenance Easier の翻訳
HCL OneTest - メンテナンスを容易にするための取り組み
2022年1月21日
著者: Peter Taylor / SENIOR SOFTWARE ARCHITECT
HCL OneTestは、企業がソフトウェアの品質を向上させ、デリバリーライフサイクルの早い段階で問題を発見することを可能にする製品群を提供します。この製品群は、UI、API、サービスの仮想化、パフォーマンスなど、さまざまな側面のテストを可能にします。では、どのようにすれば効果的にテストを行い、メンテナンスが必要な多くのテストをチームに負担をかけずにアジャイルな状態を維持できるのでしょうか?ここでは、統一された次世代アプローチによってテストのメンテナンスを容易にするために、私たちがどのように取り組んでいるかをご紹介します。
統一的なアプローチは、各アスペクトごとに製品を用意するよりも、単一の製品にした方が誰もが暮らしやすくなる、というコンセプトから始まります。そこで、既存の製品でお客様が評価している機能を、ひとつの一貫したフレームワークにまとめた新製品を作る予定です。これにより、ユーザーはUI、API、パフォーマンスのテストや、サービスの仮想化を1つの製品で簡単に実行できるようになります。
シンプルであることに重点を置いているため、どうしても複雑になりがちな製品をただ寄せ集めただけでは理解できない。つまり、複雑になりすぎて理解しにくくなるような製品同士をくっつけることはできないということです。足りない部分は既存の製品で補うことができますし、今後もサポートは継続します。
テストが壊れたら、いつ直すの?今すぐか絶対か?この質問を評価するためには、「テストの数」ではない品質の指標が必要です。そうでなければ、テストを削除することで品質が低下してしまいます。
そうでなければ、テストを削除することは品質を低下させることになります。目標は常に、高品質のソフトウェアを生産に移すことです。このゴールは、生産時の失敗を減らす場合にのみ遅らせるべきです。もしテストが、失敗を減らすことなく目標を遅らせるのであれば、それはおそらく維持する価値がない。
テストの価値を判断するために、その製品はテストに関するいくつかの指標を提供する必要があります。実行時間は簡単なもので、テスト対象のシステムにおけるコードカバレッジはより複雑なものです。
テストはコードの後に書かれることが多いのですが、テスト駆動開発ではこれを改めようとします。コード優先の理由は、その方が簡単に始められるからだ。結局のところ、テスト対象システムが利用できないため、テストは失敗する。しかし、サービス仮想化の統合により、オフラインでテストを実行し、テスト対象のシステムが利用可能になる前に、テストがどのように動作するかを実証できます。最初に書かれたテストは、実装よりも振る舞いを検証するため、より長く使え、メンテナンスの必要性も低くなります。
メンテナンスがすぐに必要なのではなく、スケジュール化できるようなストラテジーを組み込めます。
ユーザーがタスクを切り替える前に、変更の意味を理解できるように、できるだけ早くユーザーにフィードバックすることに重点を置いています。
既存のテストをコピーして少し手を加えるだけで、新しいテストを作ってしまうというミスを犯しがちです。これをやったことがない人はいないでしょう。しかし、今日のクイックウィンは、明日のメンテナンスの頭痛の種です。これは、以下の方法で最小限に抑えられます。
HCL OneTest 製品群の進化を続ける中で、皆様からのフィードバック、アイデア、ペインポイントなどを https://onetest-ideas.hcltechsw.com/ideas でお待ちしています。