JSTQBに出るかもしれない個人的偏見のある適当単語集

ITソリューション事業部 第1開発部の塚本です。

夏の湿気を、さらなるねっちょりしたベースの音で
よくわからなくしてしまうのはいかがでしょうか？
毒をもって毒を制す的な感じですね。。。

このおっさん、星型のサングラス、星型のベース（曰くスペースベース）って
どんだけ星が好きなんや？
うちの子が手放しで喜びそう（星好き）

Play With Bootsy／Bootsy Collins

今日はJSTQBに出るかもしれない個人的偏見のある適当単語集です。

探索的テスト
テストを実施しながら、テストやシステムの情報を駆使して新しいテストを設計して実施する。
テストを実施する人が、次はどんなことをしようかと考えながらする感じ
テストケースを書く手間はないので、わりとゲーム感覚で楽しい
経験値がたくさんある、または勘のいいひとはこれで結構バグを見つけられる
でもまあ、しっかり設計して構築したテストケースは基本的には必須

エラー推測
エンジニアは、こんな考慮漏れしそうだな、こんなミスしそうだなと考えてテストを作る
過去の経験が多いほうがものをいう気がする(過去の経験を生かせる勘の良さと記憶力も）
バグの経験だけでなく、バグが起こった原因も把握していると
さらにいいエラー推測ができると個人的に思うので
エンジニアさんはQAさんにバグの原因も
めんどくさがらずしっかり伝えてあげてほしいと思う

テスト計画
そのままテストの計画。何をテストするのか？何と連携しているのか？誰が責任者なのか？
テストの開始、終了基準はどこか？何人くらいテストする人がいるのか？
どんな課題、リスクがあるのか？などなどを記載する
頑張って書いてもあまり見てもらえないことが多いイメージ

テストスクリプト
自動化のスクリプトを指すけど、テスト仕様書自体も指してるとは言うが
基本的には自動化のスクリプトですよね

テストレベル
段階ごとのテスト
受け入れ　AT→　ユーザー目線で機能、非機能テストする
システム　ST→　システム全体の機能、非機能テストする
統合(結合)　IT　→モジュール、クラス間のテスト。内部的な結合テストと外部的な結合テストがあると個人的に思うんだが
単体　UT　→モジュール、クラス単体のテスト

動的テスト
ソフトを実行してするテスト⇔静的テスト
動的テストより静的テストをしっかりしてほしいといつも思います（要するにレビュー）

境界値
同じ結果になる値で分割して、テストをする
仕様上境界値がない場合は境界値を確認、追加するように進言したほうがいいと個人的に思う。

また機会があれば

今期は異世界おじさんが面白いとおもうけど、
30代以上じゃないとよくわからないのではないかと気になる？