Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア（Automation Architect）のブログです。

「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題

継続的システムテスト

 「継続的デリバリー」(*1)の章の構成はとても興味深い。第一章では「The problem of deriverling software」というタイトルで、ソフトウェア開発の目的を顧客に価値をデリバリーする事とし、その上でリリースにまつわるアンチパターン３つの紹介から始まる。

* Deploying software manually

* Deploying to a Production-like Environment Only after Development Is Complete

* Manual Configuration Management of Production Environments

これは「継続的デリバリー」というタイトルから考えるに妥当に感じるかもしれないが、一度考えてみて欲しい。

 

何故リリースにまつわるアンチパターンの紹介から始まるのか？

 

 それはソフトウェア開発に関する問題の多くが顧客に価値を届けるvalue streamの入り口と出口に潜んでいるから。

 ここで素晴らしい事は入り口に関する問題の解決方法は多くの良書で語られている事。アジャイル関連の本には特に多い。残念な事は出口に関する問題の解決方法を語っている本は「継続的デリバリー」くらいしかない事。「継続的デリバリー」自身が第一章1pで語っている。

There are many software development methodologies, but they focus primarily on requirement management and its impact on the development effort. There are many excellent books that cover in detail different approaches to software design, development, and testing; but these, too, cover only a fragment of the value stream that delivers value to the people and organizations that sponsor our efforts. 

 

 「継続的デリバリー」が出版された頃と比較して、CIツールや自動テストツール等、デプロイメントパイプラインを構成する技術要素が進化、普及し簡単に継続的デリバリーを実現出来るようになった。AntやMavenでビルドを自動化する事、Seleniumを使って画面テストを自動化する事、Jenkinsを使ってそれらの自動実行をスケジューリングする事 、ChefやFabricでprovisioningやdeployを自動化する事。どれも手軽に出来る。

 その一方で、ウォーターフォールへのテーラリングやお手軽なテスト自動化などが進み、変な継続的デリバリーが増えてしまっているように思う。変な継続的デリバリーは出口の問題を解決しないので、開発もテストも運用もどんどん疲弊していく。単体テストでコードカバレッジ100%を目指す「自動化ハイ」なんかはその典型的な例だろう。

 継続的デリバリーが手軽に実現出来るようになった今では、冒頭で紹介されているリリースにまつわるアンチパターンは、継続的デリバリー実現のアンチパターンと読み替えてもいいかもしれない。

  • プロビジョニングに関する環境の構成管理とデプロイ方法を自動化する事で、疑似本番環境へのデプロイを毎週、または毎日行っていますか？
  • 毎週、または毎日デプロイを行う事で、デリバリーが成功すると自信を持って言えていますか？

「リリース」というソフトウェア開発プロジェクトの中で大きなリスクを伴うプロセスを擬似的にプロジェクトの初期から継続的に実施する。それによってそのリスクを大幅に減らす事が出来る。そういう世界だからこそ、開発者はその設計や実装のスキルを発揮出来るし、テスターや運用者は要求や設計に関わるフィードバックを回す事が出来る。「デプロイメントパイプライン」の中での品質の作り込みを実現していく事が可能になる。

参考文献

(*1)


楽天ブックス: 継続的デリバリー - 信頼できるソフトウェアリリースのためのビルド・テス - ジェズ・ハンブル - 4048707876 : 本

プロトタイプはリアルプロダクトたりえないのか？　〜そのテストはプロジェクトのリスク管理に貢献していますか？〜

継続的システムテスト

　ソフトウェアプロダクトを開発する時、色々なリスクが想定される。今から開発するプロダクトは本当に顧客の要求を満たすのか？選定した技術要素は本当に設計要求を満たすのか？プロジェクトは期限内に終るのか？

　そんなソフトウェア開発プロジェクトのリスクを軽減する方法として、プロジェクトの最初にプロトタイプを作成し、仮説を検証する方法がしばしば取られる。プロトタイプを作成し顧客要求の仮説を検証する。プロトタイプによって設計要求に対する仮説を検証する。などなど。

 

あなたはこの「プロジェクトの最初に作成したプロトタイプ」を仮説の検証が終った後に捨てていませんか？

 

　もし、このプロジェクトの一番最初に作成したプロトタイプを捨てているのだとしたらなんともったいないことか。だってそのプロトタイプはプロジェクトの重要な仮説を検証しているのだから。リアルプロダクトとしてきちんとテストして、そのテストを自動化すれば、プロジェクトの期間中ずっとリスクが顕在化していない事を確認する事が出来る。

