「JSTQB2018対応」を読んでみて
ピックル彩乃P49
「テストスイート」よくわからんかったけど、この記事読んだら理解できた
=作成したテストケースを、効率良く連続的にテスト実行できるように並び替えを行うこと
そりゃそうだろ！っていう概念だけど、案外抜けちゃいそうだと思った
テストスイートを行うことは完全に正解かって言ったら、別にそうではないらしい
品質保証で何に重きを置くかで、組み合わせは変わる
ピックル彩乃P41
「テストベース」= テスト対象に関するあらゆる情報（テストの基となるのでテストベース）
本に挙げられてた一部
- 機能要件や非機能要件
- 構成や構造
- ソフトウェアの設計情報
- RFP（提案依頼書）
- 企画書
- 購買仕様書
- ユースケースやユーザーストーリー（発注者やユーザーの視点で記されたドキュメント）
- 要求仕様書
- リスク分析レポート
- 設計仕様書
- インターフェース仕様書
etc..対象物は沢山！！
確かに、実務でもそのタスクの要望＋その要望が生まれた背景、要望から策定された仕様までに考えられてきた数多のSlackのやり取りなどの情報、遺失物に関する法律に関する条件とか色々、総動員してまとめてテスト設計考えていたりするから確かにテストベースだわ・・
ピックル彩乃「故障」「欠陥」「不正」の用語
P22、52を読んでみてJSTQBが定義するそれぞれの用語の意味は以下と推測する
-
故障（failure）：欠陥のあるプログラムを実行した時に、実行すべきこと（または、実行すべきでないこと）が期待通りではなく、その不正な結果がコンポーネントやシステムの問題であった場合のその結果
-
欠陥（Defect）：バグ、フォールト。
作業成果物に存在する、要件または仕様を満たさない不備または欠点のことで、故障が発生する時は欠陥が存在する。欠陥があるから故障が発生する。 -
不正：期待通りではないテスト結果のこと。この中に故障を含める。
故障じゃないやつは、例えばテストケースの期待値をミスって記載したとかのテストウェアの欠陥とか。
ピックル彩乃P52
故障や欠陥を見つけた場合に作成する成果物
「欠陥レポート」「不具合報告書」「バグレポート」「問題点処理票」など組織によって言い方はバラバラ
うちの会社では、タスクとしてテンプレートを使って起票してもらっている
起票者によって、情報量がバラバラになるので、起票してもらう際に確認してもらう事項をまとめた方が良いかもなー
検討memo
- 事象が発生するパターンはそのパターンだけなのか？を色々試してみた結果を記載してもらう
- 似たような機能を持つ画面では再現するか（例えばCSV取り込みでデータを登録するみたいな機能でバグが発生した場合、他画面におけるCSV取り込み機能はどうなっているか？）
- 他の端末でも再現できるか？（スマホ（Android、iPhone）やタブレット）
- 他のブラウザでも再現できるか？
ピックル彩乃P52
「ブロック」
テスト実行が、外部要因のせいで阻まれているテストケースのこと
例１）不合格だったテストケースと同じ手順であるため、
テスト実行しても不合格であることが予めわかっているテストケース
テスターとしてアルバイトしてた時、これ結構あったな、、
「ブロック」じゃなくて普通に「NG」って読んでたな🧐
例２）テスト環境が揃わないので実行できないテストケース
テスト端末の順番待ちとか〜
ライセンスの付与待ちとか〜
ピックル彩乃只の呟き
テストケース（特にリグレッションテスト）を、
容易に動画にまとめるツールとかないかな〜
文字入れたら良いけど、編集めんどいかな〜