Tweet
Tweet

Slide 1

Slide 1 text

テストの自動化と テスト駆動開発 Test Driven Development for Automating Tests やっとむ こと 安井力 合同会社やっとむ屋 アジャイルコーチ ©2021 やっとむ、合同会社やっとむ屋

Slide 2

Slide 2 text

2001年ごろアジャイルと出会い、開発者、チームリーダー、ト レーナー、導入支援と多様な立場で関わってきた。(株)永和シス テムマネジメントにて2010年頃からアジャイルコーチを主軸とし て活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 著書・訳書 tsutomu.yasui@gmail.com twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)

Slide 3

Slide 3 text

ねらい • 主に顧客向けの業務システム(B2B)を開発している、 • プロジェクトベース、ウォーターフォールプロセスが主流の 開発現場や運用保守の現場にいる、 • マネージャーのかたに向け、 • テスト自動化が自分たちのメリットになると納得してもらい、 • その道筋として2つのアプローチを紹介して、 • テスト駆動開発 • ペアプログラミング • 組織的・長期的に取り組む価値を感じてもらう

Slide 4

Slide 4 text

アジェンダ 1. 自動化したい理由 2. 必要な人材を考える 3. テスト自動化の端緒 ～テスト駆動開発について～ 4. 深めつつ広げる鍵 ～ペアプログラミングについて～ 5. 見る夢について

Slide 5

Slide 5 text

自動化したい理由

Slide 6

Slide 6 text

アジャイルの導入 • ウォーターフォールからアジャイルへの移行が増加 • 短納期、要求の流動化、フィードバックからの改善 • ビジネス環境が激しく変化する • やってみないと結果がわからない

Slide 7

Slide 7 text

VUCA 世界の変化は激しさを増しており、予想ができない • Volatility ― 変動、変化 • Uncertainty ― 不確実性 • Complexity ― 複雑 • Ambiguity ― 曖昧 ※脅し文句です

Slide 8

Slide 8 text

アジャイルなソフトウェア開発とは アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 アジャイル宣言の背後にある原則 私たちは以下の原則に従う: • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客 様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるま で彼らを信頼します。 • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 • 動くソフトウェアこそが進捗の最も重要な尺度です。 • アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよ うにしなければなりません。 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 • シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちの やり方を最適に調整します。 アジャイルソフトウェア開発宣言(2001年) http://agilemanifesto.org/iso/ja/

Slide 9

Slide 9 text

従来型 ウォーターフォール アジャイル

Slide 10

Slide 10 text

従来型 ウォーターフォール アジャイル プロセスや ツール 個人と対話

Slide 11

Slide 11 text

アジャイルなソフトウェア開発の3側面

Slide 12

Slide 12 text

ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へソニックガーデン代表倉貫義人のブログ https://kuranuki.sonicgarden.jp/2011/09/post-46.html

Slide 13

Slide 13 text

ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へソニックガーデン代表倉貫義人のブログ https://kuranuki.sonicgarden.jp/2011/09/post-46.html いいもの 作るぞ！ できた！ 終わったー！ ここちょっと 使いにくいな 業務と 合わないなー 作り直す しか。。。 こんなアイデア どうかな？ これは 便利！ ここ変えたら もっと良くなる 手直し続けて 馴染んだな～

Slide 14

Slide 14 text

アジャイルで解決。。。？ • サイクルが早くても、速く作れるわけではない • むしろだんだん遅くなる • リリース回数が増えるほど品質の不安が増える • 対応できる人材が足りない、メンバーが疲弊する

Slide 15

Slide 15 text

アジャイル導入≠解決策 アジャルであろうがウォーターフォールであろうが必要な 開発であろうが保守運用であろうが役立つ 解決策は何か？ (ヒント: 今日のタイトルは「テストの自動化とテスト駆動開発」) ここからはテストと品質に着目

Slide 16

Slide 16 text

短納期、頻繁なリ リース、VUCA Point of Salesから Point of Useへ 個人と対話を 価値とする

Slide 17

Slide 17 text

開発の労力とテストの労力

Slide 18

Slide 18 text

追加変更とテストの労力 追加した部分をテストする その周辺までテストする 変更があると テストをほぼ やりなおす 最初は全部 テストする

Slide 19

Slide 19 text

ソフトウェアメトリックス調査2020 システム開発・保守調査 一般社団法人 日本情報システム・ユーザー協会（JUAS) 図表6-3-2 投入工数別フェーズ別新規改修区分別工数(p.21) より

Slide 20

Slide 20 text

新規/再開発と開発規模による テスト工数割合の傾向 0% 5% 10% 15% 20% 25% 30% 35% ＜ 10人月 10～50人月 50～100人月 100～500人 月 ＞500人月 ＜ 10人月 10～50人月 50～100人月 100～500人 月 ＞500人月 テスト工数(%) ユーザー総合テスト工数(%) 新規開発 再開発 ソフトウェアメトリックス調査2020 システム開発・保守調査 一般社団法人 日本情報システム・ユーザー協会（JUAS) 図表6-3-2 投入工数別フェーズ別新規改修区分別工数(p.21) より

Slide 21

Slide 21 text

再開発はテスト負担が重い • 変更内容のテスト ＋ 変えてない部分の再確認テスト • 再テストが発生 • 「1箇所でも変えたら全部テストやり直し」 • 影響範囲の見極めは大変 • システムとソフトウェアの構成、設計はどんどん複雑化 • 見落としが起きやすい • 綿密に影響範囲を見極める → コスト増加 • 影響範囲を安全寄りに判断 → コスト増加

Slide 22

Slide 22 text

アジャイルの場合 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 アジャイル宣言の背後にある原則 私たちは以下の原則に従う: • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客 様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるま で彼らを信頼します。 • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 • 動くソフトウェアこそが進捗の最も重要な尺度です。 • アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよ うにしなければなりません。 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 • シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちの やり方を最適に調整します。 アジャイルソフトウェア開発宣言(2001年) http://agilemanifesto.org/iso/ja/

Slide 23

Slide 23 text

アジャイルだとさらに深刻に • 原則から抜粋 • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることに よって、お客様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースし ます。 • 極端に小規模・短納期 • 常に再開発 • どんどん機能が増える • 仕様が変われば内部設計も変わる • 基本的に全体再テストが必要

Slide 24

Slide 24 text

「作る」より「直す」ことを重視 • 動いているものを動かしながら直す • 上手なほど小さく作ってリリースする • 車のライトが切れたのに「電気系統総取っ替え」と言われたら？ • 調子の悪い部品だけ交換したり、1パーツだけグレードアップしたり、したい • イチから作るより、直し続ける方が高度なスキル • 完璧に完成するより、直せるように作る方が高度なスキル • アジャイル開発は常に保守(改修)

Slide 25

Slide 25 text

https://www.thesun.co.uk/living/3594533/plastic-house-of-the-future-disneyland-visitors-flocked-to-in-the-1960s/

Slide 26

Slide 26 text

再テスト＝回帰テスト • 変更の影響がないか確認する • 回帰テスト、リグレッションテストとも呼ばれる リグレッションテスト： 修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他 コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。変更には、オ ペレーティングシステムやデータベース管理システムの新しいバージョンなど、環境の変更も含ま れる。そのような意図しない副作用をリグレッションと呼ぶ。リグレッションテストでは、テストを実行 して、そのような意図しない副作用を検出する。 (テスト技術者資格制度 Foundation Level シラバス Version 2018.J01 )

Slide 27

Slide 27 text

解決策 = 回帰テストの自動化 • 「意図せず影響」する範囲をテストする • 範囲を限定しにくい • 範囲を特定するだけでも工数がかかる • 「前回と同じ」テストを「すべて実行」すればよい • 自動化してあれば、流すだけ • 人間が「同じこと」を繰り返すのは非効率 • 結論: 短納期や変更頻度が高いなら回帰テストを自動化すべき 注意: 「回帰テスト」というテストはない。 前回と同じテストを再実行して差異がないか確認する。

Slide 28

Slide 28 text

組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） https://speakerdeck.com/twada/strategy-and-tactics-of-building-automated-testing-culture-into-organization-2020-autumn-edition?slide=14

Slide 29

Slide 29 text

開発とテスト の関係 再開発の テストは重い 解決策＝回帰 テスト自動化

Slide 30

Slide 30 text

テストの種類 • テストレベル • テストタイプ • 静的技法 • アジャイルテストの四象限

Slide 31

Slide 31 text

テストの種類: テストレベル • コンポーネントテスト • 独立したテスト対象のテスト • ユニット、モジュール、クラス、画面など • 統合テスト • コンポーネント間のインターフェースのテスト • OS、ハードウェアなどとの相互処理のテスト • システムテスト • システム全体のテスト • 受け入れテスト • ニーズを満たしているか、稼働できるかのテスト

Slide 32

Slide 32 text

テストの種類: テストタイプ • 機能テスト • 仕様通りに機能するかのテスト • 非機能のテスト • セキュリティ、性能、保守性など非機能要求のテスト • 構造テスト • 構造をどの程度網羅したか評価するテスト • 再テスト、回帰テスト

Slide 33

Slide 33 text

テストの種類: 静的技法 • レビュー、インスペクション • 静的解析ツールの利用

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

チェッキングとテスティング • チェッキング • 製品の特定の観測に対してアルゴリズムによる 機械的ルールを適用して評価するプロセス • テスティング • 製品を経験し、探索し、実験することで製品に ついて学ぶことを通じて、評価するプロセス。問 いを立てる、研究、モデル化、観測、推論などの 活動を含む “Testing and Checking Refined”より引用、和訳はやっとむ責 https://www.satisfice.com/blog/archives/856 http://testerchan.hatenadiary.com/entry/2020/03/09/080000

Slide 36

Slide 36 text

探索的テストと手順付きテスト • 探索的テスト • テスター一人ひとりの自由と責任を前面に出し、テスト設計、テスト実行、テ スト結果の解釈、そして学習を、プロジェクトを通じて並行に、かつ相互補完 的に続くアクティビティと捉えることで、テスターの仕事の質を継続的に最適 化する、テスティングのスタイル https://sites.google.com/site/exploratorytestingjapan/translation/et3-0 • 手順付きテスト • 仕様などを元に事前に設計したテスト手順に沿ってテスターがおこなうテス ト。手順をプログラム化(スクリプト化)して自動化することが可能。

Slide 37

Slide 37 text

テストの自動化は要注意 https://www.shoeisha.co.jp/book/detail/9784798139210

Slide 38

Slide 38 text

自動化したテスト＝保守が必要な資産 https://speakerdeck.com/twada/tdd-live-in-50-minutes?slide=15

Slide 39

Slide 39 text

STAR テスト自動化研究会 https://sites.google.com/site/testautomationresearch/test_automation_principle

Slide 40

Slide 40 text

テストの種類 自動化は 簡単ではない (２コマで 済んでしまった)

Slide 41

Slide 41 text

必要な人材を考える

Slide 42

Slide 42 text

テストに関わる2つの職種 • プロダクトをテストする • テスト担当者、テスター、品質保証担当 • テストを自動化する • SET • どちらも高度な専門職 • 両方できる人は強力(でも稀)

Slide 43

Slide 43 text

テスト自動化エンジニア(SET) • Software Engineer in Test • テストの自動化は専門スキル • 言語やツールの多様性 • アーキテクチャの多様性(Web、API、バッチ、クラウド、etc.) • テストの多様性(ユニット、結合、システム、運用、etc.) • 自動化の実行環境、インフラも自力で構築 • チームやプロジェクトに導入する エヴァンジェリスト役、コンサルタント役

Slide 44

Slide 44 text

テスト自動化エンジニア(SET) • Software Engineer in Test • テストの自動化は専門スキル (以下は一例) エリア 内容 例 言語やツール 開発言語、テスティングフレー ムワーク、自動化ツール、負荷 ツール、など Java, PHP, JUnit, pytest, jest, Selenium, Cypressなど アーキテクチャの多様性 Web、API、クラウド、バッチ、 GUI、OS、など REST, JSON, AWS, Azure, Lambda, Functions, .NET Core, Linuxなど テストの総合知識 テストフェーズ、テスト技法、テ スト戦略、など ユニットテスト、システムテスト、同値分割、ペアワ イズ法、探索テスト、レコード＆プレイ 自動化の仕組み 環境構築、インフラ設計、実行 システム、など AWS、CircleCI、GitHub Actions、自動デプロイ、 テストデータ構築 コミュニケーション コンサルティング、エバンジェ リズム、メンタリング、など チームへの導入、相談役、自動化リーダー、先生 役、組織の推進

Slide 45

Slide 45 text

