正確には、ISTQBのアドバンストレベルの日本語訳のこと。以下のJSTQBのサイトにある。（本来はトップからどうぞ）
ご存じだろうけど、ISTQBは「International Software Testing Qualifications Board」で、JSTQBは日本での加盟組織。ソフトウェアテスト技術者資格認定の運営組織である。
日本語訳として既にファンデーションレベルはあったけど、今回アドバンストレベルの訳が公開された。
結構ソフトウェアテストでの管理関係が書かれていて、参考になる。なお、個人的に非常に良いと思ったのは「15.1 現場への適用のための推奨事項 」。テストの作業効率に悪影響をおよぼす事項を掲示している。30個近い。
例えば、、、。
・機能テストに偏ったテスト計画を策定する
・ドキュメントをテストしない
個人的には、本来ソフトウェアの品質は、そのプロジェクトの長や設計／開発者が保証すべきものと考える。少なくとも、テストチームとの”連携”という意識は必要。上記の例で言えば、開発者などはテスト計画を見て、非機能テスト（非機能要件のテスト）があるかの確認や、ドキュメントのテストをテストチームが行うようになっているかの確認が必要である。テストの工数として、それらも予定に入れておくべきである。
なお、「現場への適用のための推奨事項」の悪影響排除をテストチーム以外（特に設計／開発）の協力の下に行うことや、その製品やプロジェクトでは無視できるとの判断もあろう。しかし大事な点は、それらを計画時に検討したり、作業分担の検討やその合意を取ること。
以下のような項目もある。
・全てのテストを自動化しようとする
他にも類似する項目があるが、ちょっとしたソフトウェアテストの本や講演をかじって全部に適用しようとするケースが少なくないと思える。そのために失敗とか作業のやり直し。あるいは、プロジェクトそのものの再構築になることすら発生しているように聞く。テストチームからの提言が上辺だけのものになっていないかの確認としても、本「現場への適用のための推奨事項」の部分は役立つと思う。
なお、個人的に引っかかるのが「システム統合テスト」。P25で、ファンデーションレベルでの追加のテストレベルとして記載してある。しかし、ファンデーションレベルでのP21に「システム統合テスト」は明記してある。少し細かいかもしれないが、従来での”単体テスト”が、実際はISTQBで言うところの装置のシステムテストに該当したりするケースが多い。そのため、「システム統合テスト」という用語は浸透しておくべきと考える。つまり、「システム統合テスト」は、ファンデーションレベルでの必須用語としておくべきと考える。
ちなみに個人的には、本訳に掲載されているIEEE 1044をちゃんと押さえてないような気がする。持ってたか？？？ 時間見つけて確認するつもり。