　テスターは、しばしば品質保証の対象を「完成したプロダクト」に限定する。でも、Leanな開発プロジェクトでアジャイルテスターは「これから開発するプロダクト」のリスクも検証する。だからプロダクトオーナーやアーキテクトとのコミュニケーションが求められる。

　ウォーターフォールにおけるテスト自動化では、しばしばテスト自動化の本質を「工数削減」に置く。でもLeanな開発プロジェクトでアジャイルテスターは、テスト自動化をリスク管理をするためのツールとして使う。加えてプロジェクトのプロセス品質とプロダクト品質を継続的に計測しフィードバックする。

　Leanについては、平鍋健児さんの"リーンとカンバンの本質"の6pのスライドをご参照ください。　http://www.slideshare.net/hiranabe/lean-from-the-trenches

　Leanの開発プロジェクトで、何故こんなに細いテストプロセスで品質保証が可能なのか？その本質はアジャイルテスターがテスト自動化と継続的な品質改善によってプロジェクトのリスク管理に貢献するからである。

IT勉強会からの越境　#devlove

勉強会

　このエントリーはDevLOVE Advent Calendar 2014の1月10日の記事として執筆しています。 

執筆のモチベーション：

　昨年度の私のJaSSTやSQiPでの事例発表が「IT勉強会からの出口」「IT勉強会からの越境」として取り上げられていた事を受けて、それをテーマに記事を書いてみようと思いました。

　あまり「越境している」という自覚はなかったのですが、上記で取り上げられているのを読み、あぁ自分はIT勉強会から越境していたんだなと気付きまして。越境をテーマにしているこちらのAdvent Calendarに

  • IT勉強会との関わり
  • 何故IT勉強会から越境したのか？
  • 越境して気付いた事
  • 越境を阻むものを乗り越える

について、Fearless Change のパターンを参考にしつつ書きます。

 

Fearless Change

　自分の社内勉強会の活動やIT勉強会からの越境は『Fearless Change』のパターンの文脈で考えてみるとすごく伝えやすいと思います。


楽天ブックス: FEARLESS CHANGE - アジャイルに効くアイデアを組織に広めるための４８の - マリリン・マンズ - 462108786X : 本

 

　昨年度のデブサミで監訳の川口さんのご協力のもと著者のサインを集めてからこの本を読み込みました。何かを変えたいと思ったエバンジェリストが組織や社会にその活動を広めていくためのヒントが詰まっている本です。そのヒントも「何か食べながら」「便乗」など結構身近な方法が多く、スラッと簡単に読める本です。

 

IT勉強会との関わり

　自分とIT勉強会との初めての深い関わりは社内で「テックトーク CIスペシャル」という勉強会を企画してからです。この頃はテスト自動化に苦しんでいる時期で、ただ漠然と仲間を増やしたいという気持ちで企画しました。昨年私の周囲では「ぼっち」という言葉が流行したりしましたが、面白いのは社内勉強会は「ぼっち」をつなぐ役目を果たしている面がある事です。

　エンジニアとして自分の仕事の価値を考えた時に、現場で例えば「テスト自動化したい」「キレイなコードを書きたい」「運用設計を開発にフィードバックしたい」といった想いを抱く事があると思います。難しい点はそういった想いを持ったエンジニアは現場では最初少数派である事が少なくない事。特に上に挙げたようなテーマは「クラウド」や「ビックデータ」などと違って、わざわざそれについて組織として特別力を入れようという話にまでなかなかいかないのが難しいところでして。でも、各部署に一人や二人そういったところに悩んでいたり取り組んでいたりするエンジニアがいたりします。

