Test Automation

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

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

 

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

 

結論

という事で、

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

または

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

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

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

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

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

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

継続的システムテスト 勉強会

ソフトウェア品質シンポジウムで"継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析"を経験発表をしました。

で、「何故、ウェブ系の会社からこのような発表が出て来たのか」不思議に思われた方達からそういった質問をいくつかもらいました。このエントリではその辺の話をちょっと書いてみます。

 

Fearless Changeを下支えする社内勉強会コミュニティ

組織に新しい文化や考え方を導入する、いわゆるFearless Changeを行おうとすると、導入のメリットをうまく説明出来なかったり、考え方の違う人達と摩擦が起きてしまったりといった問題が生じる事がしばしばあります。

そういう時、新しいアイデアについてブラッシュアップしたり、同じような問題意識を抱えているもの同士で課題を共有したりする社内勉強会コミュニティがあります。私が所属している会社には色々な勉強会がありますが、ここではTech TalkとGo! Go! Talkをご紹介。

Tech Talk

社外的には、佐藤さんや川口さんを中心に不定期で開催されているテックトークという勉強会が知られているかなと思います。

Satoryu's Diary(OpenShift支店)(2014-04-03)


Tech Talk という社内イベントをボチボチと続けている話 - kawaguti の日記 (id:wayaguchi)

Tech Talkでは特に流行の技術や、社内で問題意識の高いトピックについて社外の有識者をお招きして講演して頂く事が多いです。

Go! Go! Talk

私も、テックトークの女子力マックスな妹版としまして「Go! Go! Talk」という勉強会をゆる〜り主催しています。こちらでは、社内のちょっとした良い話、いろんな部署で行った改善の取り組みを集めています。例えば先月はアジャイルレトロスペクティブについての共有がありました。


チームで1番弱い子がアジャイルレトロスペクティブやってみたらの再演を聞いた #devlove #devKan - 未来のいつか/hyoshiokの日記

私のSQiPでの経験発表もこのGo! Go! Talkで３回共有しながら少しずつ、内容、発表をブラッシュアップしました。

余談ですが、、、この２年くらいホント社内の勉強会コミュニティに自分自身が育ててもらってるな、と感じるようになって。社内の勉強会コミュニティに恩返しする気持ち３割でこのGo! Go! Talkの企画とかしてます。

社外コミュニティ活動

下の記事にありますように、社外コミュニティ活動や発表をかなりやりやすい雰囲気もあります。OpenStackやChef,DockerなどのOSSのコミュニティ、DevLOVEやAgile, Scrumなどのコミュニティで活動したりしているエンジニアがたくさんいるのかなーと。


【特別鼎談Ⅰ】「積極的に外に出ることで自分が磨かれる」エンジニアはサバイブ力を身につけよ！ (2/3)：テクノロジーでビジネスを加速するための実践Webメディア EnterpriseZine (EZ)

 

社外で発表する事のメリットは数えきれないくらいあります。その中でも一番分かりやすいメリットは「インプットの情報の質が格段に上がる」事だと思います。

社外で発表すると、社外のエキスパートの方と知り合いになる機会があって、例えば、オススメの発表資料や本を直接教えて頂けたりします。数あるカンファレンス、ウェブ上に公開されているスライドや本の中から「これだ！！」というものを見つけるのは意外と大変ですよね。

私も下記に示すような「社内で活動しているだけではおそらく知る事が難しかった資料」（ほんの一部です）からヒントを得て業務の改善等を行っています。

特にまだセミナーや研修として固まっていない柔らかい領域に片足を突っ込む場合、自分（達）の考え方等を発表等を通して公にすることで、社外のエキスパートの方達とのコミュニケーションが取りやすくなるのかなと感じます。

社内勉強会コミュニティを支えるもの

そんな社内外の勉強会が盛んな会社に所属しているのですが。では、その社内勉強会コミュニティを支えているものは何だろうか？

それはhyoshiokさんのFearless Changeです。hyoshiokさんがちょうどよい感じのブログ記事を2010年頃に書かれてますのでそちらをご紹介。


2010-02-11 - 未来のいつか/hyoshiokの日記

コードを書いたらテストを書いて実行するという、あまりに単純な原理原則ですら実行するのは難しい。理屈で分かっていること、知っていることと出きることには雲泥の差があることをプロフェッショナルは理解している。新米にそれを伝えることがプロフェッショナルの仕事である。

ロートルはロートルとして伝えなければいけない原理原則がまだまだあるなあと思う。

しつこく出きるまで訓練する。トレーニングを重ねる。そーゆーことを一つ一つ積み重ね、一人一人がプロフェッショナルになるような環境を提供する。やるべきことはまだまだある。

