ホワイトペーパー・記事
テスト自動化に関する記事は、順次公開され次第こちらに表示されます。
View More品質エンジニアリング
動くと分かっている。
顧客より先に。
変更のたびに走る自動テストを構築します。手作業の確認では 見逃していたリグレッションを捕まえ、リリースの判断を勘から青信号へ変えます。
品質エンジニアリング
変更のたびに走る自動テストを構築します。手作業の確認では 見逃していたリグレッションを捕まえ、リリースの判断を勘から青信号へ変えます。
課題
導入するのは、次の四つのどれかが実際に費用として効き始め、しかもそれが積み上がっているからです。
機能を出すたびに、次のリリース前に確認すべき項目が増えます。チェックリストはコードベースと一緒に伸びていきますが、それを消化するチームは増えません。
漏れる不具合は、たいてい新しい機能の中にはありません。すでに動いていたものが別の変更で壊れ、長い一週間の終わりに行う手作業の確認がそこまで届かなかった、というものです。
誰も予測しなかった問題を見つけられる人が、前のスプリントと同じ手順書をなぞっています。チェックリストを消化する方法として、これがいちばん高くつきます。
リリースの判断が、証拠ではなく自信でなされています。誰が何を、どれだけ前に確認したのか。火曜日の変更のあとに決済フローをもう一度見た人はいるのか。
なぜ積み上がるのか
これがこのページの論旨のすべてで、巧妙な話ではなく構造の話です。リリースのたびに、再確認すべき範囲が増えます。手作業でやるなら、その請求書を毎回まるごと払い直すことになります。
機能が増えるたびに、リグレッションの範囲は恒久的に広がります。リリース日を守る方法は、テスターを増やすか、テストを減らすかのどちらかです—そしてテストを減らすことが、不具合が顧客に届く経路です。
テストを一本足す費用は一度きりです。走らせる費用はほぼゼロで、それがずっと続きます。スイートはプロダクトとともに育ちますが、実行にかかる時間はほとんど動きません。
形状はイメージであり、実測値ではありません。御社のコードベースにおける実際の曲線は、アセスメントで把握します。
進め方
今どうリリースしているか、不具合が実際にどこから漏れているか、カバレッジが本当はどうなっているか。ここでは自動化しない方がよいものもお伝えします。捕まえる不具合より保守費用のほうが高いテストは負債であり、どのコードベースにも必ずいくつかあります。
何をユニットで、何をAPIで、何を画面越しに確認するか。この切り分けが仕事の大半です。画面のテストはいちばん遅く、いちばん壊れやすいので、本当にブラウザが必要なケースだけを担わせます。テストデータと環境もここで決めます—多くの自動化プロジェクトが静かに止まるのは、この部分です。
御社のスタックで書き、御社のリポジトリにコミットし、ほかのコードと同じようにレビューします。読むために料金を払い続けるベンダーツールの中に閉じ込めません。
3段階でテストは手に入ります。残る2つが、それを御社のチームが持つ統制に変えます。
プルリクエストとデプロイでテストが走り、失敗すればそれを止めます。誰も走らせないスイートはドキュメントです。悪いマージを止めるスイートは統制です。
御社のチームが自分たちで持てるようになるまで、グリーンを保ち、失敗をトリアージし、不安定なテストに対処します。この関与は、御社のエンジニアが保守する状態で終わるよう設計されています。当社への依存が残る形ではありません。
カバレッジ
各機能が意図どおりに動くかを、リリース前に手の空いた人がではなく、変更のたびに自動で確認します。
すでに動いていたものが、動き続けているか。自動化がいちばん元を取るのはここです。誰も手で繰り返したくない作業であり、飛ばされるまで誰も気づかない作業だからです。
サービス間の契約、そして御社が依存する相手との契約。画面よりも速く安定して確認できるため、カバレッジの多くはブラウザではなくここに置きます。
本当に重要な数本の経路—登録、購入、送信、決済。性質として遅く壊れやすいので、システム全体が本当に必要なケースだけを担わせます。
想定どおりの負荷と、想定外の負荷でどう振る舞うか。キャンペーンが走った朝ではなく、テスト実行の中で見つけます。
開発チームがたまたま使っているブラウザではなく、実際の訪問者が使っているブラウザで同じ導線を確認します。
ネイティブアプリとハイブリッドアプリを実機プロファイルで。レイアウトと入力の挙動が十分に違うため、デスクトップのカバレッジはそのままでは通用しません。
マージやデプロイを止める権限を持たせた形で、パイプラインに組み込みます。誰も走らせないスイートはドキュメントで、ゲートは統制です。
再現できるデータと、きれいに初期化される環境。地味ですが、多くの自動化プロジェクトが静かに止まるのはここです。
成果物
作業をしたという報告書ではありません。成果物そのものが、御社のソース管理に、御社のライセンスで、当社がいなくなったあとに向き合うエンジニアが読める形で残ります。
率直に言うと
このページにパーセンテージはありません。意図的です。
テストのベンダーは数字を掲げます—テスト時間が何パーセント減る、という類のものです。当社はそれを外しました。正直に言えば、その数字は御社のコードベース、リリース頻度、そして今どうしているかに全面的に左右されるからです。御社のコードを一行も読まずに数字を出す相手は、どこか別の会社のプロジェクトの数字を出しています。
代わりに当社がするのは、アセスメントで御社の基準値を測ることです—今リグレッション確認に何時間かかっているか、どれだけの不具合が本番に届いているか、リリースがどれくらいの頻度でずれているか。そのうえで、御社自身の出発点に対する変化を報告します。その数字には意味があります。御社のものだからです。
サービスの背景
テスト自動化は、当社にとって付け足しの提供物ではありません。自社ソフトウェア製品のうち二つに組み込まれており、それを作っているエンジニアが、御社のスイートを担当します。
AIを活用した当社の開発プラットフォームで、開発とエンドツーエンドのテストをまとめて自動化します。締め切りが過ぎてから後付けするのではなく、コードと並べてテストが書かれます。
当社のQA・セキュリティプラットフォームで、エンドツーエンドとAPIの自動テスト、セキュリティテスト、脆弱性スキャン、コンプライアンス分析をカバーします。近日公開—そしてこのページの実務が、その出どころです。
Webとエンドツーエンド
Selenium · Cypress · Playwright
テストフレームワーク
JUnit · TestNG
モバイル
Appium
性能と負荷
JMeter
お尋ねいただく前に
いいえ—そしてそうだと言うベンダーが売っているのは、品質ではなく人員削減です。自動化は既知の確認を速く繰り返すことは得意ですが、誰も見ようと思わなかったものに気づくことは絶望的に不得意です。これは繰り返しをテスターの手から外し、二番目の種類の仕事に充ててもらうためのものです。そちらこそ、採用した理由のはずです。
それはたいてい、自動化しない理由ではなく自動化する理由になります—プロダクトが速く動くほど、背後で静かに壊れる頻度は上がります。ただし何を自動化するかは変わります。動きの速い画面は最小限に、安定したAPIと事業上重要なフローには厚く。半年後も元を取り続けているのは、そちらのテストだからです。
御社のチームです—だからこそランブックと引き継ぎは、締めの形式ではなく作業の一部として入っています。移管が終わるまでは当社が保守します。長期的に当社が運用し続ける形をご希望であれば、それは別の契約であり、なし崩しにせずそうはっきり申し上げます。
不安定なテストは、テストがないよりも悪いものです。人が無視することを覚えたスイートは、費用がかかり続けたうえに、誤った安心まで与えるからです。トリアージは、目立つほどひどくなってから着手するものではなく、スイートを運用することの一部です。
事業上重要なフローを一本に絞ったパイロットから—購入、登録、壊れるといちばん痛むものなら何でも。そのフローについて動くスイートが御社のパイプラインで走る状態と、同じやり方をプロダクト全体に広げたときにどうなるかの見通しが手に入ります。その先を決めるのは、そのあとで構いません。
どうリリースしているか、不具合がどこから漏れているか、基準値が実際にどうなっているかを見たうえで、何が自動化に値して何が値しないかをお伝えします。答えが「思っているより少ない」であれば、それもそのまま申し上げます。