Test Automation

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

2015年個人的なコミュニティ系の活動まとめ

2015年に行ったコミュニティ系の活動についての個人的なめも。

1月

テスト自動化に関するTechTalkの企画

Gebに関する勉強会がしたいとの声が社内で上がったので拾って企画。開催後、上の方から色々指令が飛んできたw

www.shiftinc.jp

2月

社外カンファレンス参加：JaSST' Tokyo 2015

特にレポートなど書いていない（笑）。アジャイルテスト系が面白かった。

3月

社外事例報告集への寄稿：IPA 先進的な設計・検証技術の適用事例報告書 2015 年度版

3月に執筆、11月に公開。2014年度のJaSSTとSQiPの発表を事例報告としてまとめた。

公開資料：https://www.ipa.go.jp/files/000049409.pdf

4月

社内勉強会企画＆LT：Global Engineer Gathering Tokyo

DevOps系のエンジニアを世界中から集めた勉強会。テスト自動化についてLT。資料非公開

５月

ブログへのポスト：アジャイルテストのテスト設計の話。

Scaled Agile Framework上でどのようにアジャイルテストを行うかと、テストのRefactorobilityについて考えていた。

kokotatata.hatenablog.com

６月

社外コミュニティへの寄稿: Ultimate Agile Stories Interation 5への寄稿

グローバルの多様性の高い文化でのソフトウェアテストについて色々考えていたので、そこらへんについて書いた。

Iteration5執筆者・タイトル一覧

７月

社外勉強会への参加：Web Service QA Meeting Vol.1

この頃は、テストの永続性とRefactorabilityのことばかり考えていたので、その辺の視点でレポートを書いている。

kokotatata.hatenablog.com

８月

資格受験：JSTQB Advanced Level Test Manager

8月に受験。11月に結果発表。受かっていた。ソフトウェアテストについては独学で勉強している部分が多く、自分の理解があっているか不安な部分もこれ以前は多々あったが、合格率10%程度の資格に受かったので結構自信を持てた。

継続的システムテストのテストレベルとテストフェーズについて、考えたブログ記事。

kokotatata.hatenablog.com

９月

社外カンファレンス参加：XP祭り

特にレポートなど書いていない。インフラ系の発表をXP祭りで聞けたのがよかった。

社外カンファレンス参加と発表：ソフトウェア品質シンポジウム

昨年度の発表を再演。また、アジャイルテストのエキスパートたちと交流できたのがよかった。

発表資料：

【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK

10月

社内勉強会参加：DevOps会議

他部署がどんなDevOpsをやっているか知れた。資料非公開。

社外ブログインタビュー：Live DevOps in Japan!

インタビューとなって公開されていますが、実質はエバンジェリストやアジャイルコーチの方達とお酒を飲みながらディスカッションした飲み会w

この飲み会を通してテスト自動化だけでなく、チームやプロセス、アーキテクチャについて濃いディスカッションが出来たのが今の業務に効いてきてる。

DevOps インタビュー : 第 1 回 楽天さんの DevOps について聞いてみた ～前編: 継続的システムテストの実力～ - Live DevOps in Japan! - Site Home - TechNet Blogs

11月

社外カンファレンス参加：Google Test Automation Conference

初めてのGTAC。グローバルジャイアントと比較して、テスト自動化の差が追いつけない距離じゃないことを知れたことがよかった。

kokotatata.hatenablog.com

社内・外カンファレンス発表：

共同セッション。純粋に楽しかったw 懇親会でも、社内、社外問わずこれからのDevOpsについて様々なディスカッションが出来た。資料非公開。

rakutentechnologyconference2015.sched.org

12月

社外カンファレンス発表：システムテスト自動化カンファレンス

継続的システムテストについて体系的にまとめた内容を発表した。漫才も楽しかったし、懇親会も楽しかった。

発表スライド：【システムテスト自動化カンファレンス2015】 楽天の品質改善を加速する継続的システムテストパターン #stac2015

