進め方と気づいたこと
テストの話original 2010/06 Yonezawa
remix 2016/01
About me
約4年前に転職してきた
Programmer
所属
東京ボルダリング部
とちぎ水泳部
agenda
自分たちのテスト
テストで気づいたこと
development
分割
優先順位
目標
反復
分割
開発アイテムをStoryという小さい単位に分割。
2、3日で終わるような作業
優先順位
だいじなところ、みたいところから作る
目標
Storyにはかならず、作業した内容を検証できるゴール(テスト)を用意する
反復各Storyは関連しながら、欲しいもの作りあげる
日々、バージョンアップ
storyとは
ゴール
開発日記
テスト
テスト履歴
1日、1イテレーション(1week)という『枠』を意識しながら、開発を
進めている。
Let’s Testing
テストの進め方
Storyが終わったら...
Story is “done”
受け入れ試験
専属テスター
into the “Test suit”
テストを分類
バージョン、機能
Test Environment
複数OS
Daily Build
Test Planning
毎朝、計画を決める
今週コミットされたもの
注目している機能
関係なさそうな機能
Tester
開発者がテスターになる
毎日、1人x1時間x7コマ
計画されたテストケース
Find Bugs
バグが見つかったら?
騒ぐ、褒める
良かったと言う
Storyを作る
everyday
テストをとめない
毎日ずっとやる
detection
テストケースの重なり
テストに必要な属性
Overlap
Storyを重ねて行くことで少しずつ『機能』が増えていく
自分たちの作りたい機能が少しずつ、多くの『テストケース』とともに作成されていく
テストケースの重複 =
1つの機能においての様々な検証
Attribute
テスターもさまざま
自分たちのチームで発見した4タイプのテスター
monkeyランダム試験が得意
仕様は気にしない
連打系、スキマを狙うなど一見、嫌がらせみたいな試験をする
developer試験する機能の仕様をよく知っている
正常系を見がちだけど、作りたいものが実現できているかを確認できる
master?仕様はあまり知らないけど、プログラムの構造など、実現方法がみえている
不具合になりやすいケースがないかを試験できる
QA?いままでの不具合を覚えている
試験から以前と同じ状況の不具合がないかを試験できる
だれかが、どれかの属性のテスターではない
テストを行う箇所や、テストの目的によって、属性が変わってくる
テスト計画や、開発の進め方を工夫することで、いろんな視点からの試験を行える。
テストは開発の『物差し』
どこまでつくったか?
なにが基準なのか?
テスターにも多様性を
様々な視点や目的が必要