ソフトウェア品質シンポジウム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)
社外で発表する事のメリットは数えきれないくらいあります。その中でも一番分かりやすいメリットは「インプットの情報の質が格段に上がる」事だと思います。
社外で発表すると、社外のエキスパートの方と知り合いになる機会があって、例えば、オススメの発表資料や本を直接教えて頂けたりします。数あるカンファレンス、ウェブ上に公開されているスライドや本の中から「これだ！！」というものを見つけるのは意外と大変ですよね。
私も下記に示すような「社内で活動しているだけではおそらく知る事が難しかった資料」（ほんの一部です）からヒントを得て業務の改善等を行っています。
- アジャイル開発における品質保証部門によるシステムテストのアプローチ
- 関係者に理解してもらえるアジャイル開発に向けて
- 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参加レポート④ 継続的システムテストの実現とこれから
９月１０日〜１２日まで参加したソフトウェア品質シンポジウムでは、”継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析”という経験発表を行い、「SQiP Best report Future Award（将来役に立つ可能性を秘めているもの）」という賞を頂きました。
この記事ではこの継続的システムテストについて、ソフトウェア品質シンポジウムへ参加し聴講した基調講演やセッション、ディスカッションを通して考えた事を書きます。
継続的システムテストのバックグラウンド
ビジネスとソフトウェアの品質の変化
クラウドやスマートフォンなどの技術革新によるビジネスを取り巻く状況が変化してます。そういったビジネスの変化に伴うソフトウェア品質の変化についてのソフトウェア品質シンポジウム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に参加したレポートですが、この品質やメトリクスについて学んだ内容については、どこまでブログに書いてよいのかよく分からないし、本気で書いたら行数もすごいことになってしまう、という事で参加したセッションのダイジェストをお送り致します。
併設チュートリアル（９月１０日）
新しいソフトウェアテスト ウォーターフォール•モデルからの決別
こちらのチュートリアルでは
- グーグルや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参加レポート④となる次回レポートでは、いよいよ経験発表をした継続的システムテスト周りの話を書きます。
ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ
ソフトウェア品質シンポジウムに参加し、レビューについて色々学んできました。このエントリーは以下の前提でお読みください。
-
社内でGitをもっと有効活用するためのテストとレビューについての議論が盛り上がってきている
- 僕自身はテスト自動化の面でその議論に参加予定。なのでレビューとは？みたいなところについてきちんと理解したい
- また、業務上、テスト容易性等の観点で仕様書のレビューはするが、積極的にバグを探すためのレビューの経験はない
- そういったモチベーションで参加したレビューのトラックとレビューとテストは使い分けるべきか？というパネルディスカッションの内容をもとに書いています。
- もちろん僕のフィルターを一度通っているので、僕が間違って理解している部分等がある可能性があります。間違いを見つけた方はご指摘のほどよろしくお願い致します。
レビューについて考える上で
どういったレビューが効果的か考える上でまず重要になる事は
- まずレビューの大前提に則る
- レビューとテストはそれぞれ得手不得手としている部分が異なる
- その上でコンテキストから、レビューの目的を明確にする
の3つだと思いました。
レビューの大前提とアプローチ
- レビューの一番の目的は欠陥を見つけ出す事。欠陥を見つけ出すという目的の上ではその観点はテストと同じ。
- ただし、レビューはテストで見つけられない保守性の問題を見つけられる。また、教育や知識の共有という面もある。
- 加えて、テストはErrorを見つける事が出来るがExtraとMissingは見つけられない。一方でレビューはExtraとMissingを見つける事が可能
- 前工程であるレビューで見つけた方が、効率的にバグ修正が可能な欠陥がある。
こういった大前提を踏まえますと、
- レビューでは、レビューでしか見つけられない保守性、Extra, Missingを見つける事が最重要
- また、教育や知識の共有といった側面でレビューを行う事も組織的に有効
- それ以外の部分についてはテストとレビューの得手不得手を理解した上で、コンテキストに応じてレビューの目的を定義する
というアプローチになるのは必然ですね。
テストとレビューの得手不得手
では、テストとレビューの得手不得手は何か？パネルディスカッション中の井芹さんの事例紹介のスライドにまとめられていました。
＊注 紹介にあたって「あくまで個人の一例であり、一般的なものではない」との補足がありました。
９枚目のスライドです。
この表を踏まえて
レビューの得手として
- テストよりもレビューの方が要求や設計を変える影響力を発揮しやすい
- 再現性が低くテストでは検出コストが高い欠陥を、達人のレビューによって低コストで発見出来る
- レビューにテスターが入る事でテスト項目を減らす事が出来る
- 探索的テストとレビューは似ている
レビューの不得手や問題点として
- 観点が属人的になりやすい
- チェックリストなどにしてしまうと、プロセスが形骸化してしまう可能性がある
- レビューで網羅性の担保を考えると、得手であるスピードが下がってしまう
- スピードを重視するあまり、準備期間をとらない事で不毛な議論に終始してしまう事がある
といった点が挙っていました。
コンテキスト重要
上記のような得手•不得手が一般的に考えられますが、
- どういった欠陥を見逃すとリスクが大きいか
- どれくらいアジリティが重要視されるか
- どういう欠陥は、レビューで見つけると修正コストを少なく済ます事が可能か
といったコンテキストは会社やプロジェクトによって大きく異なる。プロジェクト毎にレビューの目的と見つけたい欠陥を事前に決めてから行う事が重要、というお話でした。
私の所属している会社ですと、ウェブ系のアプリケーションのレビュー観点というのが共通であって、その上でサービスの性質ごとにコンテキストに沿ってカスタマイズしていくのかな、と思います。
これ以上は、会社に持ち帰ってからの議論ですので今はここでは書きません 笑。
ハーベスタ
もう一つレビューに関連して面白いと思ったのは、レビューのトラックで提案されていたハーベスタという役割です。レビュー観点や見つかった欠陥についての知見を蓄積する事で、より重要な欠陥を早く見つけられるようにしようという取り組みでした。
まとめ
レビューについて全然知識がなく参加したのですが、大前提のところを理解出来たかなと感じます。また、その得手不得手についてテスト、レビューそれぞれのエキスパートの方達のお話を聞く事で、引き出しが増えたのかなと感じます。発表者、パネルディスカッション参加者の方ありがとうございました。
ソフトウェア品質シンポジウム2014参加レポート① 参加のモチベーション
ソフトウェア品質シンポジウム
2014年09月10日から09月12日にかけて、ソフトウェア品質シンポジウム 2014に参加してきました。
このシンポジウムは"実践的で実証的なソフトウェア品質技術•施策の研究•普及を目的として、日本化学技術連盟の下に設置されたソフトウェア品質向上のための推進機構"である、SQiPの活動の一環として実施されています。シンポジウムの一番初めに野中先生よりSQiPのご紹介がありました。
「2005年頃から"多様化"に取り組んでおり、ソフトウェア領域全般からのソフトウェア品質をよくしたいという想いを共有する人が集まるオープンなコミュニティ」。
、、、が（どのカテゴリで参加登録したかハッキリ覚えてないのですが多分）僕の所属しているWeb系のサービス企業って0.2%のとこに分類される企業だよね！？参加者500人×0,2%って事は、一人って事だよね！？と4ページの表でビックリしました。
まとめると、
-
エンタープライズ系や組み込みソフト系が多い
-
品質大国ニッポンをソフトウェア面で支えて来た企業の参加が多い
-
その一方で「今の時代にあった品質」を目指すため"多様化"に取り組んでいる
そういったコミュニティのシンポジウムです。
参加のモチベーション
何故、そういったアウェイなシンポジウムに参加したのか？
この２年間取り組んで来たテストの自動化を通して、テスト自動化を成功させる鍵は品質やメトリクスだと感じるようになったからです。特に２つの目的がありました。
- プロセス改善や品質を軽視して失敗しているアジャイルのプロジェクトをしばしば見る。プロセス改善や品質についてもっと学びたい。
- 自分たちの取り組んでいるシステムテストの自動化についての発表を通して、直近で困っている事や長期的に課題になりそうな事を品質やメトリクスのコミュニティに問題提起する。
あと、参加の１ヶ月前、
- Gitでの開発をもっと効率的にしていくためのレビューとテストについてヒントが欲しい
という目的も浮上してきていました。
他の記事で詳細を書きますが、どの目的も達成出来たのではないかと思うので、大満足のシンポジウムでした。
参加してみての印象
シンポジウム参加１週間前までは「品質のシンポジウム行くの楽しみだなー」としか考えてなかったんです。
が、１週間前に「SQiPの参加者とあの発表はマッチしているか分からない」と社内のアジャイルコーチの方にアドバイスをもらったり、社内でのリハーサルへの反応が両極端だったりとかありまして、参加当日は期待と心配が半々くらいでした。
しかし、東京海上日動システムズの横塚さんの「今までどおりの品質だけでなく、これからはアジリティも品質として重要になる」というメッセージが込められた基調講演を拝聴して一気に期待の方が大きくなりました。
また、懇親会でシンポジウムの中の方達が「SQiPによく出て来たね」「コミュニティの多様化にずっと取り組んでいたから、ウェブ系から参加してくれてうれしい」とお声をかけて下さったりした事も印象的でした。
３日間を通し、"今までの品質"を大事にしつつ"これからの時代の品質"にチャレンジされている方達がたくさん集まっているコミュニティなんだなあという事を実感しました。
その他のソフトウェア品質シンポジウムの参加レポート
参加したセッションや自分の経験発表については個別に記事を書いています。もしよかったら、そちらもご覧下さい。
ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ - Test Automation
ソフトウェア品質シンポジウム2014参加レポート③ 品質やメトリクスについて学んだよ - Test Automation
ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation
ソフトウェア品質シンポジウム2014参加レポート⑤ 社内勉強会コミュニティとか - Test Automation
Continuous System Test
Written by Kotaro Ogino and Francois Picalausa
Background of this entry:
We reported on our experience with automated system testing for improving development process of large and distributed search platform (システムテスト自動化による大規模分散検索プラットフォームの開発行程改善) at Japan Symposium on Software 'Tokyo 2014.
This entry is the English version of 継続的システムテストについて - kokotatata's blog which explains the background of continuous system testing presented at the symposium.
Note: Currently the slides are only in Japanese. We hope we will have the opportunity to hold the presentation in English in the near future.
Background: Why continuous testing is important for Lean and DevOps.
Lean is a software development style which focuses on fast delivery of features of software to customers[1].To this end, one small requirement is implemented in each development cycle. Hence requirements analysis and development cycles are short, and value can be delivered rapidly to customers. Lead time is also decreased. Compared to waterfall, in which analysis, design, implementation and quality assurance are each tackled in one go, Lean allows to deliver value to customers more quickly.
On the other hand, a key factor in sucessful implementations of Lean and Agile development is software quality. For ensuring software quality in a Lean and Agile development, quality assurance activities should be conducted from earlier phases of a project[2]. In particular continuous testing helps verifying new features and preventing regressions.
DevOps is a culture where quick and fast feedback from customers to developers and analysts is valued. The realization of DevOps requires making a continuous improvement framework based on Agile practices[3]. Such practices include continuous integration (CI), continuous delivery (CD), and continuous monitoring. Continuous testing is not as well kown as CI and CD, but it can also help creating a safer continuous improvement cycle.
Objective: Why should we automate system tests?
The test automation pyramid is a representation of ROI and priority of automation for different test categories[4]. In general, unit tests and component tests lie at the bottom of the pyramid as they have high ROI. Integration tests, System tests, and acceptance tests which are a few levels above, should have lower ROI in theory, as quality is accumulated from lower levels. However, the effectiveness of test automation strongly depends on the context of the project, such as the culture of the team, and the characteristics of the software[5]. For instance, Ito Hiroyuki reports on a project which whose prioritisation of automation of acceptance tests led to high ROI [6].
Big Data related applications analyze large volumes of data with complex algorithm. In general, these applications are designed as distributed and collaborative. In addition, values for customers are not only depending on functionality of software but also on quality and size of the data.
Therefore, verification of cloud platforms characteristics including availability and operability and evaluation of both algorithm and data are important to assure customer's values. System testing is one of the places where those verification and evaluation can be conducted. Providing a continuous verification and evaluation environment for those test categories accelerate the continuous improvement cycle for both developers and analysts.
Benefits of continuous system test: reducing the time before a bug is fixed.
From our experience, continuous system tests allow to greatly reduce the time before bugs are fixed.
We identified two reasons for this. 1. We avoid big bang merges resulting from fixing system wide issues. 2. Developers can conduct system testing in their own timing.
We detail these two points next.
1. System tests can detect integration issues including specification and interface mismatch, incompatibility of versions and unexpected external specification changes. Continuous system testing aims to avoid encountering these issues at the very end of a project. Indeed, fixing these issues often implies having big bang merges that only makes the situation worse as the bugs are becoming more complicated and bigger in scope, which in turn means that investigation and fix take longer time.
Continuous system tests aim to reduce this problem by exercising the whole system in a continuous way. In particular, quick feedback is provided to developper by means of smoke tests which are quick, but usual test scenarios that the system should handle.
Using this technique, along with continuously merging source code changes allow developers to find out the integration issues as soon as possible, when their resolution is easier and quicker. This observation was also made by Henrik Kniberg in Lean from the Trenches (in its Japanese translation リーン開発の現場).
2. In addition, the cost of system test execution was very high so we needed to minimize the number of system tests that are run. For this reason, we run system tests only after a set number of bug fix and we verify them together. Since we automated these tests, our developers can verify the impact of their changes on their own schedule. The time frame for fixing bugs, from their discovery to the verification of the fix by automated system test, is shorter and the process becomes lean.
Evaluation: A reason for using "number of days for bug fix" for evaluation
For evaluating Software development practices and processes, evaluation metrics must allow comparing different practices and processes[7]. For evaluating test automation, coverage improvement, cost reduction, and number of days for bug fix can be used as metrics.
We have two important believes. First, tests themselves do not increase the quality of software, it can only be increased through analysis and development. Our second belief is that the objective of test automation is to accelerate the continuous improvement cycle of analyst and developers.
Of course, we calculated coverage improvement and cost reduction for internal project management purpose. However, to verify our assumption that is that continuous system testing accelerates the continuous improvement cycle, we chose the number of days to bug fix as our main evaluation metric.
Conclusion: Continuous system tests initiate continuous improvement.
In this report, we showed that continuous system tests is a first step towards improving development agility. In particular, it accelerates continuous improvement cycle of developers and analyst. Developers and analyst can aggressively push changes and improvments to the software safely, by verifying that their changes meet both functional and non-functional requirements using automated system test. In addition, automation of system test allows us to monitor and collect metrics for service improvement.
We hope to see more and more techniques to improve quality assurance in an agile way. Our journey to continuous improvement starts from now.
References
[1] "リーンとカンバンの本質", 平鍋健児
[2] アジャイル開発における品質保証部門によるシステムテストのアプローチ, 永田敦
[3] 事例から学ぶDevOps実現のためのプラクティス, 黒川敦
[4] はじめてのスクラム体験ワークショップ ~ アジャイル時代のテスターを目指して, 川口 恭伸
[5] コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて, 森崎修司
[6] 「最強」のチームを「造る」技術基盤 ディレクターズカット, Ito Hiroyuki
[7] 関係者に理解してもらえるアジャイル開発にむけて, 森崎修司
継続的システムテスト
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。
ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。
背景：開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる
リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに対して、要件を小さくする事でlead timeを短くし、顧客に価値を迅速に届けられるようにする。
一方で、リーンやアジャイルの開発スタイルを成功させる鍵はソフトウェアの品質であり、早期からシステムテストを実行する事が重要である[2]。継続的にシステムテストを実行し、新機能の振る舞いが正しい事やデグレが起きていないかを検証をするには自動化が必要になる。
DevOpsは、顧客からのフィードバックを迅速に開発へと反映させるサイクルを作ろうという概念だ。顧客からのフィードバックをもとにした迅速な改善を継続的に実現するために、継続的インテグレーション（CI）や継続的デプロイ(CD)、継続的モニタリングなどのプラクティスを実践する[3]。CIやCDほど知られていないが、継続的テストの実施は迅速な改善のサイクルを安全に回すためやはり重要だ。
目的：何故、自動化の対象がシステムテストなのか？
テスト自動化ピラミッドはそのROIと優先順位について説明している[4]。一般的に、単体テストやコンポーネントテストはシステムテストに比べて自動化のコストが低く、ROIが高いと考えられている。品質は積み上げる必要があり、セオリーとしてのテスト自動化ピラミッドに疑問の余地はない。しかし、テスト自動化の効果はプロジェクトやソフトウェアのタイプ等、コンテキストに強く依存する[5]。アクセプタンステストの自動化を優先したプロジェクト運営の事例も報告されている[6]。
ビッグデータ関連のアプリケーションは複雑なアルゴリズムを大規模なデータに適用するため、複数のコンポーネントが複雑に分散、協調するように設計されている。また顧客に提供する価値はソフトウェアの機能性だけでなく、分析に使っているデータの質や量にも強く依存する。
そのためビッグデータ関連のアプリケーションでは可用性や運用性といったクラウドプラットフォームとしての性質の検証と、アルゴリズムとデータの両者の面から評価する事が顧客の価値につながる。これらの検証と評価を行うのがシステムテストであり、それを継続的に実行していく環境を提供する事は、すなわち開発者や分析者の継続的な改善のサイクルにつながる。
継続的システムテストのメリット：バグ修正日数の改善の理由は？
ビッグバンマージが解消された事と開発者のタイミングでシステムテストを実行出来るようになった事が理由として考えられる。
プロジェクトの最後に結合の開始やスモークテストの実施を行うと、そこで初めて仕様やインターフェースの不一致、バージョン間での互換性の問題や、予期しない外部仕様の変更が見つかる事がしばしばある。ビッグバンマージにより、それらの問題が複雑に絡み合い、バグの特定や修正に時間がかかってしまう。継続的に変更をマージし、スモークテストを実行する事で、まだシンプルなままの形でバグを見つけ修正する事が出来る。"リーン開発の現場"にも同様の解説がある。
また、手動で行っていたときはシステムテストのコストが高かったため、他のバグが直るのを待ってから複数のバグの再検証を一度に行う必要があったが、自動化してからは開発者や分析者が自分のタイミングでシステムテストを実行出来るようになった。バグが発見されてから修正し検証するまでがリーンになる事もバグ修正日数の改善に影響している。
評価：バグ修正日数を評価軸に使った理由
プラクティスやプロセスなどの開発スタイルを評価する場合、異なるプラクティスやプロセスとの比較が可能な評価軸を選択する事が重要である[7]。テスト自動化の評価の場合、カバレッジの向上や、コストの削減、バグの修正日数が考えられる。
我々は２つの大きな信念を持っている。１つ目は、テストそれ自身はサービスのクオリティを上げない、サービスのクオリティを上げるのは分析と開発である事。2つ目は、テスト自動化の目的は分析者や開発者の継続的な改善のサイクルを加速する事である。
自動化によるカバレッジの向上や、コストが○○億円下がった事についての計算はしている。しかし、この発表の論旨は"継続的にシステストを実行する事で、継続的な改善のサイクルを加速する"ことなのでバグ修正日数を評価軸として採用した。
まとめ：継続的システムテストは継続的改善の始まり
継続的システムテストの実現によりアジリティを改善する事は、開発者や分析者の継続的な改善のサイクルを加速する重要な１ステップ目だ。継続的システムテストにより、機能、非機能要件やアルゴリズムにデグレが起きていない事を確認する事で、積極的で安全な改善を促進出来る。加えてシステムテストの自動化は、サービス改善のためのメトリクスの収集を継続して行うための枠組みが出来た事を意味する。これから、継続的改善が始まる。
追記
継続的システムテストでの自動テストの質やバグカーブについてメトリクスに基づいて行った分析と考察をソフトウェア品質シンポジウム2014で経験発表しました。こちらも合わせてご覧下さい。
ソフトウェア品質シンポジウム2014参加レポート④ 継続的システムテストの実現とこれから - Test Automation
参考文献
[1] "リーンとカンバンの本質", 平鍋健児
[2] アジャイル開発における品質保証部門によるシステムテストのアプローチ, 永田敦
[3] 事例から学ぶDevOps実現のためのプラクティス, 黒川敦
[4] はじめてのスクラム体験ワークショップ ~ アジャイル時代のテスターを目指して, 川口 恭伸
[5] コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて, 森崎修司
[6] 「最強」のチームを「造る」技術基盤 ディレクターズカット, Ito Hiroyuki
[7] 関係者に理解してもらえるアジャイル開発にむけて, 森崎修司
