JSQTB試験の攻略法

はじめに

前回の記事ではJSTQBの勉強法について記載しましたが、今回はJSTQB試験の攻略方法について記載します。

Lo,Knなどの用語については一々説明しないのでシラバスを参照してください。

この文書の中では試験問題については「問題」、試験問題の中で選択肢に直接関わる設問のことを「課題」と表現しています。JISとは違います。

試験問題のコツ

K2レベルは単なる知識問題です。数行の問題文対して、適切or不適切な答えを選択します。意味不明な選択肢が1つは入っているので、シラバスをある程度読んでいたら割と答えられると思います。

問題はK3,K4レベルになると思います。

K3,K4レベルはいくつかの文章で記載されたプロジェクト背景を元に、例えば「優先するテストは何なの？」などの意思決定を行います。

K3,K4レベルの問題文は割と長文で、ゴシック体太字と相まって謎の威圧感をたたえています。
結果問題冊子は数十ページに及ぶので、それでビビる人もいるみたいです。

長文問題を素早く解くコツとしては、「課題を明らかにしよう」ということです。

最初に、テストマネージャー/テストアナリストとして「どのような課題に直面しているのか」や「どんな意思決定をしないといけないのか」をきちんと理解する必要があります。

そして、それらに対する選択肢としてどのようなものがあるかをきちんと認識することが重要だと考えます。

「どんな課題に向き合う必要があるのか」上記を明らかにした上で、問題文からプロジェクト背景を読み取り、真相を掴んで解答していく流れになります。

例えば私の場合、以下のような効率化を行いました。

1. 問題の末文を読んで出題意図を掴む(どのような解答が考えられるのか、仮説が立てる)
2. 選択肢を読んで選択肢の中のK2レベルで辻褄があっていない選択肢を省く
3. 末文、選択肢では読み取れなかった「制約条件」や「プロジェクトで達成したいこと」といった読み取るべきポイントについて検討をつける
4. 本文のキーワードを元に読んでいく。選択肢がひとつに定まった時点で終了

上記のポイントを抑えて置くことで、すべての問題文を読むのではなく、ナナメ読みで必要なポイントを抑えることが可能です。

試験問題に対する向き合い方についてもJSTQB試験ならではのコツがあります。

ISTQBの試験問題については、シラバスのLOという形で全て公開されています。

出題ついてはこれらのLOをそのまま出題するか、具体化したものです。

問題文を呼んだときに「この問題はどのLOに対応しているのか」「このLOに対する記述はどの部分なのか」ということを思い出すことが大事です。

そうすればK2レベルではすぐに解答可能です。

K3,K4であっても何を明らかにすべきかという問題意識を素早く導出できます。

JSTQB Advanced Level Test Analystの勉強方法

はじめに

この記事は過去の記事のリブートです。

私は2022年ごろにJSTQB TAを取ったのですが、私の周りでTAを取りたくて、その攻略法を知らない人がいたので、その人向けに書きます。

JSQTB試験の効果的な勉強方法が存在します。

それをこの記事では紹介します。

1.サンプル問題を解く

「JSTQBを受験しよう」と思った時点で、まず最初にISTQB公式にあるサンプル問題を解くことをおすすめします。

JSTQBは国際資格で、尖った問題や奇を衒った問題を出すよりも、前例にならった問題を出す傾向が強いように思えます。

特にL2,L3レベルの問題はサンプル問題そのままが出る場合が多いので、答えを丸暗記してしまっても数点稼ぐことができるでしょう。

https://www.istqb.org/certifications/test-analyst

2.シラバスにアンサーする

試験問題はシラバスのLOから出題されます。

なので、シラバスのLOについて自信を持って回答できることが合格につながります。

そこで私はシラバスのLOに対して自分なりのアンサーを持っておくことにしました。

例えば以下のようなものです。

TA-1.5.1 (K2)テスト実装の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

私のアンサー

• テストケースの実行環境、システム状態の前後関係から最も効率の良いテスト手順を導き出す。テスト手順は通常、複数のテストケースから成る。これらは特定のテストランにおいて実行される自動テストについても整備する必要がある場合もある。
• テスト実装の際にはテストデータの作成も考慮する。狙ったテスト条件を満たすデータベースの構築や、複雑なデータセットを効率よく作り出すこともテストアナリストの仕事である。
• テスト環境についても、テストマネージャーが識別したテスト環境を整備しなければならない。これらはテスト環境の調達のほか、テスト対象の調達も含まれる。
• テスト実行スケジュールも作る。
• 対処的アプローチや探索的テストなどの非形式的なテストの場合、詳しいテストスクリプトを作らない可能性もある。これらはテスト担当者の想像力や製品の状態に応じて効率よく欠陥を摘出できる場合があるが、テストの再現性、見積などの点でリスクが高く、どこで適用するかは見極めないといけない。

これらのLOに自分の言葉でアンサーできるようにしておくことで、
文章問題の正誤問題などの精度を高めることができます。

3.テスト技法を手になじませる

テスト技法は100％出ます。
仕様読み,モデリング,テストケース導出,テストケース設計まで淀みなくできるようにしておくことが求められます。

特にデシジョンテーブル・状態遷移は確実に出ます。

私のやり方としては、GIHOZを使って適当にモデリングを行い、手動でテストケース作りして、GIHOZの出力結果と自分のテストケースが合ってるかを確かめていました。

https://gihoz.com/

4.シラバス引用元の原著を読む

私は下記を読み込みました。あんまり試験には関係なかったですが、シラバス内容の理解を深めるためには有用です。

• 実践的プログラムテスト
• ソフトウェア要求
• 体系的ソフトウェアテスト入門

JSTQBTAには同人誌や有料の学習サービスがありますが、シラバスの誤読や原著の解釈違いなどがあるため、個人的にはおすすめしません。

洋書ではALの教科書がありますが、正直シラバスの焼き増しで、読む必要はないと個人的には思います。

TMMi Lightning Scan Toolを使ってみた感想

はじめに

TMMi Lightning Scan Toolに興味があったので使ってみました。

https://www.tmmi.org/

TMMiはテストのベストプラクティスが詰め込まれたモデルであり、テストプロセス改善ツールでもあります。

JSTQBカンファレンスでErik氏が登壇していたこともあり、以前から興味があったのですが、試しに使ってみました。

https://jstqb.jp/prinfo/conference2024/

私の背景として、私は江戸時代のテストプロセス改善モデルであるTPIがプロとして使える程度には修めており、しいて言えばテストプロセス改善技術に専門性があるテスターです。

そんな中で、自分の専門性の幅を広げるために、TMMiについて調べてみようと思ったのです。

TMMi Lightning Scan Toolを適用することの所感

ほとんどの組織はLevel２に到達しないと思います。

そして、このツールだけを使ったところで次のSTEPに進むための効果的な施策は打てないと感じました。

本当に簡易的な判定をするだけであるので、人によってはふうんで終わるかなと思いました。

また、テストエンジニアのレベルによってはスキャンツールの意味すら理解できないかもしれません。最低限でもJSTQB ALレベルの用語理解が必要だと感じました。

TMMiの特徴

TMMiの特徴として、テストマネジメントに重点を置いた内容であると感じました。

TMMiで扱っている概念自体は29119やTMapとそう変わらないので、これらを一度でも学習したことがある人ならとっつきやすいと思います。

TMMiはこれらのプラクティスのうち、重要なプラクティスについて体系立てて順番をつけたものだと理解する必要があるでしょう。

TMMiの所感

テストマネジメント重視な点を、私は評価しています。

一方、「テストにおいてテストマネジメントが重要」という価値観がないと、適用しない人がいるのではないかと思っています。

人によってはテストマネジメントをガントチャート書くだけだけだと思っていたり、テストマネジメントを毛嫌いする人がいる場合があるので、そういった場合にも注意が必要ですね。

また、TMMiを採用する以前に「テストにおいて納得感が大事」「体系的なテストプロセス改善が必要」という価値観がないと、TPIより適用は難しいと思いました。

「難しいことはいいからバグ出したいねん」「うちはテスト設計だけうまくやれたらいいんです」というチームにはあんまり向かない手法だと思いました。

テストの街の例大祭2024に行ってきた

はじめに

テストの街の例大祭2024に参加してきました。

ost-zatu.connpass.com

初めての葛飾で年末にわざわざ２泊３日で行くものかと思ったりしましたが、私としては十分行った甲斐のあるイベントとなりました。

