ソフトウェアプロジェクトにおけるツールの活用を考える会( #sgforswtools ) 第2回勉強会 参加メモ

「ソフトウェアプロジェクトにおけるツールの活用を考える会 第2回勉強会」へ参加した際のメモです．

日時　　：2011/09/12 19:00-21:00
場所　　：日本マイクロソフト　オープンセミナーサークル
参加者数：10人位からスタート。最終的に15人位
参考　　：https://sites.google.com/site/sgforswtools/

■感想

• ツールをメタな視点で議論・情報発信/収集する場はこれまで国内になかったので，とても良い場になることを感じた．
  • ただし，メタな視点で議論したい人がどれだけいて，継続的に参加するか不明な点が気にかかる．
• おみやげいただいた．TFS入門
  • 長沢さん，ありがとうございます．

チーム開発プラットフォーム Team Foundation Server 入門

□以下メモ
■流れ

• 池田さんから挨拶
• 長沢さん講演
• 松木さん講演
• 閉会挨拶

■池田さん挨拶

• しっかり勉強して帰ってください．

• ソフトウェアプロジェクトで利用できるツールの活用を考える
• 有効に活用するにはどうしたら良いか
• 池田さん，松木さん，藤原さんのみ
• ボランティア活動
  • 参照：https://sites.google.com/site/sgforswtools/gaiyou

• ツールを深く扱うのではなく，ツール全般を扱う
• ツールをどう使うかよりメタな話
• 中立的な立場

• ML,勉強会，SIGで議論
• ドキュメント化して広く使ってもらう

• 1年目：各種立ち上げ
• 2年目：定着化
• 3年目：外へ公開

■長沢さん講演

• MSツールをサンプルに，ソフトウェア開発支援ツールの話を．特にツールの進化について．
• 細かいことではなくて，ツールができることを感じてほしい．
• 自身としては開発支援ツール3ブランド目なので、語れる方ではないか。

• ALM
  • なぜでてきたのか，今どうなのか，これからどうなるのか．
  • 言葉自体は10年前からある

• ビジネスとソフトウェア
  • 90年代：ソフトウェアは便利
    • ビジネスと同期していない
    • 時間かけられる
  • 00年代：ソフトウェアは有効
    • ビジネスと同期する
    • 時間かけられない
  • 10年代：ソフトウェアは不可欠
    • ビジネスを加速させる
    • 変わることに対応しないと意味が無い
  • こんな背景があって，ソフトウェアは必須になった．
  • 現在はビジネスのアジリティに開発アジリティが対応しないと意味が無い．
    • 極端ではあるがビジネスに合っていれば，ソフトウェアが完成していなくても問題ない．

• 時代の変化による変化
  • 注力点
    • 90年代：システム内部
    • 00年代：システム間
    • 10年代：ビジネス間
  • 開発環境
    • 90年代：IDE
    • 00年代：ALM 1.0
    • 10年代：ALM 2.0
  • 意識
    • i'm doneからwe're doneへ
  • 10,20年で大きく進化している

• 従来は作った時が最大の価値だったが，今はビジネスの価値が増えていくについてソフトウェア価値が増えていく

• 個人のアジリティ
  • ワークダウン，単能工，WF
• チームのアジリティ
  • イテレーション，単能工と多能工、UP
• ビジネスのアジリティ
  • 多能工，Agile

• ツール
  • IDE
    • 個人の生産性，バージョン管理，開発者同士の連携
  • ALM 1.0
    • チームの生産性，ソフトウェア構成管理，BTS/ITS，個別最適化ツール，ロール間の連携
    • BTS/ITSを連携させることが大事
    • 要求管理ツール，モデリングツール，ソース管理ツール，テストツール，それぞれをいれる
      • 各ロールが各ロールにあったツールを導入することが多かった．
    • チーム全体の情報をとるには，各ツールから情報取ってくる必要あった
    • 開発者にとっては見ていくことに負荷がかかる．マネージャーにとっては全部見ないといけないためさらに負荷がかかる。
    • 作業開始・情報取得に手間がかかる
  • ALM 2.0
    • チームの生産性，ALMプラットフォーム，全体最適ツール，作業間の連携
    • リポジトリを１つにする．
      • リポジトリから情報取る
    • 各ツールからリポジトリの情報を取ってくる
    • 何も考えずとも情報を横串的にとることが可能になる．
    • 作業開始・情報取得が容易

• 今は，リポジトリのパタンが2つある．
  • ALM1.0に代表される複数リポジトリ
  • ALM2.0に代表される単一リポジトリ
  • それぞれ特徴が存在する．

• 最近の流れは，設計の初期から検証して品質を作り込んでいく
  • 設計段階から検証結果などの情報を取得する必要が増えている

• IDE：excel,VS,VSS
• ALM2.0：VS,TFS
  • ユーザーストーリーの表示を行うだけでも，様々な情報を引き出したい．
    • 要件，タスクの計画，タスクの実績，テストの計画，テストの結果，バグ…
    • これらを作るのに手間かけるのは不要な負荷
  • データがあれば見せ方は様々にできる

• TFS
  • 作業項目：要件やそれに紐付くタスク．スプリントバックログ
  • 使い慣れたツールをI/Fとして，リポジトリへアクセスすることができる
    • ファイルを作るのではなく，リポジトリから情報読み取っている
  • 情報に関しては，テンプレートがあり，それをカスタマイズすることで多くの情報が簡単にとれる．ただし情報を新たに定義するのは可能だが大変．

• TEST Manager
  • テストの計画と実行を管理できる
  • テスター向けツール
  • テストの状況を表示できる．
  • TFSと連携して，自動的にビルドIDやそのビルドのテスト項目一覧，やるべきテスト一覧などを表示できる
    • 要件ごとに表示もできる
  • 手動テストのテスト手順を表示することができる．
    • 一回実行した操作は再生することができる．
    • 手動テスト一回やっておけば二回目以降は自動化できる
  • バグの起票も簡単に行うことができる
    • 行ったテストの情報を自動的にバグ表に入力してくれる
    • 入力工数削減だけでなく，入力ミスを削減することもできる

• Excel連携
  • ピボットでデータを取ってくる

• 情報を取ってくる際には，大抵複数の情報リソースから取ることになる
  • それを1リポジトリにすることで改善することができる．

• ソフトウェア開発のスケーリング
  • ツールも方法論も進化している

• 利害関係者が増えれば増えるほど，レポートの手間がかかる

• VSのバージョンの違い
  • ツールでどこまでサポートするのか．
  • 高いツールのほうがカバー範囲が広い
    • 高いVSでは単体テストのパフォーマンステストも可能

• 次の進化も始まっている
  • USのMSでbuildというイベントあり，ここで次の話もあるはず．
    • http://www.buildwindows.com/

■松木さんの講演 -TABOK-

• TABOK：ATI策定の自動テストに関する知識体系
  • ティーエーボック
  • ATI:Automated Testing Institute
    • http://www.automatedtestinginstitute.com/home/index.php?
  • ATIがCertificateする
  • http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1352&Itemid=95
  • おまけ：SQuBOK,REBOKは国内から発信

• ここでいう自動テストは比較的システムテスト以降、上位の話が多い

• TABOK
  • イントロ，プロセススキル，アペンド
    • プロセススキルにおける Skill Category 1-7は自動化リーダ向け，8-12は自動化技術者向け
    • 技術者も1-7を見ておいたほうが良いとされる
    • 本編はプロセススキル
  • テストを考える上で自動化を考える

• ブログ参照
  • http://d.hatena.ne.jp/shinsuku/20110908/p1
  • 1Wしか読んでないので突っ込んでほしい
    • たぶんうそついてるw

• Skill Category 1: Automation's Role in the STLC
  • ソフトウェアライフサイクルにおける自動化の役割
    • ソフトウェアテストとの違い
    • 統合（インテグレーション）＝ツールを導入しなじませる
• Skill Category 2: Test Automation Types and Interfaces
  • テスト自動化の種類とインターフェース
    • テストタイプの識別
• Skill Category 3: Automation Tools
  • テスト自動化ツール
    • 自動化ツールの種類
      • ツールの話
    • 自動化？なツールも含まれる
• Skill Category 4: Test Automation Frameworks
  • テスト自動化フレームワーク
    • ロールの話が主
    • Cross Coverage Coordinator=組織間のツールなじませる
      • 自動テスト界のSQA
• Skill Category 5: Automation Framework Design
  • テスト自動化フレームワークの設計
• Skill Category 6: Automated Test Script Concepts
  • 自動化スクリプトのコンセプト
    • どういった分析をおこなうと導入がはやくなるか
• Skill Category 7: Quality Attribute Optimization
  • 品質特性の最適化
    • 一般的な品質特性以外にもロバストネスやフレキシビリティ，スケーラビリティを定義している
      • 自動テストならでは．
• Skill Category 8: Programming Concepts
  • 現在プログラミングについて
    • ここから担当者のスキル
    • 現在のプログラミング言語のパラダイムとかを自動化担当者も知っとかないといけないよ
• Skill Category 9: Automation Objects
  • 自動化オブジェクト
    • 動的オブジェクトを担当者も自動テストで意識しないと
    • アプリケーションオブジェクトをいかにテストコードから触るか
      • 動的なものをテストすることは課題，といっている
      • これを言えれば載るよ！by松木さん
• Skill Category 10: Debugging Techniques
  • デバッグのテクニック
• Skill Category 11: Error Handling
  • エラーハンドリング
• Skill Category 12: Automated Test Reporting
• 自動テストレポート
  • ハイレベルテストスイート／ローレベルテストスイート
    • テストのハイローとは異なる

• ユーザ登録後買える
  • 本とCDで89ドル

• 明日から使えるTABOK
  • TABOKの存在自体
    • テスト自動化を片手間にしない
    • アペンドにROIを計算することが書かれている
    • 自動化では実行の手間のみ減らせる．少し設計の手間は増える．
      • 実行が一番手間がかかる
  • テストコードは高い保守性と変更が起きる．そのノウハウは高い価値となる．
  • 自社にロールがないならば，逆にこれを機に作るチャンス．