SETの仕事の例 https://www.slideshare.net/linecorp/an-agile-way-as-an-set-at-line

Slide 46

Slide 46 text

テスト担当者 • テストの目的、効果、プロセスを熟知した専門家 • テスト担当者の仕事 • テスト対象を分析する • テスト計画を立てる • テストを設計する • テストを実施する • 開発者とコミュニケーションする • 状況を見える化する • プロセスを改善する

Slide 47

Slide 47 text

テスト担当者に必要な能力 • 学校の先生が書いた作文を生徒が添削する？ • プロスポーツの試合を素人が批判する？ 「我々が直面する重大な問題は、 問題を引き起こしたときと同じ思考レベルでは 解決できない」 アルベルト・アインシュタイン "The significant problems we face cannot be solved at the same level of thinking we were at when we created them“ Albert Einstein https://en.wikiquote.org/wiki/Albert_Einstein

Slide 48

Slide 48 text

https://www.amazon.co.jp/dp/B00GSHI03I/

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

なぜテスト担当者に能力が必要なのか そもそもテストとは… • すべてを網羅できない • 「全部テストせよ」は不可能 • 「バグがないこと」は証明できない • 有限のテスト工数で問題を効果的に見つける創造的作業 • バグは遍在する • 問題を見つけるのに効果的な技法がある → 修得 • 人間がおかす間違いには傾向がある → 分析 • 1匹見たら30匹 → 想像力 • 包括的理解、緻密な分析、創造的探索

Slide 51

Slide 51 text

テスト担当者の心意気 https://twitter.com/miwa719/status/1370647468275232768

Slide 52

Slide 52 text

テスト担当者の心意気 https://miwa719.hatenablog.com/ https://miwa719.hatenablog.com/entry/daily20210221 http://www.jasst.jp/symposium/jasst1 9kyushu/report.html#S1

Slide 53

Slide 53 text

テスト人材 • 絶対数が少ない・業界として足りてない • 流動性が低く採用はハードルが高い • イベント、勉強会が活発 • 内部で育成するのが一番 (他にあまり選択肢がない)

Slide 54

Slide 54 text

テスト自動化の 人材 (SET) テスト計画、テス ト設計の人材 テスターは 情熱ある専門職

Slide 55

Slide 55 text

スクラムと人材育成 「スクラムがもたらす最終的な結果、 いわば設計目標は、飛躍的に生産性 を上げるチームの実現にある」p.22 (『スクラム 仕事が4倍速くなる世界標準のチーム戦術』ジェフ・サザーランド、 2015) 「メンバーはグループ全体として学習 し、さらに専門を越えて学習する」p.209 (『アジャイル開発とスクラム』野中郁次郎、平鍋健児、2013) https://www.amazon.co.jp/dp/4152095423 https://www.amazon.co.jp/dp/4798129704

Slide 56

Slide 56 text

スクラムフレームワーク • 1チーム(10人以内)でプロダクトを作る • 1スプリント(1ヶ月以内)でプロダクトの増分(インクリメント)を 完全な品質で完成する • 必要な工程は管理も含めすべてチーム内で担当する (他にも大事なポイントがあるがここでは割愛)

Slide 57

Slide 57 text

https://www.servantworks.co.jp/resources/scrum_overview_figures/

Slide 58

Slide 58 text

https://www.servantworks.co.jp/resources/scrum_overview_figures/ 設計 仕様 ユーザー ヒアリング 実装 フィード バック 相談 画面 デザイン データ ベース 1ヶ月以内の スプリント 修正 設計改善 デバッグ 改善 テスト 自動化 テスト

Slide 59

Slide 59 text

スクラムで成長するメンバー • 1チーム(10人以内) • すべての行程、作業、管理業務をおこなう • 各自の能力を生かし かつ 協力し学び合って プロダクトを作る • マネージャーも、固定したリーダーもいない 役割分担もない • 全員にすべての作業のチャンス • 繰り返し練習して習熟 • 学びと成長の可能性を最大化

Slide 60

Slide 60 text

知識が生まれて広がる • メンバーからメンバーに • チーム内で発生する学び • 外部から取り込んで、内部で生きた知識にする • コーチとか専門家とかに立ち上げを手伝ってもらうのも大事 • チームから組織に

Slide 61

Slide 61 text

https://speakerdeck.com/yattom/mob-programming-to-build-teams?slide=46

Slide 62

Slide 62 text

学習リソース (コミュニティ) • テストコミュニティは人材育成に積極的 • WACATE https://wacate.jp/ • 合宿形式でハンズオン • 智美塾 http://aster.or.jp/business/satomijuku.html • テスト設計コンテスト http://aster.or.jp/business/contest.html • テスト設計コンテストU30チュートリアル https://youtu.be/DrgfzXzv7MU • YouTube ASTERソフトウェアテストチャンネル https://www.youtube.com/channel/UCKNO4SmQ7KRs4i2v_fLmCfA • ASTERセミナー標準テキスト http://aster.or.jp/business/seminar_text.html

Slide 63

Slide 63 text

学習リソース (書籍) • 「これからソフトウェアテストを学ぼうと 考えている人に読んでほしい10冊」 https://swquality.jp/?p=1180 • まずはソフトウェアテストの世界を覗こう • テストの基本的な考え方を体系的に抑えよう • テスト技法を身につけよう • テストツールの基本的な考え方を抑えておこう • ソフトウェア品質保証についての知識 池田暁さん http://www.jasst.jp/symposium/jasst19hokkaido/report.html#S1 https://twitter.com/nihonbuson/status/1373104318790864899

Slide 64

Slide 64 text

学習リソース (イベント) • JaSST日本ソフトウェアテストシンポジウム http://jasst.jp/ • 通年、全国各地でイベント開催(いまはオンラインで) • 日科技連 ソフトウェア品質研究会 SQiP https://www.juse.or.jp/sqip/ • 毎年、ソフトウェア品質シンポジウム を開催 • DevOpsDays Tokyo https://www.devopsdaystokyo.org/ • 開発、インフラ、運用をトータルで考える、品質の話題も。毎年開催

Slide 65

Slide 65 text

テスト人材 • 絶対数が少ない・業界として足りてない • 流動性が低く採用はハードルが高い • イベント、勉強会が活発 • 内部で育成するのが一番 (他にあまり選択肢がない) • 学ぶための材料はいろいろある • 学習と実践が両方必要 • 実践にはテスト駆動開発がおすすめ

