Slide 1
Slide 1 text
テストコードを
書き始める前に
考えるべきテストの話
ブロッコリー( @nihonbuson )
https://www.pexels.com/photo/man-wearing-black-and-white-stripe-shirt-looking-at-white-printer-papers-on-the-wall-212286/
Slide 2
Slide 2 text
自己紹介
● 株式会社ビズリーチ
○ QA基盤推進室
○ QA Evangelistチーム
● 社外活動
○ WACATE実行委員
○ JaSST Review 実行委員長
○ ASTER正会員
○ Agile Testing Fellow会員
■ https://agiletestingfellow.com/
↓Twitterアイコン
風間 裕也(@nihonbuson)
Slide 3
Slide 3 text
アジェンダ
はじめに
テストの目的
何をテストすべきか
どうやってテストケースを作るのか
どうやって「ともにつくる」のか
おまけ
Slide 4
Slide 4 text
はじめに
https://www.pexels.com/photo/young-game-match-kids-2923/
Slide 5
Slide 5 text
この発表の注意事項
● テストの話にかける時間数
○ 社内の新人研修…丸2日
○ デブサミ …45分
● 本来話したい内容の1/15程度しかありません！
● もっと詳しく話を聞きたい方、
今日参加してない人にも伝えたい方、
講演後、お気軽に話しかけてください！
Slide 6
Slide 6 text
この発表の注意事項
● 話さない内容
○ テストコードの書き方
○ TDDのやり方
○ 自動テストの設計方法
● 話す内容
○ テストの目的とは何か
○ テストファーストで行うことの本当の良さ
○ 何をテストすれば良いのか
Slide 7
Slide 7 text
こんな経験していませんか？
開発はできたけど、
テストをどうやれば良いのか
分からないよ…。
リリースしてから
トラブルがいっぱい
起きるなぁ…
Slide 8
Slide 8 text
こんな経験していませんか？
開発はできたけど、
テストをどうやれば良いのか
分からないよ…。
リリースしてから
トラブルがいっぱい
起きるなぁ…
品質やテストのことを学べば
解決できるかもしれない︕
Slide 9
Slide 9 text
今日話す内容は…
QA（Quality Assurance＝品質保証）
チームはどういう動きをするか
Slide 10
Slide 10 text
今日話す内容は…
QA（Quality Assurance＝品質保証）
チームはどういう動きをするか
↓
開発者はどんなことをすべきか
Slide 11
Slide 11 text
アンケート
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
テストの目的
https://jp.freeimages.com/photo/on-target-1504936
Slide 15
Slide 15 text
テストの目的とは何か？
欠陥の検出
対象ソフトウェアの品質レベルが十分であることの確認
意思決定のための情報の提示
欠陥の作り込みの防止
実装前に行うこともある
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版
Version 2011.J02より
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
TDDでの検知、リリース判断、ユーザーの利用判断など…
テストの7原則①テストは「⽋陥がある」ことしか⽰せない
Slide 16
Slide 16 text
なぜ実装前にテスト・レビューをするのか
仕様誤りの修正コスト
要求仕様 設計 実装 テスト リリース後
1倍
5倍
10倍
20倍
200倍！
出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社
Slide 17
Slide 17 text
なぜ実装前にテスト・レビューをするのか
仕様誤りの修正コスト
要求仕様 設計 実装 テスト リリース後
1倍
5倍
10倍
20倍
200倍！
出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社
修正コストを下げるには…(1)
素早くリリースしてフィードバックをもらい、
すぐに修正できる体制にする
Slide 18
Slide 18 text
なぜ実装前にテスト・レビューをするのか
仕様誤りの修正コスト
要求仕様 設計 実装 テスト リリース後
1倍
5倍
10倍
20倍
200倍！
出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社
修正コストを下げるには…(2)
早い段階で不具合を発見する
Slide 19
Slide 19 text
何をテストすべき
か
https://jp.freeimages.com/photo/target-1306247
Slide 20
Slide 20 text
例題
● パスワードは4文字以上12文字以下の
英数字のみを許容する。
● パスワードを3分以内に4回以上
間違って入力すると、
アカウントを5分間ロックする。
http://www.slideshare.net/takashiyamasaki378/ss-55384920 https://www.pexels.com/photo/man-in-brown-shirt-writing-on-
notebook-3202028/
Slide 21
Slide 21 text
例題
http://www.slideshare.net/takashiyamasaki378/ss-55384920
あなたが考えた
● テスト内容
● 気になった内容
● 起こりそうなバグ
をどこかにメモして
ください。
● パスワードは4文字以上12文字以下の
英数字のみを許容する。
● パスワードを3分以内に4回以上
間違って入力すると、
アカウントを5分間ロックする。
https://www.pexels.com/photo/man-in-brown-shirt-writing-on-
notebook-3202028/
Slide 22
Slide 22 text
例題
● 2人組を作ってください。
● お互いに何を書いたのか
説明してください。
https://www.pexels.com/photo/man-working-on-laptop-while-woman-takes-notes-3153199/
Slide 23
Slide 23 text
回答例
パスワードは4文字以上12文字以下の
英数字のみを許容する。
パスワードを3分以内に4回以上間違って入力すると、
アカウントを5分間 ロックする。
文字列長
文字種
誤入力期間 誤入力回数
ロック保持期間 状態遷移
Slide 24
Slide 24 text
回答例
パスワードは4文字以上12文字以下の
英数字のみを許容する。
パスワードを3分以内に4回以上間違って入力すると、
アカウントを5分間 ロックする。
文字列長
文字種
誤入力期間 誤入力回数
ロック保持期間 状態遷移
許容しないとどうなる？
（ボタン制御orエラー画面）
5回目の入力はどうなる？
Slide 25
Slide 25 text
設計・開発時点
Slide 26
Slide 26 text
テスト時点
Slide 27
Slide 27 text
テスト時点
追加コストが発生！
Slide 28
Slide 28 text
回答例
パスワードは4文字以上12文字以下の
英数字のみを許容する。
パスワードを3分以内に4回以上間違って入力すると、
アカウントを5分間 ロックする。
文字列長
文字種
誤入力期間 誤入力回数
ロック保持期間 状態遷移
許容しないとどうなる？
（ボタン制御orエラー画面）
5回目の入力はどうなる？
Slide 29
Slide 29 text
伝えたいこと
● 隣の人はあなたが気づかなかったことを
知っていませんでしたか？
○ お互いにテスト内容についても議論しましょう！
Slide 30
Slide 30 text
伝えたいこと
● 隣の人はあなたが気づかなかったことを
知っていませんでしたか？
○ お互いにテスト内容についても議論しましょう！
● この例では1文字もプログラムを書いていません！
○ 実装前にテストすることができる例です。
○ もしもこの時点で指摘できれば
総コストは削減できるでしょう。
■ 今回の場合、「許容する」をこの時点で
話し合うと、ほぼ不具合が発生しません。
Slide 31
Slide 31 text
テストの目的とは何か？（再掲）
欠陥の検出
対象ソフトウェアの品質レベルが十分であることの確認
意思決定のための情報の提示
欠陥の作り込みの防止
実装前に行うこともある
ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02より
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14
TDDでの検知、リリース判断、ユーザーの利用判断など…
Slide 32
Slide 32 text
なぜ実装前にテスト・レビューをするのか（再掲）
仕様誤りの修正コスト
要求仕様 設計 実装 テスト リリース後
1倍
5倍
10倍
20倍
200倍！
出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社
修正コストを下げるには…(2)
早い段階で不具合を発見する
Slide 33
Slide 33 text
どうやって
テストケースを
作るのか
https://jp.freeimages.com/photo/check-list-1150080
Slide 34
Slide 34 text
例題：テストケースはいくつ？
パスワードは4文字以上12文字以下
1文字、2文字、3文字…100文字
テストの7原則②全数テストは不可能
膨大な数の
テストケース
Slide 35
Slide 35 text
テストケース作成の心得
テストケース作成者「○○○のテストをします！」
司会者「ほぉ～、それはどうしてだい？」
テストケース作成者「【理由を一言】」
Slide 36
Slide 36 text
境界値分析で考える
12
4
有効
無効 無効
3 13
Slide 37
Slide 37 text
境界値分析で考える
「パスワードが4文字以上12文字以下」で
なぜ3,4,12,13をテストするのか？
if( x < 3 ){
return “入力したパスワードが短いです”;
}
Slide 38
Slide 38 text
境界値分析で考える
「パスワードが4文字以上12文字以下」で
なぜ3,4,12,13をテストするのか？
if( x < 3 ){
return “入力したパスワードが短いです”;
}
上記の例で、不等号のミスによる不具合を
発見できるのは、3の時だけ！
Slide 39
Slide 39 text
カバレッジは100%だけど…
public boolean judge (int x) {
if( x < 3 ){
return false;
} else if( x > 13 ){
return false;
}
return true;
}
@Test
public void test_short_password{
assertThat( judge(2), is(false));
}
@Test
public void test_long_password{
assertThat( judge(15), is(false));
}
@Test
public void test_valid_password{
assertThat( judge(7), is(true));
}
Slide 40
Slide 40 text
カバレッジは100%だけど…
public boolean judge (int x) {
if( x < 3 ){
return false;
} else if( x > 13 ){
return false;
}
return true;
}
@Test
public void test_short_password{
assertThat( judge(2), is(false));
}
@Test
public void test_long_password{
assertThat( judge(15), is(false));
}
@Test
public void test_valid_password{
assertThat( judge(7), is(true));
}
Slide 41
Slide 41 text
カバレッジは100%だけど…
public boolean judge (int x) {
if( x < 3 ){
return false;
} else if( x > 13 ){
return false;
}
return true;
}
@Test
public void test_short_password{
assertThat( judge(2), is(false));
}
@Test
public void test_long_password{
assertThat( judge(15), is(false));
}
@Test
public void test_valid_password{
assertThat( judge(7), is(true));
}
Slide 42
Slide 42 text
カバレッジは100%だけど…
public boolean judge (int x) {
if( x < 3 ){
return false;
} else if( x > 13 ){
return false;
}
return true;
}
@Test
public void test_short_password{
assertThat( judge(2), is(false));
}
@Test
public void test_long_password{
assertThat( judge(15), is(false));
}
@Test
public void test_valid_password{
assertThat( judge(7), is(true));
}
Slide 43
Slide 43 text
カバレッジは100%だけど…
public boolean judge (int x) {
if( x < 3 ){
return false;
} else if( x > 13 ){
return false;
}
return true;
}
@Test
public void test_short_password{
assertThat( judge(2), is(false));
}
@Test
public void test_long_password{
assertThat( judge(15), is(false));
}
@Test
public void test_valid_password{
assertThat( judge(7), is(true));
}
Slide 44
Slide 44 text
欠陥は局所的に発生する
テストの7原則④欠陥の偏在
12
4
有効
無効 無効
3 13
Slide 45
Slide 45 text
もう1箇所テストできるならば…
テストの7原則④欠陥の偏在
12
4
有効
無効 無効
3 13
Slide 46
Slide 46 text
0文字はnull処理などの可能性がある
テストの7原則④欠陥の偏在
12
4
有効
無効 無効
3 13
0
Slide 47
Slide 47 text
テストケース作成の心得（再掲）
テストケース作成者「○○○のテストをします！」
司会者「ほぉ～、それはどうしてだい？」
テストケース作成者「【理由を一言】」
Slide 48
Slide 48 text
テスト実施の前にも段階的に行う内容がある
http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65
Slide 49
Slide 49 text
テスト実施の前にも段階的に行う内容がある
http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65
パスワードの例題
Slide 50
Slide 50 text
テスト実施の前にも段階的に行う内容がある
http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65
境界値分析の例
Slide 51
Slide 51 text
どうやって
「ともにつくる」のか
https://www.pexels.com/photo/woman-in-black-coat-1181346/
Slide 52
Slide 52 text
QAチームは何をするの？
これだけテストが充実できれば
QAチームは必要ないのでは？
Slide 53
Slide 53 text
QAチームは何をするの？
これだけテストが充実できれば
QAチームは必要ないのでは？
→まだまだ必要なことが多いです。QAは
1. システムテストレベルを見たい！
2. CheckingではなくTestingを行いたい！
3. テスト以外も行いたい！
※QAチームが無い場合、誰かor全員が担うべき
Slide 54
Slide 54 text
QAチームはシステムテストレベルを見たい！
● 単体テスト
○ 商品の個数欄にマイナス値は入力できない
● 結合テスト
○ カートに3個入っていて、2個追加したら、
確認ページで5個になった。
● システムテスト
○ 会員登録→商品購入→商品キャンセル→退会の
一連の流れ
EC
サイト
の例
Slide 55
Slide 55 text
QAチームはシステムテストレベルを見たい！
● 単体テスト
○ 商品の個数欄にマイナス値は入力できない
● 結合テスト
○ カートに3個入っていて、2個追加したら、
確認ページで5個になった。
● システムテスト
○ 会員登録→商品購入→商品キャンセル→退会の
一連の流れ
QAチームは
ここをやりたい！
Slide 56
Slide 56 text
QAチームはシステムテストレベルを見たい！
● 単体テスト
○ 商品の個数欄にマイナス値は入力できない
● 結合テスト
○ カートに3個入っていて、2個追加したら、
確認ページで5個になった。
● システムテスト
○ 会員登録→商品購入→商品キャンセル→退会の
一連の流れ
開発者は
ここをやりきって！
Slide 57
Slide 57 text
QAチームはTestingをしたい！
https://www.infoq.com/jp/news/2009/12/testing-or-checking
Slide 58
Slide 58 text
QAチームはTestingをしたい！
https://www.infoq.com/jp/news/2009/12/testing-or-checking
Checking
意図通り動くか確認する作業
Testing
なんとかして製品を破壊する作業
Slide 59
Slide 59 text
QAチームはテスト以外も行いたい！
私の
経験
Slide 60
Slide 60 text
QAチームはテスト以外も行いたい！
Slide 61
Slide 61 text
Agile Testing Condensedの例
QA＝「Question Asker」という考え方
● 誰も質問しないと思う質問を定期的に出す
● 自由回答形式の質問もする
○ 隠れた仮定が明らかになる
○ 質問例
■ 実装しても問題解決できない可能性はあるか？
■ この機能の使用前にユーザーは何をするか？
■ その後、ユーザーは何をするか？
Slide 62
Slide 62 text
QAチームはテスト以外も行いたい！
Slide 63
Slide 63 text
GmailチームのTE(Test Engineer)の例
● 最初の数週間は話を聞くために費やし、
自分からは話しません。
● 私は最初の5分で抗生物質を処方する医者
のような人とは働きたくありません。
● 長年のうちに、もっとも強力な問いは
「なぜ？」だということを学びました。
話を聞く段階でもそこのところを聞きます。
（アンキットメータへのインタビューより）
Slide 64
Slide 64 text
QAチームはテスト以外も行いたい！
私の
経験
Slide 65
Slide 65 text
開発者とどのように「ともにつくる」のか
開発者に一番多く投げかける質問
● 「で、これで何をしたいんだっけ？」
● 「ごめん、ちゃんと理解できてないから、
この部分をもう一度説明してもらっていい？」
Slide 66
Slide 66 text
開発者とどのように「ともにつくる」のか
開発者に一番多く投げかける質問
● 「で、これで何をしたいんだっけ？」
○ HowからWhatに立ち返ることができる
● 「ごめん、ちゃんと理解できてないから、
この部分をもう一度説明してもらっていい？」
○ もっと詳しく説明してくれる
○ 抜けてるパターンを開発者自身が気付ける
Slide 67
Slide 67 text
「ともにつくる」を実現した例
Slide 68
Slide 68 text
モブプロ体験会のお題
● 題材は自動販売機
● Cucumber + JUnit
● 与えられた要求は下記の3つ
○ 100円硬貨を入れたら
入金額が100円になってほしい
○ 100円硬貨を入れた後に50円硬貨を入れたら
入金額が150円になってほしい
○ 1円硬貨は対応しないでほしい
Slide 69
Slide 69 text
モブプロ体験会の結果
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
public class VendingMachine {
int currentMoney = 0;
public void insertCoin(int money) {
if (money == 50 || money==100) {
currentMoney += money;
}
}
public int getCurrentMoney() {
return currentMoney;
}
}
Slide 70
Slide 70 text
テストシナリオをさらに改善する
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
Slide 71
Slide 71 text
テストシナリオをさらに改善する
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
すべてシナリオ名が
『⼊⾦額確認』になってますね。
同じ名前はどうかと思うので
変えたほうが良い気がしてます。
なるほど。
そしたらこんな感じですかね。
（テストシナリオを編集する）
Slide 72
Slide 72 text
テストシナリオをさらに改善する
Scenario: 1回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 2回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 使用不可の硬貨投入
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
すべてシナリオ名が
『⼊⾦額確認』になってますね。
同じ名前はどうかと思うので
変えたほうが良い気がしてます。
なるほど。
そしたらこんな感じですかね。
（テストシナリオを編集する）
Slide 73
Slide 73 text
テストシナリオをさらに改善する
Scenario: 1回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 2回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 使用不可の硬貨投入
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
なるほど。ちなみに、
2つ⽬のテストの意図って
なんですかね︖
コインを1回だけではなく、
2回投⼊した時にも
ちゃんと動くか確認したい
という意図です。
Slide 74
Slide 74 text
テストシナリオをさらに改善する
Scenario: 1回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 2回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 使用不可の硬貨投入
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
なるほどー。
そしたら『2回投⼊時』と
書いていますが、
3回⽬はどうなるのでしょうか︖
3回⽬は2回⽬と同じく、
加算されていく仕組みなので、
ロジック上は⼤丈夫です。
Slide 75
Slide 75 text
テストシナリオをさらに改善する
Scenario: 1回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 2回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 使用不可の硬貨投入
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
ということは、気にしているのは
2回投⼊の⾦額ではなく、
複数回の投⼊時の加算
なんですね。
あー、確かにそうですね。
（テストシナリオを編集する）
Slide 76
Slide 76 text
テストシナリオをさらに改善する
Scenario: 1回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 複数回投入時の入金加算額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 使用不可の硬貨投入
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
ということは、気にしているのは
2回投⼊の⾦額ではなく、
複数回の投⼊時の加算
なんですね。
あー、確かにそうですね。
（テストシナリオを編集する）
Slide 77
Slide 77 text
数年後、テストの意図が分かるのはどっち？
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 入金額確認
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
Scenario: 1回投入時の入金額確認
Given 自動販売機がある
When 100円を入金
Then 100円が入金されている
Scenario: 複数回投入時の入金加算額確認
Given 自動販売機がある
When 100円を入金
And 50円を入金
Then 150円が入金されている
Scenario: 使用不可の硬貨投入
Given 自動販売機がある
When 1円を入金
Then 0円が入金されている
Slide 78
Slide 78 text
テストコードのメンテナンスコストを低減する
Slide 79
Slide 79 text
「ともにつくる」の
追加の例
（時間が残っていれば）
https://jp.freeimages.com/photo/reading-1420126
Slide 80
Slide 80 text
例題：何個の選択肢をテストする？
都道府県の項目についてテストする場合、
どんな値を使ってテストしますか？
何個の選択肢をテストしますか？
Slide 81
Slide 81 text
テストケース作成の心得
テストケース作成者「○○○のテストをします！」
司会者「ほぉ～、それはどうしてだい？」
テストケース作成者「【理由を一言】」
Slide 82
Slide 82 text
答え(その1)
プルダウンの一番下の値を使う（沖縄県）
→最後の項目まで動くか確認したいから
Slide 83
Slide 83 text
答え(その2)
都・道・府・県の4つを使う
（東京都、北海道、大阪府、神奈川県）
→以下のように、印刷物に丸印を反映させる場合
都道府県それぞれの値でテストすべき
Slide 84
Slide 84 text
答え(その3)
文字数が3文字と4文字の選択肢を使う
（東京都、神奈川県）
→以下の確認画面のように、文字数による崩れを
見つけたい場合、文字数の違う値でテストすべき
Slide 85
Slide 85 text
答え(その4)
各地域の選択肢を使う
→例えば地域によって価格が異なる場合、
価格ごとにテストすべき
Slide 86
Slide 86 text
答え(その5)
すべての選択肢を行う
→switch文で分岐の場合、全選択肢をテストすべき
switch(area){
case “北海道”:
// 何らかの処理
break;
case “青森県”:
// 何らかの処理
break;
…
Slide 87
Slide 87 text
テストケース名にも役立つ
@Test
public void _青森県の場合{
}
@Test
public void _広島県の場合{
}
Slide 88
Slide 88 text
テストケース名にも役立つ
@Test
public void _青森県の場合{
}
@Test
public void _広島県の場合{
}
Slide 89
Slide 89 text
テストケース名にも役立つ
@Test
public void _東北地方の場合送料が1000円{
assertThat(calcShipingCost(“青森県”), is(1000));
}
@Test
public void _中国地方の場合送料が510円{
assertThat(calcShipingCost(“広島県”), is(510));
}
Slide 90
Slide 90 text
テストケース名にも役立つ
@Test
public void _東北地方の場合送料が1000円{
assertThat(calcShipingCost(“青森県”), is(1000));
}
@Test
public void _中国地方の場合送料が510円{
assertThat(calcShipingCost(“広島県”), is(510));
}
ハイレベルテストケース
ローレベルテストケース
Slide 91
Slide 91 text
追加で伝えたかったこと
ハイレベルテストケースを記載することで
メンテナンス性が高い状態を保つ
そのテストを行う理由をテストケース名にする
テスト作業ではなく、テスト活動をする
Slide 92
Slide 92 text
まとめ
https://jp.freeimages.com/photo/bright-sky-1393231
Slide 93
Slide 93 text
まとめ
テストの目的は欠陥の検出以外に
欠陥の未然防止がある
テストには実装開始前に行う活動もある
早期テスト活動でコストを削減できる
理由を考えながらテストを作成する
開発とコラボしてテスト活動する
やり方もある
Slide 94
Slide 94 text
テストの勉強方法
（時間があれば）
https://jp.freeimages.com/photo/reading-1420126
Slide 95
Slide 95 text
こんな質問が多い
どうやってテストの勉強を
すれば良いの︖
テストの勉強ができる
オススメの書籍が知りたい︕
Slide 96
Slide 96 text
「何をテストすべきか」でオススメの書籍
https://www.amazon.co.jp/dp/4297105063/
2019/4/13
改訂版発売！
Slide 97
Slide 97 text
「どうやってテストケースを作るのか」でオススメの書籍
2020/1/7発売！
https://www.amazon.co.jp/dp/4817193603 https://www.amazon.co.jp/dp/429711061X/
Slide 98
Slide 98 text
「どうやって『ともにつくる』のか」でオススメの書籍
https://www.amazon.co.jp/dp/B07YR4CC4B
2019/9/25完成！
（英語版のみ）
Slide 99
Slide 99 text
「どうやって『ともにつくる』のか」でオススメの書籍
https://www.amazon.co.jp/dp/B07YR4CC4B
2019/9/25完成！
（英語版のみ）
鋭意翻訳中！
Slide 100
Slide 100 text
アンケート
Slide 101
Slide 101 text
No content
Slide 102
Slide 102 text
最新のテスト情報収集ならJaSSTがオススメ！
● 日本最大級のテストのイベント
○ JaSST'19 Tokyoは2日間で1600名が参加
● 年に10回、各地で開催
● 2018年から新たにJaSST Reviewも開催
○ 実行委員長は私
http://www.jasst.jp/
Slide 103
Slide 103 text
テストを実践して学ぶならWACATEがオススメ！
● 1泊2日のワークショップ形式のイベント
● 2007年初開催
● 半年に1度開催（6月と12月）
● 新卒1年目の開発・QAも多く参加
● 参加費は24,000円（35歳以上は27,000円）
https://wacate.jp/
Slide 104
Slide 104 text
もしも今回の話を同僚に伝えたい場合は…
● 本来話したい内容の1/15程度しかありません！
● もっと詳しく話を聞きたい方、
今日参加してない人にも伝えたい方、
講演後、お気軽に話しかけてください！
○ Ask the Speaker
○ 懇親会
○ Twitter : @nihonbuson
Slide 105
Slide 105 text
おしまい
https://jp.freeimages.com/photo/track-finish-1442273
Slide 106
Slide 106 text
参考文献：ソフトウェアテストの7原則
1.テストは欠陥があることは示せるが、
欠陥がないことは示せない
2.全数テストは不可能
3.早期テストで時間とコストを節約
4.欠陥の偏在
5.殺虫剤のパラドックスにご用心
6.テストは状況次第
7.「バグゼロ」の落とし穴
● ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03
○ http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf
Slide 107
Slide 107 text
使用デザイン
● スライドデザイン
○ Professional Google Slides Template
■ https://slidesmash.com/professional-google-slides-template/
● アイコン画像
○ Lynny Icon Set
■ https://dribbble.com/shots/1925069-Lynny-Icon-Set-Free