会社にそのようなコミュニティを作るのがわたしの仕事だと最近思っている。

 


2010-03-12 - 未来のいつか/hyoshiokの日記

例えば、テストのないレガシーコードにテストを作ることによって、そのシステムの理解が深まったり、動作を記述することによって、変更の影響が即座にわかったりする。変更の影響がわかれば、大胆に実装を変更したりすることが容易にできるようになり、開発の俊敏性が高まる。それが安心であり、心の平静が保てる。

テストがないシステムはレガシーシステムであるが、それをモダンにする第一歩はテストを書くことである。

hyoshiokさんが何年かかけて作り上げて来ているハッカー文化や社内勉強会コミュニティそして、ソフトウェアテストの文化が根付いているなあと。

実際、hyoshiokさんががGo! Go! Talkに来て下さると、勉強会の雰囲気がピリッと締まったりとか、発表をブログで取り上げて頂いて発表者のモチベーションがさらに上がったりとか、色々な形でサポートして頂いております。

おわりに

先日のSQiPでの経験発表が

"SQiP Best Report Future Award 将来役に立つ可能性を秘めているもの（審査委員会で選定）

という賞を受賞した事を楽天テクノロジーカンファレンス2014の準備に追われている社内勉強会メンバーに報告しました。

f:id:kokotatata:20141014153059j:plain

 

 

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

継続的システムテスト 講演活動

９月１０日〜１２日まで参加したソフトウェア品質シンポジウムでは、”継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析”という経験発表を行い、「SQiP Best report Future Award（将来役に立つ可能性を秘めているもの）」という賞を頂きました。

http://www.juse.jp/sqip/symposium/report/2/images/ippan_photo1.jpg

http://www.juse.jp/sqip/symposium/report/images/award_photo.jpg

開催レポート | ソフトウェア品質シンポジウム 2014

この記事ではこの継続的システムテストについて、ソフトウェア品質シンポジウムへ参加し聴講した基調講演やセッション、ディスカッションを通して考えた事を書きます。

 

 

継続的システムテストのバックグラウンド

ビジネスとソフトウェアの品質の変化

クラウドやスマートフォンなどの技術革新によるビジネスを取り巻く状況が変化してます。そういったビジネスの変化に伴うソフトウェア品質の変化についてのソフトウェア品質シンポジウム2014での東京会場日動システムズの横塚さんの基調講演がとても印象的でした。


ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 － Publickey

システムテストや品質保証に求められる変化

独立した組織として品質の門番の役割を果たすだけでなく、積極的に開発者やユーザーと結びついて、もっと価値を提供していこう、そういった考え方の変化がシステムテストや品質保証に求められています。ここでは２つご紹介。

継続的システムテスト

私たちは近年のこういったシステムテストや品質保証の変化の中、システムテストを自動化し継続的に日次で実行する継続的システムテストというアプローチをとっています。

JaSST' Tokyo 2014では継続的インテグレーションから継続的システムテストへと拡張するため私たちが取り行った施策、またシステムテストの自動化により自動化前に比べバグの修正日数が中央値で５日から２日へと改善されたという開発者へのメリットを報告しました。


継続的システムテストについて - Test Automation

 

継続的システムテストの実現

開発者とテスターのどちらがテスト自動化をするべきか？？

システムテストの自動化について社内外の勉強会でお話しすると「テストの自動化は開発者、テスターどちらがやるのが良いか？」という質問を必ず貰います。

おそらくこの質問の裏には「テスト自動化の重要性は分かる。Seleniumなどのツールも使える。開発者とテスターが協力する事が大切という事も分かる。でも、どういう風に開発者とコミュニケーションを取りながらプロセスを回せばよいのか具体的に分からない」という疑問をみなさん持っているのかなあと想像しています。

自動化とテストプロセス

実際私たちもテスト自動化がプロセスとして無理なく実行出来るようになるまで多くの苦労がありました。その中でも特に苦労した点は、テストプロセスのプロセス品質を落とさずに、そのサイクルタイムを短くすることです。ここで大事なのは意外と単純な以下の２つです。

  • テストプロセスへのインプットの正確性
  • 開発•テストプロセスの一気通貫したマネージメント

テストプロセスへのインプットの正確性

テストプロセスは、テスト設計を行うのに必要な機能の仕様と設計をインプットとして受け取ります。機能提供のスピードが求められるので、完璧なドキュメントを作る事はしません。しかし、この仕様や設計に間違いや抜け漏れがあると、いわゆる手戻りによるテスト設計やテストケース実装のやり直しが発生してしまいます。

仕様や設計の間違いを減らすためテスターは積極的にこれらの作成に関わります。実際にテスターのレビューにより仕様や設計の間違いや抜け漏れがテスト設計の前に発見、修正された事が何度もあります。

