Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

テストとリファクタリングに関する深い方法論 #wewlc_jp

17 656 vues

Publié le

レガシーコード改善勉強会 in Yahoo Japan 2014.09.27

プロジェクトに対する方法論構築と、タスクマネジメントについての紹介

後半はMikado Methodの簡易紹介です。

Publié dans : Technologie
  • Soyez le premier à commenter

テストとリファクタリングに関する深い方法論 #wewlc_jp

  1. 1. Dive in Test, Refactoring kyon_mm #wewlc_jp 2014.09.27
  2. 2. Self Introduction きょん kyon_mm テストアーキテクト 2年目 TDD/BDD, SCM, Agile, Softwaretest, SoftwareEngineering なごや 基礎勉強会, SCMBC, Nagoya.Testing, Cafe.Testing
  3. 3. Attention 今日お話することは、エンジニアであるとい う立場でお話しします。 やらなければいけないことに目がくらんでい るときは、私は今までレールに乗っていただ けだったのだと気づいたときでした。(経験
  4. 4. Important things
  5. 5. Important things リグレッションしてはいけない 変更にバグはない 保守しやすいことが望ましい ! ただし、バグは変更した部分が原因である事 がほとんどである!!!(←重要
  6. 6. Safety 開発チームが出来るのは基本的には次のどち らか Test Formal Method どちらを選んでも限定的でしかないんだけ ど:-p
  7. 7. Brownfield Development
  8. 8. Wrestle with System
  9. 9. Today’s Topic Testing, Analyzing Task Management
  10. 10. Process プロジェクトを明確にする部分を扱いやすく する単位,粒度を決める それぞれの粒に適した方法で明確にする プロジェクトを変化させる
  11. 11. Example 次の単位でまとめる TestLevel/UserLevel/MaintenanceTerm ViewPoint, Perspective 単位の中で適した方法で明確にする 状態遷移図 マトリックス、テーブル グラフ DSL(ユースケースやシナリオなども含む) 機能配置図 絵
  12. 12. Analyzing, Testing
  13. 13. Analyzing, Testing 要求、コード、ドキュメントを分析し、明確 することが求められます。 それがユーザからみてバグであるかどうかも 含めて明確にすることが重要です。 コンコリックテスティングなどを用いてテス トケース生成をすることは可能ですが、これ は現状を表現するだけであって、何があるべ き姿であるかは不明のままです。
  14. 14. Unit
  15. 15. TestLevel/User テストレベル 動作するシステムの粒度で区切る方法 Unit,Component,Integration,System ユーザー 誰が使うかで区切る方法 Developer,Operator,PO,Tester,ActiveUser ,DisinterestUser,Payer,etc,,,
  16. 16. MaintenanceTerm 保守する期間 どれくらい保守する必要があるのかで分別 する。いつ不要になったり、変更されるの か。 1日、1週間、1ヶ月、3ヶ月、6ヶ月、未定
  17. 17. ViewPoint, Perspective ViewPoint(着眼点) 機能、情報、並行、開発、配置、運用、etc Perspective(横断的関心事) セキュリティ、パフォーマンス、発展性、 etc
  18. 18. Quality Model ISO25000シリーズ(品質モデルをかなり抽象 化して標準化したもの) とりあえずこれでシステムが満たすべきも のをグルーピングするといいと思われる。 FQM(NATOが古に開発した品質モデル)
  19. 19. Clear
  20. 20. FSM… 状態遷移図などを用いてイベントの流れを表 現する。 まぁ、2 bleis 月くらいのプロジェクトだと、 僕はA3用紙40枚くらいの状態遷移図を書いて いたりします。(ミドルウェアの障害まで含 めてシステム全体の状態遷移図を書く)
  21. 21. Matrix,Table 組み合わせを表現する ベースはDSLでもいいのだけど、レビューに効 果的なので積極的に採用しています。 デシジョンテーブルとか 直近の1 kyon_mm 月だとだいたい表の行数は20 万行前後くらいあって、そこからいくつかを 選択するようになっている。
  22. 22. Unit Meets Clear
  23. 23. プロジェクトに最適な表現手段を構築する Developer PO Tester ActiveUser 有効性シナリオシナリオシナリオ テーブル 動画 コンテンツ 快適性レビュー システム 機能完全性DSL テーブル 障害許容性状態遷移図シナリオ 置換性 グラフ DSL 機能配置図機能配置図 グラフ 上記の中身は無作為に近いです(イメージ図です)
  24. 24. Do it 表現方法が決まれば、あとは試行錯誤してやっ ていく感じ。 明確にした部分をテストやドキュメントとし て表現する。
  25. 25. Testing 仕様に基づくようなテストケース生成方法 デシジョンテーブル グラフ網羅 ドメイン分析 Pair-wise まぁこの辺は自動生成のツールを書けば済む 話なので。
  26. 26. Testing テストの実施方法 計画的 探索的
  27. 27. Reference システムアーキテクチャ構築の原理 BABOK ISO25000シリーズ REBOK SWEBOK IA100 ソフトウェアテスト技法 第二版 実践的プログラムテスト 基本から学ぶソフトウェアテスト Specification By Example BDD in Action
  28. 28. Task Management
  29. 29. Task Management WBS Backlog Epic, User Story Todo list Impact Mapping Mikado graph
  30. 30. Mikado Graph Mikado Methodという方法論で書くもの とてもシンプルな図です
  31. 31. 全体 High WBS, Impact Mapping Midlle Backlog, Epic, UserStory Low Todo List, Mikado Method
  32. 32. Mikado Method 他はみなさん知っていると思うので、あまり 知られていないと期待しているMikado-Method について話します。
  33. 33. Mikado Graph 達成したい事
  34. 34. Mikado Graph 達成したい事 新しい課題 新しい課題
  35. 35. Mikado Graph 更に新しい課題 達成したい事 新しい課題 新しい課題 更に新しい課題
  36. 36. Mikado Graph 更に新しい課題 達成したい事 新しい課題 新しい課題 更に新しい課題 更に更に…
  37. 37. Flow of Mikado Method Mikado Method本を見てみよう!
  38. 38. Flow ゴールを書く ナイーブアプローチをとって、見つかった課 題をリーフにする リーフをあげたらコードを捨てる! リーフを達成するナイーブアプローチをとっ て、、、 成長していったツリーを上から達成していけ ばゴールにたどり着く!!
  39. 39. Mikado Graph 達成したい事
  40. 40. Mikado Graph 簡単に達成出来そうなコードを書く 達成したい事
  41. 41. Mikado Graph 見つかった課題を追加する 達成したい事 新しい課題 新しい課題
  42. 42. Mikado Graph 変更したコードを捨てる! 新しい課題2 git reset —hard hg revert 達成したい事 新しい課題1
  43. 43. Mikado Graph 新しい課題1を達成出来そうな簡単な 新しい課題2 コードを書く 達成したい事 新しい課題1
  44. 44. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 見つかった課題を追加する
  45. 45. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 変更したコードを捨てる! git reset —hard hg revert
  46. 46. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 繰り返して。。。
  47. 47. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 課題が見つからなくなる!
  48. 48. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 最後に着手しているところから、 奇麗にしつつ依存しているものを順に 解決していく
  49. 49. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 更に新しい課題2からやっていくと
  50. 50. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 更に新しい課題1, 2 、新しい課題2を達成した!
  51. 51. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ 達成したものはチェックする!
  52. 52. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ 繰り返す。。。
  53. 53. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ ✔️
  54. 54. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ ✔️ ✔️
  55. 55. Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ ✔️ ✔️ 改善達成!!!
  56. 56. Features ナイーブアプローチ シンプル 安全 わかりやすい
  57. 57. Naive Approach ナイーブアプローチと割り切って最初のコー ドは捨てる! 探索的に変更したコードは捨てれば安全! 知るために書いたコードと設計されたコー ドは別!
  58. 58. Simple Mikado Graphはシンプルな記法にすること で、開発を妨げない! Unbeatable Modeling Languageではないん だ!と言っている
  59. 59. Safety システムが動作している状態でしかコードへ チェックインされない。 なんとなく動かすためのコードではなく、ボ トムアップで積み上げるため、VCSのリビジョ ンツリーも見やすくなる
  60. 60. Communication ビジュアライズされているので、共有しやす い
  61. 61. Mikado Method with… レガシーコード改善ガイド Mikado Methodは「試行リファクタリング」 を発展、プロセス化したものです。 リファクタリング
  62. 62. Conclusion
  63. 63. Conclusion レガシーコード改善には、次が必要になる コードを変更する技術 テスト設計の技術 タスク管理する技術 幅広くやることが、良い結果を生むと私は信 じています。

×