はじめに
：当記事に示された意見はわたし個人のものであり、所属する組織を代表するものではありません。
概要
テストの観点について考えることが業務上あったので備忘録も兼ね記載する。
また他にもまとめている方がいたのでこちらのリンクも併せて記載。
大変参考になりました。
とはいえ人が書いてくれたリンクを張るだけだと記事として成り立たないので自分なりにテストについて考えてみる。
テストケースを起こすときなんかに見返すことのできる資料にしたい（願望）
テストとは
今更言うまでもないとは思うのだが誰が目を通すのかわからないので、テストとはから少し考えてみる。
「テスト」とシステム開発・修正などを行った際に、仕様（要求）通りできているかまたバグはないか？の確認をするものである。
テストフェーズはこちら
1. 単体テスト（Unit Testing）
目的: 個々の関数やメソッドなど、プログラムの最小単位をテストする。
対象: 関数、メソッド、クラス。
ツール: JUnit（Java）、PyTest（Python）、NUnit（.NET）など。
2. 結合テスト（Integration Testing）
目的: 複数の単体が正しく連携して動作することを確認する。
対象: モジュール間のインターフェースやデータフロー。
ツール: TestNG、JUnit、PyTestなど。
3. システムテスト（System Testing）
目的: システム全体が設計どおりに機能することを確認する。
対象: 完成したシステム。
ツール: Selenium、Appium、LoadRunnerなど。
4. 受け入れテスト（Acceptance Testing）
目的: システムがユーザーの要求や業務要件を満たしているかを確認する。
対象: ユーザーシナリオ、ビジネス要件。
ツール: Cucumber、FitNesse、Robot Frameworkなど。
5. 回帰テスト（Regression Testing）
目的: 新しい変更が既存の機能に影響を与えていないことを確認する。
対象: 変更が加えられた部分とその周辺。
ツール: Selenium、JUnit、PyTestなど。
6. パフォーマンステスト（Performance Testing）
目的: システムの速度、スケーラビリティ、安定性を確認する。
対象: 応答時間、スループット、リソース使用率。
ツール: JMeter、LoadRunner、Gatlingなど。
7. セキュリティテスト（Security Testing）
目的: システムのセキュリティ脆弱性を特定し、悪意のある攻撃から保護する。
対象: 認証、認可、データ保護。
ツール: OWASP ZAP、Burp Suite、Nessusなど。
8. ユーザビリティテスト（Usability Testing）
目的: ユーザーインターフェースが使いやすいかどうかを確認する。
対象: ユーザーインターフェース全般。
ツール: ヒューリスティック評価、ユーザーテスト、A/Bテスト。
9. コンフィグレーションテスト（Configuration Testing）
目的: ソフトウェアがさまざまな環境で正しく動作することを確認する。
対象: オペレーティングシステム、ブラウザ、ハードウェア構成。
ツール: VirtualBox、Docker、Selenium Gridなど。
10. インターフェイステスト（Interface Testing）
目的: システムのインターフェースが正しく動作することを確認する。
対象: API、GUI、通信プロトコル。
ツール: Postman、SoapUI、REST Assuredなど。
んで、基本的な考え方は「入力値が処理を介した結果、どうなった？」で考えられると思う。
イメージは以下の通り
んで、例えば入力Aに対して＋5した結果を返すプログラムがあるとしよう
public class MathUtils {
public static int addFive(int a) {
return a + 5;
}
}
※構造上問題だらけではあるけど（入力の方法だったり例外処理がなかったりツッコミどころはあるかもしれないけど）そこはいったん置いときます。
で今回のプログラムに対してテストケースを考えるわけです。
ケースとはどのような入力と期待する結果かを列挙するわけです。「入力値が処理を介した結果、どうなった？」の入力値とどうなった？の部分
入力値の例(一部)
- 数値
- 文字
- 空文字
- Null
次に入力に対する結果（期待値）を考えます。
- 数値を入力したとき結果は？
- 文字を入力したとき結果は？
- 空文字を入力したとき結果は？
- Nullを入力したとき結果は？
数値にフォーカスして話をすると入力Aを仮に3としましょう。プログラムを介した場合入力と期待値は以下のようになります。
- 入力値:3
- 期待値:8
他にもあるけど全部やったらきりがないのでここまでとします。
ここまでテストに関する基本的な考え方です。
テスト観点
だらだらと語ってきたけどではどのようなことを考慮すべきか？
もちろん修正や開発内容などによってはケースバイケースではあるけど、
大事な点はいくつかあるがその中でも「漏れなく被りなく」を意識することが大切。
テストケースの漏れ＝テスト未実施だからね
未実施は品質を上げるためにもなくすべき！
ケースを作成する際は、先人の知恵 をベースに自分のおこないたいケースに当てはめて考える。
自分の修正が入力系なら空文字やNullのケースはやらなきゃね！とかScript入れたらどうなるの？とか検証した方がいい気がする
あと発生しないことの証明は（エビデンスに）しずらい。
現場によっては動画でのエビデンスがOKの場合では動画を回し発生していないことを一連の流れで証明できるが、画像だけでは正直判断できないと思う（過去に画像でエビデンスとしたけど正直無意味だと思う！テストはちゃんとしたけど）
なのでテストケースとして作成する場合は「XXが発生しないこと」よりも「XXが表示されること」など誰もがそのエビデンスを見たときに確認しやすい内容で記載した方がテスト実施者や、確認者の視点からみても証明しやすいと思う。
ずらずら書いたけどまた思いついたら記載しますでは！