ヨタの日々

用語の定義というか IT方面の用語とゲーム業界の用語を擦り合わせるのに時間の半分くらい使って、ゲーム開発のプロセスの説明に 1 時間くらい使い、肝心の魅力を作り込む云々は 10 分くらいしか話してなかったような。「魅力を作り込むのはプランナーとプログラマに依存しているのでどうにかしたい」という話題だった。うーん

講師
- 粉川貴至 (セガ)
  - 開発インフラ整備とかツールとか
  - CEDEC 2011 でしゃべったので CEDEC ライブラリ見てね
  - { CEDEC Digital Library 登録すれば無料で利用可能。過去の CEDEC 資料も見れる }
  - [CEDEC]ゲーム開発効率化/品質向上ツール　ラウンドテーブル
- 石畑義文 (セガ)
  - バーチャロンとか
  - CEDEC 2011 でしゃべったので CEDEC ライブラリ見てね
  - [CEDEC]ハッター軍曹のソフト運営改革術
  - スクラムマスターになりました
- 多田航 (バンダイナムコゲームス)
  - ACE COMBAT とか
  - CEDEC 2011 でしゃべったので CEDEC ライブラリ見てね
  - [CEDEC]ACE COMBAT ASSAULT HORIZONにおける継続的インテグレーション
  - プロジェクトごとにテストの実態は異なる
  - テスト専任者は居ないのでとにかく自動化
  - CI しまくり
  - 単体テスト、結合テスト、静的解析、デプロイ
- 益弘和 (Ubisoft Osaka)
  - CEDEC 2011 でしゃべったので CEDEC ライブラリ見てね
  - プログラマの開発効率向上パターン
  - ユニットテスト導入の技術的課題とその解決例
  - ゲーム開発効率化/品質向上ツール　ラウンドテーブル
- 東大輔 (JaSST東京実行委員会)

CEDEC 2011 自動テストラウンドテーブル
- GDC( Game Developers Conference ) で自動テストのラウンドテーブルをやってたのでマネしてみた
- テストツールアンケート
- cppunit 2割
- google test 2割
- 使ってない 6,7 割

やってるテスト
- スモークテスト
- モンキーテスト
- ボット
- 機能テスト

プロセス
- CI
- バージョン管理
- コード管理
- アセット(ゲームの絵とか)管理
- データ収集

日本のゲームSUGEEEだったのは一昔前
- いまは誰も思ってない
- ゲーム開発は町工場みたいな感じ

大規模とは？
- 関係者 100 人くらいで大規模
- プログラマ 10 人くらい
- ただし海外は異なる
- エンディングのスタッフロールでプログラマの人数を数えるのが楽しみ
  - ただし外注などは載ってないので注意

全体のプロセス
- ゲームが起動するまではプログラマの責任
- プログラマがテストする

テストエンジニア
- ゲーム開発にテストエンジニアは居ない
  - テスト(デバッグ)は外部の会社に発注しておりテスター(デバッガー)という活動しかしていない
  - マイクロソフトのひとが言っていた「1995年代のテスター」という状況
- 居るべきだと思ってはいますがー
- マイクロソフトのひとも言っていましたがー
- テストをエンジニアリングできる体制を作らねばならない
- 品質向上→品質コスト削減→魅力に注力できる→ウハウハ
- という流れにしたい

「最近の静的解析の立ち位置」

講師安竹由起夫 (コベリティ日本支社)
- CEDEC 2011 でしゃべったので CEDEC ライブラリ見てね
- 効率的なゲームタイトル開発の要、「ソースコード静的解析」の運用を知る

動向
- 4 年前
  - 開発者が個人で解析
- 2 年前
  - チーム活動で連携
  - リポジトリから取得してどうのこうの
  - jenkins はじめました的な
- Now
  - ALM の中に組み込む
  - アプリケーション・ライフサイクル・マネジメント - Wikipedia
  - IT Pro のための ALM 入門 - Tech Fielders コラム
- 今年
  - セキュリティリスクコード検出
  - セキュリティ事故のうち 6 割はコードが原因。CERT もそう言っている

Tags: JaSST

[ツッコミを入れる]

2012-01-25 :-)

_ 午前

0700 起床

0900 雅叙園

_ 午後

1300 雅叙園

_ 夜

2000 飯

_ JaSSTソフトウェアテストシンポジウム-JaSST'12 Tokyo

＠目黒雅叙園

久しぶりに行ってきた。[ 20070130#p03 ][ 20080130#p01 ]

マイクロソフトのひとも「dev & test equal partners」と言っていたけど、開発者とテスト者がお互いがお互いのことを考えて活動する(対立するんではなく)というのが思想として流れているような。

「dev & test」だけでなく、1, 2 年くらい前から「dev & ops」という言葉も見られるようになった( ウェブ業界(?)で開発者と運用が歩み寄るという思想だとかなんとか。ウェブオペレーションにも書いてある )。ソフトウェアというか製品に関わるひとすべてが協力しないと良い物は出来上がらんよという。しかしそんなことは大昔から歴史の教科書に書いてそうなんだけど、誰も指摘しなかったんだっけ。

ウェブオペレーション ―サイト運用管理の実践テクニック
John Allspaw/Jesse Robbins/角征典
オライリージャパン
￥ 2,730

How We Test At Microsoft マイクロソフトでどのようにテストをしているのか？

講師 Bj Rollison (Microsoft)

Tester profiles
- 1995 年ころ
  - テスターはバグを出すだけの簡単なお仕事をしていた
- 2003 年ころ
  - { Windows NT 2000 ころか }
  - それだけだともはやバグが大爆発したとかなんとかで
  - テスターは高度にコンピューターサイエンスを持った専門家の部隊になった

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% くらい
- 単体テストなどをやらせるようにする
- テスト容易性が高まるような設計をしてくれるようになる
- テストはデータを開発へ提供する

「チャーン」というのを初めて聞いたんだがこれらしい

前回のビルドから今回のビルドまでに追加／変更／削除されたソースコード行数のこと（チャーン（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 段階
- 開発者がテスト容易性を高める姿勢になる
- 互いが互いに歩み寄る

要件定義
- 獲得→分析→仕様化→検証
- 分析が重要
- 開発で使う手法で分析するのではなく
- テストが使う手法で分析する
- テストはユーザーの視点に立てる

[ツッコミを入れる]


		2012年 1月
日	月	火	水	木	金	土



						28
29	30	31

ヨタの日々

2012-01-27 :-(

_ 午前

_ 午後

_ 夜

_ はじめての pull request

2012-01-26 :-)

_ 午前

_ 午後

_ 夜

_ JaSSTソフトウェアテストシンポジウム-JaSST'12 Tokyo 2 日目

「ホンマでっか！？ゲーム開発現場 ～魅力を作り込む事を最優先にする開発プロセスとテスト～」

「最近の静的解析の立ち位置」

2012-01-25 :-)

_ 午前

_ 午後

_ 夜

_ JaSSTソフトウェアテストシンポジウム-JaSST'12 Tokyo

How We Test At Microsoft マイクロソフトでどのようにテストをしているのか？

「テストアーキテクチャ解説 ～テストアーキテクチャ設計を実践するには～」

「Wモデルとは何か」

「ホンマでっか！？ゲーム開発現場～魅力を作り込む事を最優先にする開発プロセスとテスト～」

「テストアーキテクチャ解説～テストアーキテクチャ設計を実践するには～」