市場で勝ち続けるための品質とテストの技術②

Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
伊藤宏幸
市場で勝ち続けるための
品質とテストの技術
2017年2月16日

伊藤宏幸
 黒帯（アジャイル開発プロセス）
 アジャイルコーチ
 自動化コーチ
自己紹介
1

テスト自動化は製品開発の必須要素
2
DevOpsの考え方の普及
↓
• さらなる「Time to Market」の短縮要望
• 市場に耐えうる品質の製品を
リリースし続ける必要性
↓
テスト自動化！

一方で
3
テスト自動化自体が難しい
• やり方が分からない
• たくさんの種類や方法があって、
どれをやれば良いのかが分からない
• メリットが分からない
（エンジニア/マネージャーとして）
• 工数が余計にかかるのでは？という疑念

自動化コーチ：我々の役割
4
テスト自動化
（特にユニットテスト）を、
サービスが自発的に
実施・推進できるようにすること
前述の疑問に対して１つ１つ回答し、
かつ施策をドライブすることが役割

当セッションのテーマ
5
テスト自動化を自ら開始・推進し、
組織文化の改善にまで
取り組んでいる
チームの事例とポイントの紹介
+
ポストDevOps時代の働き方

アジェンダ
6
1. テスト自動化の始め方
2. 落とし穴とその回避方法
3. テスト自動化のためのステークホルダーマネジメント
4. 結論

1. テスト自動化の始め方

我々の基本方針
8
原則、ユニットテストから始める
• 「単体テスト」と同義
• ISTQBの定義に従い、
以下「ユニットテスト」と呼称

理由１：テストの種類
9
ユニットテスト
総合テスト
結合テスト
受入テスト
開発
基本設計
詳細設計
要件定義
ココから
導入が簡単かつ
すぐに効果を出せるため

理由２：テスト自動化のピラミッド
10
GUIテスト
受入テスト
（API層）
ユニットテスト
ココから
一番ROIが高いため
手動テスト

よくやる過ち
11
• 座学
• ワークショップ
• 実際にテスト自動化・TDD・ペアプロを
実践している現場の見学
ほとんど役に立たない！
ハンズオンなどで実際に手を動かして、
その価値を「体感」させない限りは
効果が見込めない

解決策
12
• Cyber Dojoで
TDD・ペアプロを「体感」させる
http://cyber-dojo.org/
• プロダクションコードへ
ユニットテストを追加する
（即実戦で鍛える）
• 必要になってから、
理論やテクニックを深く教える

この章のポイント
13
習わせるより慣れさせよ！

2. 落とし穴と
その回避方法

1) コードカバレッジの罠
15
コードカバレッジ60%突破！
もう少しで80%にできます。
ほとんど修正のない、簡単にテストを
追加できるプログラムがあるので、
引き続きここにテストを追加していこうと
思います♪
by 大泉洋

1) コードカバレッジの罠
16
コードカバレッジの達成が
自己目標化してしまい、
市場に耐えうる品質の確保という
テストの目的から外れてしまう
↓
価値あるテストをつくることを
意識付けすることが必要

1) の解決策：価値あるテスト箇所を明確にする
17
• マネーパススイート
• 障害の頻発する箇所
• 頻繁に修正する箇所
• 追加／修正する箇所

2) テストが作りづらい
18
• プロダクションコードが複雑すぎて
解読できない
• モックを差し込めない
• 重複ロジックが多数ある
↓
テストをしやすくしよう！

2) の解決策：テストをしやすくする
19
• テストをしやすくするためのツールを
探し出して適用する
• Mockito（Java）
• Phake・AspectMock（PHP）
• テストをしやすいアーキテクチャに変える
• 「仕様化テスト」を整備する
• その後にリファクタリングを行う

3) 目的を見失う/作業のマンネリ化
20
• メンバーがテストへの関心を失う
• テストの作成ペースが伸びなくなる
• 価値の低いテストが増える
↓
チームに適切な刺激を与え、
自発的な成長を促そう！

3) の解決策1：短期の目標設定とふりかえり
21
• 定期的に目標を設定させる
• 一定期間が経ったら
目標の達成度合いを確認し、
KPTベースで振り返りを行う
• 定期的かつ自発的に、
次の改善アクションを提案・実施させる

3) の解決策2：自主的なテストルールの策定
22
• テストのコーディング規約
• C0/C1/C2
• ルール自体の定期的な見直し
↓
自主性のあるチームの構築へ
つながる

23
目的のために
良い手段を選ぼう！

3. テスト自動化のための
ステークホルダー
マネジメント

ある日チームから寄せられた相談
25
チームの活動目標を提示するよう、
「サブリーダー」から求められた
↓
活動目標を「サブリーダー」に提示した
↓
「部長」と「リーダー」からも、
別途目標を提示するよう求められた
↓
チームが混乱状態に陥ってしまった

調べてみた
26
• ステークホルダーがそもそも多い
• サブリーダー・リーダー（複数名）・
部長・テクニカルディレクターetc.
• ステークホルダーで情報が届いている人と
届いていない人とがいる
• ステークホルダー間でも情報をやりとり
している人としていない人とがいる

コーチとしてのチームへの提案
27
ステークホルダー管理に改善点あり
↓
ステークホルダー管理
（コミュニケーション管理）を
やろう！

しかし…チームの主張
28
• ユニットテストを書くことに集中したい
• ステークホルダーたちの問題だから、
自分たちは関係ない
↓
この状況を自ら改善することに
消極的だった

実施した説得
29
• 情報の交通整理をすること
＝ステークホルダーを喜ばせる行為
• ステークホルダーを喜ばせること
＝仕事に集中できる環境作りにプラス
• 仕事に集中できる環境を作ること
＝テスト自動化実現のための立派な行為

説得の結果
30
チーム自ら、
ステークホルダー全員が会する場を設定
• 何が分かっているのか
• 何が分かっていないのか
• 何が必要なのか

説得の結果
31
わずか30分で、
必要な情報共有と次のアクション決めを達成
写真：アフロ

32
テストの作成に集中できる
環境を作ることも、
立派なテスト自動化だ！

4. 結論

その後のチーム
34
ほぼ我々コーチ陣の手を離れ、
自走するようになった
• チームメンバー同士で助け合いながら、
自力でユニットテストを書いている
• ステークホルダーとの調整も、事前に
済ませてから報告してくれるようになった
• 部署での成功のシンボルとなっている

課題の克服・改善
35

36
課題の克服・改善

これまでのポイントのおさらい
37
• 習わせるより慣れさせよ！
• 目的のために良い手段を選ぼう！
• テストの作成に集中できる環境を
作ることも、立派なテスト自動化だ！

ポストDevOps時代の働き方
38
職種・業務を限定しない
継続的学習・改善の仕組みを、
技術的・組織的に構築する
写真：アフロ

結論
39
「当たり前のこと」を、
「当たり前に」やろう。

市場で勝ち続けるための品質とテストの技術②

More Related Content

What's hot

Viewers also liked

Similar to 市場で勝ち続けるための品質とテストの技術②

More from Yahoo!デベロッパーネットワーク

市場で勝ち続けるための品質とテストの技術②