／|∧_∧| ＜お久しぶりです。2020.11.20」振りの執筆です。2年とちょっと振りかな。
||. (･ω･´| ＜QAパチスロライターの本間です。
||oと. Ｕ| ＜まだ、5号機のギルクラ、まどか2があった時代ですね。懐かしい。
|| |（__）Ｊ|＜最大ハマり？上乗せ演出？懐かしい5号機の話に花を咲かせよう。
||／彡￣ ｶﾞﾁｬ ＜・・・って、、あれ？今日はそういう話では無かったではない？ふむ。
” ＿＿_
／|∧_∧|
||. ( | ＜違うって今日は「パチンコ」/「スロット」ファン向けの解説をする場じゃないってよ。
||oと. |
|| |（__）Ｊ|
||／彡￣”
“
＿＿_
| |
| o.| …一旦失礼します。・・・＜協議中＞
| |
| |
￣￣ ﾊﾞﾀﾝ”
“
＿＿_
| |
| o.|
| |
| |
￣￣
どうする？今日の編集長「今回だけは」流石に真面目な記事にしろって言ってますけど。
…ええ、真面目じゃない人がガチ真面目に記事を書くなんて、シン⇔サウザーステージを延々とループを見させられ続けるか「10回転/1K」位の回らない上に、保留玉が1つとか2つになると絶対当たらない煽り演出を延々と見させられ続ける台くらいきついぞ。
“／|∧_∧| ＜じゃあ。代替案でアニメとか、声優の話とかでも・・・？え？・・ダメ？
||. (･ω･;´| ＜前回の一般教養について、パチンコファンからクレームが来たから禁止？
||oと. Ｕ| ＜ああ。このときか、、、あー。まぁーはい。
|| |（__）Ｊ|
||／彡￣ ｶﾞﾁｬ”
※2020年のテックカンファレンスで「一般教養」と称し、声優やアニメ安藤CTOの個人情報などかなり難しい内容が出題された。
“
＿＿_
／|∧_∧|
||. ( | ＜違うって今日は「声優」とか「アニメ」ファン向けの解説をする場じゃないってよ。
||oと. |
|| |（__）Ｊ|
||／彡￣”
“
＿＿_
| |
| o.| …失礼します。・・・＜本間ブログrush！～終了～＞
| |
| |
￣￣ ﾊﾞﾀﾝ”
“
＿＿_
| |
| o.|
| |
| |
￣￣
「ボタン」連打でブログ記事の執筆を継続させろっ！
【期待値：★☆☆☆☆ (ミッション系、日常系の連続演出みたいな期待値です)】
「連打」 「連打」 「連打」
だっだっだっだっ・・・ヨシッ！ヨシッ！ヨシッ！ヨシッ！
（青オーラ→黄色オーラ→緑オーラ）・・・。スンッ…。
だだだっだっだっだっ
～ 終 ～ result 払い出し：330P「左打ちに戻してください！」
“／|∧_∧|＜←ドアを開閉しているAAです。決してパチンコを打ってるAAではありません。
||. (･ω･;´|
||oと. Ｕ|＜今回はソフトウェアテスト「JSTQB_FL資格の取得講座」的なので行きます。
|| |（__）Ｊ|
||／彡￣ “
少し長くなったので、２つの記事に分けて紹介します☆彡
経歴について軽く―2nd
＜前回の私の設定はこちらをご覧ください＜【4/2実施レポ】GMOリサーチテックカンファレンス「REMO CON」を開催いたしました。＞＞
★2004年
【将来分岐演出】情報技術系の短大を卒業後、保育士を目指すも話すネタがことごとく、幼い将来ある幼児たちへ悪影響を与えると悟り、エンジニアの道を選ぶ。
★2008年
【収監演出】横浜近辺でテストの仕事をしていたら不審者扱いされて、YRP(ヨコスカ・リサーチ・プリズン(Yokosuka Research Prison)に収監される。辺境で高台の崖の上にそびえ立っており、唯一の交通手段は京浜急行電鉄が運行する「YRP野比駅」から護送車という名のバス1つのみでトンネルを超えると脱出は不可能である。
★2014年
【転職演出】テストエンジニアの専門職としてのキャリア蓄積を開始。
★2015年
【エンカウント演出】何かの間違いか、現GMOリサーチITセキュリティ＆品質管理部の「O部長」との出会いはこの時である。
★2019年
【決意演出】スタンド使い「O部長」の誘いを受けGMOリサーチ株式会社へ配属。
★2023年現在
現在に至る。4年が経過していた。4年勤続褒章で「角砂糖3つ貰った」よーしよしよしよしよしよしよしよしよしよしよし。
テストエンジニアの効果的な資格：JSTQB認定テスト技術者資格
★前回記事「現役テスト（QA）エンジニアが仕事内容について説明してみる。」でおすすめしたテスト関係の資格のうち、今回は初心者にもやさしい導入部門としてJSTQB Foundation Level「JSTQB FL」を紹介します。
JSTQB認定テスト技術者資格とは？
JSTQB認定テスト技術者資格とは、日本におけるソフトウェアテスト技術者資格認定の運営組織であるJSTQB（Japan Software Testing Qualifications Board）により認定される、ソフトウェアテスト技術者資格です。JSTQB認定テスト技術者資格には以下の２つのレベルがあります。
①JSTQB認定テスト技術者資格 Advanced Level（AL）
・テストマネージャ
→65問/180分 選択式 合格率：20％程度 えぐい時は6％
・テストアナリスト
→60問/180分 選択式 合格率：20％程度 えぐい時は10%
②JSTQB認定テスト技術者資格 Foundation Level（FL）←今回の記事はこれのお話
40問/60分 選択式 合格率：60%程度
JSTQB FLの合格ラインは65%です。 全体で40問なので「26問正解すれば」合格ラインです。
自信を持って26問正解を選んでいれば、また、当選率1/4の選択肢を己のヒキを信じれば「40問」のうち「10問」は当選できるでしょう。
つまり全体の半分で確実に「正解」フラグを引けば、残り20問を己のヒキ次第で突破できます。1/4強の引きを発揮すればいいんです！何とかなる気になったでしょう。
・・・が私は、引きが弱く「継続率： 約93％」ですら、即落ちするので、やはり対策は練りましょう。（受験料も結構出費でかいですし）
STQB認定テスト技術者資格取得に伴う試験対策
基本的な勉強方法は、以下のサイトに行き「シラバス」をDLしてひたすら読み込めばOKです！
「JSTQB 認定テスト技術者資格―シラバス（学習事項）・用語集」
JSTQB認定テスト技術者資格 Foundation Level試験詳細
朗報：2022年度よりCBT（コンピュータ・ベースト・テスティング）を実施
申込開始日：2022年10月3日開始
試験実施日：予約可能日であればいつでも受験できます（以前は年2回だけだった）
また、JSTQBは資格保有者に応じたISTQBパートナープログラムがあります。
このプログラムに参加することにより、ソフトウェア品質技術およびテスト技術向上への取り組みを社内外にアピールすることができます。
パートナーシップレベルに必要なポイント数と付帯条件は下記の通りです。
各レベルに付与するポイントは下記の通りです。
Foundation Level：１ポイント
Advanced Level：３ポイント（TM/TA/TTA毎）
Expert Level：５ポイント（ITP/TM/TAU/SET毎）
JSTQB認定テスト技術者資格 Foundation Level試験構成
■はじめに
JSTQB_FLは1章～6章の構成となっています。(どの参考書でも一緒)
■全体構成
第1章—テストの基礎 ←今回の記事はこちらの内容です。
第2章—ソフトウェアライフサイクルを通じてのテスト
第3章—静的技法
第4章—テスト設計技法
第5章—テストのマネジメント
第6章—テスト支援ツール
■学習の目的/知識の認知レベル K1：記憶 / K2:理解 / K3：適用 / K4:分析
Foundation Level試験は「K1：記憶 / K2:理解」がメインとなっています。
JSTQB_FL試験の第１章「テストの基礎」を解説-Part1
★第1章 テストの基礎
一言ポイント(嘘)：古井戸の底にいる「ホイ●ン」を仲間に連れて行きましょう。脳筋だけでは回復が間に合わず、クリア難易度が跳ね上がります。
一言ポイント(正)：「デバッグとテストの違い」「テストの7原則」「テストプロセス」「テストの心理学」あたりを理解すればクリアです。(一言じゃない気がする)
JSTQBのシラバスの章構成に準じて、1章の構成範囲↓①〜③の解説をしていきます。
④〜⑥についてはこちらの記事で紹介。
①.テストの必要性
②.テストとは何か？
③.テストの７原則
④.基本的なテストプロセス←ここから次の記事で説明します。
⑤.テストの心理学
⑥.行動規範
①テストの必要性
★ソフトウェアシステムの状況
ソフトウェアが正しく動作しないと「経済的な損失」「時間の浪費」「信用を失う」といった害がある。
★ソフトウェアの欠陥の原因
人間が「エラー(誤り、間違い)」を犯す。それが、コードやドキュメントの「欠陥(フォールト、バグ)」となる。 「欠陥(フォールト、バグ)」が実行されることで「故障(処理不正、フェイラー)」が起きる。
つまり 「欠陥(フォールト、バグ)」が混入されるのは、人間が「エラー(誤り、間違い)」を犯しやすいため。要因として挙げられるのが「納期のプレッシャー、コードの複雑さ、技術の変化、他システムとのインターフェース」などがある。
調査が必要なイベントってなんて呼ぶの？→「インシデント」と呼ぶ。（チケット管理システムで不具合管理しているなら、調査のために発行した「チケット」が該当しますね。)
★ソフトウェアの開発、保守、運用におけるテストの役割
テストの役割とは？→「システムが稼働する前に欠陥を摘出する」「問題が発生するリスクを軽減」「システムの品質向上」の役割がある。
★テストと品質
テストにより、「ソフトウェアの品質を計測できる」
テストを実施して欠陥がほとんど見つからなかった場合は、「ソフトウェアの品質に自信が持てる」「リスクが下がる」 そして、欠陥を修正することで「システムの品質が上がる」
★テストの十分性
どこまでテストするかの判断は、「技術や安全性」「リスクレベル」「期間や予算などのプロジェクトの制限」により決まる。
テストは、「ステークホルダーが意思決定するのに十分な情報を提供」する。(sprint移行、PJフェーズ移行、リリース判断)
※「ステークホルダ」とは利害関係者と呼ばれるもののこと。（プロダクトオーナー、開発者、QA担当者等）
②テストとは何か？
テストとは？→テストを実施(ソフトウェアの実行)することだけではなく、以下の様な行動も含まれる。
「テスト計画」「コントロール」「テスト条件の選択」「テストケースの設計と実行」「実行結果のチェック」「テスト結果報告」。「ドキュメントレビュー」「静的解析」など。
また、テストには次のような目的がある。
1.「欠陥を検出する」
2.「品質レベルが十分であることを確認する」
3.「意思決定のための情報を示す」
4.「欠陥の作り込みを防ぐ」
さらに、テストの観点（確認対象の粒度）によって目的も異なり、以下４つのレベルに分けることができます。
「a:コンポーネントテスト」「b:統合テスト」「c:システムテスト」「d:受け入れテスト」
※詳細は「第2章-ソフトウェアライフサイクルを通じてのテスト」の際に、解説します。1章時点ではイメージだけあればOKです。
テストの目的「欠陥を検出する」
A.開発でのテスト(「a：コンポーネントテスト」「ｂ:統合テスト」「c:システムテスト」)の場合、なるべく多くの故障を叩き出し、欠陥を特定して修正することを主目的とします。
☆ここで一言アドバイス☆
テスト活動における試験出題パターンとしてよく見かける誤った問題の選択肢の中に、「欠陥を除去する」が出てきます。・・が、これは「デバッグ」作業です。テスト活動じゃないので注意。
「～を除去する」って選択肢が出てきたら、煽り演出の間違った回答選択肢の可能性が大です。パチンコの青保留みたいなものです。迷ったら選択肢の候補から外しましょう。
テストの目的「品質レベルが十分であることを確認する」
B.「d:受け入れテスト」の場合は、システムが期待通りに動作し、要件に合致することの確認を主目的とします。
※上記A、Bについては、「第2章-ソフトウェアライフサイクルを通じてのテスト」で出てくる「テストレベル」と呼称されるものである。
テストの目的「意思決定のための情報を示す」
開発プロジェクト内で意思決定が指す具体例としては、「リリース日」「リリース判断」「機能ドロップ判断」などがあります。
こちらの判断をプロジェクトマネージャおよび開発責任者が行うにあたり、判断材料を提供するのもテストエンジニアのお仕事です。
具体的な提供情報は↓
・実施テストケース数
・実施テスト結果（OK,NG,保留等）
・検知不具合件数、残不具合件数(priority情報も添えて) ・現状SWの品質レベルのサマリ情報
テストの目的「欠陥の作りこみを防ぐ」
「保守テスト」の場合は、ソフトウェアの変更時に新たな欠陥が混入してないかをチェックすることが主目的で、「運用テスト」の場合は、信頼性や可用性などの”システム特性”をチェックすることが主目的となります。
★大事なポイント
・デバッグとテストは同じではない。
テスト担当者→再テストを実施して、あくまで「修正により故障が解決したことを確認する。」まで。 開発担当者→「故障」の原因を突き止めて解析して「欠陥を取り除く」一連の作業をする。
③テストの7原則
1.テストは欠陥があることしか示せない。
→どんなにテストしても「欠陥がないとは言い切れない」。
2.完全なテストは不可能(全数テストは不可能)
→すべてをテストすることは不可能。（入力条件の全組み合わせ)バグは「すべて検出するのは無理」、稼働面や予算もあるから。
3.初期テスト
→テストフェーズの「早い段階で見つけておく」と手戻りも少ない。
終盤になるほど影響範囲、デグレ範囲も増えて修正も動作確認も大変になる。
4.欠陥の偏在
→「バグはある特定の一部のモジュールに偏在する」と言われる。
よくあるのが担当エンジニアのスキル不足や画面遷移など、正常系は考慮されていますが、バリデーションチェックが甘くて、異常系数値がスルーしがち等。
なので、PJ終盤やテスト期間が限られる場合などは、検出された不具合事象の傾向を判断して重点的にアドホックリソース充てるなど、よくあるパターン。
5.殺虫剤のパラドックス
→「同じ試験ばっかりじゃダメよ。新しいのは見つけられないよ。」って意味。
6.テストは条件次第
→「条件次第でテスト技法は変わるよ」という意味。
例えば「カメラ」が売りであるスマホがありました。なのに文字入力試験ばかりやっても…。
機能やPJ(ウォータフォール、アジャイル開発)に応じた条件下に応じて行いましょう。
7.「バグゼロ」の落とし穴
→不具合ないから売れる！ではない。「お客さんのニーズに応えてないと結局は売れない！」。
とにかく欠陥を潰しきればよいのではなく、修正によって機能的あるいは非機能的な部分に新たな問題が発生しないかどうかも考える必要がある。
不具合ある機能をやたらとドロップして、欠陥をなくせば良いってわけじゃない。的な意味。
パチンコユーザーの方に分かりやすい例を例えるなら、通常変動で「演出ゼロ」パチンコ玉が、入賞口に入ったタイミングの「1/319」でガコッって光ったら当たる演出のみの台があったとします。
私なら一日打ってたら発狂レベルの台です。1500回転ハマっても光らない気がします。 これは売れますか？脳汁演出を求めるユーザのニーズを満たしてますか？満たしてませんよね？これが「バグゼロ」の落とし穴です。鬼ががってますね。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
JSTQBのシラバスの1章「テストの基礎」の構成範囲↓④～⑥については次の記事で紹介します。
④.基本的なテストプロセス
⑤.テストの心理学
⑥.行動規範
次の記事では第１章「テストの基礎」の範囲から模擬問題等も書いているのでご覧ください！
