BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 継続的デリバリーはテストにどんな影響を及ぼすか

継続的デリバリーはテストにどんな影響を及ぼすか

ブックマーク

原文(投稿日:2018/10/04)へのリンク

継続的デリバリーでは、コードを書きながら品質に重点を置く必要がある。全てのチームにテスターがいるわけではないが、もしいるなら開発者と密に仕事をして、開発者がユニットテストを作成するのを手助けしながら、ユニットテストでカバーできない少数のテストを自動化するコードを書くことになる。

eXperience Agile 2018において、Industrial Logic CanadaのCEOであるJeff Morgan氏は、継続的デリバリーがテスターの仕事にどんな影響を及ぼすか語った。InfoQでは、eXperience AgileについてQ&As、要約、記事で取り上げる。

継続的デリバリーのパワーはすばやく本番環境で実験することだ、とMorgan氏はいう。これにより、プロダクトのアイデアをユーザーで迅速にテストし、結果に関するデータを収集することができる。

ユニットテストではアプリケーションの大部分がテストされる。手動のテストはなく、自動化がテストを回している、Morgan氏は主張する。ハードニングフェーズはなく、最初から質を高める必要がある。

Morgan氏は、テストの専門知識が必要な場合、専門家を連れてきても、テスト自体を書かせるのではなくチームと一緒に仕事をさせるよう提案した。チームは、専門家ではなくテストを所有するのだ。

テスターがますます技術的になり、開発者がますますテストのことを知っていくと、やがて開発者とテスターの多くは区別がつかなくなる、Morgan氏は語る。

継続的デリバリーがテストにどんな影響を及ぼすのか、InfoQはMorgan氏にインタビューした。

InfoQ: 組織が継続的デリバリーを採用すると、ソフトウェアの作り方や届け方にどんな変化がありますか?

Jeff Morgan: 一番の変化は、作ってからテストフェーズに入るという従来のソフトウェア開発アプローチがなくなることです。継続的デリバリーでは、コードがソースコード管理にチェックインされ、デプロイメントパイプラインを流れると、すぐに本番環境へとデプロイされます。

この大きな変化は、テストと開発は同時に行う必要があることを意味します。実際、私たちは通常、開発とテストを別の2つのアクティビティだと見なしません。テストは開発全体の一部にすぎません。この変化は、テストの自動化、デプロイメントの自動化、環境の自動化といった、ずっと高度な自動化に依存することも意味します。

InfoQ: 継続的デリバリーは品質についての考え方にどんな影響を及ぼしますか?

Morgan: 品質はたいてい、リリース直前のデプロイメントサイクルの最後に、検証/追加するものだと思われています。これはハードニングフェーズと呼ばれることがあります。継続的デリバリーでは、コードをチェックインするとすぐに本番環境に投入されるため、ハードニングフェーズは必要ありません。その代わり、コードを書くときは常に品質に重きを置く必要があります。私が働いているチームにとって、これはコードの書き方に対する根本的な変更でした。私たちは、ペアプログラミング/モビング、テスト駆動開発、ブランチの廃止、フィーチャートグルといったプラクティスを採用しています。開発者はこれまでよりずっと、テストと品質を意識しています。チームにテスターがいる場合、彼らは通常、少数のエンドツーエンド自動化と、探索テストにおける開発者とのペアリングに重点を置きます。非機能要件のテストは、テスターだけに属する従来のアプローチではなく、チームの「全員」に属します。非常に優れたチームでは、開発者とテスターとの間にほとんど区別はありません。

また、多くの人がDevOpsと呼ぶものを使って、システムからリスクを引き出しています。ビルドパイプラインは、様々な方法でテスト全てを実行することでリスクを軽減し、セキュリティ、キャパシティ、コンプライアンス問題といった懸念に対するテストを実行します。環境リスクを軽減するために、コンテナやInfrastructure as Codeが使われています。そして、ユーザーとプロダクトに対するリスクを軽減するために、小さな変更や実験のコントロールされたリリースが使われています。

InfoQ: テスターの仕事にはどんな影響がありますか?

Morgan: 最初に言っておくべきことは、この新しい世界において、全てのチームにテスターがいるわけではない、ということです。テスターがいる場合、彼らは手動のテストスクリプトを実行しているわけではありません。代わりに、開発者がテストをピラミッドのより下方、ユニットテストまで持っていく手助けをしながら、ユニットテストでカバーできない少数のテストを自動化するコードを書いています。テスターは開発者と非常に緊密なコラボレーションループにいて、パイプラインの構築を支援します。またデリバリー全体を通して、開発者とペアになって探索テストを実行しています。欠陥が見つかると、テスターは開発者とペアになって迅速に修正し、デプロイします。全ては開発者とのコラボレーションの中で行われます。