今年でトップクラスに学びやメイクセンスが多かったイベントだったのかもしれません。

それについて今日のうちに記載しておきたいと思います。

やまずんが刺さった背景

私は現在、「会社のQAをよくしていく」という大きくもざっくりとしたミッションを持っています。そうした中で、AckyさんやRyoさんのアプローチは自分の中で全くなかった視点だったので、それを取り入れられる部分は取り入れたいと考えました。

また、私もKeynoteを行い、それに対する議論やフィードバックをもらうことで、自分自身のQA観のアップデートに繋がったと思います。

また、この発表を通じて、（もう二度とないかもしれないですが）長時間のリアル発表に対する課題についても気づくことができました。

Keynote Ackyさん

すべてNDAな内容なので、発表の中身は言えません。

なので、私が思ったことのみを記載します。

私自身、ふわっとした問題を扱っているのが現状なのですが、「まずやみくもに走ってみよう」と思っているところでした。

しかし、今回の発表を聞いて、きちんと品質保証の原則に基づいて整理すべきだと考えました。

私の仕事の進め方が誤っているということもあるかもしれませんが、現状与えられたミッションを考えると、やりたいことすべてを実施することはできないですし、きちんと投資のリターンが見込める活動を見極める必要があると感じたからです。

この発表を元に、自分の来年からの仕事を見直していきたいと思いました。

そういった来年への仕事への意識の変化が得られたことは、年末ということもあって、とてもいい体験でした。

Keynote Ryoさん

私もRyoさんと同様に、組織レイヤーの改善のミッションを与えられています。

そうしたときに、〇〇（NDA）という考えを使い、ワークショップを通して意識や行動の変化を促すというアプローチには、今後の活動においてよく考えておくべきだなと思いました。

「ワークショップを通して」という部分に関しては、Keynoteの中では説明がありませんでしたが、自分で以下のように考えました。

やまずんのワークショップへの感想

セミナーや学習でなく、「ワークショップである」というのは、身体的な体験や行動を伴います。そのため、自発的な学習や気づきの機会を与えられるという点で有効な手段だと思いました。

Keynote 俺

Keynoteをしてきました。

www.docswell.com

発表内容についての気づき

• このQA観は誰にとって嬉しいのか？
  • 自分と同じ考えを持っている人にとって、少しでも勇気と言語化を与えられたらと思って記載しました。ここでいう「自分と同じ考えを持っている人」とは、私自身も指します。私は自分自身のために自分自身の考えを言語化したのでした。
  • 「すべての人がこういったQAになる」に対して、私は何を思っているかというと、何も思っていません。全く考えてもいませんでした。
• 日本的とは何？
  • 「日本的」という言葉を教科書のまま受け取っていましたが、様々な背景のことを「日本的」と表現することができます。
  • 日本の会社法かもしれないし、日本の規格や、文化、「日本人が作っている」かもしれません。
• 日本的品質管理はなんでいいの？
  
  • これは「日本的品質管理は私の考えに合っているよね」という理由で引用しているにすぎないと感じました。
  • 実際に日本的品質管理が本当にいいかどうかは私はわかっていません。これは品質保証の原則における、「結果による評価」を違反しています。世界一品質がいいものをコンスタントに出している企業はどこか、から比較して考えないと、この質問には答えられないと感じました。さまざまな主観的な情報を並べることはできますが、これも事実に基づいて話すべきことだと思いました。
• パーフェクトQAパーフェクトスタイルへの誤解
  • 「パーフェクト」という言葉に誤解を与えていることが発覚しました。意味はありません。私はPerfumeが好きで、パーフェクトスターパーフェクトスタイルが好きで、この歌詞が最高に好きだからです。それ以上に意味はありません。

発表に対する気づき

• 全く緊張していませんでしたが、そんな状態で自然に話していると、思ったより早口になっていることに気がつきました。これは聴講者にとって聞きづらいかなと思いました。
• 身振りや手振りへの気遣いがなかったと思いました。昔のプレゼンでは意識していたのですが、リアル話は久々だったので完全に忘れていました。
• 視線は下や画面ばかりを見ていたので、きちんと聞いてくれる人の顔を見ながら話せばよかったと思います。
• 思ったより早めに終わったので、今後長めの発表時間を与えられた時があれば、もっと中身を考えて、きちんと練習をして挑みたいと思いました。