感想

  • こうやって振り返ってみると、前半はソフトウェアテストを深掘りしていたが、後半はDevOpsにシフトチェンジしてきているのが面白い
  • 昨年後半の発表は２件とも共同セッションだったのが面白かった。今年もうすでに決まっているものも、共同セッションや共著ばかりだw
  • 社外の方から声がかかるようになってきたのが成長なのかなと思う。コミュニティから得た知見で、業務で成果を出せたときは、その経験を積極的にコミュニティにフィードバックしていきたい
  • テックカンファで英語での社外発表をした。
  • 社内勉強会の企画を前半は少し行っているが、後半まったく出来ていないことが反省
  • チームメンバーをコミュニティにうまく巻き込めていないことが反省。社外発表できるくらいの成果をチームメンバーに出してもらって、それを自分の言葉で社外で発表できる。そんなチームに育てていきたいなあ。
  • 海外カンファレンスでの発表もやりたいなあという気持ちがありつつ、積極的には動けてない。うーーん。。。
  • 大きな声では言えないけれども、採用につながるような発表ができるようになりたいなあ。そこまで出来たらコミュニティ系活動が会社に貢献している感がリアリティを増す。

 

Google Test Automation Conference 2015に行ってきた

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

 2015年11月10~11日にかけてボストンで開催されたGoogle Test Automation Conference 2015に参加してきました。 このブログエントリでは、カンファレンスの雰囲気や講演内容の感想についてレポートします。

f:id:kokotatata:20151114064048p:plain

GTAC 2015  |  Google Test Automation Conference  |  Google Developers

参加の背景

 ある日、上司に「何か海外カンファレンス参加しないの？」と聞かれて、そういえば先日モバイル系のテスト自動化をしている同僚から「俺、Google Test Automation Conference申し込んだけども、お前も申し込まない？」と誘われてた事を思い出して申し込みました。

 僕は運良く抽選にあたり、同僚は運悪く抽選に外れてしまったのですが、、、。正確な数字は公表されてなかったと思いますが、1000人くらいの申し込みに対して100~200人が抽選に当たったようです。他の参加者からは「うちの会社は100人くらい申し込んで、３人だけ参加できた」との話も聞いたので、参加できた事自体かなりラッキーでした。

 会社の業務では海外のテストエンジニアと関わる事も多い、というか、80%くらいのコミュニケーションは外国籍のエンジニアとなんですが、海外のエンジニアコミュニティとの関わりは多くないので、海外のトップエンジニアの話が聞ける機会として大きな期待を持って参加しました。

全体的な印象

 全体的な印象として、スマートフォンやChrome Castのような物理的なデバイスを扱うテストの話の比率が多かったなという印象を受けました。発表タイトルで言うとこの辺りですね。

  • Robot Assisted Test Automation
  • Mobile Game Test Automation Using Real Devices
  • Using Robots for Android App Testing
  • Nest Automation Infrastructure
  • Effective Testing of a GPS Monitoring Station Receiver
  • Automation on Wearable Devices

やっぱりGoogleさんとしても、これからのIoT時代のテストを意識しているという事でしょうか。他の発表は以下のようにカテゴライズできると思います。

  1. Fearless Change系
  2. Testability改善のためのアプリケーションや自動テストシステムの設計
  3. テストデータの生成・管理
  4. テストの品質評価

以下、それぞれのカテゴリについて感想を書きます。

講演を聞いての感想

1.Fearless Change系

 KeynoteであったJürgen Allgayerさんの講演が、YouTubeにおけるテスト自動化のFearless Changeの発表で本当に素晴らしかったです。

 解くべき課題として、複数のサービスやコンポーネント間での結合、システムテストの問題が挙げられていました。このあたりはどこの開発・運用でも一緒なんですね。

で、その課題を5年くらいかけて解いていくFearless Chageが紹介されてました。最初の数年で、自動化プラットフォームの構築をして、その後チーム作りをし、今は文化作りをしているそうです。

 チーム作りの部分で

  • Metricsやレポートの自動化、見える化、透明化
  • Metricsにもとづいたチーム主導でのプロダクト、運用、テストの品質改善
  • 自動化！！
  • 自動化とインフラのスキルのチームミックス

が紹介されていて、すごいなと思うとともに、今のチームが進んでいる方向と段階も間違っていないなwと思いました。

2. Testability改善のためのアプリケーションや自動テストシステムの設計

 Testabilityの設計改善系では「Flaky(なテスト)」という言葉が使われていました。日本のコミュニティでは「自動テストの信頼性」として取り扱われている分野ですね（*1 *2）。印象的だったのは、

  • デバッグモードでしか動作しないテスト用の機能をアプリケーションに埋め込んでおく
  • テストのコントローラーにGod Classのようなものを作るのではなく、各デバイスやコンポーネント間で協調動作するようなメッセージ機能をアプリケーションに埋め込んでおく