　そういった「部署内ぼっち」をつなげる役目を社内勉強会は一つ担ってるのかなあと感じます。Fearless Changeのパターンで言うと

  • 勉強会(25）
  • 体験談の共有(32)

ですね。

　またIT勉強会にも似たような側面があるのかなあと思います。例えば社内にアジャイルを導入したい、でも自分は社内では少数派、といった場合に社外の同じような経験や悩みを抱えている人と共有するだけでも色々と楽になる事があります。

 

何故IT勉強会から越境したのか？

　もともと自分の中には「越境しよう」というモチベーションはありませんでした。ただ漠然と「エンジニアなら技術で仕事して特許取ったり論文書いたりするのが当たり前でしょ」という考えがあります。なので、いつも仕事をしながら目の前の技術を見て「これはLTネタになるかも」「これは特許がとれるかも」とか「これは論文になるかも」とか、業務とは別の軸での着地点を考えています。

　JaSSTやSQiPなどの発表についても、２年間続けて構築してきた自動テストプラットフォームについて"なんとなく"論文になるんじゃないかと思ってまとめてみたというのがホントのところです。。（ホントは経験論文にしたかったのだけどまとめるまでの時間の都合で事例発表になっていますが 笑）

 もちろんビジネスとしての出口の「成果」やサービスとしての出口の「リリース」も重要です。それと同じくらいエンジニアリングとしての出口の「特許や論文」も大事だと思っていて、そのバランスがうまくとれている会社や仕事はステキだなあと思っています。

 

越境して気付いた事

　そんな曖昧なモチベーションで越境してたのですが、越境してみて実際に色々な気づきがありました。

① 客観的なデータと論理構成に基づく発表

　テスト自動化について仮説を立て、色々な施策を実行しその結果をデータ分析に基づいて客観的に考察したSQiPの発表は、テスト自動化や継続的インテグレーションの導入について決断を下す責任ある役割を担っている方達に特に刺さっていたという話を後から何度か聞きました。

　業界の有識者が集まるシンポジウムという事で客観的なデータ分析と論理構成に特に注力してまとめたのですが、結果的にそういった立場の方達が判断をする際のリフェレンスにして下さっていたり、「あの発表から勇気をもらった」と直接コメントを頂いたりしました。

　IT勉強会の発表では感情に訴えかけるような発表もしばしば重要です。Fearless Changeを一緒に行う現場レベルの仲間を探す時には効果を発揮するし、実際僕自身もそういった発表に救われた事が何度もあります。一方で感情を抜きにした論理的な発表は、少し年配の方や責任ある立場の方に対して

  • 達人を味方に(14)
  • 経営層の支持者(28)
  • 身近な支援者(35)

といったパターンが期待出来るという事が気づきとしてありました。

 

② 襟を正して参加するようなシンポジウムは意外と効果がある

 　襟を正して参加するようなシンポジウムの効果は意外と大きいなという事も感じました。

　私の周囲では何がテスト自動化の正解なのかよく分からずみんな手探りであれこれと試しながら成果を出したり失敗したりというのが実情として多いです。で、①でも触れたように、ある層の方達がテスト自動化の成功事例として参照して下さっていたのですね。ソフトウェア品質の有識者が集まるシンポジウムでの発表、しかも賞を頂いたという事が

  • 外部のお墨付き(12)

を得て、テスト自動化の正解パターンの一つとして周囲に認知された背景にあるのかなあと感じます。

 

③ 振り返りと有識者のフィードバック大切

　有識者に見て頂く発表としてまとめる事で、自分達の仕事や成果を俯瞰して振り返る時間を持つ事が出来ました。そういった時間から、例えば「あの時自分たちはAというアプローチで問題を解いたけど、実はBやCといった解き方もあった」など、日常の業務の中からはなかなか得られない気づきを得る事が出来ます。

　また外部の有識者と話す事で、自分たちにとっては当たり前だった"変化"が一般的にはそうではなく、じゃあ何で自分たちのケースではうまくいったのだろうとコンテキストの違いや、ちょっとした工夫の効果について深く考えてみるきっかけとなった事もありました。

　普段の業務から考えるとちょっと特別な

  • ふりかえりの時間(5)
  • 達人のレビュー(31)

を得る事で、日常の仕事の中からはなかなか見つけ出す事の出来ない気づきを得るきっかけになると感じます。

④ Fearless Changeはパターンの積み重ね

　発表を作るにあたってたくさんの専門書を読んだり社外のエキスパートの方達と議論をする中で、エンジニアリングの世界には正解パターンがある事も多いという事を感じました。自分の業務の中に閉じこもっているとなかなか気付かないのですが、業務で出くわす様々な問題や悩みは、もうすでに誰かが解いている事も多いのですよね。

　この２年の中でかなりの数のソフトウェアテストや品質の研究論文を２年の中で読み、また自分でもトライしてみました。その経験の中で、何がもうすでに解かれている問題なのか？それらの問題はどのようなアプローチで解かれているのか？何がまだ解かれていない問題なのか？を自分の中でかなり整理出来てきたのかなあと思います。引き出しの中の正解パターンの数がこの２年で100倍〜1000倍に増えている 笑。

　もちろん、過去の研究や正解パターンを完全に否定する事で起きるイノベーションがある事も重々承知しています。一方で、大きな問題を分解し

  • 種をまく(22)
  • 適切な時期(23)
  • ちょうど十分(34)

といった小さな正解パターンを

  • ステップバイステップ(3)

で積み上げていくだけでも解ける事がたくさんある、そしてその積み重ねがFearless Changeそのものなんだなあと思います。

 

最後に：越境を阻むものを乗り越える

　ボキャブラリーや文化、考え方の違いが越境を阻む事も少なくないですよね。IT勉強会とシンポジウムや研究会はそういった違いが敷居の高さを作ってるように感じる事があります。ですが、その壁はきっとエンジニア個人の努力で乗り越えられる。

　例えば「アジャイル」と「品質保証」はお互い相容れないと考えられていた時期というのがあったように思います。それぞれが出て来た文脈が違うので一見すると全然異なる事を主張しているのではとギョッとする事があるのかもしれません。でも「継続的デリバリー」と「ソフトウェア品質知識体系ガイド」は、サービスやソフトウェアの品質を継続的に改善して行こうという目的は一緒です。また、たくさんのエンジニアがそれぞれの分野の『越境』をくりかえしてきたため、そこで主張されている方法論についてほとんど矛盾を感じません。

　先日、ソフトウェア開発について「テスト」も「レビュー」も「XP」についても造詣の深いエキスパートの方に「色々な分野でご活躍されてますがご専門は何ですか？」と質問しました。その方の答えは「特に１つの分野に限定して専門を考えた事はない。どんな分野のエキスパートともディスカッションをすると興味深い知見が得られるし、そのためにどんな分野についても議論出来るように勉強している」というものでした。

　目的さえ同じならば、ボキャブラリーや文化、考え方の違いは個々のエンジニアの努力次第で乗り越えられるんだなあ、越境を繰り返すエンジニアによって技術の進歩は支えられていると実感させて下さる、偉大な先輩の言葉でした。

　IT勉強会からの越境に壁を感じたとしても

  • 怖れは無用(46)

です。IT勉強会から越境して様々な分野のエキスパートと出会い、議論する事で、もしかしたらあなたの新しいキャリアが始まるかもしれません。

次の人へ

明日のDevLove Adventcalendar 2014の記事執筆は岡山さをりさんです。

おまけ

1月15日に「自社内で開く「カフェ・ソフトウェアクオリティ」勉強会」というテーマでソフトウェア品質の勉強会を楽天タワー２号館で開催します。ご興味のある方の参加をお待ちしております。


1月15日 カフェ・ソフトウェアクオリティ第24回勉強会(東京都)

2014年振り返り

全般：

　もともと、２年前に５年計画でテスト自動化とかメトリクスとか、あと勉強会とかもろもろについてやっていきたい事について漠然と計画を立てた。勝率50%くらいで進むかなあと予想していたのだけど2013年は運がよくてほぼ勝率100%で色々進んだ。2014年はそれ以上に運が良くて、これから３年でやって行きたい事を実現するための土台が出来たのかなあと思う。

 

業務関係：

　業務関係でやったことの中身はさすがの僕でもここでは書かないけど 笑　業務関係の成果について新しく仲間が出来たりと昨年までと大きく流れが変わったなと印象づける出来事がいくつかあった。異動した先の組織では、前の部署で２年くらいかかったところまでもっていくのに６ヶ月くらいでもっていけそう。来年は本当に飛躍の年になる。

Kotaro Ogino - 部署異動して２週間ちょい経った。異動するにあたって色んな人に迷惑をおかけしたためか、たま... | Facebook

 

社外コミュニティ活動：

　JaSSTとSQiPでの発表。JaSSTでの発表では日本の業界に一定のインパクトを与えられたし、SQiPでの発表では賞を頂く事が出来た。今は某組織向けにArticleを書いている。最近やっぱり「海外カンファレンスへの投稿」をボチボチと薦められるので、来年そこまでやって一つの区切りかなあ。


継続的システムテスト - Test Automation


ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation

  

社内勉強会：

Go! Go! Talk

　Go! Go! Talkという勉強会を2014年に始めて一年近く続けている。この勉強会を継続させている事が想像以上に自分にとって大切な武器になっている。SQiPでの発表をこの勉強会でブラッシュアップさせたのはもちろんなんだけど、それ以上に、この勉強会のブランド力、リーチ力、出会った技術と人脈が僕の中の引き出しに大切にしまってあって、それが大きな自信になっている。


Kotaro Ogino - 最近たまに聞かれる「何故、社内勉強会を企画するの？ 」という質問。... | Facebook


ソフトウェア品質シンポジウム2014参加レポート⑤ 社内勉強会コミュニティとか - Test Automation

 

https://scontent-a-pao.xx.fbcdn.net/hphotos-xpa1/t31.0-8/p843x403/10484778_10152502858223568_3219283173475531193_o.jpg

https://www.facebook.com/photo.php?fbid=10152502858223568

 

 Tech Talk

　Tech Talkの企画。今年は「データサイエンススペシャル」「ソフトウェアテストスペシャル」「レビュースペシャル」「静的解析スペシャル」をやった。テックトークには偉大なイベント企画者達がいて、その人達の発想力、考え方と行動力が僕とは全く異なっている事が新鮮。今年も色々盗んだし、来年も色々盗むと思う　笑


Kotaro Ogino - 今日の社内勉強会の感想と見せかけたチラ裏日記を書いておこっと。... | Facebook

https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-xpa1/t31.0-8/p843x403/10713980_10152483143448568_7713200022593601481_o.jpg

https://www.facebook.com/photo.php?fbid=10152483143448568

  

資格：

業務とシャドーウォークの合間に

  • プロダクトオーナー
  • JSTQB (Foundation Level)

を取って、あとまだ結果返って来てないけど

  • JCSQE（初級）

を受けた。来年はスクラムマスターと、テストと品質のそれぞれ中級を取りたいなー。

 

2014年の反省と2015年に向けて

　こうやって書いてみると2014年は社内外のコミュニティ活動をかなり積極的に行ったし 、そのコミュニティ活動に自分の仕事が支えられてたなあと改めて実感。

　もともと社内外のコミュニティ活動については年初にはJaSSTとSQiP（またはAgile Conference）で発表する事くらいしか考えてなかったのだけれど、仕事が落ちてたり誘われたりする事が増えたので、参加可能なものは出来るだけ参加するようにしてた。ま、なんか異様に"意識が高い"一年だったわけです。

　そういった活動の中で「なんのためにコミュニティ活動してるのだろう？」「コミュニティ活動ってROIが低いなあ」などと悩んだ事もありました。コミュニティ活動をしていても目に見えた報酬ってないのですよ。でも逆に目立つためかよく分からない文脈で標的にされるような事がちらほらあったりして。

　ただ、そういったコミュニティ活動に自分の仕事が支えられていたのも事実。例えば今年、部署異動がかなりスムーズかつWin-Winに出来たのもコミュニティ活動のお陰だった。異動先の候補をいくつか教えてくれたのもコミュニティ関係の人脈だったし、その異動先の方達がテスト自動化についての悩みを相談して「そのレベルでテスト自動化を出来るのは社内にはOginoしかいない」とコミュニティ関連で知り合った方が推薦して下さっていた、という事を後から知りました。最近ではコミュニティの人脈を辿ってうちのチームに異動して来てくれる人を探したりもしています（笑）。

　そんなこんなで、2014年は社内外のコミュニティの見えざるサポートのお陰で「個人」の仕事の土台が作れた年だった。2015年はそれに加えて「チーム」としてコミュニティに関わっていけたら良いなあ（願望）。今年作った土台の上で、だけど　2014年の延長ではないチームとしての活動を2015年はやっていきたいなあ。

テスト自動化のメリット〜欠陥特定の改善〜

継続的システムテスト

この記事はソフトウェアテストあどべんとかれんだー2014の12月15日のブログ記事として執筆しています。

昨日はKyon Mmさんのパフォーマンステストについての記事でした。

この記事は最近見かけたクソコードから思いつきで書いています。内容はテスト自動化のTipsですが、普通のプログラマーにとっては当たり前レベルの内容です。

バッググラウンド：テスト自動化のROI

テスト自動化を始める際一番最初にテスト自動化のROIについて議論します。例えば４回以上繰り返し実行するテストを自動化すれば元が取れるとか、テストスクリプトの保守のためのコストを低減するための工夫を取り入れようとか。昨日開催されたシステムテスト自動化カンファレンスでも、共有スクリプト、データ駆動テスト、キーワード駆動テストなどの手法によりテストスクリプトのメンテナンスコストを抑えようというお話がありました。

この話は至極もっともで私がテスト自動化を行う時も必ずそうします。ですがこの辺りの議論について、コスト=投資を最小化する話ばかりでメリット=利益の最大化の議論が少ないなあと思っています。テスト自動化に対してメリットがあるから投資をするわけで、そこを無視して議論したらそれは減価償却ではないのか？とか。

ではテスト自動化のメリットとは何か？

昨日のシステムテスト自動化カンファレンスのKyon Mmさんの発表スライドを引用。

テストを自動化する事が正しいのではなく、ソフトウェア開発自体をよいサイクルにすること、そしてリリースにかかる時間を短くするための有用な選択肢

#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン 17p

ソフトウェアの開発サイクルやリリースに存在するボトルネックを解消出来る事がテスト自動化のメリットである、この意見に私も賛成です。

システムテストの典型的なボトルネック

コンポーネントの完成を待ってからでないと開始出来ないという事情により、システムテストではコンポーネントの結合、欠陥特定とバグ修正にボトルネックがある事が典型的です。もちろんシステムテストそのものの実施に時間がかかっているというケースもあると思いますし、そういう場合はテスト実行そのものの効率化が目的になるでしょう。ですが開発サイクルを俯瞰した場合、多くの場合のボトルネックは欠陥特定とバグ修正なのではないでしょうか？

今年のJaSST'Tokyoではシステムテストの自動化によりバグ修正コストを中央値で５日から２日に短縮した事例を発表しました。


継続的システムテスト - Test Automation

「システムテストの自動化に失敗するプロジェクトも多いが、何故この事例では成功したのか？」と聞かれる事がしばしばあり、社外のエキスパートの方達とディスカッションをしながら改めて自分の中で整理する機会がありました。そこで導きだした答えは「システムテストのボトルネックであった欠陥特定の問題を解消し、バグ修正日数の短縮というメリットの最大化に成功したから」です。

欠陥特定の短縮というメリット

開発プロセスにテスト駆動開発やCIを導入して、ちょっとずつテストをしながら機能の実装をしていくようにすると、まとめてテストをする場合に比べてはるかに早く欠陥特定が出来るという経験をした事のあるプログラマーは多いのではないでしょうか？

当たり前ですよね。ちょっとずつテストで確認をしながら実装をすれば、もしテストが失敗したとしてもその原因は直前のソースコード変更にあるはず。だから膨大なソースコードの中から欠陥特定するよりもはるかに早く済む。これと同じメリットをシステムテストの自動化でも享受する事が出来るのです。

例外処理設計とログレベル設計

では、そのメリットを最大化する為にはどういった工夫が必要か？テスト戦略とかデプロイメントパイプラインとか障害許容性とか移植性とか色々あると思いますが、ここでは例外処理設計とログレベル設計を取り上げます。

自動テストの実行結果からの欠陥特定という文脈で考えたとき、単体テストとシステムテストでは大きな違いがあります。（もしかしたらこの主張が正しいコンテキストはWeb系だけかもしれませんのでご注意ください。）単体テストでの欠陥特定はIDEのデバッグ機能等を使って簡便に行う事が出来ますが、システムテストでは疑似本番環境にデプロイしますし、コンポーネントも複数ありますのでIDEのデバッグ機能のように「１ステップずつ実行」という事が出来ません。

いや、やれば出来るのは分かります。でもそんな事するよりも、本番運用と同様の例外処理設計とログレベル設計をしっかり行い、テストのログを見るだけで欠陥特定する事を可能にした方がスマートです。

前述のJaSSTで発表した事例でバグの修正日数を５日から２日に短縮出来たのは、システムテスト自動化後、テストのログとソースコード変更履歴を１０分から１時間くらい見るだけでほとんどの欠陥特定を行えるようになったからです。

例外処理にまつわるクソコード

この記事を書いてみたモチベーションは、最近いくつかの場所で下記のようなクソコードを見た事です。

public void method() throws Exception {

    try {

        // some logic

    } catch (Exception e) {

        // some logic

        throw new Exception("An error message");

    }

} 

このコードでもExceptionが起きない正常処理は問題なく処理出来ますし、どんなException が起きても例外処理はしてくれます。そういう意味ではソフトウェアは動きます。でもこうしてしまうと

  • 異常系のテストが書けない。例えば「異常な入力に対しIllegalArgumentExceptionが発生する事」「通信先に障害が起きている時にConnectionRefusedExceptionが発生する事」を区別して書けない。
  •  実際に例外を処理している部分がどんなExceptionも同じものとして処理してしまうので、テストが失敗した時に実際に何が起きたのかをログから追跡する事が出来ない。

という問題が生じます。こんなコードが至る所にあるような場合、欠陥特定やバグ修正に関するボトルネックの解消が達成出来なくなってしまうのではないかという気がしてなりません。

おわりに

普通にテスト自動化に成功している人達にとっては”当たり前”の話ですみません。色々なもやもやに対する勢いだけで書きました。

 ただ、「開発者はテストをしない」と嘯くと開発とテストの良好な関係を築くのが難しいのと同様に、「テスターに欠陥特定は関係ない」と嘯く事もまた開発とテストの関係を悪化させてしまう原因になると思います。

開発とテストの関係をよりよいものにするために、「欠陥特定の改善」を目的としたテスト自動化に着手してみるのはいかがでしょうか？

---

明日12/17はnemorieさんです。よろしくお願いします。

楽天テックカンファ前夜祭2014のまとめ #rakutentech

勉強会

ここでは、１０月２４日に開催された楽天テックカンファ前夜祭のスライドとツイッターのみんなの反応をまとめます。

楽天テックカンファ前夜祭とは？


楽天テックカンファ前夜祭 10月24日（金） 〜楽天の若手エンジニアが挑戦する技術イノベーションLT祭り〜｜EventRegist（イベントレジスト）

 

■イベント概要

クラウドやビッグデータなど最近の技術トレンドに対する革新や、既存のレガシーシステムの開発へのアジャイルやテスト自動化の導入など、楽天の若手エンジニアの様々な挑戦を集めました。

質問OK! マサカリOK!楽天の若手エンジニアの挑戦について、熱く、楽しくタブー無しのディスカッションをしてみませんか？

 

LT大会第一部

プログラミング言語 Egison by 江木聡志さん

スライド（探し中）
ツイッターの反応

 

はじめてのあぷりけーしょんせっけい by 高橋勲さん

スライド（探し中）
ツイッターの反応

 

Video Recommender system in Viki by 梅田卓志さん

スライド

Video Recommender in Viki (VikiでのVideoレコメンド事例)

ツイッターの反応

 

個人タスク工数 見積もりと実績のデッドヒート by きくがわまりこさん

スライド（探し中）
ツイッターの反応

 

誰がテスト自動化をするべきか？ by  荻野恒太郎

スライド

Ngauto rtc2014 1024

ツイッターの反応

 

懇親会

 

LT大会第二部

Road to "Infrastructure as Code" in Rakuten by @tkakさん

スライド


Road to "Infrastructure as Code" in Rakuten // Speaker Deck

ツイッターの反応

 

Rakuten Hackathon! by @ooharabucyouさん

スライド
ツイッターの反応

 

特大のヤラカシからの復活－俺とみんながテストを書き出すまで－ by 渡邉太一さん

スライド

特大のヤラカシからの復活 －俺とみんながテストコードを書き出すまで－

ツイッターの反応 

 

楽天市場の商品ページはなぜ長いのか？ by 木下寛大さん

スライド
ツイッターの反応 

 

絶望と最後の希望？ by @sato_ryuさん

スライド

絶望と最後の希望

ツイッターの反応 

 

 乱入LT

メトリクスによる「見える化」のススメ: エッセンシャル・リーン by Hiroyuki Ito さん

スライド

メトリクスによる「見える化」のススメ: エッセンシャル・リーン

ツイッター反応

閉会の挨拶

 

その他リンク


楽天テックカンファ前夜祭まとめ #rakutentech - Togetterまとめ


楽天テクノロジーカンファレンス前夜祭 #rakutentech - 未来のいつか/hyoshiokの日記

 


Satoryu's Diary(OpenShift支店)(2014-10-24)


誰がテスト自動化をするべきか？ #rakutentech - Test Automation

 

誰がテスト自動化をするべきか？ #rakutentech

継続的システムテスト

楽天テックカンファ前夜祭で「誰がテスト自動化をするべきか？〜あなたのテスト自動化は大量のテストを高速実行するだけですか？〜」というLTをしました。

このエントリでは、「誰がテスト自動化をするべきか？」という質問の背景にある問題について考察した上で、それらの問題に対するエキスパート達の最近（2014年頃）の取り組みの資料を（勝手に）ご紹介。

Ngauto rtc2014 1024

ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation

 

 

「誰がテスト自動化をするべきか？」の背景

この質問、社外講演をすると必ず聞かれるんです。で、いつも答えに困って、最近では「開発者もテスターも協力してやるのがいいですよ」と曖昧に答えてます。

答えに困るのは質問がすごく曖昧だから。実際テスト自動化のどういったところに困っていて、それをどういう風に解決すればよいか？という質問なら、何か具体的な事を答えられるかもだけど、、、。

という事で、この質問の背景にある「具体的な問題」について想像してみます。

  • 開発とテストが分かれていて、テスト自動化を開発やテストのプロセス改善と捉える事が出来ていない
  • テストエンジニアが片手間でテスト自動化に取り組んでいてあまり効果が出ていない
  • 開発エンジニアが片手までテストを行っていてあまり効果が出ていない
  • 開発者やテスターのスキル不足

といった問題があるのかなーと。

これらの具体的な問題について、品質やテスト、自動化のエキスパート達が最近どのように取り組んでいるのか？というところが、上記の質問を抱いている方達へのサポートになるかと思いますのでご紹介。

エキスパート達のテストやテスト自動化への取り組み

メトリクスにもとづいたプロセス改善

「テスト自動化が流行ってるらしいからうちもやってみるか」のようなボンヤリとした目的でやってると色々つまづきます。テスト自動化はプロセス改善の一部なんだ、という事を私にはっきりと認識させてくれたのが下記の資料です。

プロセス改善は1.メトリクスを計測する 2.メトリクスに基づいて継続的に改善する　ことでしか達成出来ない、という事が見てとれます。でないと、「ボトルネックが移動した」ことに気付けない！


情報処理学会の現場 - THE HIRO Says

テスト自動化の品質とかアーキテクチャ

テスト自動化の”システム”をテスターや開発者が片手間で開発している事って多くないですか？　本番稼働するシステムなら「アーキテクチャ」とか「品質モデル」とかをきちんと考えるけど、テスト自動化システムは裏側で動くだけだし、動けばいいや、と。

いやいやいや、テスト自動化も「開発プロセスを改善するためのシステム」なのだからユーザーにとって使いやすいシステムでなければならない。じゃあ、ユーザーにとって使いやすい自動テストシステムの「品質」や「アーキテクチャ」って何だろう？という問いへの取り組みです。

テスト自動化の品質モデルの扱い

テスト自動化とアーキテクチャ

 

テストの設計やプロセスの品質

ドラクエとかFFとかのテレビゲームがあるじゃないですか。とりあえず、ストーリを楽しみながらゲームのクリアを目指す人が多いと思います。で、クリアした時アイテムコレクション率が70%とかで、「そうだ！アイテムも全部コンプリートしよう！！」とやってみて苦労した経験とかあったりしませんか？私は完全に早解き派だったのでいつでもそうでしたww

世の中には最初から全部のアイテムをコンプリートする事を考えて、そのための「設計」とか「プロセス」とかをどんどん改善して行く事がメチャクチャ得意な人達もいるんだなーと考えさせられたスライドです。

開発者が片手間でテストを書くとついついゲームクリア=デリバリーを優先してしまって、アイテムコンプリート=バグを探し尽くすが、後回しになってしまう。そんな問題を周りでみかけた事ありませんか？

魁!! 智美塾 「テストアーキテクチャ設計の 質について議論しよう」 智美塾塾長＋塾生一同  

テストやテスト自動化に必要なスキルセット

上記のようにテスト自動化を行うエンジニアには、従来のテストのスキルだけでなく「プロセス改善」や「テストアーキテクチャ」、「高度なテスト設計やプロセス品質改善」のスキルが必要です。

同じような議論が"テストエンジニアの品格"という事でテストエンジニアに必要なスキルセットとして下記の資料で取り上げられています。が、これ別にテストエンジニアだけに限らずテストや自動化に関わる開発者やマネージャーにも必須のスキルセットだと思われます。

テストエンジニアの品格 #automatornight

 

テスト自動化エンジニアの発掘と教育

 

結論

という事で、

  • 従来のテストスキルに加えて、プロセス改善活動、品質モデルとかテストアーキテクチャについて高度なスキルを持っているエンジニアに任せる

または

  • 開発者とテスター、マネージャーが協力する

が、「誰がテスト自動化をするべきか？」の私の回答です。

おぉっとっと。一番大事な選択肢が抜けていた。もう一つ、

  • テスト自動化というまだまだ柔らかくてベストプラクティスが決まっていない課題に取り組んで、あなた自身が「テスト、プロセス改善、品質モデル、テストアーキテクチャ」などのスキルセットを持つテスト自動化エンジニアになる

という選択肢も！！あなたもテスト自動化のエキスパートを目指してみませんか？？