文系でも極端にわかるテストと品質 v0.2 / Easy to understand testing and quality

ざっくりまとめる。

Transcript

1. 1 文系でも 極端にわかるテスト Dai Fujihara @daipresents Copyright © 1978-2019 Sekai Co., Ltd. All Rights Reserved. https://daipresents.com/service/
2. 注意事項 • 今は違うかもしれませんが、昔は文系と理系の間に確固た る溝があったように思います（気のせいかな） • わやりやすくするために極端に解説しています。正しさを求 める場合は専門家にご相談ください • 今回はテスト・品質について極端に説明しようと思います • その結果、なんとなく理解し、テストや品質に対する意思決 定の助けになれば幸いです
3. テストについて
4. テストとは？ 「テスト ＝ チェック ＋ α」とします • 「テスト」が単純な「チェック」を意味する場合は、バグがあるかないかを確認する単純作業です。 • 単純作業レベルのテストは、人によって多少の違いはあれど、誰がやっても似たような成果にな ります • 後述しますが、チェックをするだけでは、バグは減っていくかもしれませんが品質向上になりませ ん
5. テスト ＋ α とは？ 以下、αの例をあげてみます。全社はバグを見つけていますがOKに しており、後者はその逆の判断がされています。 • ここが変ですが、ユーザへの影響はとても小さいので無視してリ リースしていいと思います • 仕様どおりですが使い勝手が悪すぎるので修正するべきでしょう
6. テストの種類（上に行くほど粒度が小さい） テストしたいもの テスト目的と内容 プログラム ユニットテスト（UT)ともいう。プログラムが正しいことを確認をする。テストコードを書くのが一般 的。 機能 結合テスト（IT)、機能テスト（FT）とも呼ばれる。機能が正しいことを確認する。手動で確認されるこ とが多い。 全体 システムテスト（ST)、エンドツーエンドテスト（E2E）とも呼ばれる。仕様どおりにできていることを ユーザの利用環境目線で確認する 。手動がメインだが最近だとテストツールを使う事が多い。 仕様 受け入れテスト（UAT）と呼ばれる。作ったものが 当初の期待（要件）を満たせそうかを確認する 。 リグレッションテスト 機能が壊れていないことを確認する 。ざっくり一通りの機能をテストする形で構成することが多い。 機能テストや通しのテストは、機能が増えたり更新されるたびにここに追加していく運用がステキ。 パフォーマンス・脆弱性 特定領域を確認する。専門ツールでやるのが一般的。
7. テストの種類（上に行くほど粒度が小さい） テストしたいもの テスト目的と内容 プログラム ユニットテスト（UT)ともいう。プログラムが正しいことを確認をする。テストコードを書くのが一般 的。 機能 結合テスト（IT)、機能テスト（FT）とも呼ばれる。機能が正しいことを確認する。手動で確認されるこ とが多い。 全体 システムテスト（ST)、エンドツーエンドテスト（E2E）とも呼ばれる。仕様どおりにできていることを ユーザの利用環境目線で確認する 。手動がメインだが最近だとテストツールを使う事が多い。 仕様 受け入れテスト（UAT）と呼ばれる。作ったものが 当初の期待（要件）を満たせそうかを確認する 。 リグレッションテスト 機能が壊れていないことを確認する 。ざっくり一通りの機能をテストする形で構成することが多い。 機能テストや通しのテストは、機能が増えたり更新されるたびにここに追加していく運用がステキ。 パフォーマンス・脆弱性 特定領域を確認する。専門ツールでやるのが一般的。 分けると整理されますが、増えた分管理が面倒です。 分けないと量は減りますが、整理がしにくくなります。 まずは、担当ごとにシンプルに3つぐらいにわけてはどうでしょ う？ 例： 1. 開発のテスト（開発チーム） 2. 全体のテスト（テストベンダー） 3. 受け入れテスト（発注元）
8. テストの広さ • 戻ったり進んだり操作のパターン • 入れたり消したり入力・出力のパターン、 • プラットフォーム、OSごと（iOS、 Andorid、Windowsな ど） • ブラウザごと（Chrome、IEなど） • 状況（高負荷、弱電波、攻撃時） • ・・・・ ほぼ無限なので限られた時間で 何を、いつ、どこまで、だれがやるか決めましょう
9. 良いテスト・悪いテスト • 良いテストは ◦ サービスやプロダクトが実現したいことに 貢献できるテストです。 ◦ 限られた時間内で大きいバグから順番に 見つかるテストです • 上記の逆が悪いテストです
10. テストと人とお金 • テストの質はその人のスキルレベルに依存します • スキルレベル＝単価とはかぎりません。以下は実際にあった例です。 ◦ 例： 最初は外で発表したりしている有能そうな人が来たけど その後は業務中に居眠りする人がアサインされた ◦ 例： 単価は高いのに指示がないと動かない。お願いすると 「それは予算を超えるので追加で・・」と追加課金された ◦ 例： テストベンダーの管理コストが高くて仕事ができない 期待値を明確に伝え それを満たせるのか確認しましょう
11. 品質について
12. 品質とは、品質が高いとは？ • 利用者様： 使いやすくてまた使いたくなる • 営業の人の品質例： 売上が上がるサービスであること • 開発の品質例： たくさんのアクセスがあっても サービスが止まらないこと • 開発全体の品質例： リリース日にリリースできるものが リリースされること 人によって違うので それぞれ確認しておきましょう
13. 品質が高い・低い • 品質が低いのは良くありません • 品質が高いだけでもいいともかぎりません ◦ 例： 売上激増！ でも新機能リリースに膨大なコストが かかってしまう・・・ ◦ 例： バグゼロでリリース！ でもお客さんがぜんぜんこない・・・ ば・ら・ん・す（はーと）
14. バグとは？ • 「エラー」「欠陥」「フォールト」「故障」いろいろ呼び方があ ります 面倒なのでバグでいきましょう
15. バグが多い・少ない • 作れば作るほど、バグの数も増えがちです • バグがあるものを修正しても、品質が高くなったとは いえません ◦ 例： 車にバグがたくさんありましたが全部取り除 いたのでもう大丈夫です！ • バグが少なくても、ちゃんとテストしていない可能性が 残ります ば・ら・ん・す（はーと）
16. バグを活用した品質の確認方法 • 普通は、バグが 見つかったれば みつかるほど、 減っていくはず なので、その傾 向を活用して残 存するバグを推 定できます
17. CREDITS - Special Thank! ◦ Presentation template by SlidesCarnival and Photographs by Unsplash • Photo by Markus Winkler on Unsplash 17 お問い合わせは https://daipresents.com/service/ からお気軽にどうぞ。