Slide 66

Slide 66 text

人材は内部で 育成する スクラムによ る人材育成 学習を通じた 人材育成

Slide 67

Slide 67 text

テスト自動化の端緒 ～テスト駆動開発について～

Slide 68

Slide 68 text

テスト駆動開発 / TDD Test Driven Development

Slide 69

Slide 69 text

Why Develop? • 実現したいことがあるのに、ソフトウェアがない • 今あるソフトウェアの変更、追加をしたい • プログラムを書くのは楽しい • 難しい

Slide 70

Slide 70 text

Why Test？ • 思った通りにできたか知りたい • 問題がないか知りたい • 目的にかなっているか知りたい • 誰かに証明したい

Slide 71

Slide 71 text

Why Test “Driven”？ • フィードバック

Slide 72

Slide 72 text

Development Test

Slide 73

Slide 73 text

きれい 汚い (すぐには)動かない 動作する Green Refactoring TDDと黄金の回転

Slide 74

Slide 74 text

TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5. 2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングを おこなう(Refactor) 7. １〜6を繰り返す

Slide 75

Slide 75 text

テスト駆動開発のプロセス • ゴールをテストとして先に書く • 定義したゴールに向かってコードを書く • まず「What(何を)」を考え、次に「How(どうやって)」を考える • 正解かどうか、ゴールに達したかどうか、自動で瞬時にわかる • 自分の仕事を自分で検証する • ソフトウェアは動かしてナンボ • ふつうの開発 • リファクタリングできれいに保つ • コードや設計 • テストの整理

Slide 76

Slide 76 text

メリット • 自動化したテストが書ける • 低レベルのエラーが減り、品質が良くなる • コンパイルが通らない • 動かない • システムテストフェーズなのに単体レベルのバグが出る • 引き継ぎがし易くなる • 常にメンテナンス性高いコードベースを維持できる • リファクタリングの効果

Slide 77

Slide 77 text

注意: すべてのテストをTDDだけで書けない • 品質を担保する観点では、テストが不足する • テスト駆動開発＝「開発」手法 • 品質を担保する作業は別に必要 • 開発者だけでは、テストを充足できない • テスト設計の観点が必要 • 開発者もテスト設計を学ぶ • テスト設計が上手い人とペアプロをする • TDDには向かないテストもある • 非機能テスト • 画面の見た目や使いやすさ • システムテスト

Slide 78

Slide 78 text

アジャイルテスト 高品質を追求するアジャイルチームにおけるテストの視点 増田聡 Developer Summit 2010 http://www.slideshare.net/satoshimasuda/ss-3241717

Slide 79

Slide 79 text

デメリット • 工数が増えるのでは？ • スキルが必要では？ • メリットがわからない

Slide 80

Slide 80 text

工数が増えるのでは？ • 書く量は増える • 実装フェーズの工数が増える • トータル工数は増えない・減る • 品質がよくなり、テストフェーズで問題が起きなくなる • テスト自動化を目標とする • 後から自動化するよりテスト駆動開発のほうが有利

Slide 81

Slide 81 text

テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数 9 6 5-7 7 コード量(KLOC) 41.0 6.0 26.0 155.2 開発規模(人月) 119 24 46 20 欠陥数 (TDD未使用に対 する) 61% 38% 24% 9% 開発時間の増加 (管理者の見積) 15～20％ 25～35％ 15％ 20～25％ Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through test driven development: results and experiences of four industrial teams” 2008 http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

Slide 82

Slide 82 text

スキルが必要では？ • その通り • 時間をかけて修得する • テスト駆動開発は小規模に、個人レベルでも始められる • スキルを伸ばしながらできることを増やせる • スキルの高い人を生かす • メンバーの書いたコードのレビューと修正ばっかり。。。 • テストをレビューする • ペアプログラミングで一緒にやりながら指導する • テスト駆動開発は「開発」技法 • テスト設計も学ぶ • 必要に応じて学ぶ・学んだことをすぐ実践する

Slide 83

Slide 83 text

TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and Jurgen Munch 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究の結論を整理した TDDは欠陥の作り込み(introduced defects)を減らし、 メンテナンスしやすいコードを産む TDDで実装されたコードは、部分的に、 サイズが小さく、複雑度が低い場合がある メンテナンスがしやすくなるものの、 初期開発では時間がかかる

Slide 84

Slide 84 text

TDDの効果の研究をまとめた研究 やっとむ TDD 検索 https://yattom.hatenablog.com/entry/20131103/p1

Slide 85

Slide 85 text

メリットが理解できない • 体験しないとわからない • 実践してTDDに習熟したプログラマの判断に耳を傾ける

Slide 86

Slide 86 text

体験の機会 • TDDBC テスト駆動開発ブートキャンプ http://devtesting.jp/tddbc/ https://tddbc.connpass.com/ • テスト駆動開発の講演と体験 • 全国(いまはオンライン)で開催、参加無料 • TDDワイワイ会 https://tddyyx.connpass.com/ • テスト駆動開発の体験 • 小規模で気軽、参加無料、不定期開催 • TDD飲み会 (Test Driven Drinking) https://tddrinking.connpass.com/ • お酒などを飲みながら楽しくテスト駆動開発とモブプログラミング体験 • 2ヶ月に1回程度開催、いまはオンライン

Slide 87

Slide 87 text