ここで注意したい事は「完璧なドキュメント」を求めているわけではない事です。ブレインストーミング段階のメモ程度のレベルでディスカッションを行っています。そういう意味では、機能の仕様策定や設計を開発者とテスターが一緒に行っていると言った方が正確かもしれません。

開発•テストプロセスの一気通貫したマネージメント

せっかくテストプロセスへの入力の間違いを減らす事が出来ても、開発とテストプロセスが別々にマネージメントされていては意味がありません。理想は、機能実装とテスト実装が同じタイミングで終わる事です。

機能実装とテスト実装を同じタイミングで終わらせるためには、両者のプロセスを一気通貫したものとして捉えたマネージメントが必要になります。例えば、SQiPの経験発表で取り上げた「スモークテストを壊すようなコミットを分割する」がこれにあたります。（ブログエントリトップのスライドの31p以降の分析です。）

このスモークテストについての議論は、今回の経験発表の分析の中でも個人的に特に興味深いと考えている部分です。開発•テストプロセスが一気通貫している世界で「コミット数」という開発のメトリクスと「検出バグ数」という品質保証のメトリクスを横、縦の軸にとり、いわゆるバグカーブを描いてみるとプロジェクト運営に有用な情報が色々得られる可能性がある、という事が分かったからです。

テスト自動化はバグカーブをより早く収束させるためのプロセスの最適化として捉えると、テストや品質のエキスパートの方達の得意領域になってくるのではないでしょうか。

つまり。。。？？

ここで、最初の疑問「テストの自動化は開発者、テスターどちらがやるのが良いか？」について考えてみます。開発者とテスターが協力する事で初めてテストプロセスへの入力の正確性を高めたり、開発•テストプロセスの最適化が可能になると私は考えています。つまり私の回答は「テスト自動化は開発者とテスター両者が協力してやった方が良い」です。

 

継続的システムテストのこれから

テストプロセスの効率化

継続的システムテストのプロセス品質を高めて行くためにはもう一つ、プロセスの効率化が欠かせません。継続的システムテストのテストプロセスでも一般的なものと同じ以下のプロセスがあります。

  • テスト設計
  • テストケース生成（実装）
  • テスト実行優先順位付け
  • テスト実行
  • 欠陥特定
  • 振り返り
  • テスト設計や優先順位付けへのフィードバック

メトリクスと開発者の知見の活用

このテストプロセスを効率化していくためにはメトリクスと開発者の知見の活用が重要になります。

「テストの自動化」と言ったときに、今その言葉が指す自動化の対象は「テスト実行」だけである事がほとんどです。ですが、メトリクスを活用する事で、もしかしたらテストケース作成やテストの優先順位付けの多くの部分も自動化する事が可能になるかもしれません。

また、システムテストではテストの抜け漏れが問題となるケースがしばしば起きます。これは、システムテストが自動化されている環境でのテストの網羅性について実はよく分かっていないという課題が根底にあります。○○億件のテストが自動化されていると有名なGoogleのSETとICST 2014で「システムテストの網羅性と十分性とを評価する指標が今後必要になる」と話す機会がありました。

テストプロセスの中でもテスト設計と欠陥特定は特に重要な部分であり、テストが自動化された環境でもヒトがたくさんの時間をこの２つに割く必要があります。このテスト設計や欠陥特定をより早く正確に行うための開発者の知見の活用も重要です。

 

おわりに

「継続的システムテストは新しい概念なのか？」と言えばそんな事はないです。継続的インテグレーション(CI)や継続的デリバリー(CD)に本来内包されるべきものです。

ただ、CIやCDでは"従来のシステムテストや品質保証はどうなるのか”についてスポットライトがあてられていないため、システムテストについては様々な論争が巻き起こっているのも事実です。

私の一連のContinuous System Testについての活動について、海外のアジャイルテストのエキスパートに「Good to see system test getting some love」とコメントを頂いた事もあり、まぁシステムテストに対してみんな愛が足りないよな、と。 （笑）

この継続的システムテストという考え方と経験発表は、「システムテストの自動化」「メトリクス」に着目したアジャイルなプロジェクトの中でもかなり希有なものであり、これからの開発プロセスの変化の中でシステムテストや品質がどう変わっていくのかを考える一助になればと思います。

 

ソフトウェア品質シンポジウム2014参加レポート③ 品質やメトリクスについて学んだよ

カンファレンス参加レポート

ソフトウェア品質シンポジウム2014に参加したレポートですが、この品質やメトリクスについて学んだ内容については、どこまでブログに書いてよいのかよく分からないし、本気で書いたら行数もすごいことになってしまう、という事で参加したセッションのダイジェストをお送り致します。

