「JSTQB2018対応」を読んでみて
ピックル彩乃P49
「テストスイート」よくわからんかったけど、この記事読んだら理解できた
=作成したテストケースを、効率良く連続的にテスト実行できるように並び替えを行うこと
そりゃそうだろ！っていう概念だけど、案外抜けちゃいそうだと思った
テストスイートを行うことは完全に正解かって言ったら、別にそうではないらしい
品質保証で何に重きを置くかで、組み合わせは変わる
ピックル彩乃P41
「テストベース」= テスト対象に関するあらゆる情報（テストの基となるのでテストベース）
本に挙げられてた一部
- 機能要件や非機能要件
- 構成や構造
- ソフトウェアの設計情報
- RFP（提案依頼書）
- 企画書
- 購買仕様書
- ユースケースやユーザーストーリー（発注者やユーザーの視点で記されたドキュメント）
- 要求仕様書
- リスク分析レポート
- 設計仕様書
- インターフェース仕様書
etc..対象物は沢山！！
確かに、実務でもそのタスクの要望＋その要望が生まれた背景、要望から策定された仕様までに考えられてきた数多のSlackのやり取りなどの情報、遺失物に関する法律に関する条件とか色々、総動員してまとめてテスト設計考えていたりするから確かにテストベースだわ・・
ピックル彩乃「故障」「欠陥」「不正」の用語
P22、52を読んでみてJSTQBが定義するそれぞれの用語の意味は以下と推測する
-
故障（failure）：欠陥のあるプログラムを実行した時に、実行すべきこと（または、実行すべきでないこと）が期待通りではなく、その不正な結果がコンポーネントやシステムの問題であった場合のその結果
-
欠陥（Defect）：バグ、フォールト。
作業成果物に存在する、要件または仕様を満たさない不備または欠点のことで、故障が発生する時は欠陥が存在する。欠陥があるから故障が発生する。 -
不正：期待通りではないテスト結果のこと。この中に故障を含める。
故障じゃないやつは、例えばテストケースの期待値をミスって記載したとかのテストウェアの欠陥とか。
ピックル彩乃P52
故障や欠陥を見つけた場合に作成する成果物
「欠陥レポート」「不具合報告書」「バグレポート」「問題点処理票」など組織によって言い方はバラバラ
うちの会社では、タスクとしてテンプレートを使って起票してもらっている
起票者によって、情報量がバラバラになるので、起票してもらう際に確認してもらう事項をまとめた方が良いかもなー
検討memo
- 事象が発生するパターンはそのパターンだけなのか？を色々試してみた結果を記載してもらう
- 似たような機能を持つ画面では再現するか（例えばCSV取り込みでデータを登録するみたいな機能でバグが発生した場合、他画面におけるCSV取り込み機能はどうなっているか？）
- 他の端末でも再現できるか？（スマホ（Android、iPhone）やタブレット）
- 他のブラウザでも再現できるか？
ピックル彩乃P52
「ブロック」
テスト実行が、外部要因のせいで阻まれているテストケースのこと
例１）不合格だったテストケースと同じ手順であるため、
テスト実行しても不合格であることが予めわかっているテストケース
テスターとしてアルバイトしてた時、これ結構あったな、、
「ブロック」じゃなくて普通に「NG」って読んでたな🧐
例２）テスト環境が揃わないので実行できないテストケース
テスト端末の順番待ちとか〜
ライセンスの付与待ちとか〜
ピックル彩乃只の呟き
テストケース（特にリグレッションテスト）を、
容易に動画にまとめるツールとかないかな〜
文字入れたら良いけど、編集めんどいかな〜
ピックル彩乃P53
「コードカバレッジ」
以下ふた通りの解釈がある（人による）
- =「テストカバレッジ」=「網羅率」の解釈（テスト全体に対して今どれくらい確認終わっている？）
- ソースコード全体に対して何行分、確認が終わっているのでXX%確認が終わっている！とするやつ（ホワイトボックスの一つ）
- = 命令網羅率と捉えている人もいる
この記事、参考になった
特に、
ブランチカバレッジと判定カバレッジの違い
ブランチカバレッジとコンディションカバレッジの違いがわかりやすかった
1機能リリース（1バグ修正リリース）する際は、
コードを書いたエンジニアがコード差分からテスト設計を書くことを弊社では「差分テスト」と称しているけど、この差分テストは自分の場合は結構コンディションカバレッジを採用してるなーと思った
ピックル彩乃ポストモーテム（postmortem）
SREで使用されるビジネス用語
SRE：インフラ及び運用上の問題で、ソフトウェアエンジニアリングプラクティスを適用することで、拡張性が高く信頼性の高いソフトウェアを作成するためのエンジニアリング分野のこと
サービス運用時のシステム障害やデータの損失など、インシデントについてまとめた文書のこと
主に以下をまとめている
- 発生したインシデントについて
- そのインパクト
- 問題解決のために行われたアクション
- ユーザーへの影響
- 根本的原因
- 再発防止策 etc
上だけ見ると、障害報告書と一緒じゃね？って思ったけど、読者対象が異なるそう
障害報告書：上司・ユーザー
ポストモーテム：開発メンバー
JSTQB的にはポストモーテム=振り返り会という意味っぽい
この記事良かったので記載
- ダウンタイムが一定の閾値を超えた
- データの損失が生じた
- オンコールエンジニアの介入が必要だった
- 解決までに一定以上の時間を要した
ここら辺のレベルに達したら、社内でも取り組んでみたいなぁ
ポストモーテムみたいに1つの障害に対してじゃないけど、
1プロジェクト（1スプリント）に対して毎回終了間際にざっくばらんに反省会実施してアクションリスト作っているからこれに結構近いかもな（これの障害版だと私は解釈した）
書いてて思ったけど、日頃の差分テストで
発見されたバグチケットが、開発したエンジニアにこんなバグあったよ。コードはこうした方がいいかもみたいなFBあげれていないから良くないかも（？）
次、開発する時に改善が期待できそうかも
ただ、指摘すると怒っているみたいになるから知識として共有するスタイルがいい？
ピックル彩乃探索的テスト（Exploratory Testing）
テストを実行しつつ、その結果をFBすることで、新たなテスト項目を生み出す技法
ある程度の目的や方針を決めてから開始するテストなので、アドホックテスト（モンキーテスト）とは性質が異なる
※アドホックテストは、目的や方針を全く決めずに場当たりでテスト対象を操作していく技法
テストチャーター（テスト目的を沢山リストアップしたもの）を事前に用意する必要あり
メリット
- 事前にテスト計画やテスト設計を行わずにテストを始められるので、テスト工数が大きく削減できる（通常の記述式テストだと、テスト工程は全開発工数の30%を占めるのが一般的）
- 記述式テストでは想定できないバグを見つけることができる
デメリット - 結果が、テスターのスキルやシステムに対する理解度にだいぶ、依存する
- バグチケットがあがっても、テスト条件が本当に正しいか証明できない（正直、これはどのバグチケットにも言えることだけど、テストケースとして事前に記述していたらこの動きを行ったら発生した！という証拠になるけど、探索的テストはテストケースがないまま実行するからテスターが思い込み（？）勘違いで実施してしまうケースは十分有り得る）
探索的テスト自動化ツール（Eggplantなど）あり
個人的に、探索的テストはあまり魅力感じないな、、
品質を担保するって視点から考えると、スキル依存になるのは避けたいところ
記述式テストは勿論だけど、プラスαで目的を記述してそれに対して探索的テストやってていう二重構造でやった方がいい気がするな
思ったより、テストが早めに終わった時とかは、
探索的テストをお願いする形がいいかも？？テストチャーターの作成方法を学ばなきゃやな、、、
ピックル彩乃P68
ITガバナンス
（あるサイトより）ITの活用で、顧客・社員・株主に対する企業価値を最大化するための行動のこと
（経営産業省より）経営陣がステークホルダーのニーズに基づき、組織の価値を高めるために実践する行動で有り、情報システムのあるべき姿を示す情報システム戦略の策定及び実現に必要とする組織能力のこと
設問
テストベースとテスト作業成果物との間のトレーサビリティを維持することが
なぜ必要であるかを説明したものとして最も適切なものはどれか？
→「ITガバナンスの基準を満たすことができる」???
"情報システムのあるべき姿を示す情報システム戦略の策定及び実現に必要とする組織能力"をトレーサビリティを維持することで満たせるってこと？？？？
なんだろ、納得いきそうで納得いかない、、、
なんていうんだろ、範囲広くないか？？テストベースと作業成果物のトレーサビリティを維持することで情報システムのあるべき姿を実現するために必要な組織能力が満たせるって違うくないか？？？？
ピックル彩乃P71
テストの利点
- 欠陥情報は作業成果物の品質向上
- 欠陥情報は開発担当者のスキル向上
- 欠陥を見つけて修正すると時間と経費の節約になる
ピックル彩乃確証バイアス
開発担当者が影響を受けやすい
ソフトウェアの内部構造を熟知しているので、「自分自身で何度も繰り返して確認して実装したコードは正しい！！」と思い込んじゃうバイアスのこと
認知バイアス
コード読み込んでるんだから、テスターよりもそのソフトウェアを理解しているわかっている！と認知している場合に、テスターからの指摘に対して欠陥指摘を正しく受け入れられない、自分に対する非難として受け取ってしまう（バイアスになっちゃう）
ピックル彩乃やっと第1章読み終わった、、
ピックル彩乃イテレーティブ開発モデル
「イテレーティブ」：「反復的な」と言う意味
仕様化、設計、構築、テストというサイクルを何度も繰り返すのが特徴
1サイクルをイテレーション
-
RUP（ラショナル統一プロセス）
UMLを使って設計を行う
イテレーション期間は2〜3ヶ月 -
スクラム
イテレーション期間は数日から数週間（数時間ということも、、、！）
スクラムでは、イテレーションのことをスプリントと呼ぶ
スクラムでは、プロダクトオーナーやスクラムマスターなどの役割をきちんと明確化 -
カンバン
イテレーションは必須ではない -
スパイラル（プロトタイピング）
プロトタイピング：開発の初期段階でプロトタイプ（試作品）を作成し、ユーザーからのFBを基に仕様を確定した後で本番開発を行うソフトウェア開発方法論
このプロトタイプでフィーチャーを少しずつ追加することを繰り返していくのがスパイラル
イテレーションってリリースを含めないのかな？
自社は、1スプリントとしているけどリリースしちゃっているから厳密にはスクラムじゃないのかも？？？