のような、Testabilityに関するアプリケーション設計へのフィードバックが当たり前のように行われていることでした。

 後は、モックを使うことはいいことなのか？Microserviceな世界でのモックの在り方とかが今後の議論になりそうだと感じました。

3. テストデータの生成・管理

 テストデータの生成にはみなさん苦労していますね（笑）。カンファレンスでは、"Statistical Data Sampling"という発表の中で確率論的なアプローチ、"Event Generators"で、決定論的なアプローチが紹介されていました。どちらもアルゴリズムの詳細な説明がなかった事が残念でしたが。

 "Statistical Data Sampling"が非常に面白く、ソフトウェアテストではテストデータの統計的な分布の情報よりもEdgeケースの方が重要という点を指摘した上で、その解決方法のアプローチを簡単に紹介していました。詳細は語られていないので分からないのですが、機械学習のクラスタリングを緩く適用することで、テストデータの"Representative Point"を炙り出しているようです。

4.テストの品質評価

 テストの品質評価のために、自動テストのリファクタリングの必要な部分を見つけ出すアルゴリズム(発表タイトルは"Test Suites and Program Analysis")と、テストのカバレッジは直接的にはテストの品質には関係ない(発表タイトルは"Coverage is Not Strongly Correlated with Test Suite Effectiveness")という話が紹介されていました。

 特にテストの品質の方では、「バグの検出能力とコードカバレッジには相関関係はあるけども因果関係はない」といった趣旨の話がされており、個人的にはうーんどうなんだろうとも思いつつ、この辺りの議論が将来盛り上がると面白くなりそうですね。

おまけ

 11月21日に私の所属している会社で、楽天テクノロジーカンファレンスが開催されます。

tech.rakuten.co.jp

 Microsoft牛尾さんとのセッション内でGTAC 2015の内容も少しフィードバックしようと考えてますので、ご興味のある方はぜひご参加ください。

rakutentechnologyconference2015.sched.org

リンク

GTAC 2015のビデオ

参考文献

テストエンジニアにこそ楽天テックカンファのDevOpsセッションに参加して欲しい

タイトルからして分かりやすいステマ記事ですね。

はい。 ま、僕はカンファレンススタッフではないのでステマ記事を書く必要はないんですけども、ちょいちょいと流れてくるDevOpsセッションの情報を見ると「おー豪華だなー」と。

rakutentechnologyconference2015.sched.org

 

その一方で「Dev? Ops? ってか、楽天テックカンファにはソフトウェアテストのトラックがないの？！」、と思ったテストエンジニアの方も多いのではないかと思います。

違うんです。

テスト自動化はDevOpsを支えるための一番重要な技術。継続的デリバリーを読んでみても、半分くらいのページはテストや品質の話。ということで、楽天テックカンファではテスト自動化関連のトピックはDevOpsのトラックに吸収されています。

これからのソフトウェアテストを考える上で重要なことは「テストがチームにもたらす価値」。

アジャイルテスト４象限見てみましても、「開発をサポートするテスト」「エンドユーザーのためのテスト」に区分することからテスト戦略の立案が始まっています。僕はここにもうひとつ「素早く安定した運用を実現するためのテスト」が重要だと考えています。

つまり、DevOpsによってユーザーに価値を届けるためには、自動テストによってDevとOpsに素早く改善のフィードバックループを回していく。

DevOpsのトラックでは、DevOpsの基本から実際の企業での実例、そしてテスト自動化がDevOpsにもたらす価値と技術についての議論などが展開されるようです。 テストエンジニアの方々の楽天テックカンファのDevOpsセッションへのお越しをお待ちして居ります。

システムテストフェーズで単体テストレベルを実行する？！

継続的システムテスト

テストフェーズとテストレベル

昨日受けたソフトウェアテストの資格試験で面白い問題があった。

縦軸にテストフェーズ、横軸にテストレベルをとってテスト計画を作れ

という趣旨のもの。

システムテストフェーズで単体テストレベルのテストを実行する？！

みたいなw

 継続的システムテストのコンセプトが一般的にまだまだ理解されにくく、その原因は

  • Myersの言う「テストフェーズ」[1]
  • Beizerのいう「テストのスコープ・観点（テストレベル）」[2]

あたりを混同しているエンジニアが多いからなのかなとちょうど考えていたので、この問題は僕の心にクリティカルヒットした。このブログエントリでは、継続的システムテストをテストフェーズとテストレベルから整理し直してみる。

