JSTQB Advanced Level Test Analystを勉強した感想
最近JSTQB Advanced Level Test Analyst（以下、JSTQB AL TA）試験を受験したので、勉強期間で感じたことを書こうかなと思います。
※あくまでも個人の主観なので、「こういう人もいるのか～」という感覚で見ていただければと思います。
JSTQBについて
ソフトウェアテスト技術者の育成を目的とした団体で資格制度やオンラインセミナーなどの取り組みをしています。
JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織として2005年4月に認定されています。
ISTQBの加盟組織の各国団体は資格および教育・訓練組織認証について相互認証を行っています。つまり、JSTQBが運営するソフトウェアテスト技術者資格は海外でも有効な資格となっています。
JSTQBは次のような3つの委員会（Commitee）から構成されています。 それぞれの委員会は国内における品質保証関連の研究を行っている研究者、高いスキルを持つテストエンジニアやコンサルタントなどを中心に構成されています。
なぜ受験しようと思ったのか
もともとテストエンジニアだったため、JSTQB Foundation Level（以下、JSTQB FL）は取得していました。
現在は開発業務をしており、その中でソフトウェアテストの知識を活用しています。
マインドマップを使ったテスト分析・設計
テストコードの実装
業務ルール整理
デシジョンテーブルやCFDの活用
しかし実業務でも不具合がリリース後に発生することがあり、いろいろ忘れているなと感じていたため、この際受験してみようと思いました。
どうやって勉強したのか・勉強して感じたこと
実施したことは以下の3つです。
① サンプル問題解く
ISTQBが公開しているサンプル問題があります。
資格勉強の鉄板かもしれませんが、過去問やサンプル問題を見て、試験問題のイメージをつかむことにしました。
とりあえず初期に実施し、復習や深掘りをした後、受験前に再度解いて、受験当日にモチベーションをMAXにする的なことをしていたので、今回もやりました。
このおかげで本番で面食らうことはなかったです。
（問題の難易度が簡単だったというわけではないです。）
② 間違えたところのシラバス範囲読む
①のサンプル問題ごとに、シラバスの該当箇所（学習の目的）が記載されています。
そのため、間違えた部分のシラバス範囲を重点的に読み込むようにしました。シラバスを読んでいるといろいろな気づきを得られました。
1. テストプロセスにおけるテストアナリストのタスクではなんとなくでしか理解していなかった部分（テスト分析・設計）に気づくことができました。
（JSTQB FLをちゃんと勉強できていなかっただけかもしれませんが。。）
現状の業務は小規模な開発業務だったため、何とかなっていた部分がありましたが、今後規模が大きい開発業務に携わる際はシラバスに載っている知識は抑えておいた方がよいなと思いました。
4. ソフトウェア品質特性のテストでは、テストのグルーピングを実施する際に参考になると思いました。
実務では整理したユースケース記述を基にどんなテストをするのかをマインドマップで整理していました。
整理するときは「このユースケースで起きると価値がなくなってしまうもの」「これは出来ないと意味がないもの」といったいやなことを中心に整理していただけだったので、抜け漏れチェックするときにシラバスの内容を活用できそうだと感じました。
5. レビューのチェックポイントの部分は、要件作成時のチェックポイントにもなるので参考になると思いました。
③ ソフトウェアテスト技法の理解
①と②をやってみて、テスト技法は読むだけでは定着しないなと感じました。
そのため、中途半端になっていたソフトウェア・テスト技法練習帳をメインにテスト技法を実際に使ってみることにしました。
※もちろん実務でも出番があれば、実践してみました。
こちらの書籍では40問と多くの問題があるので、テスト技法の勉強にはもってこいかなと思います。
他にも以下の書籍を参考にしました。
実際に説いてみると開発者目線で使うテスト技法とテストエンジニア目線で使うテスト技法が若干違うなということに気づけました。
たとえば、デシジョンテーブルの作成では、開発者は処理のルールも知っている状態で始めるため、最初から簡単化されたデシジョンテーブルを作ります。
ただ、テストする場合はいきなり簡単化することはありません。詳細（処理内容）はブラックボックスとして捉えるためです。（実際にちゃんと考慮していると思い込んで不具合を仕込んだことがあるので、よくわかります。。。）
簡単化するときは、開発者とコミュニケーションを取りながら実施しますし、リスクが高いところでは簡単化しないこともあります。
こういうところは「作り上げる」という視点と「検証する」という視点で違いがあるなと感じました。
また、同値分割が意外と難しいなと感じました。
いままでは「同じものをまとめるだけ」と思ってやってましたが、よくよく考えるとどんなテストがしたいのか不明確だと、矛盾したクラスが生まれたり、分割できなかったりしました。
テスト分析とテスト設計が分かれている理由も以前より理解できたかもしれません。
受験した感想
手応えは微妙ですw
まったくできなかったわけではありませんが、ちゃんとできた!!と呼べる感じでもありませんでした。
すこし忘れている部分があったり、技法をちゃんと活用できなかったりしたかなと感じました。
途中で勉強できない期間があったので、そこは反省点です。
ただ、今回の勉強を通じて多くの気づきが得られ、良い機会になりました。
今後
テスターになりたての頃に読んでいた[改訂新版]マインドマップから始めるソフトウェアテストをもう一度読んでみようかなと思います。
また、JSTQB FLのシラバスもつまみながら、再度チャレンジして見ます。
と言いつつ、テスト自動化エンジニア試験（TAE）も申し込んでいるので、しばらくはTAEを頑張ります。
追記
受験から約1週間後ぐらいには結果が通知され、無事に合格していました。
この経験を無駄にせず、学んだことを現場業務で活用していきたいと思います。