Keynote　おおひらさん

まあ、いいと思いますよ。

というのは当日参加していた人しかわからない冗談ですが、私もスリムでスタイリッシュな”QAエンジニア”には思うところがあります。

必ずしもQAエンジニアが手を動かすべきとは思わないですが、Whole Team Approachを声高らかに言う前に、自分がプロとして成果を出すべきという気持ちは私もあります。

本セッションは主におおひらさんの専門性について紹介いただきました。

その中で「おおひらさんの弟子」についての興味深い議論がありました。

おおひらさんの弟子になる方がどんな人になるかはわかりませんが、今後おおひらさんの弟子として活躍できる人は、テスター筋肉ムキムキテスターとして活躍できるのではないかと思いました。

区長のクロージングセッション

話せることは何ひとつありません。

総括

区長＋４Keynote＋区長でしたが、比較的クローズな場ということで、普通のイベントではとても聞けないような学び深い話を聞けて、とても有意義な時間となりました。

本当に言ってよかったと思います。

1人目QAエンジニアを募集する前に考えたほうがいいと思うこと

はじめに

私は転職意欲の有無に関わらず、カジュアル面談を拒みません。

そういった背景もあり、今まで100社近い会社とカジュアル面談を行ってきました。

その中で「1人目QAになってほしい」と誘われることもあります。

しかし、お話を伺う中で、注意すべきポイントがあるなと考えることがありました。

それらについて言語化を試みます。

「品質はQAが考えてくれる」ではなく「自分で考えてみる」

「品質について不安だから専門家のQAに考えてほしい」と考える人がいます。

それは分業という点では効率はいいとは思いますが、組織の品質文化を考えると、必ずしもいい方法ではないと思っています。

ぜひ一度品質について考えてみてほしいと思います。

「品質について考える」はハードルが高いように思うかもしれません。

ただ私は一度素朴に考えればいいと思います。

それは「顧客満足を最大化するために何ができるだろうか」「顧客満足を損なわないためにどうすればいいだろうか」です。

これらについては「効率的」「効果的」という観点でそれぞれ考えて、言語化を試みたらいいと思います。

品質保証の真髄は「顧客志向」だと私は考えます。

「顧客満足」を目的として、やるべきことを考え、やる、というのが品質保証の本質だと考えます。

これらを考えたときに、「必要な専門性が足りない」と思った時に、必要なQAエンジニア像がクリアになるのではないでしょうか。

「とにかく自動化してほしい」ではなく「自動化が選択肢にある人」

一人目QAとしてテスト自動化エンジニアを雇おうとする組織もよく見かけます。

私個人の意見としては、品質保証の経験よりも、ソフトウェアエンジニアリングの素養がある人の方が、QAエンジニアとしては柔軟に動けると思っています。（実際は両方あるのが望ましいです）

一方で、自動テストを実装する技術よりも、まずは自動テストの取捨選択を行なったりする技術に目を向けてほしいという個人的な思いがあります。

「テストがボトルネックになっているから自動化してほしい」という理論があるならば、ソフトウェア開発全体の自動化を検討するべきだと考えます。

上記について「詭弁」だと思われたならテストに対しても同じです。

テストのアクティビティはテスト実行だけではありません。また、テスト実行以外のアクティビティを自動化する技術もありますが、これらによって人の仕事がなくなるわけでもありません。

E2E自動テストの構築・運用の場合、よっぽどハイクラスな自動テストエンジニアでないかぎり、一人のQAエンジニアで実装できる範囲は限定的ではないかと考えています。

なので、テスト自動化の実装技術のみにフォーカスするのではなく、ソフトウェアエンジニアリングそのものの素養を判断したほうがいいと考えます。

「〇〇さんみたいな人がいい」ならその人をバイトで雇う

「〇〇さんみたいな人に来てほしい」と要望を持っている会社があります。

ここでいう〇〇さんとは、業界の有名人です。

具体的な人物像があることは素晴らしいことですが、だとしたらアルバイトなどの時短勤務であってもその人を実際に雇って、次の採用に繋げた方がいいと考えます。

実際にその人と働いたことがある上で、本当にその方が今の会社のフェーズに必要かどうかを判断してみた方がいいと思います。

