テストの自動化とテスト駆動開発

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

View Slide

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

View Slide

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

View Slide

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

View Slide

自動化したい理由

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

いいもの
作るぞ！
できた！
終わったー！
ここちょっと
使いにくいな
業務と
合わないなー
作り直す
しか。。。
こんなアイデア
どうかな？
これは
便利！
ここ変えたら
もっと良くなる
手直し続けて
馴染んだな～

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

新規/再開発と開発規模による
テスト工数割合の傾向
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) より

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

必要な人材を考える

View Slide

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

View Slide

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

View Slide

テスト自動化エンジニア(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、自動デプロイ、
テストデータ構築
コミュニケーションコンサルティング、エバンジェ
リズム、メンタリング、など
チームへの導入、相談役、自動化リーダー、先生
役、組織の推進

View Slide

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

View Slide

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

View Slide

テスト担当者に必要な能力
• 学校の先生が書いた作文を生徒が添削する？
• プロスポーツの試合を素人が批判する？
「我々が直面する重大な問題は、
問題を引き起こしたときと同じ思考レベルでは
解決できない」
アルベルト・アインシュタイン
"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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

学習リソース (コミュニティ)
• テストコミュニティは人材育成に積極的
• 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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Development
Test

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

テスト駆動開発の効果
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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

巷間の感想
初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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

本当は常にリファクタリング
時間
高品質
低品質
すぐ起きる
苦しい領域
gravity
重力
日々の仕事に
組み込む
＝テスト駆動開発
起きにくい
安全な領域
内部
品質

View Slide

View Slide

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

View Slide

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

View Slide

実装は設計
“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

View Slide

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

View Slide

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

View Slide

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

View Slide

命綱を編む

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

ペアプログラミングとは
"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人で会話するこ
とだ(設計もテストも同時にする)。会話するのは、もっと上手にプログ
ラムするためである。」

View Slide

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

View Slide

重要な仕事は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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

ペアプログラミングの効果-ユタ大学の研究
“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倍にはならない)
ペアプロだと
品質が高い
(不具合が少ない)
ペアプロの
ほうが楽しい
ペアプロだと
同じ機能を
少ない行数で
実現する
(洗練された
設計)

View Slide

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

View Slide

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

View Slide

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

View Slide

見る夢について

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

こんなのも
できないの？
こんなこと
できるんだ！

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

運用保守も
テスト駆動？

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

まとめ

View Slide

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

View Slide

テストの自動化とテスト駆動開発

テストの自動化とテスト駆動開発

yattom

More Decks by yattom

Other Decks in Programming

Featured

Transcript