発表資料
www.slideshare.net
今回の発表の目的
- 自分自身がテストオペレーターからテスト設計者にステップアップするための方法
- 今日のJaSSTの参加者がみんなベテランやん！
- 自分の後に続く人に伝えてあげる方法
改めてソフトウェアテストについて考えてみる
- テストってなんですか？
- 背景によって色々異なる
- JSTQB用語集などが参考になる…けど分かりづらい
- 『ソフトウェア技法』よりテスト担当者の精神面による区分を引用
- 成熟度によって異なる
- フェーズ1「テストとは動くことを示すものである」だと、テストをして何が嬉しいの？と思われがち
- フェーズ4まで行くと「テストは欠陥予防である」
- にしさんが「テスト道」として伝えることが多い
- 成熟度によって異なる
- 山崎さんの言葉でいうと「テストとは品質に関わる"新たな"情報を提供するための活動」
テストの価値は情報提供の価値
- 早い・安い・旨い
- 早い…CIで行うことで、すぐにフィードバックがくる
- 3日後の自分は他人である
- リスクの高いものは早めにやることで改善できる
- 安い
- 旨い…有益な情報でなければならない
- 作業をこなすことは意味がない。せっかくやった結果がうまく活用されない
- テスト結果がわかり易いほど価値が高くなる
- 早い…CIで行うことで、すぐにフィードバックがくる
山崎さんがモヤモヤしていること
なぜテスター≠テストの専門家と認知されないのか
- テストに対して理解されていない
- そもそもテストの専門家以外もやってる？
- テストをする人がテスターだけでなく、ユーザーだったりする
- 他の専門職と比較してスコープが広いから？
- V字モデルの右側すべてが「テスト」ですからね。
理想のテスターとは？
- 良いテストエンジニアとは？
- JaSST'14 Tokyoの基調講演より（Stuart Readさん）
- TEST SKILLS
- IT SKILLS
- インフラの知識とかも必要
- DOMAIN KNOWLEDGE
- ドメイン固有の情報
- 満たさなければならない要件とか
- SOFT SKILLS
- トレーニングしても身につき難いもの
- 例えばコミュニケーションモデルとか
- 正しかったとしても、それをきちんと伝えていなければ意味がない
- この4つをバランス良く習得しているのがProfessional Tester's Skill-space
- 「テスターだからプログラミングはしません」は残念なこと。価値として提供できない
開発を加速させるための協力者というマインド
- テストは基本的にテストそのものが目的ではなく手段である。
- テストが安定してない→バグが出ている状態
- そんなネガティブなことを伝えても加速しない
- テストをゲーティング（これを通らないと先に進ませないよ）とならないように
- 開発と対立関係ではなく協力関係にならないといけない
最初の一歩を踏み出すのに重要な3つのこと
- テストの全体観を持つ
- ロールモデルを見いだす
- 成長へのモチベーションを持ち続ける
- 動機づけしてない人に伝えても暖簾に腕押し状態
1.テストの全体観を持つ
- テストの全体観を保つための3つの軸
- テストレベル
- テストタイプ
- テストプロセス
- この3つを理解していると非常に理解しやすくなる
- ドラクエ1の松明のようなもの
テストレベル
テストタイプ
- 以下のようなテストタイプがある
- 機能テスト
- 非機能テスト
- 構造テスト
- 変更部分のテスト
- テストオペレータに何のテストタイプを行わせているのか理解していますか？
テストプロセス
- 普通の開発プロセスと同じように、テストにおいてもプロセスがある
- テスト計画
- テスト分析
- どんなテストをしなくちゃいけないのか
- テスト設計
- どんなテストケースを作ればよいのか
- テスト実装
- 実際にテストケースを作成する
- テスト実行
- 終了基準の評価とレポート
- テスト終了作業
- モニタリングおよびコントロール
- テスト実行しか見えていないと、テスト分析とかに意識がいかない
テストケースを作るまでのイメージを持てることが重要
- テスト設計技法は学ぶが、それを上手く使えない…
- テストベースに対していきなりテスト設計技法を適用しているのでは？
テスト開発プロセスの例
- 文書
- →テスト分析してテスト設計仕様を作る
- →テスト設計してテストケース仕様を作る
- →テスト実装することでテスト手順仕様が作られる
- マニュアルでなければテストスクリプトになったりする
- 29119-2では、テスト条件とテストケースの間にテストカバレッジアイテムがあったりする
- どうしてこのテストケースにしたの？という質問に答えられないといけない
- 「なんとなくテストしたらバグが発見できませんでした」だと情報が少ない
テスト要求分析の例
- 何をテストしなければならないのかをきちんと洗い出すのがテスト要求分析の一側面
テストアーキテクチャ設計の例
- 導出したテスト観点から関連性を見出してテストフレームを定義したり、
- 複数のテスト観点やテストフレームをまとめてテストコンテナを作ったり
- 例えば、相互互換性のテストではOSとかブラウザとかのテストフレームがあり、それをまとめて「相互互換性」とするのをテストコンテナを作る
- 「テストの十分性や妥当性の教えて欲しい」とよく言われる
テスト詳細設計の例
- 網羅基準とかコンテキストを元にテストケースを導出する
- これらのプロセスの最後で初めてテスト設計技法が使われる
2.ロールモデルを見出す
大まかな志向の方向性を意識しよう
- ロールモデルは会社の人事制度とも関わるが、大きく分けると以下の2つ
- 技術トラック
- マネジメントトラック
- 偉くなるためにはマネジメントトラックしかない会社の場合、自分がパイオニアになって技術トラックの方向性を作る必要がある
ISTQBより
- Agile
- Core
- Specialist
具体的にイメージできる憧れの人を持とう
- 可能であれば社内の人
- コミュニケーションが取りやすいから
- 走り出したばかりの人が「俺は海賊王になる！」と言ったら…
- →どうやって？実現性が分からない
自分の志向する方向性を探してみよう
- セルフデベロップメントプランを作ってみよう
- どうやって極みを目指すか？
- 目指すべき理想の姿において、1年後の自分・10年後の自分…などを具体的に描いてみよう
- ある時点での姿に対して、「どのような姿か」「その姿になるためにはどうすればよいか？」を書いてみる
- どんどん具体的に落とし込むことで、今の姿に近づいていく（半年後→1ヶ月後→2週間後）
- 自分自身で壁を作って成長を限ってはいけない
- そんな壁は壊してしまえ
3.成長へのモチベーションを持ち続ける
- 成長が目に見える形で測れて実感できることが大事
- 既存のツールを使ってみたり…
- テストにおいてはTest.SSF(Skill standard Framework)があったりする
- テストに限らなければITSSとかETSSとか。
- テストの全体観が無いとそもそも測れない
- 資格試験も自分の成長を感じられる一つの尺度
- ただ、単調に行い続けるのが大変
ぜひ社外に飛び出してみよう！
- 社外活動による知見・刺激は多いはず
- JaSST
- WACATE
- SQiP
- テスト設計コンテスト
- いずれは参加者から運営側になろう
- 社外活動に関わると今まで得られなかった情報量が増える
- そのまま社内に適用するとうまくいかなくなる
- うちの会社の人は分かってねぇ！という麻疹になったりする
- 「そうじゃないんだよ」と諭してあげよう
感想
- 「テストの全体観」ってどれだけの人が持っているんだろう…？
- 成長へのモチベーションとして書かれている「社外に飛び出す」のきっかけの作り方（与え方）が難しいなと感じた。
- 理想のテスターがもっともっと出てきてほしい！