継続的システムストのテストフェーズとテストレベル

継続的システムテストのテストフェーズ

継続的システムテストでは、

　・開発テストフェーズ　　（開発者の行うテスト）

　・システムテストフェーズ  (テストエンジニアの行うVerification)

    ・ユーザーテストフェーズ  (プロダクトオーナーなどが行うValidation)

の３つのテストフェーズがある事を前提としている。

 ここでのテストフェーズはMyersが言う通り、テスト活動の時間的順序を表しているわけではなく、工程の実施時期が重なっても構わない[1]。例えば自動化が進み１日に何回もデプロイとテストしているような環境であれば、これらのフェーズはそのほとんどが重なり平行に実施されるようになる。

 フェーズがほとんど重なるのであれば、フェーズを分ける事のメリットは何だろう？という疑問が湧くと思う。フェーズを分ける事のメリットは、それぞれのテストフェーズによってもたらされる価値が明確になる事だ。この３つのテストフェーズは、ソフトウェア開発ライフサイクル内の実施される時期にもとづいて、それぞれ異なる価値をプロジェクトに提供する。

 開発テストフェーズは開発者に「素早く実装可能な開発環境」という価値をもたらす。ユーザーテストフェーズは「ユーザーに価値のある正しい機能が提供されているか？」を確認する。

 継続的システムテストが主眼を置くシステムテストフェーズの価値は３種類の受け取り手が存在する。

  • １つ目は開発者。継続的にシステムテストを実行し素早くテストからのフィードバックをする事で、開発者はバグの修正を短縮したりと開発のアジリティが向上する[3]。
  • ２つ目はプロジェクトマネージャー。継続的にテストを実行しそのメトリクスをモニタリングする事でプロジェクトの進捗状況が見える化される[4]。
  • ３つ目はユーザーテストの担当者。ユーザーテストフェーズの準備ができている事をシステムフェーズが保証する事で、ユーザーテスト環境の安定性が向上する。

継続的システムテストのテストレベル

 継続的システムテストでは、各テストフェーズがそれぞれ適切なテストレベルを持っている。ここでいうテストレベルはBeizerの言う「テストのスコープや観点」だ[2]。なので、例えば

システムテストフェーズの中で

  • 「単体テスト」や「インターフェースの結合テスト」といった低レベルのテスト
  • 一般的にテストレベルの文脈の中でシステムテストと呼ばれる「パフォーマンステスト」「信頼性テスト」「運用性テスト」
の両方を実施する

という、言葉的には少し奇妙な事態が発生する。

 しかし、この一見すると少し奇妙な現象がもたらすメリットは大きい。システムテストフェーズでも、単体テストレベルからシステムテストレベルまでのテストレベルを網羅する事で、

  • テストの網羅性を担保する事
  • 柔軟にテストレベルを変更したり、テスト設計のリファクタリングを行うことででテスト活動を効率化する事

が可能になる[5]。

アジャイルテストと従来のソフトウェアテスト

 勘のいい人はお気づきだと思うけれども、僕は継続的システムテストは継続的デリバリーと同様にアジャイルテスト四象限と自動化にのっとってテストを整理し直したコンセプトだと考えている[6]。

 アジャイルテスト四象限では「誰に」「どんな」価値をテストが提供するのかを考える[7]。次にそれらの価値の提供を「いつ」「どのスコープのテスト」によって実現するのかを考える。

 この『「誰に」「どんな」価値を提供するのか』の部分が『V&Vとテストフェーズ』だし、『「いつ」「どのスコープのテスト」』の部分が『「テストフェーズ」「テストレベル」』だ。

 これらのコンセプトや考え方は別にウォーターフォールやテスト自動化を前提としていない[8][9]。もちろんウォーターフォール開発でも実現可能だが、継続的デリバリーやアジャイルテストにおいても実現可能だ。

 継続的システムテストやアジャイルテスト四象限は従来のテストの考え方を積極的に取り入れている。突然変異的に生まれたものではなく、むしろソフトウェアテストの発展の歴史の中で正統的に出てきたものだ。

お知らせ

継続的システムテストについて2015年9/18(金)にソフトウェア品質シンポジウムでお話しします。ご興味のある方は是非ご参加ください。

www.juse.jp

参考文献

手動の運用手順書と自動スクリプトのレビュー