http://www.juse.jp/sqip/symposium/common/images/logo.png

開催レポート | ソフトウェア品質シンポジウム 2014 

併設チュートリアル（９月１０日）

新しいソフトウェアテスト ウォーターフォール•モデルからの決別

こちらのチュートリアルでは

  • グーグルやSalesforceなどでテスト自動化が進められている事例の紹介
  • テストもこれからどんどん変わって行く必要がある事
  • TDD + 探索的テスト

が紹介されていました。

「コードカバレッジ100%を目標としてたくさん時間をかけてテストをするのではなく、顧客に価値を提供するのに80%で十分なら20%分上げるのに必要になる時間の短縮がアジリティとして価値になる」という説明の仕方が伝わりやすそうでいいなと思いました。

本会議１日目（９月１０日）

基調講演１ ビジネスが変わる••• 品質が変わる

この基調講演には「今まで通りの品質だけでなく、これからはアジリティも品質として重要になる」というメッセージが込められていて、まさにシンポジウム全体を象徴する講演でした。また、「お堅いイメージの金融システムのトップがこういうメッセージを発する事がすごい」とのコメントを伺い、なるほど！と思いました。

セッションA1 一般発表（テスト）

僕も経験発表をさせて頂いたセッション。自分の発表については別途詳細を書きます。特徴的だったのは、４つの発表すべてが結合•システムテストを対象にしていたことです。これは、TDD is dead. Long live testing. に代表されるような最近のアジャイル系の潮流とも合致しているなぁと思いました。

また、"SQiP Best Presentation Award"を受賞した"システムテストにおけるテスト分析手法の提案" という発表では、アジャイルでシナリオテストと呼ばれているタイプのテストを網羅的に設計するのに有効かもしれない手法が提案されていました。

セッションA2 一般発表レビュー (レビュー)

レビューのセッションでは、なるほど、バックグラウンドとして「些細な欠陥のレビューに時間が割かれてしまう事で重要な欠陥を見逃す事」が問題としてあると言う事、そしてそれを防ぐための手法が提案されていました。どの手法も

  • レビューで欠陥を見つけたらそれで終わり、ではなく、きちんとそれらの情報を分析して、次のレビューにつなげる
  • レビュー観点の導出を工夫する事で重大な欠陥に集中出来るようにする

という考え方が根底にあるのかなと感じました。

SIG 何で協力してくれないの？！•••　新しい仕事の前に働きやすいチームを作ろう

SIGでは、テストやレビューから離れて、チームビルディングのテーマに参加してみました。"アイスブレイク"の方法が紹介された後、皆で実際にやってみるというスタイルでした。まぁ、なんといいますか、どんな組織の方もチームビルディングに苦労されているんだなあ、そんな感想を持ったSIGでした。

本会議２日目 (９月１２日)

セッションE3 ソフトウェア品質保証部長の会からの情報発信

最近、テスト自動化、品質、アジャイルについて少し上の方の上長とどう話したら良いのかなと考える機会が多いので参加してみました。

そしてこのセッション枠は僕の中で一番賛否両論の多い枠でもありました。

賛否両論うずまく色んな意見や考え方に触れる事が大事という視点では、一番気づきの多い枠だったかもしれません。

よかった点は、既存のスキームの枠をこえた新しい品質についての考え方がいくつも示されていました。ここで示されていたスキームやフレーズを使えば、少し上の方の上長にも響くかもと感じました。

セッションD4 企画セッション レビューとテストは使い分けるべきか？

こちらのセッションについては


ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ - Test Automation

で詳細書きましたのでそちらをご覧下さい。

 

基調講演２　リスクマネジメントのための失敗学--再発防止と未然防止--

こちらのセッションは、内容、しゃべり、随所に入るボケなどすべてに圧倒されました。ホントにスゴかったです。このセッションを文字にしてブログで伝える事は不可能ですので、是非みなさん一般財団法人 日本科学技術連盟 − 失敗学と創造学セミナーに参加してみて下さい。

メッセージとしては、失敗を失敗として終わらせるのではなく、次の失敗をしないためにつなげる事が大事 というモノでした。

うーん、、、上の表現だとやっぱり、精神論とか教訓じみてて何か違うなぁ。もっとリアルで実践的なお話なんだよなぁ。

まとめ

３日間を通し「今までの品質をさらに改善、発展させる」お話と「新しい品質にチャレンジする」お話がたくさん詰まっていて、本当に学びの多いシンポジウムでした。

ソフトウェア品質シンポジウム2014参加レポート④となる次回レポートでは、いよいよ経験発表をした継続的システムテスト周りの話を書きます。