1.
Dive in Test, Refactoring
kyon_mm
#wewlc_jp 2014.09.27

2.
Self Introduction
きょん kyon_mm
テストアーキテクト 2年目
TDD/BDD, SCM, Agile, Softwaretest,
SoftwareEngineering
なごや
基礎勉強会, SCMBC, Nagoya.Testing,
Cafe.Testing

3.
Attention
今日お話することは、エンジニアであるとい
う立場でお話しします。
やらなければいけないことに目がくらんでい
るときは、私は今までレールに乗っていただ
けだったのだと気づいたときでした。（経験

4.
Important things

5.
Important things
リグレッションしてはいけない
変更にバグはない
保守しやすいことが望ましい
!
ただし、バグは変更した部分が原因である事
がほとんどである！！！（←重要

6.
Safety
開発チームが出来るのは基本的には次のどち
らか
Test
Formal Method
どちらを選んでも限定的でしかないんだけ
ど:-p

7.
Brownfield Development

8.
Wrestle with System

9.
Today’s Topic
Testing, Analyzing
Task Management

10.
Process
プロジェクトを明確にする部分を扱いやすく
する単位,粒度を決める
それぞれの粒に適した方法で明確にする
プロジェクトを変化させる

11.
Example
次の単位でまとめる
TestLevel/UserLevel/MaintenanceTerm
ViewPoint, Perspective
単位の中で適した方法で明確にする
状態遷移図
マトリックス、テーブル
グラフ
DSL（ユースケースやシナリオなども含む）
機能配置図
絵

12.
Analyzing, Testing

13.
Analyzing, Testing
要求、コード、ドキュメントを分析し、明確
することが求められます。
それがユーザからみてバグであるかどうかも
含めて明確にすることが重要です。
コンコリックテスティングなどを用いてテス
トケース生成をすることは可能ですが、これ
は現状を表現するだけであって、何があるべ
き姿であるかは不明のままです。

14.
Unit

15.
TestLevel/User
テストレベル
動作するシステムの粒度で区切る方法
Unit,Component,Integration,System
ユーザー
誰が使うかで区切る方法
Developer,Operator,PO,Tester,ActiveUser
,DisinterestUser,Payer,etc,,,

16.
MaintenanceTerm
保守する期間
どれくらい保守する必要があるのかで分別
する。いつ不要になったり、変更されるの
か。
1日、1週間、1ヶ月、3ヶ月、6ヶ月、未定

17.
ViewPoint, Perspective
ViewPoint（着眼点）
機能、情報、並行、開発、配置、運用、etc
Perspective（横断的関心事）
セキュリティ、パフォーマンス、発展性、
etc

18.
Quality Model
ISO25000シリーズ（品質モデルをかなり抽象
化して標準化したもの）
とりあえずこれでシステムが満たすべきも
のをグルーピングするといいと思われる。
FQM（NATOが古に開発した品質モデル）

19.
Clear

20.
FSM…
状態遷移図などを用いてイベントの流れを表
現する。
まぁ、2 bleis 月くらいのプロジェクトだと、
僕はA3用紙40枚くらいの状態遷移図を書いて
いたりします。（ミドルウェアの障害まで含
めてシステム全体の状態遷移図を書く）

21.
Matrix,Table
組み合わせを表現する
ベースはDSLでもいいのだけど、レビューに効
果的なので積極的に採用しています。
デシジョンテーブルとか
直近の1 kyon_mm 月だとだいたい表の行数は20
万行前後くらいあって、そこからいくつかを
選択するようになっている。

22.
Unit Meets Clear

23.
プロジェクトに最適な表現手段を構築する
Developer PO Tester ActiveUser
有効性シナリオシナリオシナリオ
テーブル
動画
コンテンツ
快適性レビュー
システム
機能完全性DSL
テーブル
障害許容性状態遷移図シナリオ
置換性
グラフ
DSL
機能配置図機能配置図
グラフ
上記の中身は無作為に近いです（イメージ図です）

24.
Do it
表現方法が決まれば、あとは試行錯誤してやっ
ていく感じ。
明確にした部分をテストやドキュメントとし
て表現する。

25.
Testing
仕様に基づくようなテストケース生成方法
デシジョンテーブル
グラフ網羅
ドメイン分析
Pair-wise
まぁこの辺は自動生成のツールを書けば済む
話なので。