巷間の感想 初TDDの感想 •レッド、グリーン、リファクタリングの黄金の回転は非常に心地がよく、着実に前にすすんでいることを実 感できました。 •ふと気づくと動作確認をしていないことに驚きました。 作成した関数の戻り値をprint文で出力したり、デバッガを立ち上げて変数の状況を確認してみたり。 •リファクタリングを行って大きくコードを変えても、テストコードが通っている＝仕様を満たせている、と いう安心感がありました。 初ペアプロの感想 •コーディング中の選択ひとつひとつをペアの方と議論して進められるため、自然と質が上がると思いま す。 •トラブル対応などで一刻も早く対応せねばならず、冷や汗を書きながら震える手でコーディングせね ばならない状況においてもペアプロは有効ではないでしょうか。 •他人のコーディングをライブで見ることは気づきの宝庫です。 •メリットも多いけど、業務で毎日ペアプロやるのはしんどそう。週1でペアプロデーを設けるくらいがちょ うどいいかも。 TDDBC Tokyo 1.7 for PHP お題1実践記 https://www.karakaram.com/tddbc-tokyo-17/#feedback-tdd 「テストをしながら設計出来る」「テストコードがドキュメントになる」そんな 魔法のような売り文句のTDDが魔法でないことを教えてくれる、まさに魔 法のようなセミナーでした！！ CodeZine Academy テスト駆動開発実践講座 参加者アンケートより 「TDDは分析技法であり、設計技法であり、実際には開発の すべてのアクティビティを構造化する技法なのだ。(本書より 引用)」ということが良くわかった。 オンライン記事などで聞き かじってきたテスト駆動開発は、テストファーストの説明がほ とんどであった。対して本書ではテストコードを書くことで設 計、実装を深めていく様子を再現し、その有効性を示してい る。良書を読むことができてよかった。 テスト駆動の大きなメリットは、 ・実装がシンプルになる。 ・ 過去に書いたコードの質か担保される→精神的に安定する、 自信が持てる。 ただ、あくまでプログラムを書く方法の1つで あって、全てのテストを書けるわけではないことに注意。 テ スト駆動の実践は個人でできるものなので、まずは一人で やってみたい。 因みに本書でも、「テスト駆動をチームメン バー強要すればするほど、広まらない。」と書かれているw (略)テスト駆動開発の真似事をしてみた感想として は、ーーーこの本にも書かれているがーーー着実な前進感 が得られて、心の平静が保たれるところが非常に強力なポ イントのように思う。 書籍『テスト駆動開発』への感想 (2021.3.26参照) https://bookmeter.com/books/12375096

Slide 88

Slide 88 text

機能追加や障害対応のプロセス 自動テストがない場合 自動テストがある場合 テスト駆動開発の場合 変更箇所と影響範囲を特定する 全体を把握していないと難しい 自動テストを新仕様に合わせて直す 障害の場合は再現テストを書く テストと仕様を把握していないと難しい コードを変更して完成する つぎはぎの対応になりやすい コードを変更して完成する テストして動作確認する 意図しない影響の確認には 限界がある 手動でテストして動作確認する 自動テストをすべて実行して、 意図しない影響が出ていたら、直す テストの自動化が不十分だと漏れが起きる 自動テストを新仕様に合わせて 直す リファクタリングして コード、設計、テストをきれいにする 自動テストをすべて実行して、 意図しない影響が出たら直す テストの自動化が不十分だと 漏れが起きる 手動でテストして動作確認する 自動テストを過信して省略しがち ユーザー受け入れテストをする 変更を依頼した箇所しかテストしない ユーザー受け入れテストをする ユーザー受け入れテストをする

Slide 89

Slide 89 text

リファクタリングが大事 • メンテナンス性の高いコードを維持する • テスト駆動開発の本当のねらい • テストもリファクタリングの対象 • 「きれいを保つ」 • メンテナンス性が高いと • 変更の手間が少ない • 把握にかかる時間が短い • 想定しない副作用が起きにくい • 未発見の不具合があまりない • Point of Salesでは不要 → Point of Useでは大事 • できるようにならないといけない

Slide 90

Slide 90 text

ソフトウェアは経年劣化する 時間 内部 品質 高品質 低品質 追加変更が容易で 意図しない問題も 起きにくい 楽な領域 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力 急ぎの対応 予期しない仕様変更 OSバージョンアップ 詳しい人が退職 新システムと連携

Slide 91

Slide 91 text

きれいを保つ http://www.flickr.com/photos/adwriter/226233780/

Slide 92

Slide 92 text

リファクタリングでいいポジションをキープ 時間 高品質 低品質 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力 相応の 手間・コストは 必要 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 重力に 打ち克つ 内部 品質

Slide 93

Slide 93 text

品質は最高が安上がり • 整った環境での仕事は速くて安全 • 安全に変更できる＝最高速度を出せる • プロジェクトを炎上させるのは、テストではなくデバッグと再テスト • 変更しやすい状況を維持するためのリファクタリング • よりよいプロダクトに変更できるという顧客価値 • 「後で直す」より「いますぐ直す」ほうがだいたい 常に低コスト • リファクタリングを後回しにする＝負債を背負い込む

Slide 94

Slide 94 text

本当は常にリファクタリング 時間 高品質 低品質 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力 日々の仕事に 組み込む ＝テスト駆動開発 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 内部 品質

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

テスト駆動開発と保守性 • テストがある＝保守性が高い • テストがある＝テストしやすい設計になっている • テストしやすい設計＝変更しやすい設計 • コンポーネントが高凝集低結合 • テストしやすいような設計を導く

Slide 97

Slide 97 text

実装は設計 「これは，他のエンジニアリングの世界とソフトウエア開発が大きく違う点だ。例えば工業製品であ れば仕様書（設計図）は絶対であり，それさえあれば，同じような製造設備を持ったメーカーなら同 じモノを作り上げることができる（もちろん例外はある）。これに対しソフトウエア開発の製造工程は プログラマの能力に依存する。仕様書の内容と完成したソフトウエアが違っている，ということも少 なくない。つまり仕様書というのは，設計図としての役割を果たしていない，ということになる。」 「ソフトウェア開発のどこまでを設計と呼ぶか？」 真島馨、日経XTECH, 2001 https://xtech.nikkei.com/it/free/ITPro/OPINION/20010528/1/ • 製造業の設計＝ソフトウェアのコーディング • 製造業の生産＝ソフトウェアのコンパイル、デプロイ • プログラミングは複雑で、創造性が必要な仕事 • ソフトウェアの設計と実装は分離しにくい

Slide 98

Slide 98 text

実装は設計 “These kinds of questions led Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.” “The New Methodology” Martin Fowler https://www.martinfowler.com/articles/newMethodology.html “A program listing is a document that represents a software design. Compilers and linkers actually build software designs.” “What is Software Design?” Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Slide 99

Slide 99 text

自動テストとドキュメント • 自動テスト自体をドキュメントとして機能させる • 実行結果からテストケース一覧や内容がわかるように • 仕様に対する網羅 • コードに対する網羅 • エビデンスとしての実行履歴 • 不具合対応も自動テストとして残す • 不具合を再現するテストを書いてから直す • レポートとして残す • (とっても)簡易な説明スライド https://docs.google.com/presentation/d/1MaeT4OVk74j7BO6DFzjsjhV9RSXhqrZ7n49jz8obsZg/edit?usp=sharing

Slide 100

Slide 100 text

