テストの考え方＆テスト最適化の話 How to think of testing

by Matsu

Slide 1

Slide 1 text

テストの考え方＆テストの最適化の話

Slide 2

Slide 2 text

自己紹介松谷峰生（まつやみねお）株式会社LIFULL テクノロジー本部/技術開発部/品質改善推進ユニット/QAグループ社外活動 • テスト • JaSST Kyushu(ソフトウェアテストシンポジウム九州)共同実行委員長 • 機械学習方面 • QA4AI コンソーシアム発起人の一人 • マンガ・イラスト • 新人さんからわかるソフトウェアテスト解説マンガ「テスターちゃん」 • IVIA（IT検証産業協会）キャラクターイラスト • 他ソフトウェアテスト系マンガ、イラスト • 他 • 大学の授業（非常勤講師 / 特別講師）

Slide 3

Slide 3 text

この発表の目的テストって何だっけの再考来週から「テストどうしようね」と考え始める

Slide 4

Slide 4 text

テストって何？

Slide 5

Slide 5 text

テストって何？ソフトウェアテストとは想定したことが想定した通り動くことをチェックする活動である

Slide 6

Slide 6 text

テストって何？だけではない

Slide 7

Slide 7 text

テストって何？テストによってそのシステムに何らかの価値を付加するならば

Slide 8

Slide 8 text

テストって何？品質・信頼性の向上

Slide 9

Slide 9 text

テストって何？信頼性はバグを見つけ取り除くことでより向上させることができる

Slide 10

Slide 10 text

テストって何？ソフトウェアテストはバグを見つけるつもりでプログラムを実行する過程 G.J.マイヤーズ「ソフトウェア・テストの技法第2版」より

Slide 11

Slide 11 text

テストって何？想定した通り動くか確認想定外の問題を発見＋チェッキングテスティング

Slide 12

Slide 12 text

http://www.jasst.jp/symposium/jasst18kyushu/pdf/S6.pdf

Slide 13

Slide 13 text

テストって何？チェッキング機械的なチェックが比較的容易人によるテストが必要テスティング＋

Slide 14

Slide 14 text

テストって何？チェッキング出来る限り自動的なテストが望ましいマニュアルテストでなければ難しいテスティング＋

Slide 15

Slide 15 text

よくあるテストのありかた

Slide 16

Slide 16 text

よく言われる形ユニットテスト APIレイヤーのテスト ←end to endテストマニュアルテストテストのピラミッドコスト高テスト実行時間長さテスト範囲の広さテストの実行数

Slide 17

Slide 17 text

現実 ←ユニットテスト ←APIレイヤーのテストマニュアルテストアジャイル開発に耐えられないプロセステストが多すぎて間に合わない

Slide 18

Slide 18 text

現実と破綻プロジェクトの破綻

Slide 19

Slide 19 text

よくある原因ユニットテストなんて書かなくても最後に全部通してみるからいいや… テストはテスト側のお仕事だよね（テストを別組織/外部に渡している組織）ユニットテストもAPIレイヤーのテストもしているけど最後のテストで前工程のテスト関係なしに全部見てる

Slide 20

Slide 20 text

よくある原因「全体としてのテスト最適化」に考えが及んでいない

Slide 21

Slide 21 text

よくある原因プロダクトの全体的なテストをどうすればいいかみんなで相談していますか？

Slide 22

Slide 22 text

じゃあ、どうしよう？の例何も考えずテストするではなく「どうテストしていこう」をちょっと考える時間を作る機能追加でも、新規開発でも、いったんプロダクト全体を見まわして「何を、どの段階で、どうテストしよう」ということを考える。この機能のこの部分はユニットテストで、ここはAPIのレスポンスで、ここはE2Eの自動化を回して保守して、どうしても手でしかできないこれはマニュアルテスト……など

Slide 23

Slide 23 text

松谷の理想論、テストポリシーテスティング、どうしても手でしか見れない場所、回帰テスト APIレイヤーでのチェッキングユニットテストでのチェッキング各レイヤーで行うべきテストが考慮されているバランスタイプ

Slide 24

Slide 24 text

松谷の理想論、テストポリシーユニットテストでのチェッキング • テスティング • どうしても手でしか見れない場所 • 回帰テスト振る舞いを APIレイヤーでチェッキング

Slide 25

Slide 25 text

The Testing Trophy

Slide 26

Slide 26 text

そんなことできるの？そんな仰々しいことしてる時間なんかない！ウォーターフォールでしょそれアジャイルだと回らないよね

Slide 27

Slide 27 text

実際の取り組み例

Slide 28

Slide 28 text

60分でテスト計画作成テスト計画＝仰々しくて重い、は思い込み

Slide 29

Slide 29 text

テスト計画コンシェルジュ ※弊社では、ユニットテストもマニュアルテストも開発者が実施 QAは「コンサルタント」の立ち位置 • 60分のミーティングでテスト計画（テストどうします？）を作成するスケジュールではなく、テスト範囲の明確化、テストアプローチの合意までを行う状況変化があったときは都度柔軟に組み替え • 品質を効率よく高めるためにテストのトータルコーディネートを行う「デザイン段階でユーザビリティのチェックを入れてはどうですか」「このテストにはマニュアルテストよりもE2Eによる自動化が良さそうです」「パフォーマンス劣化のリスクがありそうです」「セキュリティテストが必要です」 • QAとプロジェクトチームが話し合って、互いに腹落ちするテストアプローチやリスクを定義する

Slide 30

Slide 30 text

テスト計画コンシェルジュ簡単にいうとみんなと話す時間を設けて、プロダクト全体のテストの段取りをする

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

最後にもろもろ • テスト計画は変わるものであると周知。状況で柔軟に変更必須 • 最初に話し合っていると「あれも必要これも必要」となるが、大体開発は押す！よって後半のスケジュールは基本ピンチになると思ってよい。「この辺は探索的テストで押さえましょう」といった変更プランは用意しておく。 • 最近は「松竹梅」プランを作っていた。最初は松プランだったけれど、最後にはやはり梅プランになった。 • 闇雲にユニットテストを増やすといつもどこかでユニットテストがコケる事態が発生する • 修正するコストも増える

Slide 34

Slide 34 text

この発表の目的テストって何だっけの再考来週から「テストどうしようね」とつい考えちゃう

Slide 35

Slide 35 text

Thank you