26.
Testing
テストの実施方法
計画的
探索的

27.
Reference システムアーキテクチャ構築の原理
BABOK
ISO25000シリーズ
REBOK
SWEBOK
IA100
ソフトウェアテスト技法 第二版
実践的プログラムテスト
基本から学ぶソフトウェアテスト
Specification By Example
BDD in Action

28.
Task Management

29.
Task Management
WBS
Backlog
Epic, User Story
Todo list
Impact Mapping
Mikado graph

30.
Mikado Graph
Mikado Methodという方法論で書くもの
とてもシンプルな図です

31.
全体
High WBS, Impact Mapping
Midlle Backlog, Epic, UserStory
Low Todo List, Mikado Method

32.
Mikado Method
他はみなさん知っていると思うので、あまり
知られていないと期待しているMikado-Method
について話します。

33.
Mikado Graph
達成したい事

34.
Mikado Graph
達成したい事
新しい課題
新しい課題

35.
Mikado Graph
更に新しい課題
達成したい事
新しい課題
新しい課題
更に新しい課題

36.
Mikado Graph
更に新しい課題
達成したい事
新しい課題
新しい課題
更に新しい課題
更に更に…

37.
Flow of Mikado Method
Mikado Method本を見てみよう！

38.
Flow
ゴールを書く
ナイーブアプローチをとって、見つかった課
題をリーフにする
リーフをあげたらコードを捨てる！
リーフを達成するナイーブアプローチをとっ
て、、、
成長していったツリーを上から達成していけ
ばゴールにたどり着く！！

39.
Mikado Graph
達成したい事

40.
Mikado Graph
簡単に達成出来そうなコードを書く
達成したい事

41.
Mikado Graph
見つかった課題を追加する
達成したい事
新しい課題
新しい課題

42.
Mikado Graph
変更したコードを捨てる！
新しい課題2
git reset —hard
hg revert
達成したい事
新しい課題1

43.
Mikado Graph
新しい課題1を達成出来そうな簡単な
新しい課題2
コードを書く
達成したい事
新しい課題1

44.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
見つかった課題を追加する

45.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
変更したコードを捨てる！
git reset —hard
hg revert

46.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
繰り返して。。。

47.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
更に新しい課題2
課題が見つからなくなる！

48.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
更に新しい課題2
最後に着手しているところから、
奇麗にしつつ依存しているものを順に
解決していく

49.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
更に新しい課題2
更に新しい課題2からやっていくと

50.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
更に新しい課題2
更に新しい課題1, 2 、新しい課題2を達成した！

51.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
✔️
✔️更に新しい課題2
✔️
達成したものはチェックする！

52.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
✔️
✔️更に新しい課題2
✔️
繰り返す。。。

53.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
✔️
✔️更に新しい課題2
✔️
✔️

54.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
✔️
✔️更に新しい課題2
✔️
✔️
✔️

55.
Mikado Graph
新しい課題2
更に新しい課題1
達成したい事
新しい課題1
✔️
✔️更に新しい課題2
✔️
✔️
✔️
改善達成！！！

56.
Features
ナイーブアプローチ
シンプル
安全
わかりやすい

57.
Naive Approach
ナイーブアプローチと割り切って最初のコー
ドは捨てる！
探索的に変更したコードは捨てれば安全！
知るために書いたコードと設計されたコー
ドは別！

58.
Simple
Mikado Graphはシンプルな記法にすること
で、開発を妨げない！
Unbeatable Modeling Languageではないん
だ！と言っている

59.
Safety
システムが動作している状態でしかコードへ
チェックインされない。
なんとなく動かすためのコードではなく、ボ
トムアップで積み上げるため、VCSのリビジョ
ンツリーも見やすくなる

60.
Communication
ビジュアライズされているので、共有しやす
い

61.
Mikado Method with…
レガシーコード改善ガイド
Mikado Methodは「試行リファクタリング」
を発展、プロセス化したものです。
リファクタリング

62.
Conclusion

63.
Conclusion
レガシーコード改善には、次が必要になる
コードを変更する技術
テスト設計の技術
タスク管理する技術
幅広くやることが、良い結果を生むと私は信
じています。