おはようございます。2023年のパチンコスロット収支は既に手遅れで穢れ蓄積MAX解放待ちなGMOリサーチのQAパチンカスエンジニアの本間です。
前回までの記事で、JSTQBのシラバスの1章の構成範囲①〜⑥について紹介いたしました。
前回の記事はこちら▼
「【試験対策法紹介】QAエンジニアがJSTQB認定テスト技術者資格について解説①」
「【試験対策法紹介】QAエンジニアがJSTQB認定テスト技術者資格について解説②」
今回は前回の続きとして「第2章-ソフトウェアライフサイクルを通じてのテスト」を通じてスマスロ北〇神拳の伝承者になるべく、現段階で最大天井の第6章までは行かずとも、このステージでは中段チェリー25％位の当選正答率まで上げて行けるかと思います。
まぁ各問題項目4択でひたすら1/4のヒキでもなんとかなるから、それで挑むもOK‼
誰だってそーする。俺だってそーする。
・・・(。´・ω・)おっと、誰か来たようだ。
「この髪型がサザエさんみたいだとぉぉ？！」←言ってない。
※JSTQB認定テスト技術者資格とは、日本におけるソフトウェアテスト技術者資格認定の運営組織であるJSTQB（Japan Software Testing Qualifications Board）により認定される、ソフトウェアテスト技術者資格のこと。当記事はJSTQB認定テスト技術者資格のうち、「JSTQB認定テスト技術者資格 Foundation Level（FL）」の話です。
■全体構成
第1章-テストの基礎
第2章-ソフトウェアライフサイクルを通じてのテスト ←今回の記事はこちらの内容です。
第3章-静的技法
第4章-テスト設計技法
第5章-テストのマネジメント
第6章-テスト支援ツール
■学習の目的/知識の認知レベル K1：記憶 / K2:理解 / K3：適用 / K4:分析
Foundation Level試験は「K1：記憶 / K2:理解」がメインとなっています。
JSTQB_FL試験の第２章-ソフトウェアライフサイクルを通じてのテスト（無想転生バトル94％継続）の解説
JSTQBのシラバスの2章構成に準じて、構成範囲の解説をしていきます。
なお、過去1章の記事については以下の過去記事をご確認ください。
「1章‐前半(ATパート)」JSTQB_FL試験の第１章「テストの基礎」を解説-Part1
「1章‐後半(バトルパート)」JSTQB_FL試験の第１章「テストの基礎」を解説-Part2
それでは、2章「ソフトウェアライフサイクルを通じてのテスト解説」に入ります！
ソフトウェア開発モデル
・JSTQB_FLでの「ソフトウェア開発モデル」のくだりは、以下3点を覚えておこう。
①V字モデル(シーケンシャル開発モデル)
②イテレーティブ-インクリメント開発モデル
③ライフサイクルモデルの中のテスト
★「V字モデル(シーケンシャル開発モデル)」の解説
V字モデル(シーケンシャル開発モデル)とは、要件仕様からメンテナンスまでのソフトウェア開発ライフサイクル活動を記述するための枠組みを指します。
テストには4つのレベルがあります。細かいことは後述「3」テストレベルで説明します。
この場では「テストレベル」という単語に遭遇したら、以下4つのレベルがあるという概念だけ覚えてくれればOKです。
１：コンポーネントテスト（ユニットテスト）
２：統合テスト
３：システムテスト
４：受け入れテスト
参考：「https://products.sint.co.jp/ober/blog/v-model」
★「イテレーティブ-インクリメント開発モデル」の解説
イテレーティブ・インクリメント開発モデルとは、システムの要件、テストを「何回かの短い開発サイクルでくり返して」ソフトウェアを作る開発モデルのこと。
＝スプリント開発、アジャイル開発的なこと同義！ってくらいの理解で良いです。
★「ライフサイクルモデルの中のテスト」の解説
各開発活動に対応してテスト活動がある。
開発ライフサイクルで、ドラフトのドキュメントを入手でき次第、テスト担当者はレビューを実施すべきである。
【よくあるミスリード】
問題の選択肢に「テスト担当者はレビューを実施すべきでない」と
転落ナビが発生する場合があるので、惑わされないように。
テストレベル
・JSTQBで定義する以下4つのテストレベルについて、詳細に解説していく。
①コンポーネントテスト(ユニットテスト)
②統合テスト
③システムテスト
④受け入れテスト
★「コンポーネントテスト(ユニットテスト)」の解説
【概要はこう!!】
「分離してテストが可能」
(ソフトウェア、モジュールなどの欠陥を摘出し、「機能の正しさを検証する」)
【つまりは？】
一般的には開発環境にて開発者を巻き込んで実施することが多く、欠陥は正式に管理されることなく、見つけ次第修正！
コンポーネントテストに対する試験アプローチは、「コーディング前にテストケースを準備し実行を自動化して繰り返す」
→「テストファースト法(テスト駆動型開発)」と呼ばれ、合格するまで修正と反復(イテレーション)を繰り返す。
★「統合テスト」の解説
【概要はこう!!】
「システム間のインターフェースを検証する」
(コンポーネント間のインターフェース、OSなどの相互処理など)
【つまりは？】
-「コンポーネント統合テスト」
→ソフトウェアコンポーネント間の相互処理をテスト
-「システム統合テスト」
→他システム間やハードウェアとソフトウェア間の相互処理をテスト
統合の範囲が大きくなるほど、欠陥原因の絞り込みが難しくなる。
統合は一度に纏めて統合「(ビックバン統合と呼ぶ)」しないで、少しずつ統合するのが普通です。
(問題でよく出るパターン)
理想としては、「テスト担当者が統合計画の構造や影響を理解している」のが理想である。
★「システムテスト」の解説
【概要はこう!!】
「システムの機能要件、非機能要件およびデータの品質特性を検証する」
【つまりは？】
運用もしくは使用する「テスト環境は、商用と同じ環境」が望ましい。
システムテストは「システム動作を高レベルで記述したテキスト、システムリソースなどの要求仕様に基づいた」テストがある。
(問題でよく出るパターン)
・高レベルって単語が出てきたら「システムレベル」に分類されると覚えましょう。
・テスト担当者は「不完全であったり、ドキュメントしていない要件も扱わなければならない。」
・独立したテストチームが請け負うことが多いのが「システムテスト」のレベルである。
★「受け入れテスト」の解説
【概要はこう!!】
「ゴールはシステム全体、一部、非機能的な特性が正しいことを検証する」
【つまりは？】
・欠陥を摘出するのが主目的ではないではないです。
・受け入れテストも以下のように分類されます。覚えておきましょう。
１：「ユーザ受け入れテスト」
→システムがビジネスで使えるかを「ユーザがテスト」するもの。
２：「運用受け入れテスト」
→システム管理者によるテスト
(バックアップ、保守、セキュリティの脆弱性の定期チェックなど)
３：「契約による受け入れテストおよび規定による受け入れテスト」
→カスタムメイドのプロダクトを開発する際、契約書の判定基準に従って検証する。
４：「アルファテスト、ベータテスト(フィールドテスト)」
→ユーザや顧客からのフィードバックを受けたいもの
・アルファテスト：開発組織でテストするが開発チームが実施するものではない。
・ベータテスト：顧客によるテスト
テストタイプ
・JSTQBで定義する以下4つのテストタイプについて、詳細に解説していく。
・「機能テスト」「非機能テスト」「構造テスト」「確認テスト、回帰テスト」がある。
※テストタイプとテストレベルが混合するケースあり、ご注意下さい。
ここでは末尾の言い回しの違いが問題で出題されやすいので違いを理解しましょう。
①機能テスト(ブラックボックステストと同義)
②非機能テスト
③構造テスト(ホワイトボックステストと同義)
④確認テスト、回帰テスト
★「機能テスト(ブラックボックステストと同義)」の解説
【概要はこう!!】
「機能テスト」とは、システムが「何をするかを検証する」テストである。
【つまりは？】
・「すべてのテストレベルで実施が必要」なテストタイプである。
・ソフトウェアの「内部構造を意識することなく、外部動作を検証(ブラックボックス技法と呼ぶ)」
・「セキュリティテスト」は、ウイルスを検知するテストで機能テストの部類に入る。
★「非機能テスト」の解説
【概要はこう!!】
「非機能テスト」とは、システムが「どのように動作するか検証する」テストである。
【つまりは？】
・「すべてのテストレベルで実施が出来る」テストタイプである。
・以下、非機能テスト部類になる。
「性能テスト」
「ロードテスト」
「ストレステスト」
「ユーザビリティテスト」
「保守テスト」
「信頼性テスト」
★「構造テスト(ホワイトボックステストと同義)」の解説
【概要はこう!!】
「構造テスト」とは、「構造をどの程度゛網羅゛したか」でテスト実施の完全性を評価するテストである。
【つまりは？】
・「すべてのテストレベルで実施が出来る」テストタイプである。
・「構造テスト」の技法は、「仕様ベースの技法を適用後の実施するのが良い」(問題でよく出ます)
・「カバレッジ(網羅率)」とは「テストスイート(テストセット)が実施したテストで何％カバーしたか(網羅したか)」を示すもの。
※カバレッジって単語は聞きなれない方も居ると思いますが「どの程度網羅されているか？」的な意味です。難しく考えないで良いです。
この辺の詳細は「第4章-テスト設計技法」の時代が来たら解説予定です。
★「確認テスト、回帰テスト」の解説
【概要はこう!!】
・「確認テスト」とは「欠陥を見つけて修正された場合、正しく修正されたかを検証する」テストである。
・「回帰テスト」とは変更に伴うデグレード確認として「既にテスト済みを何度も検証する」テストである。
デグレ確認！って単語＝回帰テストと理解すればOK！
【つまりは？】
・「すべてのテストレベルで実施が出来る」テストタイプである。
・回帰テストは、「テストスイート（テストセット）は何度も実行し、少しずつ内容が変わるのが普通」(問題でよく出ます)
→従って、「自動化による効率が非常に高い」のが特徴である。
保守テスト
・保守テストってなんだについて解説します。
★「保守テスト」の解説
【概要はこう!!】
「保守テスト」とは「システムに変更や追加などのメンテナンスが発生したときに実施する」テストのことで、「現在稼働しているシステムで実施」する。
【つまりは？】
・「すべてのテストレベルで実施が出来る」テストタイプである。
・「保守テスト」では、変更部分のテストに加えて
「未修正部分に対する回帰テストも実施する必要」がある。
※保守テストですが、「テストタイプ」に分類されない独立したカテゴリのものだと思ってもらえれば大丈夫です。
最後に
今回はJSTQB_FL「第2章-ソフトウェアライフサイクルを通じてのテスト」について解説しました。
問題選択肢4択について回答するので、ある程度の概要を理解して消去法であからさまに「煽り釣り」演出の選択肢を排除することが大事です。
最近のパチンコスロットも「煽り」演出が増えて当たらないのが増えてます。困りますね。先読みレバブルで外れると どうしようもないです。「さらば諭吉！」
あと不要な先読み「保留」点滅が来て、リーチにすらならないことも増えてます。何が言いたいかというと、今回解説した「非機能テスト」内にある「ユーザビリティテスト」の段階で、この辺はしっかりユーザの声を取り入れて、打ち手にストレスを与えない台を開発することも ＝ 稼働貢献になります。
・・・
あ…ありのまま今起こった事を話すぜ!
おれは今やつのス〇ンドをほんのちょっぴりだが体験した
い…いや…体験したというよりはまったく理解を超えていたのだが……
あ…ありのまま 今起こった事を話すぜ！
私は皆の前でJSTQBの解説をしていたと思ったらいつのまにかスロットの話に結びつけていた…
な…何を言ってるのかわからねーと思うが私も何をされたのかわからなかった…
頭がどうにかなりそうだった…
催眠術だとか超スピードだとかそんなチャチなもんじゃあ断じてねえ…
もっと恐ろしいものの片鱗を味わったぜ…
ARIGATO またお会いしましょう。