テスト駆動開発 (TDD)とは テスト駆動開発の メリット・デメリット リファクタリングと Point of Use

Slide 101

Slide 101 text

なぜテストを書きたいのか ― 個人の理由 • 不安がある＝リスクがある • 工数が見通せない • 影響範囲を見切れない • 最善の対応かどうかわからない • 命綱、安全ネットとしての自動テスト • 自分の身を守るために書く • 将来が今より安全になるよう書く • チームや組織を守るために書く

Slide 102

Slide 102 text

命綱を編む

Slide 103

Slide 103 text

変更を担保するためのテスト • 命綱、安全ネット • 「コードを変えて祈る」から「テストで保護し安心して変える」へ 不安 安心

Slide 104

Slide 104 text

不安を脱して学習ゾーンへ 責 任 大 ← → 小 能力 →高 低← 学習 パニック 快適

Slide 105

Slide 105 text

テスト自動化の練習 • テスト駆動開発＝コードを書く＋テストを書く • テスト自動化の観点 • どうすればテストできるか？ • テストを実行する方法は？ • 自動化や効率化をするには？ • メンテナンス性の高いテストとは？

Slide 106

Slide 106 text

フレームワークはテスト自動化前提 • .NET • xUnit.net, NUnitなど • Django (Python) • unittest, pytest • Spring Boot • JUnit 5, Spring Test, AssertJ, Hamcrest, Mockito など • Ruby on Rails • RSpec • React • Jest

Slide 107

Slide 107 text

テスト設計の練習 • テスト駆動開発＝コードを書く＋テストを書く • テスト設計の観点 • 仕様に抜け漏れはないか？ • 仕様を正しく理解しているか？ • 仕様通りに動いていると確認するには？ • 最小限必要なテストは？ • どのあたりが怪しいか？

Slide 108

Slide 108 text

システムを理解する • リファクタリングを通じてコード、設計、テストを把握 • 担当チームにとって安全になるよう少しずつ手を入れる

Slide 109

Slide 109 text

テスト自動化エンジニア(SET)を育てる • テスト駆動開発で得られる経験はSETにぴったり • 自分のプロダクト、環境、組織の中でうまくいくやり方を編み出す • 自分の経験を元にして、応用しながら広める

Slide 110

Slide 110 text

不安ゾーンから 学習ゾーンへ テストの経験 システムを 理解

Slide 111

Slide 111 text

深めつつ広げる鍵 ～ペアプログラミングについて～

Slide 112

Slide 112 text

ペアプログラミングとは "Write all production programs with two people sitting at one machine. ... Pair programming is a dialog between two people simultaneously programming (and designing and testing) and to program better." (Extreme Programming Explained 2nd) 「プロダクションコードはすべて、2人で1台のマシンに向かって書くこと。 …ペアプログラミングとは、プログラミングしながら2人で会話するこ とだ(設計もテストも同時にする)。会話するのは、もっと上手にプログ ラムするためである。」

Slide 113

Slide 113 text

ペアプログラミングとは • 2人が密に連携し、支援し合いながら仕事をする • 2人で1台のコンピュータ、1組のキーボード＋マウスを使う • キーボードをにぎるのがドライバー、見ているのがナビゲーター • 設計、実装、テストをする • 2つの脳、4つの眼球で共同作業 • 2人分の知恵を出し合い、2人分以上の成果を出す • お互いをカバーし合う • 知識、経験、ノウハウを交換する • 該当箇所を知っている人が最低2人できる

Slide 114

Slide 114 text

重要な仕事は2人組で臨む • 捜査する刑事 • 人命救助 • 学術研究 • ペアプログラミング → ペアワーク https://anagileway.com/2017/02/17/digital-innovation-leadership-with-jeff-nonaka-and-takeuchi/ https://hominis.media/category/actor/post3925/ https://sandanoumesan.com/archives/9803

Slide 115

Slide 115 text

例 次は登録処理をやろう まず…変換トリャッ…あー？あー。…(カタカタ) なるほど…(カタカタ) あ、こっちのメソッドのほうがよくないです？ ああ…そうかな。ちょっとやらせて(カタカタ) あれ？ この条件どう扱おう んー…このメソッド使えないかな そこのパラメータを変えて…そうそう なるほどいけるね！ やったー！ やったー！ 頭の中を さらけ出す アイデアを 思いつきでしゃべる もっと アイデアを出す 気軽に 交代する 元気づける 共同勝利して カジュアルに 喜ぶ

Slide 116

Slide 116 text

よくない例 次は登録処理をやろう わかりました(カタカタ) できました うん、よさそうだね この条件、だいじょうぶ？ 考えてみたんけど、ダメです? このメソッド使うといいよ わかりました(カタカタ) できたね。じゃあ次は… 黙って 手を動かしている 対話せず 報告している レビューアーの態度 共同作業ではない 頭の中を さらけ出していない アイデアではなく 指示 淡々とこなしている 達成感がない 考えずに 従っている 頻繁な 交代がない

Slide 117

Slide 117 text

ペアプログラミングのプロセス • にぎやかにしゃべる • ドライバーとナビゲーターが対話しながら作業する • 黙ってはダメ、しゃべりながら手を動かす • ペアの役割を入れ替える • ドライバーとナビゲーターは頻繁に、数分～数十分で交代 • ペアを組み替える • 別のペアと組み替える • 他チームの人とペアを組む • プログラマとデザイナ • プログラマとQA • 仕様ホルダとプログラマ • 仕様ホルダとQA

Slide 118

Slide 118 text

例 • 毎週新しいペア • 週40時間みっちり • プロジェクトを越えることも • 1タスク1ペア、だいたい1日ごと • 1タスクを担当するペアとなる • チーム内であれこれする • 毎時新しいペア • タスクに付く人と、あちこちする人 • 必要なスキルで呼ばれたり • いろいろ工夫する！

Slide 119

Slide 119 text

仕事B 仕事C 仕事A 例1 フルタイムペアプロ1週間組み替え 1週間 1週間 1週間 1週間 1週間 1週間 組 み 替 え 組 み 替 え

Slide 120

Slide 120 text

仕事B 仕事C 仕事A 例2 仕事を小さく、仕事毎にペアを組む 1日 1日 1日 仕事E 仕事F 仕事D 1日 半日 半日 仕事G 仕事H 半日 半日

Slide 121

Slide 121 text

仕事 仕事 仕事 例3 90分単位、頻繁な組み替え、主担当が残る 1.5時間 1.5時間 1.5時間 1.5時間 1.5時間 1.5時間 1.5時間 仕事 仕事 仕事 仕事 仕事 1 日 の 終 わ り

Slide 122

Slide 122 text

No content

Slide 123

Slide 123 text

「チームの心理的安全とは、対人のリスクを取っても 安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「対人関係のリスクを取っても安全 だと信じられる職場環境であること。 それが心理的安全性だと、私は考 えている。」 https://www.amazon.co.jp/dp/4862762883

Slide 124

Slide 124 text

図3. グループ レベルで研究し た心理的安全 性の関係

Slide 125

Slide 125 text

ペアプロ＝協力 ペアプロ＝学習 ≠教育 心理的安全な 環境

Slide 126

Slide 126 text

組織としてペアプロを取り入れる • 重要な仕事は2人組んで臨む • プログラミングに限らない(ペアワーク) • トラックナンバーを大きくしレジリエンスを高める • 知識、経験、スキルを組織内に環流させる トラックナンバー チームから何人欠けたら、仕事が継続できなくなるか？ 「X人が交通事故に遭って仕事を急に休んだら」という意味 Xが大きい方が、情報共有ができていて、耐性がある 縁起が悪いので、ハネムーンナンバーと呼ぶこともある

Slide 127

Slide 127 text

ペアプロと信頼関係 • 「同じ釜の飯を食った仲間」 • 同じキーボードを叩いた仲間 • 同じコードを書いた仲間 • 同じ障害に悩んだ仲間 • 同じ解決に喜んだ仲間 • お互いを知るところから生まれる信頼 • 好き嫌いとは別 • 嫌いな人でも信頼できる • 相性問題は気を付ける

Slide 128

Slide 128 text

ペアプロと生産性 • ペアプロの生産性が高いと示すデータは少ない • 低いというデータもない • やり方次第、ペアの組み方次第 • 目の前の生産性 vs. 長期的な成長 • どっちも大事 • 目の前に捕らわれると未来がなくなる • ペアプロに向く作業、向かない作業 • 単純作業、定型業務、学びや発見のない作業には向かない • やってみてから判断するとよい

Slide 129

Slide 129 text

ペアプログラミングの効果-ユタ大学の研究 “The Costs and Benefits of Pair Programming” Alistair Cockburn, Laurie Williams, 2000 https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming プログラミング 工数は増えるが、 15％しか増えない (2倍にはならない) ペアプロだと 品質が高い (不具合が少ない) ペアプロの ほうが楽しい ペアプロだと 同じ機能を 少ない行数で 実現する (洗練された 設計)

Slide 130

Slide 130 text

ペアプログラミングの効果-ユタ大学の研究 • 作業中に間違いを見つけて直せるので、後工程に残らない(常時コー ドレビュー) • 不具合が減る(常時コードレビュー) • 設計がより良くなり、コード行数が減る(常時ブレインストーミングとペ アリレー※) ※常に相談し、意見交換し、一緒に考えることで問題解決が早くなる様子が観察された • 問題解決が早い(ペアリレー) • 学習効果が高い。対象システムについてもソフトウェア開発の技法に ついても(“教師の目が届く”効果) • 終了時、各自の理解している範囲が広くなる • 協力して働き会話も増えるため、情報の流れとチームのダイナミズ ムが生まれる • 仕事がもっと楽しくなる“The Costs and Benefits of Pair Programming” Alistair Cockburn, Laurie Williams, 2000 https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming

Slide 131

Slide 131 text

多様性を結びつける • いろいろなスキルがあり、いろいろな人がいる • 分業ではなく協力することで、新たな知識が生まれる • 効率＜効果 • 垣根を越えるペアプロ、ペアワーク • 組織を越える • 職能を越える • 役職を越える • 意識を越える

Slide 132

Slide 132 text

ペアプロする 組織 ペアプロする 人々 強いチーム 強い組織へ

Slide 133

Slide 133 text

見る夢について

Slide 134

Slide 134 text

No content

Slide 135

Slide 135 text

いいね！ やろう！ • ちょっと待って…… • 誰がやる？ • どこでやる？ • どういうステップで上手になる？

Slide 136

Slide 136 text

最初の一歩 • 誰がやる？ • 情熱のある人 • 人を巻き込める人 • どこでやる？ • リスクの小さなプロジェクト • 新規開発から(可能であれば) • どういうステップで上手になる？ • テスト駆動開発を身につける • テスト自動化を身につける • 効果、メリット、ROIを確認して広げる

Slide 137

Slide 137 text

テスト苦労開発 あるいはTDDの夢 https://speakerdeck.com/yattom/tesutoku-lao-kai-fa-aruihatddfalsemeng

Slide 138

Slide 138 text

No content

Slide 139

Slide 139 text

No content

Slide 140

Slide 140 text

組織の取り組みとして位置づける • 個人の情熱だけでは燃え尽きる • 要員や工数への影響も • 権限者の後押しが必要 • 最初から組織全体でやると失敗する • 自分たちの環境で上手くいくやり方を探索する • 最初は失敗するので、小規模に、安全に • 上手くいったら、少しずつ広げる • 100％にならなくてよい • 周囲が理解できるよう広報する • 広く伝えるための活動レポート • 顔を見て話せる成果発表会 • 仲間を増やす勉強会

Slide 141

Slide 141 text

効果があるところを見つける • ユーザーの環境がダイナミックに変わる領域 • 成長中のビジネス • ITの貢献度が高いビジネス • 業務や使い方に変化が多いシステム • 人員の拡大、入れ替えがある現場 • 変化が少ない、安定性重視のところでは効果が小さい • 既存コードベースが大きいと効果が出るまでに時間がかかる

Slide 142

Slide 142 text

組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） https://speakerdeck.com/twada/strategy-and-tactics-of-building-automated-testing-culture-into-organization-2020-autumn-edition?slide=58

Slide 143

Slide 143 text

プラスの効果をねらう • やる気が出る指標 • 顧客満足度に着目 • 「もっと何とかならないの？」と文句ばかりの人を驚かせる秘策として • 「あなたのおかげで自分の仕事によい影響が出た」と言われたい • 効果が出るようにねらう • ユーザーの業務やビジネスを理解 • 仕様変更要望より踏み込んで提案 • 変わりそうな部分にテストで網を張る

Slide 144

