Skip to content

Instantly share code, notes, and snippets.

@mshibuya
Created September 11, 2013 09:58
Show Gist options
  • Save mshibuya/6521596 to your computer and use it in GitHub Desktop.
Save mshibuya/6521596 to your computer and use it in GitHub Desktop.

ビジネスに求められる開発ライフサイクルの進化とテスト工程の革新

〜DevOpsとサービス仮想化〜

CA technologies


ご挨拶

LISA事業部 佐藤さん

  • チーム日本
  • DevOps
  • サービス仮想化

CAのDevOps

  • 時間のゆとり
  • 心のゆとり
  • シフトレフト
    • 時間軸を左に→短期化
      • LISA

クラウド・アジャイル時代の最適テスト手法 探索的テスト

高橋さん

  • オリンピックのプレゼン
  • プレゼンに慣れて欲しい
    • なぜなら、品質を保証するためにプレゼン能力って必要

著書

  • 知識ゼロから学ぶプロジェクト管理
  • 現場の仕事がバリバリ進む ソフトウェアテスト手法
  • 知識ゼロから学ぶソフトウェアテスト

これから必要なのは

  • リスクコントロール
  • タイムマネージメント

旧来のテストとは

  • 網羅的
  • お金がかかる
  • 時間がかかる

クラウド・アジャイルの新しいテストとは

  • 早い
  • 安い
  • そこそこの品質

Androidアプリ・Webアプリ・SNS

→新しいテストの枠組みが必要

提案する新しいテストのスタイル

TDD + 探索テスト

探索テストとは

  • Kent Beck(XPを作った人)は基本的にシステムテストや受け入れテストに関して定義していない

  • XPで早く開発できるようになったのに、重いテストは誰も受け入れない。Daily Releaseにも耐える、軽いテストを

  • ソフトウェアテストの一つのスタイル

  • 一個人のテスト活動

  • 継続的にテスト活動を洗練させる

  • 以下の活動を 同時実行

    • ソフトウェアを理解
    • テストケース設計
    • テストケースを実行
  • 一つ一つの細かいテストケースは書かない!

  • そんな暇があったら実際にテストしようぜ!

  • 触ってみていいろいろテストするとわかるじゃん!

  • 開発者の修正とか、製品の癖とか考えながら スキルのあるテスト担当者 がテストするからたくさん回帰テストのバグが見つかるんだよ(回帰テスト)

テストケースベースのテストの限界

  • 要求仕様は間違いというより、記述しきれてないものがバグとなる
  • 要求仕様の抜けは、致命的なバグにつながりやすい

具体例

  • General Functionality and Stability Test Procedure
  • Pass/Fail基準を決める
  • テストプロセス
    • 製品の目的を明確にする
    • 機能を明確にする
      • 製品をウォークスルーする。どういった機能を有しているか
    • 弱いエリアを叩く
      • 日本人は網羅的を目指しがち
      • 理論的には、継続開発では7%のファイルから 全てのバグ が出る
        • 最近たくさんいじられているファイル
        • 長さが長いファイル
          • コードがよく整理されてないから
    • テスト実行及びバグを記録
    • 上記を継続的に実行

利点

  • 抜群に投資効果が高い
  • 早くバグを見つけられる
    • 優秀な人材回転率がいい!
  • たくさんのバグを見つけられる

欠点

理論的にはない。悪くてもテストケースベースのテストと同等

注意点

  • 探索的テストに100%頼らない
    • テストケースベースのテストに100%頼らないのと同じ
    • 所詮テストで見つけられるバグは50%以下
  • 探索的テストはトレーニングを十分に受けた担当者によってなされる
    • なかなか日本だとトレーニングを出来る機関とかない…
    • 本とかで自分で勉強したり?
    • なるべく優秀な人材をアサインする!
  • 非機能テストを探索的テストでアプローチしない
    • パフォーマンステストとか

テストの生産性と品質の劇的向上!"サービス仮想化"でいままでの常識を覆す

〜CA LISAご紹介〜

LISA事業部 西野さん

  • システム関連予算が横ばいな中、スピードが求められている
  • テスト工程にもっとも時間がかかっている
  • 視点を変えて大幅な短縮を
  • テスト実行における制約を取り除く
    • 連携先サービスの"ふるまい"を仮想化

ふるまいの仮想化?

  • "ふるまい"のみをモデル化
    • リクエスト/レスポンス
    • 応答時間
  • ロジックをもたない
  • 制約からの解放

仮想サービス生成方法

  • ダイナミックな生成
    • リクエストをキャプチャ・学習
  • スタティックな生成
    • WSDL・フラットファイル・仕様書等
  • セルフヒーリング
    • 維持していく

デモ


ビジネスを加速するためにDevOps

〜課題と解決策〜

Microsoft 長沢さん

ポイント

DevOpsの意味は、各自で定義すべき!

ゴール

  1. DevOpsの概念を理解
  2. 一般的な課題と解決策を把握
  3. 戦略的ITへの準備へ

ビジネスとIT

  • ビジネスにとって、ITは不可欠

  • ビジネスモデル

    • ITの重要性が増している
    • ITに非依存→ITが関与→ITがドライバー
  • 意思決定

    • ITの重要性が増している
    • IT部門→経営者層→顧客/市場が中心
  • テクノロジー

    • C/S→Web/Webサービス→クラウド/デバイス

まとめると

  • ビジネスモデルを牽引
  • 顧客と市場へのアジリティ
  • クラウド&デバイスの活用
  • DevとOpsの強調

DevOps 概要

  • ビジネスとIT(= Dev + Ops)

  • 一方通行

    • ビジネスのアイディアや課題→開発→運用→ビジネスの価値提供と改善
  • DevとOpsの間に壁ができる

  • 繰り返し型のビジネスでは致命的!

  • Lean Startup

    • Build - Measure - Learn
  • ムーブメントはすでにエンタープライズに

    • 顧客にダイレクトに響く活動
    • つながる商談の継続
    • 先進的な業務環境
    • 独自性と競合優位性
  • エンタープライズITの"ユーザー"

    • お客様
    • 従業員
    • システム間連携
  • エンタープライズアプリの進化

  • SYSTEM OF RECORD

    • 基礎体力
  • SYSTEM OF ENGAGEMENT

    • 戦闘力
    • 差別化
    • アジリティが必要
  • DevOpsによる戦略的なITへ

DevOps 課題と解決策

  • 開発と運用の対立

Biz + IT(Dev + Ops)の共有ゴール

  • サイクルタイム

    • ビジネスアイディアを定期的に体系化出来る仕組み
  • MTTR

    • 障害からの復旧時間を最低限に
  • 自動化

  • 共同所有

ムダ取りができ、透明性が高まる

  • 本番稼動中の障害対応
    • 再現可能な開発環境
  • デプロイの問題
    • トレーサビリティの確保
    • 自動化
  • テスト
    • 継続的インテグレーション

システム開発を請け負うSIerからみたCA LISA

JIEC 飯久保さん

CA LISA導入の背景

  • 品質確保
    • テストの重要性が高まる
  • 開発
    • 様々な手法・ツールがある
    • これ以上の生産性向上は難しい
  • テスト
    • 全体の5割近い工数を占める
    • まだ生産性向上の余地がある

CA LISA適用パターン

いろいろ役に立つよ!みたいな内容

まとめ

新しい手法を取り入れた場合は、従来の開発運用規約は必ず見直す必要がある。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment