Tweet
Tweet

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