Slide 144 text

ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へソニックガーデン代表倉貫義人のブログ https://kuranuki.sonicgarden.jp/2011/09/post-46.html こんなのも できないの？ こんなこと できるんだ！

Slide 145

Slide 145 text

ただし時間はかかる • 上手くいくやり方を確立し、広める • できる人を育て、スキルとノウハウを伝達する • 十分な安全ネットになるまで地道にテストを書く • テストが書けるよう既存コードを直す(後述) • 時間とコストと感情エネルギー(情熱)を要する • 戦略的なリソース配分を

Slide 146

Slide 146 text

いますぐ始め 時間をかける 組織全体で 取り組む 顧客満足度と いう品質

Slide 147

Slide 147 text

既存システムは どうするの？

Slide 148

Slide 148 text

テスト苦労開発 あるいはTDDの夢 https://speakerdeck.com/yattom/tesutoku-lao-kai-fa-aruihatddfalsemeng

Slide 149

Slide 149 text

STAR テスト自動化研究会 https://sites.google.com/site/testautomationresearch/test_automation_principle

Slide 150

Slide 150 text

既存システムとテスト自動化 • レガシーコード ＝ テストがないコード • 歯を食いしばって注意深く書き換えながらテストを書く • 地道かつスキルが要る仕事 テストを書きたい テストが書けるよう コードを変更したい 安心してコードを 変更するためには テストが必要

Slide 151

Slide 151 text

書籍『レガシーコード改善ガイド』 • https://www.amazon.co.jp/dp/4798116831 • 目次から抜粋 • 第2章 フィードバックを得ながらの作業 • 第6章 時間がないのに変更しなければなりません • 第7章 いつまで経っても変更作業が終わりません • 第9章 このクラスをテストハーネスに入れることができません • 第13章 変更する必要がありますが、 どんなテストを書けば良いのかわかりません • 第16章 変更できるほど十分に私はコードを理解していません • 第18章 自分のテストコードが邪魔になっています • 第21章 同じコードをいたるところで変更しています • 第24章 もうウンザリです、何も改善できません

Slide 152

Slide 152 text

基本戦略 • テスト自動化の経験者をアサインする • 初めてテストを書くような人が立ち向かうのは無理 • 熟練者、外部のコンサルなどがいるとベスト • エンドツーエンドテスト(システムテスト)を書いて全体をカバーする • 動かなくなるような事態を検出できる • システム全体のテスト環境が稼働する • 自動テストでカバーすべき箇所を見つける • 過去の変更依頼や障害箇所を分析 • いつも変更するモジュール、苦労するモジュール • 適用できる自動テストのバリエーションを持っているとよい • 慎重に依存関係を除去する • シーム(接合部、縫い目)を見つける • 『レガシーコード改善ガイド』のパターンを用いる • テストを書き、リファクタリングする • 繰り返す

Slide 153

Slide 153 text

生存戦略 • 経験者を増やす • バックアップできる体制が出来てから広げる • 完璧を目指さない。100％どころか、40％でも十分な場合も • 苦労と辛抱、時間が読めないことを覚悟する • 効果を丁寧に測定し指標とする • 努力を評価する。まったく成果を出せない期間もある

Slide 154

Slide 154 text

ただし時間はかかる • 既存コードベースの規模に応じて • 年単位かかる場合もある • 自動化だけをやり続けるのは厳しい • 通常業務を回しながら • 一定の割合で作業時間を確保する • 心が折れないように • 対投資効果のある箇所に限定する • 苦労に対して実入りがあるように • 実入りが薄いところは諦める

Slide 155

Slide 155 text

既存システム はたいへん 戦略とスキル が必要 苦労と辛抱

Slide 156

Slide 156 text

運用保守も テスト駆動？

Slide 157

Slide 157 text

運用保守のつらみ • 問題なくて当然、問題が起きれば大変 • 時間もコストもかけられない • ソフトウェアを完全に理解・把握しきれない • スーパーマンはいない • いても遠かったり、忙しかったり

Slide 158

Slide 158 text

機能追加や障害対応のプロセス 自動テストがない場合 自動テストがある場合 テスト駆動開発の場合 変更箇所と影響範囲を特定する 全体を把握していないと難しい 自動テストを新仕様に合わせて直す 障害の場合は再現テストを書く テストと仕様を把握していないと難しい コードを変更して完成する つぎはぎの対応になりやすい コードを変更して完成する テストして動作確認する 意図しない影響の確認には 限界がある 手動でテストして動作確認する 自動テストをすべて実行して、 意図しない影響が出ていたら、直す テストの自動化が不十分だと漏れが起きる 自動テストを新仕様に合わせて 直す リファクタリングして コード、設計、テストをきれいにする 自動テストをすべて実行して、 意図しない影響が出たら直す テストの自動化が不十分だと 漏れが起きる 手動でテストして動作確認する 自動テストを過信して省略しがち ユーザー受け入れテストをする 変更を依頼した箇所しかテストしない ユーザー受け入れテストをする ユーザー受け入れテストをする もっとも安全で低コスト テストが十分あれば

Slide 159

Slide 159 text

それでも改修は大変 • 直すべきテストが見つからない • テストが整理されていない • そもそもテストが足らない • テストで捉えられない影響が出る • テストをメンテナンスできていない • そもそもテストが足らない • テストを書けない • スキル不足 • そもそもテストが足らない • 関係するテストが多すぎて大変 • テストが整理されていない

Slide 160

Slide 160 text

ただし時間はかかる • 運用保守に引き渡す前に時間をかける • テストを書く • テストを整理する • テスト環境を引き渡す • 初期開発の責任が大きくなる • 安全に運用保守できる準備をする • 「完成する」から「変えられるように作る」へ • 運用保守の工数を担保する • 開発と保守運用が一緒に活動する

Slide 161

Slide 161 text

ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へソニックガーデン代表倉貫義人のブログ https://kuranuki.sonicgarden.jp/2011/09/post-46.html

Slide 162

Slide 162 text

運用保守こそ TDD 開発時から 保守を考える 人から人に 手渡す

Slide 163

Slide 163 text

まとめ

Slide 164

Slide 164 text

短納期、保守、アジャイルで 自分たちがゆゆっくり死ぬのを 避けるためテストを自動化する 自動化の 人材育成のために テスト駆動開発をする 顧客価値のため、 Point of Useのために 品質を高く維持する 育成の強化と 組織への浸透のため ペアプログラミングをする