JSTQBシラバス V4.0.J01 から色々キャッチアップ〜レビュー編〜

はじめに

私はJSTQBのAL保有マンですが、FLを取ったのは2018年ですので、真面目にリスキリングしようと思いました。
この記事の公開は2024年5月で、試験は2024年10月以降らしい。
まだ慌てる時間じゃないということで、気ままにシラバスを見ていこうと思います。
また、おそらく私の記事ではISTQBの原文は参照しません。
過去の経験からあんまり意味がないとわかっているからです。ex.日本語シラバスでよくわからんところはどうせ原文でもよくわからない。
本日はレビューの部分について実施します。
ちなみに以下のnoteでレビューの目的についてよくわからないところがあったので、その点も調べます。まだシラバスを読まずに「はじめに」を書いています。

静的テストの基本

静的テスト＝レビューだと思っていましたが、これは違うみたいです。
人手による確認=レビューとか
ツールによる確認=静的解析とか
になるらしいです。

実例マッピング

実例マッピングで生きている人には申し訳ないですが。
わざわざ「静的テストの基本」の最初の章に書く意味あるかはよくわかりませんでした。レビュー技法の一つじゃないかと思わなくもないです。これってアジャイルテスティングの闇だったりします？

静的テストで確認可能な成果物

ほとんどの成果物は静的テストの対象になるらしい。
- 人間による解釈が困難なものはレビュー不可能。(ダンプとかかな？)
- ツールで解析してはいけないものは静的解析不可能。
読んで理解できる成果物はレビューの対象になる。
静的解析はツールに適した構造が必要とのことです。そりゃそうだ。文章もここで言う「構造」だと思うので、「LLMは当てはまらないじゃん」は違うかなと思いました。この文章でLLMは多分想定していないと思いますが。

静的テストの価値

早期テストの原則を満たすらしい。
動的テストで出せない欠陥を導出できる場合も多分にある。単なるシフトレフトではない。と理解しました。
「静的テストには、さまざまなステークホルダーが参加することを推奨する」は個人的にはレビューの目的によるかなーと思いました。
例えば静的解析の結果を見るのに必ずしもデザイナーが見た方がいいかというとそうでもない気がしました。

静的テストと動的テストの違い

品質特性によって動的テストを選ぶのか、静的テストを選ぶのか決めるらしいので、品質特性ベースのテストアプローチをしていたらより効果的に使えそう。
静的テストでしか発見できない欠陥、動的テストでしか発見できない欠陥があるということを強調しているみたいでした。
検出できる欠陥の種類についてはリスクベースドテストで参考になりそう。

フィードバックとレビュープロセス

早期かつ頻繁なステークホルダーからのフィードバックの利点

計画書レビューや要件定義レビュー、バックログリファインメントを意識して書いている感じがする。
WFにおいてはいろんな設計資料が出てくるけど、ここでは「早期かつ頻繁」なフィードバックの利点に入らない気がした。

作業成果物のレビュープロセス

自明なことなのでここでは省略

レビューでの役割と責務

ここでは基本的には自明なので省略。
ISO/IEC 20246という規格があることを私は知りませんでした。
ただ、中身についてはシラバスでは触れられていません。

レビュー種別

昔は「レビュー技法」あった気がするけど、「レビュー種別」になったのか？
「チェックリストレビュー」とかがレビュー技法でしたっけ？忘れた。
「非公式レビュー」や「インスペクション」などがレビュー種別として定義されています。
インスペクションについては「主な目的は、不正を最大数発見することである」といあるので、やはりレビュー対象成果物の品質を上げることにフォーカスしており、形式性で定義したのがレビュー種別があるっぽいです。

レビューの成功要因

重要なのでいつも読んで心に刻みつけたい。

おわりに

レビュー技法の記載がなくなったことと、実例マッピングの場所が気に食わなかったですが、静的テストが単なるシフトレフトではないことを確認できたのがメイクセンスしました。多分2018年のシラバスでも同じこと言ってましたが。

とりあえず早くJSTQB AL 静的テストシラバスが待たれる。

参考文献

https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf