楽天テックカンファ前夜祭2014のまとめ #rakutentech
ここでは、10月24日に開催された楽天テックカンファ前夜祭のスライドとツイッターのみんなの反応をまとめます。
楽天テックカンファ前夜祭とは?
楽天テックカンファ前夜祭 10月24日(金) 〜楽天の若手エンジニアが挑戦する技術イノベーションLT祭り〜|EventRegist(イベントレジスト)
■イベント概要
クラウドやビッグデータなど最近の技術トレンドに対する革新や、既存のレガシーシステムの開発へのアジャイルやテスト自動化の導入など、楽天の若手エンジニアの様々な挑戦を集めました。
質問OK! マサカリOK!楽天の若手エンジニアの挑戦について、熱く、楽しくタブー無しのディスカッションをしてみませんか?
前夜祭はじまった! #rakutentech pic.twitter.com/yjCK0084yn
— kotaro (@kokotatata) 2014, 10月 24
LT大会第一部
プログラミング言語 Egison by 江木聡志さん
スライド(探し中)
ツイッターの反応
最初がEgisonのお話という、ぶっ込んでくるかんじが素晴らしい #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
江木さんが作ったからEgison #rakutentech
— ばしし (@rada_bashishi) 2014, 10月 24
Egison読みはエギソン。由来は江木さんが作ったから #rakutentech
— しゅう (@shuh) 2014, 10月 24
はじめてのあぷりけーしょんせっけい by 高橋勲さん
スライド(探し中)
ツイッターの反応
前と同じはベターだけどベストじゃないかも #rakutentech
— ばしし (@rada_bashishi) 2014, 10月 24
フレームワークとか言語の選定基準も説明できないとなのか。。 #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
びっくりするがなww #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
Video Recommender system in Viki by 梅田卓志さん
スライド
Video Recommender in Viki (VikiでのVideoレコメンド事例)
ツイッターの反応
楽天さんの無料動画サービスViki #rakutentech
— ばしし (@rada_bashishi) 2014, 10月 24
ユーザーのアクティビティと動画のコンテンツを使った動画のレコメンデーション。 #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
#rakutentech VIKIのレコメンド枠改善のお話。 今見ている動画と関係する動画をどうやってレコメンドするのか。。。
— 楽天WEBSERVICE (@RakutenAPI) 2014, 10月 24
レコメンデーションはそれだけで1分野を成してるかんじなのでもっと勉強したい #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
個人タスク工数 見積もりと実績のデッドヒート by きくがわまりこさん
スライド(探し中)
ツイッターの反応
#rakutentech 3年目の楽天女子エンジニアがタスクの見積もりについて話します。 見積もり難しいですよね。 新人エンジニアにとっては特にむずかしいとおもう。
— 楽天WEBSERVICE (@RakutenAPI) 2014, 10月 24
1日の2hを突発対応 or MTG枠をあらかじめとっておくのはいいよね。 #rakutentech
— ばしし (@rada_bashishi) 2014, 10月 24
楽天女子「発表時間見積もれてない><」www #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
他の人に振るってあったけどどういう感じなんだろ リーダー的な立場で裁量権があるのか、スクラム的な感じで誰か助けてくれるのか #rakutentech
— Taichi Watanabe (@taichiw0424) 2014, 10月 24
誰がテスト自動化をするべきか? by 荻野恒太郎
スライド
ツイッターの反応
荻野さん @kokotatata LTで躍動してる #rakutentech pic.twitter.com/D1zKGwDt6r
— Yuichi Takada (@_takady) 2014, 10月 24
テスト自動化はすごくスキルが必要で、一人でやるならスーパーエンジニアじゃないと無理。じゃあみんなでやろう #rakutentech
— Taichi Watanabe (@taichiw0424) 2014, 10月 24
#rakutentech 継続的システムテストと、検索すると 荻野さんの名前しか出てこないらしい! テストに悩んでる方、いろいろきいてみましょう!
— 楽天WEBSERVICE (@RakutenAPI) 2014, 10月 24
開発者もテスタもマネージャもそれぞれにできることでテストに参加しよう! #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
懇親会
ディスカッションタイーム http://t.co/5IhCivgq5P #rakutentech
— Taichi Watanabe (@taichiw0424) 2014, 10月 24
LT大会第二部
Road to "Infrastructure as Code" in Rakuten by @tkakさん
スライド
Road to "Infrastructure as Code" in Rakuten // Speaker Deck
ツイッターの反応
発表前で緊張している @tkak #rakutentech pic.twitter.com/lM1HwulUWr
— Yoshiyuki Nakai (@yoshiyukinakai) 2014, 10月 24
ぷろびじょにんぐ業。最近の興味は言語と言語 #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
発表中の @tkak #rakutentech pic.twitter.com/bZUqxFDXlE
— Yoshiyuki Nakai (@yoshiyukinakai) 2014, 10月 24
dockerhubのchef版の社内版があったらいいかも #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
Rakuten Hackathon! by @ooharabucyouさん
スライド
ツイッターの反応
#rakutentech #rakutenhack 楽天ハッカソンよろしくね! http://t.co/ZFNNXnuJo1
— 楽天WEBSERVICE (@RakutenAPI) 2014, 10月 24
東京から仙台まで歩くのが趣味ww #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
技術の無駄遣い選手権www #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
BaaSってなんだよっていうとAWS芸人さんだな。http://t.co/aGd0Zm3oSH #rakutentech #jawsug
— ばしし (@rada_bashishi) 2014, 10月 24
特大のヤラカシからの復活-俺とみんながテストを書き出すまで- by 渡邉太一さん
スライド
特大のヤラカシからの復活 -俺とみんながテストコードを書き出すまで-
ツイッターの反応
結婚3日後に昇格したリア充。爆発s(ry #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
Jenkinsの素晴らしさをマンガで伝えよう! #rakutentech
— ばしし (@rada_bashishi) 2014, 10月 24
見える化すると改善モチベーションでてくるという人間の性質を利用! #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
やらかしをバネにしてリア充になった! #rakutentech pic.twitter.com/53GehP22Ds
— kotaro (@kokotatata) 2014, 10月 24
楽天市場の商品ページはなぜ長いのか? by 木下寛大さん
スライド
ツイッターの反応
リア充ばっかりだ!さすが楽天!() #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
キタ!楽天の商品ページはなぜ長いのか! #rakutentech pic.twitter.com/SKOb0I9JrF
— kotaro (@kokotatata) 2014, 10月 24
最高のTKG(卵かけ御飯)の為にページが長くなった。要するに商品のストーリーを語る所為とのこと #rakutentech
— しゅう (@shuh) 2014, 10月 24
ジャンルによって商品ページが長くても最後まで見てもらえるものと、見てもらえないものがある #rakutentech
— Taichi Watanabe (@taichiw0424) 2014, 10月 24
絶望と最後の希望? by @sato_ryuさん
スライド
ツイッターの反応
本日の一番ブラックなやつきた! #rakutentech pic.twitter.com/DjyF4bANIJ
— kotaro (@kokotatata) 2014, 10月 24
「そこまでして勉強会をするモチベーションはなんですか?」「あきらめないと夢は叶うからです」 #rakutentech
— kotaro (@kokotatata) 2014, 10月 24
勉強会してたとき、自分でハードル上げて勝手にしんどくなっていたのはよくわかるお #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
テーマを出す人とそれを回す人がいる #rakutentech
— ばしし (@rada_bashishi) 2014, 10月 24
乱入LT
メトリクスによる「見える化」のススメ: エッセンシャル・リーン by Hiroyuki Ito さん
スライド
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
ツイッター反応
乱入キタコレ #rakutentech pic.twitter.com/aCiIOXrlmK
— kotaro (@kokotatata) 2014, 10月 24
バーンダウンが落ちないww耳が痛いww #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
凸「状況把握はチーム全体の責務だ #rakutentech
— しゅう (@shuh) 2014, 10月 24
人間なら見える化するとKAIZENしたくなるかんじ、さっきも似た話あったな! #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
閉会の挨拶
相変わらず真っ赤な吉岡さんである #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
シラフで仕事してましたw #rakutentech pic.twitter.com/BqvOWLODKR
— kotaro (@kokotatata) 2014, 10月 24
これにて全野菜はおわり! #rakutentech
— 東京の名古屋のおさかな (@sakanazensen) 2014, 10月 24
その他リンク
楽天テックカンファ前夜祭まとめ #rakutentech - Togetterまとめ
楽天テクノロジーカンファレンス前夜祭 #rakutentech - 未来のいつか/hyoshiokの日記
Satoryu's Diary(OpenShift支店)(2014-10-24)
誰がテスト自動化をするべきか? #rakutentech - Test Automation
誰がテスト自動化をするべきか? #rakutentech
楽天テックカンファ前夜祭で「誰がテスト自動化をするべきか?〜あなたのテスト自動化は大量のテストを高速実行するだけですか?〜」というLTをしました。
このエントリでは、「誰がテスト自動化をするべきか?」という質問の背景にある問題について考察した上で、それらの問題に対するエキスパート達の最近(2014年頃)の取り組みの資料を(勝手に)ご紹介。
ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation
「誰がテスト自動化をするべきか?」の背景
この質問、社外講演をすると必ず聞かれるんです。で、いつも答えに困って、最近では「開発者もテスターも協力してやるのがいいですよ」と曖昧に答えてます。
答えに困るのは質問がすごく曖昧だから。実際テスト自動化のどういったところに困っていて、それをどういう風に解決すればよいか?という質問なら、何か具体的な事を答えられるかもだけど、、、。
という事で、この質問の背景にある「具体的な問題」について想像してみます。
- 開発とテストが分かれていて、テスト自動化を開発やテストのプロセス改善と捉える事が出来ていない
- テストエンジニアが片手間でテスト自動化に取り組んでいてあまり効果が出ていない
- 開発エンジニアが片手までテストを行っていてあまり効果が出ていない
- 開発者やテスターのスキル不足
といった問題があるのかなーと。
これらの具体的な問題について、品質やテスト、自動化のエキスパート達が最近どのように取り組んでいるのか?というところが、上記の質問を抱いている方達へのサポートになるかと思いますのでご紹介。
エキスパート達のテストやテスト自動化への取り組み
メトリクスにもとづいたプロセス改善
「テスト自動化が流行ってるらしいからうちもやってみるか」のようなボンヤリとした目的でやってると色々つまづきます。テスト自動化はプロセス改善の一部なんだ、という事を私にはっきりと認識させてくれたのが下記の資料です。
プロセス改善は1.メトリクスを計測する 2.メトリクスに基づいて継続的に改善する ことでしか達成出来ない、という事が見てとれます。でないと、「ボトルネックが移動した」ことに気付けない!
テスト自動化の品質とかアーキテクチャ
テスト自動化の”システム”をテスターや開発者が片手間で開発している事って多くないですか? 本番稼働するシステムなら「アーキテクチャ」とか「品質モデル」とかをきちんと考えるけど、テスト自動化システムは裏側で動くだけだし、動けばいいや、と。
いやいやいや、テスト自動化も「開発プロセスを改善するためのシステム」なのだからユーザーにとって使いやすいシステムでなければならない。じゃあ、ユーザーにとって使いやすい自動テストシステムの「品質」や「アーキテクチャ」って何だろう?という問いへの取り組みです。
テストの設計やプロセスの品質
ドラクエとかFFとかのテレビゲームがあるじゃないですか。とりあえず、ストーリを楽しみながらゲームのクリアを目指す人が多いと思います。で、クリアした時アイテムコレクション率が70%とかで、「そうだ!アイテムも全部コンプリートしよう!!」とやってみて苦労した経験とかあったりしませんか?私は完全に早解き派だったのでいつでもそうでしたww
世の中には最初から全部のアイテムをコンプリートする事を考えて、そのための「設計」とか「プロセス」とかをどんどん改善して行く事がメチャクチャ得意な人達もいるんだなーと考えさせられたスライドです。
開発者が片手間でテストを書くとついついゲームクリア=デリバリーを優先してしまって、アイテムコンプリート=バグを探し尽くすが、後回しになってしまう。そんな問題を周りでみかけた事ありませんか?
魁!! 智美塾 「テストアーキテクチャ設計の 質について議論しよう」 智美塾塾長+塾生一同
テストやテスト自動化に必要なスキルセット
上記のようにテスト自動化を行うエンジニアには、従来のテストのスキルだけでなく「プロセス改善」や「テストアーキテクチャ」、「高度なテスト設計やプロセス品質改善」のスキルが必要です。
同じような議論が"テストエンジニアの品格"という事でテストエンジニアに必要なスキルセットとして下記の資料で取り上げられています。が、これ別にテストエンジニアだけに限らずテストや自動化に関わる開発者やマネージャーにも必須のスキルセットだと思われます。
結論
という事で、
- 従来のテストスキルに加えて、プロセス改善活動、品質モデルとかテストアーキテクチャについて高度なスキルを持っているエンジニアに任せる
または
- 開発者とテスター、マネージャーが協力する
が、「誰がテスト自動化をするべきか?」の私の回答です。
おぉっとっと。一番大事な選択肢が抜けていた。もう一つ、
- テスト自動化というまだまだ柔らかくてベストプラクティスが決まっていない課題に取り組んで、あなた自身が「テスト、プロセス改善、品質モデル、テストアーキテクチャ」などのスキルセットを持つテスト自動化エンジニアになる
という選択肢も!!あなたもテスト自動化のエキスパートを目指してみませんか??
ソフトウェア品質シンポジウム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で3回共有しながら少しずつ、内容、発表をブラッシュアップしました。
余談ですが、、、この2年くらいホント社内の勉強会コミュニティに自分自身が育ててもらってるな、と感じるようになって。社内の勉強会コミュニティに恩返しする気持ち3割でこのGo! Go! Talkの企画とかしてます。
社外コミュニティ活動
下の記事にありますように、社外コミュニティ活動や発表をかなりやりやすい雰囲気もあります。OpenStackやChef,DockerなどのOSSのコミュニティ、DevLOVEやAgile, Scrumなどのコミュニティで活動したりしているエンジニアがたくさんいるのかなーと。
【特別鼎談Ⅰ】「積極的に外に出ることで自分が磨かれる」エンジニアはサバイブ力を身につけよ! (2/3):テクノロジーでビジネスを加速するための実践Webメディア EnterpriseZine (EZ)
社外で発表する事のメリットは数えきれないくらいあります。その中でも一番分かりやすいメリットは「インプットの情報の質が格段に上がる」事だと思います。
社外で発表すると、社外のエキスパートの方と知り合いになる機会があって、例えば、オススメの発表資料や本を直接教えて頂けたりします。数あるカンファレンス、ウェブ上に公開されているスライドや本の中から「これだ!!」というものを見つけるのは意外と大変ですよね。
私も下記に示すような「社内で活動しているだけではおそらく知る事が難しかった資料」(ほんの一部です)からヒントを得て業務の改善等を行っています。
- アジャイル開発における品質保証部門によるシステムテストのアプローチ
- 関係者に理解してもらえるアジャイル開発に向けて
- Ultimate Agile Stories
- メトリクス公団
- データ指向のソフトウェア品質マネジメント
- ちょっと明日のテストの話をしよう
- DevQUT !
- テストアーキテクチャ設計の質について議論しよう
- ソフトウェア信頼性モデル
- ソフトウェア品質知識体系ガイド
特にまだセミナーや研修として固まっていない柔らかい領域に片足を突っ込む場合、自分(達)の考え方等を発表等を通して公にすることで、社外のエキスパートの方達とのコミュニケーションが取りやすくなるのかなと感じます。
社内勉強会コミュニティを支えるもの
そんな社内外の勉強会が盛んな会社に所属しているのですが。では、その社内勉強会コミュニティを支えているものは何だろうか?
それは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の準備に追われている社内勉強会メンバーに報告しました。
ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから
9月10日〜12日まで参加したソフトウェア品質シンポジウムでは、”継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析”という経験発表を行い、「SQiP Best report Future Award(将来役に立つ可能性を秘めているもの)」という賞を頂きました。
この記事ではこの継続的システムテストについて、ソフトウェア品質シンポジウムへ参加し聴講した基調講演やセッション、ディスカッションを通して考えた事を書きます。
継続的システムテストのバックグラウンド
ビジネスとソフトウェアの品質の変化
クラウドやスマートフォンなどの技術革新によるビジネスを取り巻く状況が変化してます。そういったビジネスの変化に伴うソフトウェア品質の変化についてのソフトウェア品質シンポジウム2014での東京会場日動システムズの横塚さんの基調講演がとても印象的でした。
ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 - Publickey
システムテストや品質保証に求められる変化
独立した組織として品質の門番の役割を果たすだけでなく、積極的に開発者やユーザーと結びついて、もっと価値を提供していこう、そういった考え方の変化がシステムテストや品質保証に求められています。ここでは2つご紹介。
継続的システムテスト
私たちは近年のこういったシステムテストや品質保証の変化の中、システムテストを自動化し継続的に日次で実行する継続的システムテストというアプローチをとっています。
JaSST' Tokyo 2014では継続的インテグレーションから継続的システムテストへと拡張するため私たちが取り行った施策、またシステムテストの自動化により自動化前に比べバグの修正日数が中央値で5日から2日へと改善されたという開発者へのメリットを報告しました。
継続的システムテストについて - Test Automation
継続的システムテストの実現
開発者とテスターのどちらがテスト自動化をするべきか??
システムテストの自動化について社内外の勉強会でお話しすると「テストの自動化は開発者、テスターどちらがやるのが良いか?」という質問を必ず貰います。
おそらくこの質問の裏には「テスト自動化の重要性は分かる。Seleniumなどのツールも使える。開発者とテスターが協力する事が大切という事も分かる。でも、どういう風に開発者とコミュニケーションを取りながらプロセスを回せばよいのか具体的に分からない」という疑問をみなさん持っているのかなあと想像しています。
自動化とテストプロセス
実際私たちもテスト自動化がプロセスとして無理なく実行出来るようになるまで多くの苦労がありました。その中でも特に苦労した点は、テストプロセスのプロセス品質を落とさずに、そのサイクルタイムを短くすることです。ここで大事なのは意外と単純な以下の2つです。
- テストプロセスへのインプットの正確性
- 開発•テストプロセスの一気通貫したマネージメント
テストプロセスへのインプットの正確性
テストプロセスは、テスト設計を行うのに必要な機能の仕様と設計をインプットとして受け取ります。機能提供のスピードが求められるので、完璧なドキュメントを作る事はしません。しかし、この仕様や設計に間違いや抜け漏れがあると、いわゆる手戻りによるテスト設計やテストケース実装のやり直しが発生してしまいます。
仕様や設計の間違いを減らすためテスターは積極的にこれらの作成に関わります。実際にテスターのレビューにより仕様や設計の間違いや抜け漏れがテスト設計の前に発見、修正された事が何度もあります。
ここで注意したい事は「完璧なドキュメント」を求めているわけではない事です。ブレインストーミング段階のメモ程度のレベルでディスカッションを行っています。そういう意味では、機能の仕様策定や設計を開発者とテスターが一緒に行っていると言った方が正確かもしれません。
開発•テストプロセスの一気通貫したマネージメント
せっかくテストプロセスへの入力の間違いを減らす事が出来ても、開発とテストプロセスが別々にマネージメントされていては意味がありません。理想は、機能実装とテスト実装が同じタイミングで終わる事です。
機能実装とテスト実装を同じタイミングで終わらせるためには、両者のプロセスを一気通貫したものとして捉えたマネージメントが必要になります。例えば、SQiPの経験発表で取り上げた「スモークテストを壊すようなコミットを分割する」がこれにあたります。(ブログエントリトップのスライドの31p以降の分析です。)
このスモークテストについての議論は、今回の経験発表の分析の中でも個人的に特に興味深いと考えている部分です。開発•テストプロセスが一気通貫している世界で「コミット数」という開発のメトリクスと「検出バグ数」という品質保証のメトリクスを横、縦の軸にとり、いわゆるバグカーブを描いてみるとプロジェクト運営に有用な情報が色々得られる可能性がある、という事が分かったからです。
テスト自動化はバグカーブをより早く収束させるためのプロセスの最適化として捉えると、テストや品質のエキスパートの方達の得意領域になってくるのではないでしょうか。
つまり。。。??
ここで、最初の疑問「テストの自動化は開発者、テスターどちらがやるのが良いか?」について考えてみます。開発者とテスターが協力する事で初めてテストプロセスへの入力の正確性を高めたり、開発•テストプロセスの最適化が可能になると私は考えています。つまり私の回答は「テスト自動化は開発者とテスター両者が協力してやった方が良い」です。
継続的システムテストのこれから
テストプロセスの効率化
継続的システムテストのプロセス品質を高めて行くためにはもう一つ、プロセスの効率化が欠かせません。継続的システムテストのテストプロセスでも一般的なものと同じ以下のプロセスがあります。
- テスト設計
- テストケース生成(実装)
- テスト実行優先順位付け
- テスト実行
- 欠陥特定
- 振り返り
- テスト設計や優先順位付けへのフィードバック
メトリクスと開発者の知見の活用
このテストプロセスを効率化していくためにはメトリクスと開発者の知見の活用が重要になります。
「テストの自動化」と言ったときに、今その言葉が指す自動化の対象は「テスト実行」だけである事がほとんどです。ですが、メトリクスを活用する事で、もしかしたらテストケース作成やテストの優先順位付けの多くの部分も自動化する事が可能になるかもしれません。
また、システムテストではテストの抜け漏れが問題となるケースがしばしば起きます。これは、システムテストが自動化されている環境でのテストの網羅性について実はよく分かっていないという課題が根底にあります。○○億件のテストが自動化されていると有名なGoogleのSETとICST 2014で「システムテストの網羅性と十分性とを評価する指標が今後必要になる」と話す機会がありました。
テストプロセスの中でもテスト設計と欠陥特定は特に重要な部分であり、テストが自動化された環境でもヒトがたくさんの時間をこの2つに割く必要があります。このテスト設計や欠陥特定をより早く正確に行うための開発者の知見の活用も重要です。
おわりに
「継続的システムテストは新しい概念なのか?」と言えばそんな事はないです。継続的インテグレーション(CI)や継続的デリバリー(CD)に本来内包されるべきものです。
ただ、CIやCDでは"従来のシステムテストや品質保証はどうなるのか”についてスポットライトがあてられていないため、システムテストについては様々な論争が巻き起こっているのも事実です。
私の一連のContinuous System Testについての活動について、海外のアジャイルテストのエキスパートに「Good to see system test getting some love」とコメントを頂いた事もあり、まぁシステムテストに対してみんな愛が足りないよな、と。 (笑)
この継続的システムテストという考え方と経験発表は、「システムテストの自動化」「メトリクス」に着目したアジャイルなプロジェクトの中でもかなり希有なものであり、これからの開発プロセスの変化の中でシステムテストや品質がどう変わっていくのかを考える一助になればと思います。
ソフトウェア品質シンポジウム2014参加レポート③ 品質やメトリクスについて学んだよ
ソフトウェア品質シンポジウム2014に参加したレポートですが、この品質やメトリクスについて学んだ内容については、どこまでブログに書いてよいのかよく分からないし、本気で書いたら行数もすごいことになってしまう、という事で参加したセッションのダイジェストをお送り致します。
併設チュートリアル(9月10日)
新しいソフトウェアテスト ウォーターフォール•モデルからの決別
こちらのチュートリアルでは
- グーグルやSalesforceなどでテスト自動化が進められている事例の紹介
- テストもこれからどんどん変わって行く必要がある事
- TDD + 探索的テスト
が紹介されていました。
「コードカバレッジ100%を目標としてたくさん時間をかけてテストをするのではなく、顧客に価値を提供するのに80%で十分なら20%分上げるのに必要になる時間の短縮がアジリティとして価値になる」という説明の仕方が伝わりやすそうでいいなと思いました。
本会議1日目(9月10日)
基調講演1 ビジネスが変わる••• 品質が変わる
この基調講演には「今まで通りの品質だけでなく、これからはアジリティも品質として重要になる」というメッセージが込められていて、まさにシンポジウム全体を象徴する講演でした。また、「お堅いイメージの金融システムのトップがこういうメッセージを発する事がすごい」とのコメントを伺い、なるほど!と思いました。
セッションA1 一般発表(テスト)
僕も経験発表をさせて頂いたセッション。自分の発表については別途詳細を書きます。特徴的だったのは、4つの発表すべてが結合•システムテストを対象にしていたことです。これは、TDD is dead. Long live testing. に代表されるような最近のアジャイル系の潮流とも合致しているなぁと思いました。
また、"SQiP Best Presentation Award"を受賞した"システムテストにおけるテスト分析手法の提案" という発表では、アジャイルでシナリオテストと呼ばれているタイプのテストを網羅的に設計するのに有効かもしれない手法が提案されていました。
セッションA2 一般発表レビュー (レビュー)
レビューのセッションでは、なるほど、バックグラウンドとして「些細な欠陥のレビューに時間が割かれてしまう事で重要な欠陥を見逃す事」が問題としてあると言う事、そしてそれを防ぐための手法が提案されていました。どの手法も
- レビューで欠陥を見つけたらそれで終わり、ではなく、きちんとそれらの情報を分析して、次のレビューにつなげる
- レビュー観点の導出を工夫する事で重大な欠陥に集中出来るようにする
という考え方が根底にあるのかなと感じました。
SIG 何で協力してくれないの?!••• 新しい仕事の前に働きやすいチームを作ろう
SIGでは、テストやレビューから離れて、チームビルディングのテーマに参加してみました。"アイスブレイク"の方法が紹介された後、皆で実際にやってみるというスタイルでした。まぁ、なんといいますか、どんな組織の方もチームビルディングに苦労されているんだなあ、そんな感想を持ったSIGでした。
本会議2日目 (9月12日)
セッションE3 ソフトウェア品質保証部長の会からの情報発信
最近、テスト自動化、品質、アジャイルについて少し上の方の上長とどう話したら良いのかなと考える機会が多いので参加してみました。
そしてこのセッション枠は僕の中で一番賛否両論の多い枠でもありました。
賛否両論うずまく色んな意見や考え方に触れる事が大事という視点では、一番気づきの多い枠だったかもしれません。
よかった点は、既存のスキームの枠をこえた新しい品質についての考え方がいくつも示されていました。ここで示されていたスキームやフレーズを使えば、少し上の方の上長にも響くかもと感じました。
セッションD4 企画セッション レビューとテストは使い分けるべきか?
こちらのセッションについては
ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ - Test Automation
で詳細書きましたのでそちらをご覧下さい。
基調講演2 リスクマネジメントのための失敗学--再発防止と未然防止--
こちらのセッションは、内容、しゃべり、随所に入るボケなどすべてに圧倒されました。ホントにスゴかったです。このセッションを文字にしてブログで伝える事は不可能ですので、是非みなさん一般財団法人 日本科学技術連盟 − 失敗学と創造学セミナーに参加してみて下さい。
メッセージとしては、失敗を失敗として終わらせるのではなく、次の失敗をしないためにつなげる事が大事 というモノでした。
うーん、、、上の表現だとやっぱり、精神論とか教訓じみてて何か違うなぁ。もっとリアルで実践的なお話なんだよなぁ。
まとめ
3日間を通し「今までの品質をさらに改善、発展させる」お話と「新しい品質にチャレンジする」お話がたくさん詰まっていて、本当に学びの多いシンポジウムでした。
ソフトウェア品質シンポジウム2014参加レポート④となる次回レポートでは、いよいよ経験発表をした継続的システムテスト周りの話を書きます。
ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ
ソフトウェア品質シンポジウムに参加し、レビューについて色々学んできました。このエントリーは以下の前提でお読みください。
-
社内でGitをもっと有効活用するためのテストとレビューについての議論が盛り上がってきている
- 僕自身はテスト自動化の面でその議論に参加予定。なのでレビューとは?みたいなところについてきちんと理解したい
- また、業務上、テスト容易性等の観点で仕様書のレビューはするが、積極的にバグを探すためのレビューの経験はない
- そういったモチベーションで参加したレビューのトラックとレビューとテストは使い分けるべきか?というパネルディスカッションの内容をもとに書いています。
- もちろん僕のフィルターを一度通っているので、僕が間違って理解している部分等がある可能性があります。間違いを見つけた方はご指摘のほどよろしくお願い致します。
レビューについて考える上で
どういったレビューが効果的か考える上でまず重要になる事は
- まずレビューの大前提に則る
- レビューとテストはそれぞれ得手不得手としている部分が異なる
- その上でコンテキストから、レビューの目的を明確にする
の3つだと思いました。
レビューの大前提とアプローチ
- レビューの一番の目的は欠陥を見つけ出す事。欠陥を見つけ出すという目的の上ではその観点はテストと同じ。
- ただし、レビューはテストで見つけられない保守性の問題を見つけられる。また、教育や知識の共有という面もある。
- 加えて、テストはErrorを見つける事が出来るがExtraとMissingは見つけられない。一方でレビューはExtraとMissingを見つける事が可能
- 前工程であるレビューで見つけた方が、効率的にバグ修正が可能な欠陥がある。
こういった大前提を踏まえますと、
- レビューでは、レビューでしか見つけられない保守性、Extra, Missingを見つける事が最重要
- また、教育や知識の共有といった側面でレビューを行う事も組織的に有効
- それ以外の部分についてはテストとレビューの得手不得手を理解した上で、コンテキストに応じてレビューの目的を定義する
というアプローチになるのは必然ですね。
テストとレビューの得手不得手
では、テストとレビューの得手不得手は何か?パネルディスカッション中の井芹さんの事例紹介のスライドにまとめられていました。
*注 紹介にあたって「あくまで個人の一例であり、一般的なものではない」との補足がありました。
9枚目のスライドです。
この表を踏まえて
レビューの得手として
- テストよりもレビューの方が要求や設計を変える影響力を発揮しやすい
- 再現性が低くテストでは検出コストが高い欠陥を、達人のレビューによって低コストで発見出来る
- レビューにテスターが入る事でテスト項目を減らす事が出来る
- 探索的テストとレビューは似ている
レビューの不得手や問題点として
- 観点が属人的になりやすい
- チェックリストなどにしてしまうと、プロセスが形骸化してしまう可能性がある
- レビューで網羅性の担保を考えると、得手であるスピードが下がってしまう
- スピードを重視するあまり、準備期間をとらない事で不毛な議論に終始してしまう事がある
といった点が挙っていました。
コンテキスト重要
上記のような得手•不得手が一般的に考えられますが、
- どういった欠陥を見逃すとリスクが大きいか
- どれくらいアジリティが重要視されるか
- どういう欠陥は、レビューで見つけると修正コストを少なく済ます事が可能か
といったコンテキストは会社やプロジェクトによって大きく異なる。プロジェクト毎にレビューの目的と見つけたい欠陥を事前に決めてから行う事が重要、というお話でした。
私の所属している会社ですと、ウェブ系のアプリケーションのレビュー観点というのが共通であって、その上でサービスの性質ごとにコンテキストに沿ってカスタマイズしていくのかな、と思います。
これ以上は、会社に持ち帰ってからの議論ですので今はここでは書きません 笑。
ハーベスタ
もう一つレビューに関連して面白いと思ったのは、レビューのトラックで提案されていたハーベスタという役割です。レビュー観点や見つかった欠陥についての知見を蓄積する事で、より重要な欠陥を早く見つけられるようにしようという取り組みでした。
まとめ
レビューについて全然知識がなく参加したのですが、大前提のところを理解出来たかなと感じます。また、その得手不得手についてテスト、レビューそれぞれのエキスパートの方達のお話を聞く事で、引き出しが増えたのかなと感じます。発表者、パネルディスカッション参加者の方ありがとうございました。
ソフトウェア品質シンポジウム2014参加レポート① 参加のモチベーション
ソフトウェア品質シンポジウム
2014年09月10日から09月12日にかけて、ソフトウェア品質シンポジウム 2014に参加してきました。
このシンポジウムは"実践的で実証的なソフトウェア品質技術•施策の研究•普及を目的として、日本化学技術連盟の下に設置されたソフトウェア品質向上のための推進機構"である、SQiPの活動の一環として実施されています。シンポジウムの一番初めに野中先生よりSQiPのご紹介がありました。
-
エンタープライズ系や組み込みソフト系が多い
-
品質大国ニッポンをソフトウェア面で支えて来た企業の参加が多い
-
その一方で「今の時代にあった品質」を目指すため"多様化"に取り組んでいる
そういったコミュニティのシンポジウムです。
参加のモチベーション
何故、そういったアウェイなシンポジウムに参加したのか?
この2年間取り組んで来たテストの自動化を通して、テスト自動化を成功させる鍵は品質やメトリクスだと感じるようになったからです。特に2つの目的がありました。
- プロセス改善や品質を軽視して失敗しているアジャイルのプロジェクトをしばしば見る。プロセス改善や品質についてもっと学びたい。
- 自分たちの取り組んでいるシステムテストの自動化についての発表を通して、直近で困っている事や長期的に課題になりそうな事を品質やメトリクスのコミュニティに問題提起する。
あと、参加の1ヶ月前、
- Gitでの開発をもっと効率的にしていくためのレビューとテストについてヒントが欲しい
という目的も浮上してきていました。
他の記事で詳細を書きますが、どの目的も達成出来たのではないかと思うので、大満足のシンポジウムでした。
参加してみての印象
シンポジウム参加1週間前までは「品質のシンポジウム行くの楽しみだなー」としか考えてなかったんです。
が、1週間前に「SQiPの参加者とあの発表はマッチしているか分からない」と社内のアジャイルコーチの方にアドバイスをもらったり、社内でのリハーサルへの反応が両極端だったりとかありまして、参加当日は期待と心配が半々くらいでした。
しかし、東京海上日動システムズの横塚さんの「今までどおりの品質だけでなく、これからはアジリティも品質として重要になる」というメッセージが込められた基調講演を拝聴して一気に期待の方が大きくなりました。
また、懇親会でシンポジウムの中の方達が「SQiPによく出て来たね」「コミュニティの多様化にずっと取り組んでいたから、ウェブ系から参加してくれてうれしい」とお声をかけて下さったりした事も印象的でした。
3日間を通し、"今までの品質"を大事にしつつ"これからの時代の品質"にチャレンジされている方達がたくさん集まっているコミュニティなんだなあという事を実感しました。
その他のソフトウェア品質シンポジウムの参加レポート
参加したセッションや自分の経験発表については個別に記事を書いています。もしよかったら、そちらもご覧下さい。
ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ - Test Automation
ソフトウェア品質シンポジウム2014参加レポート③ 品質やメトリクスについて学んだよ - Test Automation
ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation
ソフトウェア品質シンポジウム2014参加レポート⑤ 社内勉強会コミュニティとか - Test Automation