テストエンジニアリング、DevOps のこれから #testingcasual
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。
テストのエンジニアリング
トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。
テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべきだ･･･ などなど。淡々と発表されていたが、内容からは色々と熱いものが伝わって来てこちらも高揚するような話だった。
Googleのテスト
ところで、同じような趣旨の話を最近どこかで目にしたぞ･･･という気がしていた。
テストから見えてくるグーグルのソフトウェア開発
posted with amazlet at 13.07.26
これだった。
Web では話題になっているようないないような感じだが、この本はなかなか素晴らしい本で、Google が今のテストエンジニアリング体制･･･いや、体質といったほうがいいかもしれない、をそれがないころからどうやって構築していったか。また、構築できた現在においてどういう役割分担でそれを日々行っているかということが書かれている。
@ikasam_a さんの発表にはこの Google テスト本の主張と共通している項目が多かった。つまり、今時のエンジニアリングにおいてテストのことを真剣に考えたらおそらく半ば必然的にこういう結論・実践に達するということだと思う。
Productivity
発表スライドには "Productivity" という単語が何度も出てくる。
テストは開発者の Productivity を向上させるものであり、開発者を縛って Productivity を低下させるものであってはいけない。
正しいテスト自動化を行ったことがあるエンジニアは、テストが自分のソフトウェア開発をどれだけ助けてくれるか、それがどれだけの生産性向上に繋がるかをよく知っている。テストや QA は本来、開発を助けるための手段である。しかし、なぜかそれが反転している･･･というケースは多い。
Google のテスト本で面白かったのが "チームの名前を「Developer Productivity」にしたらみんなが前向きにテストについて議論するようになった" というくだりだった。テストチームのミッションはテストを実践させることではない。開発者の生産性を向上させ、延いてはビジネスのスピードを高めて業績に貢献する。その手段としてテスト自動化の実践を行う。Developer Productivity という名前によって誰もがそのゴールを想像しやすくなった。
Google本にも、@ikasam_a さんの発表にもあるとおり、近年まじめにテスト自動化を推し進めようとすると、そのためにコードを書いたり検証を行ったり、あるいはテスト専用のインフラを構成したりといった必要が出てくる。テストエンジニアたちはアプリケーション開発者と一緒になって、どういうテストインフラがあれば開発者がより助かるか、どういうテストを書けば開発の負担を減らすことができるかということに邁進し、Productivity を底上げする。
単にテストするというだけに留まるのではなく、アプリケーション開発者 (Dev) へ、テストという文脈で付加価値を提供するのがテストエンジニアリングチームのミッションになる。
Dev への付加価値向上 ･･･ これからの DevOps
「攻め」である開発部門と「守り」である品質保証部門がその攻めと守りの姿勢の違いでうまく歯車が噛み合わない。それを同じエンジニアリグの文脈で考え直して問題を解決しましょう･･･ これもどこかで聞いた話。そうそう、DevOps。Dev vs Ops から、Ops に Dev 的アプローチを取り入れることで Dev and Ops に。
先日、じげんで行われた はじめる DevOps という別の勉強会で DevOps について話してきた。スライドは以下に上げている。
昨今 DevOps 界隈では、AWS などのクラウド、Chef や Ansible といったプロビジョニングフレームワーク、それから serverspec のようなインフラテスト自動化といったテーマが盛んに議論されている。大いに結構。ただ、DevOps も先のテストの話に同じくゴールはただの自動化ではない。インフラチームが自分たちの仕事を自動化して楽になる、というのももちろん大切だけど、それは第一段階でしかなくその先にはその自動化されたインフラによって Dev を下支えし、例えば Dev がインフラが欲しいと思ったその直後にオンデマンドでそれを提供するとか、そういうことによってより Dev への付加価値を向上していくというのがミッションになっていくべきだ。
スライドの後半では、DevOps のこれからが垣間見える実装として Docker や Strider CD を紹介した。Docker や Strider CD は、「Vagrant + Chef + serverspec でインフラ構成を自動化しました」よりも更に上の価値提供を行えるポテンシャルがある。Strider CD は典型的で、これは自分たちのインフラに PaaS/SaaS 的な要素を付与する。開発者たちは Github に git push するだけで、Strider CD がアプリケーションテストを複数プラットフォームで自動で実行し、テストが通ったならばすぐにそれを Heroku への Deploy する･･･といった Continuous Delivery の恩恵に預かることができる。デプロイが苦痛ならそれを自動化してしまえばいい、というところを更に一歩推し進めて、コードレポジトリとテストインフラとプロダクションインフラをセットにしてしまって、Dev に「Git push するだけでそれが全部行われますよ」という付加価値を提供している。
Dev 的アプローチによってインフラを自動化したことにより、今後それらはよりサービス的な性質を帯びていくというのが DevOps の目的的にも技術的アプローチとしても妥当な線ではないか･･･ 「DevOps のこれから」と題してそんなことを妄想したのだった。
whitesnake
従来インフラ的だったものが、仮想化や自動化でパッケージングし直すことによってサービス的な性格を帯びたものといって自分が真っ先に想像するのは Travis CI。
Github に置いたオープンなレポジトリを、git push を契機に勝手にテストしてくれる。テストのための仮想サーバーはオンザフライで構築されて、テストが終わると破棄される。テストが失敗してるとメールや IRC その他で通知してくれるし、なにより pull request で来たパッチも自動でインテグレーションテストしてくれるのがいい。pull request をマージするのに、わざわざ自分テストしなくてもグリーンである、というのが保証される。pull request を受ける側、送る側双方の負担を劇的に減らしてくれる、まさに Dev のための Ops サービス。
テストエンジニアリングも DevOps も、Dev への付加価値向上がこれからのミッションになる、と述べた。そして DevOps のインフラはよりサービス的性格を帯びていく、単純化して言えば組織の中のインフラもこれからは PaaS 的にアレンジされていくとか、そういうのが未来なんじゃないだろうかと思っていた。
ここで Testing Casual Talks #1 に戻る。
クックパッドの @mrkn さんによって発表された whitesnake はまさにそれだった。
クックバッドでは 1,000 個ものモデルを含めた巨大レポジトリのテストに Jenkins を使っているが、それだけの規模になるとその Jenkins の設定運用もそれなりのものになる。カジュアルに新しい CI プロジェクトを回して、というものでもなくなる。でもエンジニアにはもっとカジュアルにテストをして欲しい。だったら Jenkins と連動する Travis CI のようなフロントエンドを作ってしまえばいい。開発者は社内の Github Enterprise に push するだけで、Jenkins でのテストが始まる。すごい。
そんなわけで、未来と思っていたこれからの DevOps というのが、テストエンジニアリングの文脈ではすでに現在になっていた。Google 本といい、テスト自動化と DevOps の関連といい、ここ最近追っていたこと思っていたことが色々と繋がったもので、ちょっと熱くなって、こんなブログを書いてしまうに至ったのである。
