$30 off During Our Annual Pro Sale. View Details »

受託開発でテストファーストしたらXXXを早期発見できてハイアジリティになったはなし

terahide
December 18, 2019

 受託開発でテストファーストしたらXXXを早期発見できてハイアジリティになったはなし

Spring Fest 2019
株式会社ビッグツリーテクノロジ&コンサルティング 寺島秀樹 としての発表資料です

terahide

December 18, 2019
Tweet

More Decks by terahide

Other Decks in Programming

Transcript

  1. 東京オフィス(本社) 〒106-0041 東京都港区麻布台2-3-5 ノアビル3F Tel. 03-5114-6171(代表) ベトナム開発センター 15F Ladeco Building,

    No.266, Doi Can Street, Ba Dinh District, Hanoi Vietnam 札幌オフィス 〒060-0001 北海道札幌市中央区北一条西3-3 敷島プラザビル4F Tel. 011-206-1914 シリコンバレーオフィス 3350 Scott Blvd. #29 Santa Clara, CA 95054 受託開発で テストファーストしたら XXXを早期発見できて ハイアジリティになったはなし #jsug #sf_8C 2019年12月18日 寺島 秀樹
  2. 3 Copyright © 2019 BTC Corporation All Rights Reserved. 迅速な意思決定と契約

    • ITサービスがビジネスの中心 • 競合との差別化のため経営は意思決定の迅速化が求められる • ITサービス開発におけるアジリティは意思決定に大きく影響 • 日本のソフトウェア産業における構造 – 請負契約 62.1% – 準委任契約 27.6% – 自社開発 10.3% • ※「ユーザ企業ソフトウェアメトリクス調査2018」 P27 図表NE2-6-1-1 開発体制 より 請負契約・受託開発は意思決定に十分迅速?
  3. 4 Copyright © 2019 BTC Corporation All Rights Reserved. 品質と納期の遅れ

    • 全体の品質の評価 – 欠陥は少なく稼働後も安定 55.4% – 欠陥の発生は想定内に収まり稼働後もほぼほぼ安定 32.1% – 欠陥が多数発生し対応に追われた 7.1% – 欠陥が多く発生し混乱が発生した 3.6% – 欠陥が多く発生し大きな混乱が発生した 1.8% • ※「ユーザ企業ソフトウェアメトリクス調査2018」 P32 図表NE3-1-1 全体の品質 評価 より • 全体の納期の評価 – 計画より早く稼働 1.8% – 計画通り稼働 76.4% – 少し遅れたが大きな問題はなかった 14.5% – 納期が大きく遅れ要員を多く投入した 1.8% – 納期が大幅に遅れプロジェクトの見直しを余儀なくされた 5.5% • ※「ユーザ企業ソフトウェアメトリクス調査2018」 P32 図表NE3-1-2 全体の納期 評価 より 87.5%が品質は安定。 21.8%に納期の遅れ
  4. 5 Copyright © 2019 BTC Corporation All Rights Reserved. 会社概要

    社名 株式会社ビッグツリーテクノロジー&コンサルティング (BTC Corporation) 設立 2002年2月7日 所在地 〒106-0041 東京都港区麻布台2-3-5 ノアビル3階 代表取締役社長 杉山 健 社員数 264名(連結、2019年4月1日時点。内、ベトナムオフィス22名) 売上高 40億6900万円(2018年11月決算) 事業内容 システム開発およびコンサルティング デジタルマーケティング領域におけるコンサルティングと制作 RPA・クラウドなど最新技術の提供サービス
  5. 6 Copyright © 2019 BTC Corporation All Rights Reserved. 拠点

    東京を中心に札幌・ベトナムに開発拠点を、シリコンバレーに研究拠点を有しております
  6. 7 Copyright © 2019 BTC Corporation All Rights Reserved. 提供サービス

    SI・デジタル・RPAを組み合わせ、デジタルトランスフォーメーション(DX)時代において、お客様のビジ ネスを総合的に支援いたします • お客様満足度の向上・売上向 上を目的とする「攻めのIT」では、 経営戦略に則したシステムを瞬 時に構築することが重要です • BTCは、単に「システムを作る」の ではなく、いかに課題を解決する かに主眼を置き、変化に柔軟な システムをスピーディに構築し、お 客様のビジネスを成功へ導きます • 成長し続けるインターネット業界 の中で、デジタルマーケティング戦 略の立案・構築・最適化を行い ます • BTCでは、主にユーザー体験、テ クノロジー活用、データ解析の3つ の観点を中心に、ウェブサイト、 メール、ソーシャルメディア等、 様々なデジタルチャネルの最適化 を支援します • RPAとは”Robotics Process Automation”の略で、PC上で 行われるさまざまな事務処理をソ フトウェアロボットに代行させること で、ホワイトカラーのさまざまな業 務を自動化させる仕組みです • BTCは企業のさらなる業務効率 向上を支援するために、RPAのイ ンテグレーションをトータルでサポー トします SI事業 デジタル事業 RPA事業 デジタルマーケティング支援 ITコンサルティング・システム開発 RPAコンサルティング
  7. 8 Copyright © 2019 BTC Corporation All Rights Reserved. Profile

    • 株式会社ビッグツリーテクノロジ&コンサルティング – DX事業部 シニアアーキテクト • CSP-SM/CSP-PO • Java/Spring/Groovy/Spock/Geb/Sitimi • 酒/アニメ/ラーメン • テスト駆動飲み会 – https://tddrinking.connpass.com/ 寺島 秀樹 @terahide27
  8. 9 Copyright © 2019 BTC Corporation All Rights Reserved. 今からする話

    • Project A – 某機材製造メーカー – 統計をもとにした予約サービス – チーム構成:7人(うちベトナムと社内オフショア3人) – Spring Bootを使ったAPIを製造 – Spring Bootを使ったWebサービス(前述のAPIをサーバ サイドで使用) • Project B – 某薬局チェーン – 店舗統制サービス – チーム構成:2人 – Spring Bootを使ったAPIを製造 – ReactによるSPA ここ数年で行ったプロジェクト • Project C – 某公共図書館 – 蔵書管理サービス – チーム構成:7人 – Spring Bootを使ったAPIを製造 – C# .NET によるGUI
  9. 12 Copyright © 2019 BTC Corporation All Rights Reserved. いつ気が付く?

    Sequential Process Iterative Process 課題に気が付く (十分早い) 課題に気が付く (遅すぎる)
  10. 14 Copyright © 2019 BTC Corporation All Rights Reserved. TDD

    - テスト駆動開発 1イテレーションの中で 課題に気が付く (遅すぎる)
  11. 15 Copyright © 2019 BTC Corporation All Rights Reserved. TDD

    - Test Driven Development • まずレッドになる(失敗する)自動テストを書く • 一番早い方法でグリーンにする(成功させる) • リファクタする • 以上を繰り返えし目標に向かう テスト駆動開発のサイクル Red Green Refactor
  12. 16 Copyright © 2019 BTC Corporation All Rights Reserved. 2つのサイクル

    イテレーション TDD 実装・設計における テストファースト
  13. 17 Copyright © 2019 BTC Corporation All Rights Reserved. 振舞駆動開発

    - Behavior Driven Development(BDD) • “振舞駆動開発とは、ソフトウェアの相互作用に着目し、ソフトウェアがどのように振る舞う(動作 する)かを定義することを起点とした開発手法” – 「JUnit実践入門」より • 振る舞いはシナリオで定義する。これをスペック(テスト仕様)と呼ぶ • テストファーストであるかどうかより、スペックを自然言語で表現できるかを重要視する テスト仕様の語彙 JUnit実践入門 ISBN978-4-7741-5377-3 従来の3A Pattern(Arrange/Action/Assert) BDD ( GWT:Given/When/Then ) //JUnit4 with Groovy @Test void ”電卓を起動して9+9を計算すると結果は18であるべき”(){ def sut = new Calc() def actual = sut.add(9,9) assert actual == 18 } //Spock with Groovy def ”単純な足し算のシナリオ”(){ given: ”電卓を起動” def sut = new Calc() when: ” 9+9を計算する” def actual = sut.add(9,9) then: ”結果は18であるべき” actual == 18 }
  14. 18 Copyright © 2019 BTC Corporation All Rights Reserved. 仕様の明確度と遅延の関係

    • 要求仕様の明確度と後期遅延度(予定より早い+予定通 り) – 非常に明確 76.2% – かなり明確 77.8% – ややあいまい 67.1% – 非常にあいまい 55.8% • ※「ユーザ企業ソフトウェアメトリクス調査2018」 P59 図表NE6-5-36 要求仕様の明確度と後期遅延度より 要求仕様が明確でないと遅延が大きくなる傾向
  15. 19 Copyright © 2019 BTC Corporation All Rights Reserved. 仕様の明確度と満足度の関係

    • 仕様明確度別のプロジェクト全体満足の割合 – ※「ユーザ企業ソフトウェアメトリクス調査2018」 P60 図表NE6-5-40 仕様明確度別のプロジェクト全 体満足の割合 より 仕様が明確でないとプロジェクト全体の満足度が下がる傾向 87.7 76.4 51.8 37.2 0 10 20 30 40 50 60 70 80 90 100 非常に明確 かなり明確 ややあいまい 非常にあいまい
  16. 20 Copyright © 2019 BTC Corporation All Rights Reserved. 仕様はどこに書く?

    ドキュメントに記載した場合 • 動くプログラムは修正されたが、ドキュメントは後回しにされたり、修正されなかったりする • 結果、ドキュメントと実装が乖離していく 自動テストに記載した場合 • 自動テストに仕様を記載した場合、動くプログラムと同時に自動テストが修正され続ける – 自動テストが陳腐化しないための心の強さは前提(CIでグリーンを保ち続けるなど) • 現在動いているプログラムに対して、自動テストが成功することでその仕様が実装されていることが 検証できる • 結果、記載された仕様と実装の乖離は少ない よくある話: 実装とドキュメントの乖離
  17. 22 Copyright © 2019 BTC Corporation All Rights Reserved. 2つのサイクル

    ATDD TDD・BDD イテレーションにおける テストファースト 実装・設計における テストファースト ※ATDD: Acceptance Test Driven Development
  18. 23 Copyright © 2019 BTC Corporation All Rights Reserved. 受入テスト駆動開発

    - Acceptance Test Driven Development (ATDD) • ATDDは受入テスト仕様を用いたBDD • 受入テストレベルで行うテストのユーザがアプリケーション・サービスに行う操作をシナリオ化 • シナリオをBDDの語彙で自動テストに記載する • イテレーションの計画時に受入テストの仕様を確認しイテレーションの中で自動化 受入テストのテストファースト • トップページでキーワードで簡易検索を行うと一覧ページに遷移する • 一覧ページでタイトルリンクをクリックすると、対象の書誌の書誌詳細画面に遷移する • 書誌詳細ページで関連資料を表示をクリックすると関連資料が表示される • さらに閉じるボタンをクリックすると関連資料が非表示になる ・・・ ①イテレーション計画で テスト仕様を確認 ②イテレーション中に BDDで自動化
  19. 24 Copyright © 2019 BTC Corporation All Rights Reserved. テストのピラミッド

    「初めての自動テスト」より 初めての自動テスト ISBN978-4-87311-816-1 UI 統合 ユニット メソッドレベルの小さなテスト 複数の層を一つにつなげるテスト全般 アプリケーションをエンドユーザーが操作するのと 同じようにテストするスクリプト サービス
  20. 25 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションの構造

    弊社の典型的なアプリケーションの構造 初めての自動テスト ISBN978-4-87311-816-1 A. Server Side Rendering B. SPA + API C. GUI + API HTML JSON/XML/etc. JSON/XML/etc.
  21. 26 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションの構造とテストのピラミッド

    Auto Test Framework ※Sitimi は後述 ユニット 統合 UI (E2E) サーバ フロント サーバ フロント A. Server Side Rendering Spock (+ Spring Test) - Spock + Spring Test - Geb + Spock B. SPA + API - Cypress C. GUI + API - ー Sitimi* + Spock ATDDに取り組み始めたら、あまりやらなくなった
  22. 27 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションの構造とテストのピラミッド

    Auto Test Framework ※Sitimi は後述 ユニット 統合 UI (E2E) サーバ フロント サーバ フロント A. Server Side Rendering Spock (+ Spring Test) - Spock + Spring Test - Geb + Spock B. SPA + API - Cypress C. GUI + API - ー Sitimi* + Spock
  23. 28 Copyright © 2019 BTC Corporation All Rights Reserved. 皮下テスト(Subcutaneous

    Test) • “皮下テストは、アプリケーションのUIのすぐ下で 動作するテストを意味します” – martinFowler.comより (Google翻訳) • Spring Boot でAPIを実装することが多い • SpringTest(MockMVC)とSpockを使って APIのテストを行っている • テスト対象が「外部サービスを使う」などのスタブ 化は考えるが、サービスや永続化のレイヤをスタ ブにすることはしないことが多い • HTMLを返す場合は(皮下テストではないが) このテストはほぼ書かない Spock + Spring Test @SpringBootTest @Transactional class ExampleSpec extends Specification{ MockMvc mockMvc @Autowired WebApplicationContext wac def setup(){ mockMvc = webAppContextSetup(wac).build() } def "例を取得すると期待されるjsonであるべき"() { def expected = '{"id":1,"name":"example"}' when: def json = mockMvc.perform( MockMvcRequestBuilders .get('/v1/api/example')) .andExpect(status().isOk()) .andReturn().response.contentAsString then: json == expected } } https://martinfowler.com/bliki/SubcutaneousTest.html
  24. 29 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションの構造とテストのピラミッド

    Auto Test Framework ※Sitimi は後述 ユニット 統合 UI (E2E) サーバ フロント サーバ フロント A. Server Side Rendering Spock (+ Spring Test) - Spock + Spring Test - Geb + Spock B. SPA + API - Cypress C. GUI + API - ー Sitimi* + Spock
  25. 30 Copyright © 2019 BTC Corporation All Rights Reserved. Selenium

    と Cypress Browser Automation & Stubbing Response Browser Seleniumはブラウザ上の操作の 自動化のソリューション Browser Cypressもブラウザ上の操作の 自動化のソリューション ただしSeleniumに非依存 HTTP通信のスタビングが可能 HTTP Request Response (Stubbing) HTTP Request Response
  26. 31 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションの構造とテストのピラミッド

    Auto Test Framework ※Sitimi は後述 ユニット 統合 UI (E2E) サーバ フロント サーバ フロント A. Server Side Rendering Spock (+ Spring Test) - Spock + Spring Test - Geb + Spock B. SPA + API - Cypress C. GUI + API - ー Sitimi* + Spock
  27. 32 Copyright © 2019 BTC Corporation All Rights Reserved. Geb

    – Very Groovy Browser Automation • WebDriverの機能、jQueryセレクタの便利さ、 Page Objectモデリングの堅牢さ、Groovyの 表現力を統合します(意訳) • It brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language. Geb is a browser automation solution. https://gebish.org/ import geb.Browser Browser.drive { go "http://myapp.com/login" assert $("h1").text() == "Please Login" $("form.login").with { username = "admin" password = "password" login().click() } assert $("h1").text() == "Admin Section" }
  28. 33 Copyright © 2019 BTC Corporation All Rights Reserved. Spock

    + Geb • Spockは、Gebで使用するのに最適な革新的 なテストフレームワークです。 Spock + Gebを 使用すると、非常に明確かつ簡潔で、理解しや すいテスト仕様をわずかな労力で提供できます。 (Google翻訳) • Spock is an innovative testing framework that is a great match for using with Geb. Using Spock + Geb gives you very clear, concise and easy to understand test specifications with very little effort. Page Object modelling import geb.Page import geb.spock.GebSpec class LoginSpec extends GebSpec { def "login to admin section"() { given: to LoginPage when: loginForm.with { username = "admin" password = "password" } and: loginButton.click() then: at AdminPage } } https://gebish.org/
  29. 34 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションの構造とテストのピラミッド

    Auto Test Framework ※Sitimi は後述 ユニット 統合 UI (E2E) サーバ フロント サーバ フロント A. Server Side Rendering Spock (+ Spring Test) - Spock + Spring Test - Geb + Spock B. SPA + API - Cypress C. GUI + API - ー Sitimi* + Spock
  30. 35 Copyright © 2019 BTC Corporation All Rights Reserved. Sitimi

    – Very Groovy is a GUI Automation • SikuliXの機能、Page Objectモデリングの堅 牢さ、Groovyの表現力を統合します。そう、そ れはGebのように! • It brings together the power of SikuliX, the robustness of Page Object modelling and the expressiveness of the Groovy language. so. It's like Geb! Sitimi is a Windows Automation Solution. https://github.com/terahide/sitimi import sitimi.spock.SitimiSpec import sample.CalcWindow class SimpleCalcSpec extends SitimiSpec{ def "a simple scenario"(){ given: start Calc expect: shown CalcWindow when: add(9, 9) then: "result is" (18) } } 操作したい部分をキャプチャします。 src/test/imgs/9_button.png Package sample import sitimi.Window class CalcWindow extends Window{ def add(i, j){ click "src/test/imgs/${i}_button.png" click "src/test/imgs/plus_button.png" click "src/test/imgs/${j}_button.png" click "src/test/imgs/equal_button.png" } // snip
  31. 36 Copyright © 2019 BTC Corporation All Rights Reserved. スペックの相似

    - Movable Specification BDDの語彙で表せない部分はCompose Method(Page|Window Object)に隠蔽 import geb.Page import geb.spock.GebSpec class LoginSpec extends GebSpec { def "login to admin section"() { given: "ログインページを表示する" to LoginPage when: "ユーザ名とパスワードを入力する" loginForm.with { username = "admin" password = "password" } and: "ログインする" loginButton.click() then: "管理者ページが表示されるべき" at AdminPage } } import sitimi.spock.SitimiSpec import sample.CalcWindow class SimpleCalcSpec extends SitimiSpec{ def "a simple scenario"(){ given: "電卓を起動する" start Calc expect: "電卓が表示されるべき" shown CalcWindow when: "9+9を計算する" add(9, 9) then: "結果は18であるべき" "result is"(18) } } Geb Sitimi
  32. 38 Copyright © 2019 BTC Corporation All Rights Reserved. ご参考:

    ある新人のはなし 自動テスト難しいです • 初めてテストを書いたのでspecが何をしているかわからなかった。それを把握するのに苦労した • でも日本語が多いので「うわぁ!英語しか書いてない!見たくない!」的なアレルギー反応は少なかった SitimiというかSikuliX • SikuliXは色の区別や似た文字の判別が難しいらしい – アイデンティティのある箇所を探してスクリーンショットを取るのが難しい、というか面倒 – SikuliXが見分けられない画像は人間にもフレンドリーではないUIなのかもしれない – SikuliXが識別できないものは似たようなボタンや画面が複数ある場合が多い? • 時折何をしても動かないことがある、そして次の日には何事もなかったかのように動く。気まぐれなのかもしれない Sitimi • なにより書いていて楽しい! • 簡単なコードですぐに動かせるので、達成感が得やすい • 自分の書いたテストがアプリを動かすのを見ているのが面白い • ゲーム感覚 世界“唯一”のSitimiのパワーユーザである、Aさんの感想
  33. 39 Copyright © 2019 BTC Corporation All Rights Reserved. ご参考:

    ある新人のはなし • Aさん「なぜかテストが落ちるんです」 • 寺島「機械の方がだいたい人間より正確だから、あなたの書いたテストコードに問題があるので は?」 • ー 数分悩み何かを修正 ー • Aさん「直りました」 • 寺島「おっけー。じゃあ、全部動かしてみて」 • ー 数分後 ー • Aさん「1件なぜか落ちました。単体で実行すると成功します。。。」 • 寺島「自動テストは、リピータブルで独立してないとダメよ」 日常の会話 その1
  34. 40 Copyright © 2019 BTC Corporation All Rights Reserved. ご参考:

    ある新人のはなし • 寺島「このテスト文学的じゃない」 • Aさん(ぶ、文学?) • 寺島「自動テストのスペックは読んだときに、文学作品のようにストーリーがないと」 • Aさん(何か言い出しおった。。。) 日常の会話 その2
  35. 42 Copyright © 2019 BTC Corporation All Rights Reserved. BTC

    Code Base テスト管理 自動テスト 情報集約基盤 自動デプロイ ビルドコントロール ソースコントロール AWS CodeCommit(Git) AWS CodeDeploy AWS CodeBuild AWS Device Farm 開発者 開発環境 ソースコード テストコード(JUnit) テストコード(Selenium) ビルドファイル(Gradle) 構成ファイル(Docker) Clone Push ビルド(Gradle) 単体テスト(Junit) メトリクス取得(Sonarプラグイン) AWS CodePipeline 継続的デリバリーとリリースの自動化 Amazon EC2 サービス提供基盤 デプロイスクリプト サーバ 資材 デプロイ モバイル デバイス 資材 テスト実行 テストログ プロジェクト コード 機械学習・予測分析 Amazon Machine Learning テスト ログ コミットログ BTC Code Base powered by 1 4 3 2 Microsoft Azure フィード バック データ格納・分析(BI, DWH) 格納 格納 分析 AIによって進化し続けるDevOps基盤
  36. 43 Copyright © 2019 BTC Corporation All Rights Reserved. アプリケーションテンプレート

    on Spring Boot 「Spring Boot2徹底活用」 ISBN978-4-8026-1185-5
  37. 44 Copyright © 2019 BTC Corporation All Rights Reserved. BTC

    Code Base • マージリクエスト • チケット • ドキュメント • コミット • ビルド/デプロイ • テスト • コメント • 時間帯別/曜日別/作業者別 • etc. 開発の営みの可視化 ふりかえりでマージリクエストの大きさに注目 マージ数を5倍にする取り組みを行う 次のイテレーションで消化したポイントが6倍に!
  38. 45 Copyright © 2019 BTC Corporation All Rights Reserved. 早期発見

    繰り返しのプロセスとテストファースト BTC Code Base アプリケーションテンプレート イテレーション ATDD ふりかえり CI・CD TDD・BDD ・・・
  39. 46 Copyright © 2019 BTC Corporation All Rights Reserved. 取り組みがもたらしたもの

    • 仕様の可視化・タスクの可視化・実績の可視化 • 予実などの予測がしやすくなった • トラブルが起きても収束が早くなった • コマンドコントロールが減ってきた • プロジェクトの運営が円滑に 私は、 • 仕事が増えた • 今年度が始まった時は1チームだったのが、現在5チームに所属 • 間接的に関わるチームも増えてきた
  40. 47 Copyright © 2019 BTC Corporation All Rights Reserved. 「私」がこれから取り組んでいきたいこと

    • テストの並列化 • CCPM • お客様が行う受入テストのATDD • テストの削減(テストしない品質保証)
  41. 48 Copyright © 2019 BTC Corporation All Rights Reserved. よくある質問

    • YesでありNoです – 自動テストは社内のほとんどのプロジェクトで実行しています • JUnit • Spock • Geb • Cypress • Sitimi • etc. – BTC Code Baseはまだ開発中です – が、標準的なDevOps基盤の構築は終わり、実案件へ導入が始まっています – Scrumは社内の一部のプロジェクトで行われています – BDD・ATDD に取り組んでいるのは自分のプロジェクトだけです Q. 社内全体で取り組んでいるのですか?