また、業界のプロップスが高い人が業務委託でコンサルしていると、次の〇〇ジュニアにも繋げやすいと考えます。

ダメ元でいいので、有名人にオファーしてみたらいかがでしょうか。

QAエンジニアは本当に必要なのか？

「QAエンジニアが必要」というのは本当にそうなのか？と思う時があります。

品質保証やテスト以前に、ソフトウェアエンジニアリング全体や組織が未熟な場合もあると思います。

その場合は、テストの専門家よりも、品質保証に対して造詣が深いEMを雇った方がいいと私は考えます。

個人的な考えですが、例えばテストに課題があったとしても、「テストのタスクをこなせる技術者」よりも、「テストに対して正しい期待値と正しいマネジメントができる人」がいた方が適切に問題解決ができる場合もあると思っています。

なので、QAエンジニアにこだわらずに、他のロールであっても問題解決ができないかどうかは考える価値があると思っています。

QAエンジニアへの理解を深める

QA＝テストと考えている人がよくいますが、それは正しい場合もあれば、間違っている場合もあります。

コンサルや製造業の品質保証部であってもQAと言ったりします。彼らはテスト実行をしないこともあります。

私は個人的に支持しないですが、QAはテストの上位職であり、テストをマネジメントだけする人たちだと考えている人もいます。

ですので、個人的にはQAやテスターで探すよりも、「自分たちの品質に対する課題はなんなのか」を一度言語化してみて、それが叶う人をロールで縛らずに探してみることも有効なのではないかと考えます。

「QA計画」「QA設計」「QAケース」という言葉を使ったり、「テスターのようなレベルの低い人ではなくQAを求めている」などと言っている会社も何社か見かけましたが、私は正直いい気持ちになりませんでした。

そんな私みたいな気難しい人もいます。

おわりに

個人的に1人目QAエンジニアは魅力のあるポジションだと思っています。

なのでQAは比較的募集しやすいのではないかとも思っています。

だからこそ、各社にはよく考えて採用に臨んだ方がいいのではないかと考えています。

JSTQB Test Automation Engineerを受けてきました。

はじめに

先日、JSTQB Test Automation Engineer、略してJSTQB TAEを受けてきました。

この内容についてブログを書いてほしいという要望が海の仲間からありました。

テスト界隈の派閥については以下を参照してください。

yy-world.hatenadiary.com

ですので、海の仲間に向けて、そしてTAEについて知りたい人に向けて受験記録とお気持ちを表明します。

受験について

JSTQBはじめてのCBT登録

JSTQB試験について、今まで私はPBTしか受けたことなかったので、初めてのCBTとなりました。

受験登録自体は簡単で、専用のサイトから受験登録を行うことで実施できました。

当日は梅田のテストセンターに行きまして、手軽な受験準備を行って試験を開始しました。

さまざまな受験を同じ会場で受けることができますが、同じ受験会場にJSTQB FLを受ける人がいました。

その人がずっとハンケツ出していたことが心に残っています。

試験内容

試験の難易度としては高くないです。シラバスが頭に入っていたら解けるような問題でした。

一方で、シラバスでしか使わない略語が大量に記載されているので、シラバスをきちんと読んでいない人は試験を受けるのは苦痛だと思います。

他のJSTQB試験と同様ですが、問題文を読むことが大変重要になるので、文章を読む練習はしておいたほうがいいと思います。

試験について

最終的な合格率は60パーセントを超えているので、ALレベルとしてはかなり簡単な試験なんだったと思います。

もちろん私も受かってます。

本記事の執筆時にはTAEの新シラバスも発行されており、今後試験があるとしたらそちらベースの試験が再開されると思っています。

なので、この簡単な傾向が今後も続くかはわかりません。

JSTQB TAEの勉強方法

TAEの勉強については結構前から実施していました。

前々職ではテスト自動化の研修を受けていてそこでも勉強していましたし、早い段階から試験問題の翻訳&模擬試験を実施していました。

また、TAE独特の概念であるgTAAについて、JaSST nanoやzennを通じて言語化する機会があったことも大きいです。

JSTQB試験全般に言えることですが、ISTQBが提供している試験問題をやっておくことは役に立ちます。

テスト自動化エンジニアとしての私