InfoQ: 「テストフェーズ」がない場合、テスターは何をすべきですか?

Morgan: 私の経験上、継続的デリバリーでは、従来の「アジャイル」と呼ばれるものよりもずっと多くのテストが行われます。また、テストは開発ライフサイクルの最後ではなく、様々なタイミングで至るところで行われます。私たちはシステムの品質を認識するのに、自動化(主にユニットテスト)とパイプラインに大きく依存しています。

テスターは開発者と密に仕事をして、品質が維持されていること、欠陥がほとんど発生しないことを確かめる必要があります。テスターは通常、上記のピラミッドにある「ユーザーテスト」に重点を置きます。また、開発者とペアになって、彼らのテスト能力の獲得と向上を手伝います。ビルドパイプラインの定義にも一役買います。

セキュリティや負荷/パフォーマンステストのエキスパートといったテスト専門家が必要になるときもあります。このような場合、彼らはチームと相談して、パイプラインのそれらステージで実行するテストスクリプトを作成し、保守することになります。

パイプラインは多くの点で、これまでの「テストフェーズ」に非常に近いものです。パイプラインは、コードをチェックインするたびに全てのテストを実行し、最終的にコードを本番環境にデプロイする場所です。パイプラインは全て違っていますが、チームごとによく見られるコアパターンがいくつかあります。チームが持っているステージの例を以下に示します。

  1. ユニットテストを構築し、実行する。
  2. 静的コード解析を実行し、品質が達成されなければ失敗する。
  3. 作業中のフィーチャートグルをすべてオンにしてデプロイし、未リリースの振る舞いに重点を置いたテストだけを実行する。自分たちのコントロール外にあるバックエンドシステムは、すべてモック化しなくてはならない。
  4. 作業中のフィーチャートグルをすべてオフにしてデプロイし、リグレッションのために残り全てのテストを実行する。テストは高速に実行でき、パラレルに走らせる必要がある。また、自分たちのコントロール外にあるバックエンドシステムは、すべてモック化しなくてはならない。
  5. トグルをオフにしてデプロイし、複数のブラウザやデバイスでテストの一部を実行する。バックエンドはモック化しなくてはならない。
  6. トグルをオフにしてデプロイし、モックなしにほんの一部のテストを実行する。これにより完全なインテグレーションが適切に機能することを確かめる。
  7. 静的および動的セキュリティテストを実行する。
  8. 負荷およびパフォーマンステストを実行する。
  9. コンプライアンステストを実行し、追加の運用前コンプライアンスタスクに対処する。
  10. 本番環境にデプロイする。

どこかのステージが失敗すると、パイプラインは停止します。

InfoQ: 継続的デリバリーを採用したい組織に何かアドバイスはありますか?

Morgan: 私が話す企業の多くは、継続的デリバリーを採用しつつあると言います。理由をたずねると、たいていは高速なデリバリーや品質改善について話します。これらも良いゴールではありますが、もっと重要なメリットがあると思います。私が思うに、継続的デリバリーを採用する一番の理由は、プロダクトを計画して届ける方法を変えることです。継続的デリバリーによって、労力がかかり推測を含む長期のプロダクトロードマップをなくして、代わりにもっと「リーンスタートアップ」アプローチをプロダクトデザインに採用することができます。私たちは正しいプロダクトを届けるために、実際のユーザー体験に基づいてすばやく軌道修正することができます。私はここに重点を置くべきだと思っています。

この道を進もうとする企業は、DevOpsは全ての問題に対する解決策ではない、ということを理解しなくてはなりません。DevOpsは重要な要素ですが、高品質な開発と組み合わせる必要があります。実際、私はまず品質を劇的に改善することに重点を置くことを提案します。これにはある程度時間がかかると思います。うまく進んできたら、継続的インテグレーションの追加を検討します。これにより、開発者はビルドプロセスで迅速なフィードバックを得ることができます。あなたは徐々にそれを、本格的なデプロイメントパイプラインへと拡張することがきます。

品質のカルチャーが組織に根付いたら、DevOps自動化を追加して、日に何度もデリバリーできるようになるでしょう。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT