1. コヤマン@koyaman2
in Nagoya.Testing in Tokyo #3
WACATE実行委員会とか
JaSST実行委員会とか

2.  テストエンジニアです。
 テストエンジニアにはおおざっぱに２つの役割があります。
 テストマネージャ
 テスト担当者
 おっさんなのでマネージャです。※でも10年くらい
 普段、おっさん何やってんの？と言われたのでおもむろにLT。
 J隊→プログラマ→テストマネージャ。
 今の担当はサーバの複合システムのテストマネージャ
 基本組込みで医療機器とかWebストレージとかのテスト。

3. 政治してます。

4.  半分冗談です。
 マネジメントという言葉が示す通り、基本的には環
境を用意したり、戦略を練るのがお仕事。
 あと、テスト計画ってものは毎日変わるのでリファイン
したり、何らかの手を入れたり。
※モニタリングとコントロールと言います。
 また、チーム戦略や会社の政治的なこともやったり。

5.  僕の背景
ココの
マネージャ。
開発→品証への
窓口

6.  開発メンバーとの打ち合わせがほとんど。
 なんでそんな役割がいるの？→規模が大きいから。
 開発のチームはプロダクトオーナーグループみたいな
のが８人くらいと、各サブシステムのリーダーとサブリー
ダー＋アーキテクト＋仕様策定者＋実装オフショア
チーム
 各サブシステムは４つほど。合計は１００人超えくらい。
 テストチームは８人＋オフショア１０人。
 主な仕事は仕様レビュー、要件レビュー、設計レビュー、
環境、成員、リスク、不具合のマネジメント

7. Mgr Act
tester Act
 絵にするとこんな。

8.  JSTQBではレビュー＝静的テスト
 レビューが最も効果的。
 ポイントとしては、大規模なチームとかの場合は以
下。
 チーム間の認識の齟齬の抽出
 要求側とチームの認識の齟齬の抽出
 チームリーダーとチームメンバの認識の齟齬の抽出
 開発と品質保証のひとの認識の齟齬の抽出
 手が回らないところを補助する。

9.  SQuBOK参照ｗ

10.  いつでもやれる、それがレビュー。

11.  こんな観点でやってます。

12.  レビューでモデル図の間違いを見つける場合
 モデル図の作者に欠陥の場所を指摘する
↓
 モデル図の修正(5秒)
 テストで故障を見つける場合
 テストを実施してみて、期待値の齟齬を発見
↓
 コーディング担当者がログとかを確認、再現確認
↓
 原因を特定して修正、確認テスト
↓
 修正したビルドでテスト担当者が確認(場合によっては1week以上？)
※早期不具合検出の恩恵については日本規格協会の
ソフトウェア品質ガイドブック などを参照。以下の資料などにも書いてあります。
http://www.juse.or.jp/software/pdf/23spc_2.pdf
→エラー修正に要するコストで検索しても出ます。

13.  プロジェクトの計画変更回数
 不具合の傾向分析
 不具合のよく出る傾向やモジュールの傾向とか
 市場からどんな不具合が出てるかとか
※海外だとデータエンジニアとか言われるらしい。
こんなこともやってます。