継続的システムテスト

 先日、「手動の運用手順書を書いたのでレビューして下さい」と後輩に頼まれたのでレビューした。といっても、僕の専門はテストと自動化なので正直な話、手動の運用手順書のレビュー経験がない（笑）。しょうがないので「自動スクリプト」としてレビューするよと断りをつけてレビューした。

 実際、レビューしてみると手動の運用手順書と自動運用スクリプトのレビュー観点やその方法は共通する部分も多いが、その一方で前提や観点の違いから気をつけないといけないと感じた事も多かった。

共通する点

レビューの目的

 本番運用フェーズに入っているシステム上でシステム変更を実施する事は、システム上で予期しない変更をもたらし障害を引き起こすリスクを伴う。このリスクは手動でも自動化でも変わらない。システム変更に関するレビューの一番大事な目的は、 システム変更に伴うリスクが管理可能になっているかを確認する事だと思う。

 一般的に以下の点については、手動の運用手順書でも自動運用スクリプトでも、明確に記載されているか、その考え方が分かるように表現されているべきだと思う。

  • システムの変更箇所 (例 機能A
  • 影響範囲 (例 機能B
  • リスクのリスト　（例 機能Bがデータの不整合により動作しなくなる事
  • リスクが顕在化する事なく、システムへの変更が終了した事を確認する方法　(例 機能AとBが期待通りに動作する事
  • リスクが顕在化した事を確認する方法 (例 機能Bのログファイルにエラーログが出ている事
  • リスクが顕在化した場合の対応方法 (例 データの不整合の解消

 これらを事前に明確にしリスクを管理可能にする事で、手動の運用手順書も自動運用スクリプトもその信頼性が向上する。

ロールバック

 システム停止を伴うシステム変更は、短い運用作業時間、少ないシステム停止回数で行う事が一般的に求められる。なので、複数のシステム変更を一度に実施する事は多い。ここで気をつけなければならない事は、複数のシステム変更はロールバック不可能な状況を引き起こす場合がある事だ。

 例えば変更A,変更B,変更Cを行う時に、変更Aと変更Bの後にはまだロールバック可能だが、変更Cの後にロールバック不可能になる事はしばしば起こる。

  • 一回のシステム変更で実施：　[変更A → 変更B → 変更C] (ロールバック不可能)
  • 複数のシステム変更で実施：　[変更A] (ロールバック可能)→ [変更B] (ロールバック可能)　→ [変更C]  (ロールバック不可能)

 ロールバックはデプロイに際しリスクを回避するための重要かつシンプルな手段だ[1][2]。だから、そのロールバックのポリシーが適切であるかをレビューで確認する事は重要だ。

異なる点

エラーに対する対応方法

 実行したコマンドに対して期待と異なる挙動が返って来た場合、手動の運用ではその場で人間による柔軟な対応が可能だが、自動スクリプトでは事前に定義した対応方法しか機械は実行出来ない。手動の運用ではエラーケースへの対応方法が手順書には表現されていなくても暗黙知として共有されていれば十分な場合があるが、自動スクリプトではすべて形式知化していく必要がある。

 ネガティブテストとそれらのテストで失敗した場合の対応方法が十分に定義されていない自動スクリプトは、悲惨な結果をもたらしかねない。自動運用は信頼性が低いと一部で指摘される理由はここにあるだろう。

 ただ、このあたりはもうすでに何年も前に解かれている問題だとも思う。例えばJavaでは、期待と異なる状況が起きた時には適切なExceptionを投げ、プログラムの適切な場所でCatchし対応を行う。JUnitではテスト実行中にExceptionが発生しても後処理を確実に実行するフレームワークを提供する。

システムの状態に関する前提

 もうすでに何年も前に解かれている問題であると言っても、実際にすべてのエラーケースを事前に網羅的に定義して行く事は難しい。システムの設定が複雑になるとテストすべきポイントは増える[4]。 特にシステムの状態について複数のケースを考慮しなければいけない場合や、コマンドを複数回行った場合に得られる結果が異なる場合等には、考慮すべきエラーケースの数が爆発的に増加する。

 この問題を解決するための考え方が、"Immutable Infrastructure", "Infrastructure as Code", "冪等性"だ[3]。システムの状態を適切にバージョン管理し、なりうる状態に制約を入れる事で、システムの事前状態をコントロール可能にする事が出来る。また、システム変更を実施する前にシステムの事前状態を確認し、適切な事前状態の時のみに変更を実施する事もエラーケース数の爆発を抑えることに役立つ。

 手動運用の場合も、もちろんこれらの考え方を適用する事は可能だが、その一方で手順書の効率化等から暗黙知化されていたり、逆に職人芸と化した手順書となっていたりする。手順書レビューでは、明確に表現されていないシステムの事前状態がないかの注意が必要だ。

 レビューとテストの使い分け

 僕が今回のレビューで一番戸惑った部分がここだ。自動スクリプトでは殆どの場合、自動テストも一緒に書かれる。自動テストがあると、テストとレビューそれぞれでカバーしたい範囲について簡単に議論が出来るのでそれぞれの役割が明確になりやすい。例えば、ファイルをコピーするコマンドと、コマンドの実行結果を確認するテストがある場合、自動テストを実行するだけでコマンドの正しさを確認する事が出来る。

 手動の手順書でも"#テスト済み"などとコメントを書く事で 、ある程度テストとレビューの役割を区別する事が可能かもしれないが、自動テストがないために、ついついコマンドの正しさが気になってしまう。

 レビューでは人間にしか確認出来ない事に集中する事が大切だ。コマンドの実行結果の正しさのような自動化する事で機械でも確認出来る観点ならばそちらに任せてしまった方がいい[5]。"レビューの目的"の項でも挙げた「システム変更に伴うリスクが管理可能であるかを確認する」といった人間にしか確認出来ない観点に集中しやすいという点においては自動スクリプトに分があると思う。

まとめ

 システム変更に関するレビューにおいて、手動の運用手順書と自動スクリプトで、

  • システム変更に伴うリスクが管理可能になっているかを確認する事という目的は共通

であるが、

  • エラーに対する対応方法やシステムの事前状態に関する前提が異なるため、気をつけるべきポイントが異なる

事について述べた。

 今回、それぞれの手段でのレビューに共通、異なるポイントという切り口で書いたが、これらのポイントは手動運用手順書を自動化する際の切り口として扱う事も出来る。これらのポイントを適切に解いて行く事で、より幸せな運用自動化が実現可能になると考えている。

参考文献

 

テストの期待値を分解すると言う事 ~Web Service QA Meeting Vol.1の感想~ #webqa

勉強会 Refactorable Testing Architecture

 本日、Web Service QA Meeting Vol.1という勉強会に参加して来た。様々なウェブサービス企業のQA関連企業で集まって、WebのQAについてあれこれ話そうよと言う勉強会だ（と思う）。

 ま、僕の悪い癖は「面白いな」と思った話については議論を盛り上げたいと思うと言うか、いわゆるマサカリを投げたくなる事なんですが（笑）

 マサカリ話はいったん置いておいて、面白いなと思った話について書いてみる。

 僕が面白いなと感じた発表の趣旨は僕の言葉で説明すると「テストの実行時間が長いので、テスト観点とテストレベルを見直し、適切なテストレベルで実行する事でテストの実行時間を短縮した」になる。別の言い方をすれば「アジャイル４象限の右上で実行していたテストを左上で実行する事で効率化した」だ。（発表者ならびに関係者の皆様、僕の理解が間違っていましたらゴメンナサイ。連絡頂ければ訂正します。）

 この発表で僕が面白いと感じたのは上の「テスト観点とテストレベルを見直し」の部分を「テストの期待値を分解し」と説明していた点だ。そう、１つ１つのテストケースについてテスト設計が終わった後でも期待値を分解する事は実施してもいい（のかもしれない）。

 期待値を変更してしまうと、テストの網羅性の再評価等のテスト設計のやり直しに相当する作業が発生する可能性がある。けれど期待値を分解し、分解された期待値をテスト観点を元に整理し直すだけならば、テストの網羅性には影響がない。この発表の肝はまさにテスト設計のリファクタリングをやっている事だと思った。

 テスト設計は一度作ったら終わりではない。機能の設計をリファクタリングを通じて改善して行くのと同じように、テスト設計も継続的に改善して行くものだ。テスト設計の継続的な改善を通じてサービスの成長に貢献出来る事がウェブサービスのQAの醍醐味。そんな事を考えた実りある勉強会でした。

2015年前半戦 いいなと思った記事やスライドの個人的ブックマーク

勉強会

2015年前半戦いいなと思ったインターネット上の記事やスライドを個人的にブックマークしときます。

コンセプト+ テクノロジー

 

コンセプト

アーキテクチャとかデザインパターンとか

テストとか品質とか

Docker