2012-01-25 :-)
_ 午後
1300 雅叙園
_ 夜
2000 飯
_ JaSSTソフトウェアテストシンポジウム-JaSST'12 Tokyo
＠目黒 雅叙園
久しぶりに行ってきた。[ 20070130#p03 ][ 20080130#p01 ]
マイクロソフトのひとも「dev & test equal partners」と言っていたけど、開発者とテスト者がお互いがお互いのことを考えて活動する(対立するんではなく)というのが思想として流れているような。
「dev & test」 だけでなく、1, 2 年くらい前から「dev & ops」という言葉も見られるようになった( ウェブ業界(?)で開発者と運用が歩み寄るという思想だとかなんとか。ウェブオペレーションにも書いてある )。ソフトウェアというか製品に関わるひとすべてが協力しないと良い物は出来上がらんよという。しかしそんなことは大昔から歴史の教科書に書いてそうなんだけど、誰も指摘しなかったんだっけ。
4873114934
How We Test At Microsoft マイクロソフトでどのようにテストをしているのか？
- 講師 Bj Rollison (Microsoft)
- Tester profiles
- 1995 年ころ
- テスターはバグを出すだけの簡単なお仕事をしていた
- 2003 年ころ
- { Windows NT 2000 ころか }
- それだけだともはやバグが大爆発したとかなんとかで
- テスターは高度にコンピューターサイエンスを持った専門家の部隊になった
- 1995 年ころ
- Organizing testing
- マイクロソフトの社内はフラット
- マネージャーとそれ以外だけ
- マネージャーは傘の役割り
- アジャイル
- 「速い」というか「変化に対応する」ことが重要
- コミュニケーション
- メールやチャット
- 「dev & test equal partners. but separate orgs」
- マイクロソフトのテストキャリア
- 技術方面
- アーキテクチャ
- マネジメント方面
- マネージャー
- 両方の道がマイクロソフトにはある
- Testing approaches
- ブラックボックステスト
- オートメーション
- API と GUI はシナリオテストやる
- ドッグフード
- セルフホスティング
- ホワイトボックス
- コードが読めるひとはレビュー
- カバレッジ分析
- コードとデータを分析する
- ブラックボックステスト
- Testing lifecycle
- 設計→実装→計測→解析→優先度付け
- これがマイクロソフトのテストのライフサイクル
- ウォーターフォールとかアジャイルとか関係ない
- 改善活動をひたすら継続していく。ただそれだけ
- Productivity tools
- テストでの問題はテストで解決すればいい
- ツールを作る
- Vista でのツール
- チャーンの指標を可視化
- これで優先度を決めていつ何をテストするか決める
- Visual Studio でのツール
- 開発で使用していたツールを Visual Studio にビルトインしたよ
- ゲームでのツール
- バグ発生→フィードバック→バグ発生した箇所までナビゲート→さらに関連するバグも表示しちゃうよ
- Automation model
- CI
- 自動化
- とにかく自動化
- Connected Culture
- { 生活に密着する }
- PC、タブレット、ゲーム、テレビ等を別々に考えるのではなく
- 結びつけて考える
- 生活がどう変わるか
- デバイスを行き来するデータを考える
- 開発者がテストに割く時間
- 15% くらい
- 単体テストなどをやらせるようにする
- テスト容易性が高まるような設計をしてくれるようになる
- テストはデータを開発へ提供する
「チャーン」というのを初めて聞いたんだがこれらしい
- Q: What is code churn? - Visual Studio Team System - Site Home - MSDN Blogs
- テストチームによる結合機能テストの実施 - ＠IT
前回のビルドから今回のビルドまでに追加／変更／削除されたソースコード行数のこと（チャーン（churn）とは「かきまぜる」の意味）。最初のうちは難易度の低い大量のバグが発見されるため、コードチャーンは大きくなる。しかしある程度難易度の低いバグ出しが終わってくると、少しずつコードチャーンは減ってくる。コードチャーンが一向に減らないようであれば、バグが大量に残留しているなど、何らかの問題がある可能性が高い。
「テストアーキテクチャ解説 ～テストアーキテクチャ設計を実践するには～」
- 講師 智美塾塾長＋塾生一同
テストアーキテクチャというものをみんなで考えようという時間
- テストバスケット
- テストフレーム
- テストタイプ ( e.g. 負荷 )
- テスト対象 ( e.g. CPU )
- テストフレーム
- テストタイプ ( e.g. 負荷 )
- テスト対象 ( e.g. ネットワーク )
- テストフレーム
質疑応答
「質問される方は、名前と所属を言ってください」
「所属と言われても... 日本 Ruby の会から来ました関と申します。世界的なプログラマです」( I like Ruby too. )
のど飴フイタ
結局テストアーキテクチャとはどういうものなのかというと、テストアーキテクチャはテスト対象のソフトウェアと同じような構造になる、それがアーキテクチャである。ということなのかしら。はて
「Wモデルとは何か」
- 講師
- 秋山浩一 (富士ゼロックス)
- 鈴木三紀夫 (ASTER)
- 吉澤智美 (日本本電気)
- 西康晴 (電気通信大学)
- Wモデル
- ステークホルダーを洗い出す
- 各ステークホルダーの思惑を 1 枚の絵に書き出して全員で見ること
- Wモデル導入時
- パイロットプロジェクトでやるといいんじゃないの
- テストからボトムアップで 1 つずつ働きかける
- バグが多いモジュール/カテゴリに注目し
- 「ここバグが多いんじゃないの」などとその設計からツッコミを入れるように持っていく
- 組み込み開発でのモデル
- 最初
- ソフトウェアが小規模なので V 字
- 開発者が 1 人で実装しテストする
- 規模が大きくなる (またはソフトウェアが成長する)
- 問題が起きる (インシデントだったりいろいろ)
- 第 1 段階
- テストを分離させる。テスト担当が出来る
- テストが {モジュール,コンポーネント} のバグを理解したり設計を理解してくる
- 設計にもツッコミを入れるような姿勢になる
- 第 2 段階
- 開発者がテスト容易性を高める姿勢になる
- 互いが互いに歩み寄る
- 要件定義
- 獲得→分析→仕様化→検証
- 分析が重要
- 開発で使う手法で分析するのではなく
- テストが使う手法で分析する
- テストはユーザーの視点に立てる