私は認定されたテスト自動化エンジニアになったわけですが、一日中自動テストコードを書いていたら満足するタイプの人間ではありません。（ただ、コーディングは好きです）

むしろ、自動テストをどうマネジメントするか、どう運用していくかの方に関心があるタイプです。

「テスト自動化エンジニア」とはコーディングガリガリする人というイメージがあって私を雇うことがあると、少しギャップがあるかもしれません。実際にそのような経験を長期間やったことはないです。

テスト自動化という技術要素について

テスト自動化技術は、今となっては当然の技術ではないかと私は考えています。

採用面接では必ず自動化の経験が聞かれますし、そのニーズが高いことも事実です。

ただ、テスト自動化の技術が、例えばスクリプティングの技法やテスト自動化アーキテクチャについて認知・理解がされているという状態になるにはまだ先のように感じます。

なので今後もテスト自動化エンジニアとして少なくともあまり意味のないテストスクリプトを量産しないように、気をつけていきたいと思います。

2021年のテスト設計コンテストに出た感想 〜テスコンに出れなかったすべての人へ〜

※この記事は2021年6月に書いています。

先日、テスト設計コンテスト'21 U-30の部の予選成果物を提出しました。

テスト設計コンテストについて、詳しくは下記のページで

http://www.aster.or.jp/business/contest/rulebooku30.html

テスト設計コンテストに対する思い

テスト設計コンテストのことは、以後の文章では略してテスコンと呼びます。

テストエンジニアであるということは、「良いテストケースを作れるかどうか」と問われ続けることだと思っています。

現場のしがらみを抜きにした形で「良いテストケースを作れるかどうか」を客観的に示せるところは、私の観測範囲内では、テスコンしかありません。

2018年4月にテスト会社に入社して、2019年度、2020年度とテスコンに出場できるチャンスが巡ってきましたが、コンテスト自体が中止になったり、自分のチームの成果物に自信が持てないといった事情で、成果物を作成したものの、テスコンに出場するという形で世に出すことはできませんでした。

テスコンって難しい

テスコンの難しさテスコンはテスコンならではの難しさがあります。

例えば以下のようなものです。

• 顧客やテスト計画やテストマネジメントといった制約がない点
• テスト設計成果物の不完全さをテスト実行で有耶無耶にできない点

暗黙知化された制約、テスト実行への適用を根拠に、実務でやりがちな不完全なテスト設計成果物やテスト計画成果物を作ることの言い訳、逃げ道として使えません。

「テスコンに出場する価値は出場してみないとわからない」と言ってる人がいます。

そのとおりだと思います。

「現場の都合」という言い訳や逃げ道をなくした上で、

「本当に自分は良いテストケースが作れるのか？」を問われることは現場で培った自尊心を自己否定により傷つけるような苦痛を伴う行為だと思っています。

私が選択した「逃げ」

テスコンに出るということはある種リスクを背負います。

有識者の人の批判を元に、聞いている第三者から「この人は良いテストケースを作れない」と評価される可能性があります。

それはテストエンジニアとしての存在価値を疑われる危険性のある行為だと思っています。

だから私は、気がつけば「忙しい」「興味がない」「自信がない」という言い訳を並べていました。

それは何かのせいにして、本当は弱い自分自身から逃げ続けているだけでした。

そしては私は2020年のOPENクラスの予選を聴講しました。

そこで私は土俵にすら上がれていないことに気が付きました。

劣等感を克服できるのか

2021年、私はU30クラスで予選成果物を提出しました。

これはひとえにメンバーに助けられたからです。

私はこれによって劣等感を克服できるのでしょうか。

それは未来の私が決めることなのでした。

2024年の追記

テスト設計コンテストは敗北しました。

そして、私のキャリアに大きな影響も与えませんでした。

私のことは誰も気にしていないですし、私自身も気にすることはありませんでした。

一方で、「出場した」という結果を残せたことは私にとって大変有意義でした。

自分の逃げや言い訳を克服して、一歩を踏み出せたわけです。

活動自体には確かな学びがあったと思います。

なにより、私には「あのとき」が残りました。

私の人生にとって今後、どれくらい役に立つかはわからないです。

しかしながら「あのとき」として、私の中に刻み込まれる経験だと思ったのでした。