Upgrade to Pro — share decks privately, control downloads, hide ads and more …

試験に役立つモデリングの紹介/The Introduction to Modeling for Testing

Cybozu
PRO
September 12, 2020

試験に役立つモデリングの紹介/The Introduction to Modeling for Testing

Cybozu
PRO

September 12, 2020
Tweet

More Decks by Cybozu

Other Decks in Technology

Transcript

  1. 試験に役⽴つ
    モデリングの紹介
    サイボウズ 株式会社
    渡邉 豊幹

    View Slide

  2. 渡邉 豊幹
    ⾃⼰紹介
    2011年新卒⼊社、QA
    現在は販売管理システムを担当
    サイボウズ株式会社
    開発本部

    View Slide

  3. 中⼩企業向けグループウェア
    ⼤企業向けグループウェア
    業務アプリ構築クラウド
    メール共有システム
    製品紹介

    View Slide

  4. • モデルを作成し、試験に活⽤した話
    • メリットと作成時のポイント
    お話しすること

    View Slide

  5. アジェンダ
    担当プロダクト/チームの紹介と抱えていた問題
    実施した解決策「モデルセットを作成する」
    作成時のポイントとコストについて
    今後の展望

    View Slide

  6. 担当プロダクト
    • ⽶国市場向けの販売管理システム
    • ユーザー
    1. 製品のエンドユーザー
    • 試⽤申し込みや契約 など
    2. 社内のセールスチーム
    • 特別価格での発注やライセンス管理、
    キャンペーンの設定 など
    ൢച؅ཧγεςϜ
    ֎෦αʔϏε
    End User Sales Team

    View Slide

  7. チームの紹介
    チーム構成
    開発スタイル
    状況

    View Slide

  8. チームの紹介
    チーム構成
    開発スタイル
    状況
    • 開発チームは6名(うち QAは3⼈)
    • セキュリティ検証は社内専⾨チームに依頼
    QA

    View Slide

  9. チームの紹介
    チーム構成
    開発スタイル
    状況
    • スクラム開発(1スプリント1週間)
    • リリース頻度は約2回/週
    試験後に
    QA がリリース

    View Slide

  10. チームの紹介
    チーム構成
    開発スタイル
    状況
    実装前に全て設計することや、内部の詳細な
    ドキュメントを作成することはせず、
    段階的に開発を⾏いリリースしている
    事前に全てを
    設計しない

    View Slide

  11. チームの紹介
    開発スタイル
    状況
    1. 開発が進むにつれて処理が複雑になる
    2. 各機能の仕様書はあるが、全体像を把握で
    きるドキュメントが無い
    チーム構成 個々の
    機能仕様書は
    あるけど…

    View Slide

  12. 開発上の問題点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い

    View Slide

  13. 開発上の問題点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い
    連携している外部サービスとのシステム境界が
    複雑になり、試験設計の難易度が上がる

    View Slide

  14. 開発上の問題点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い
    個々の機能の詳細な仕様書はあるが、
    全体像を把握するための資料が無い

    View Slide

  15. 開発上の問題点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い
    基本的なケースのモデルを
    作成して解決できないか

    View Slide

  16. なぜモデルが必要?
    ひも?
    • ⽂書よりイメージの⽅が概要をうまく掴める
    • 細かい点だけに着⽬すると全体像を掴みにくい
    かべ?

    View Slide

  17. モデルに着⽬したきっかけ
    平鍋健児さんを招いて開催された社内勉強会
    • アジャイルにおいて必要⼗分な設計とは?
    • ⼀貫性を保って開発するには?
    • 効果的な対話のために必要なものは?
    → シンプルなモデルセット(Keeps)を
    作成する、というアイディアを知る
    Keeps!

    View Slide

  18. Keeps?
    モデル
    モデルとして残すもの
    ・安定している
    ・寿命が⻑い
    Keeps
    残さないもの
    ・実装中に変わる
    ・⼀度共有して捨てる
    Temps

    View Slide

  19. Keeps?
    モデル
    モデルとして残すもの
    ・安定している
    ・寿命が⻑い
    Keeps
    残さないもの
    ・実装中に変わる
    ・⼀度共有して捨てる
    Temps
    共通理解を促す
    シンプルな
    モデルセット

    View Slide

  20. 作成したKeepsの紹介
    Keeps
    システム全体の構造を表すもの
    Architecture
    業務で扱う対象とそれらの繋がりを表したもの
    Domain Model
    ユーザーから⾒たシステムの代表的な使い⽅
    Key Use Cases

    View Slide

  21. 作成したKeepsの紹介
    Keeps
    システム全体の構造を表すもの
    Architecture
    業務で扱う対象とそれらの繋がりを表したもの
    Domain Model
    ユーザーから⾒たシステムの代表的な使い⽅
    Key Use Cases

    View Slide

  22. 作成したKeepsの紹介
    Keeps
    システム全体の構造を表すもの
    Architecture
    業務で扱う対象とそれらの繋がりを表したもの
    Domain Model
    ユーザーから⾒たシステムの代表的な使い⽅
    Key Use Cases

    View Slide

  23. 作成したKeepsの紹介
    Keeps
    システム全体の構造を表すもの
    Architecture
    業務で扱う対象とそれらの繋がりを表したもの
    Domain Model
    ユーザーから⾒たシステムの代表的な使い⽅
    Key Use Cases

    View Slide

  24. 作成したKeepsの紹介
    Keeps
    システム全体の構造を表すもの
    Architecture
    業務で扱う対象とそれらの繋がりを表したもの
    Domain Model
    ユーザーから⾒たシステムの代表的な使い⽅
    Key Use Cases
    ユースケース図
    コミュニケーション図

    View Slide

  25. ユースケース図
    ※⼀部秘密情報のため、実際の表現を変えています

    View Slide

  26. ユースケース図
    特定の操作の
    影響範囲がわかる
    ※⼀部秘密情報のため、実際の表現を変えています

    View Slide

  27. コミュニケーション図
    渡されるデータや
    実⾏ API を記載
    ※⼀部秘密情報のため、実際の表現を変えています

    View Slide

  28. 改善できた点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い

    View Slide

  29. 改善できた点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い
    1. 連携サービスとの境界や、サービスが実⾏される
    タイミングが分かりやすくなった
    2. 仕様書では細かい挙動に注⽬しがちだが、
    俯瞰して影響範囲を⾒ることができる

    View Slide

  30. 改善できた点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い
    1. システム全体で各ユーザーがどのような操作を
    ⾏うのか、俯瞰して⾒ることができる
    2. 各ユースケースごとのシステムの振る舞いに
    ついても概要が把握しやすい

    View Slide

  31. 改善できた点
    試験の影響範囲が把握しにくい
    新規メンバー/他チームへの教育コストが⾼い
    その他
    1. モニタリング対象の API を洗い出す際に活⽤
    2. E2E のテストの改善で活⽤

    View Slide

  32. 作成時のポイント
    ⽬的を明確にする
    チーム内で合意をとる
    ツールを活⽤する

    View Slide

  33. 作成時のポイント
    ⽬的を明確にする
    チーム内で合意をとる
    ツールを活⽤する
    1. スコープを明確にし、作りすぎを防ぐ
    2. 作成するケースを最⼩限に抑える
    ゴール

    View Slide

  34. 作成時のポイント
    ⽬的を明確にする
    チーム内で合意をとる
    ツールを活⽤する
    1. メンテナンスコスト含めて検討する
    2. 更新すべき情報について共有する
    協⼒が不可⽋

    View Slide

  35. 作成時のポイント
    ⽬的を明確にする
    チーム内で合意をとる
    ツールを活⽤する
    PlantUML を使⽤し作成コストを抑えた

    View Slide

  36. 作成時のポイント
    1. 誰でも同じような図を作成できる
    2. コードなので git でバージョン管理できる
    ⾒た⽬の微調整が難しいが、厳密な表現より
    概要を把握できることを優先して使⽤
    PlantUML
    コードで UML を作成するツール

    View Slide

  37. メンテナンスについて
    ルール
    作成コスト
    メンテナンスコスト

    View Slide

  38. メンテナンスについて
    ルール
    作成コスト
    メンテナンスコスト
    • 開発時(仕様変更時)に PG/QA が修正
    • 上記ルールは他の機能仕様書などと同様
    既存のプロセスに
    合わせる形で開始

    View Slide

  39. メンテナンスについて
    ルール
    作成コスト
    メンテナンスコスト
    • 10⼈⽇程度
    • 計11枚の図と説明を作成
    クラス図 ×1
    オブジェクト図×1
    ER図×1
    コミュニケーション図×1
    ユースケース図×7

    View Slide

  40. メンテナンスについて
    ルール
    作成コスト
    メンテナンスコスト
    • 2020年6⽉の運⽤開始後、誤りを⼀度修正
    • 仕様変更による修正はまだ無し

    View Slide

  41. 今後の展望
    チーム内⽤語を記載
    ADR の記載

    View Slide

  42. 今後の展望
    チーム内⽤語を記載
    ADR の記載
    チーム特有の⽤語を定義し記載することで
    認識に齟齬が⽣じることを防ぐ

    View Slide

  43. 今後の展望
    チーム内⽤語を記載
    ADR の記載
    Architecture Decision Records と呼ばれる、
    アーキテクチャ上重要な意思決定の
    背景を記載し、暗黙知が増えることを防ぐ

    View Slide

  44. まとめ
    • 下記問題を解決するために Keeps を作成した
    • 試験の影響範囲が把握しにくい
    • 新規メンバー/他チームの教育コストが⾼い
    • 作成ポイント
    • ⽬的を明確にする
    • チーム内で作成について合意をとる
    • 楽に作成できるツールを活⽤する
    • メンテナンスのルールを決める
    • 今後の展望
    • ⽤語の定義と ADR を記載する

    View Slide

  45. 参考情報
    • 平鍋健児さんの資料
    「 Modeling in the Agile Age」
    https://www.slideshare.net/hiranabe/modelin
    g-in-the-agile-age-228224347
    • PlantUML
    https://plantuml.com/

    View Slide