JSTQB AL TAを学習中に心に残ったことをまとめておく
bun913テストアナリストのシラバスより
心に残った部分
p19（1.4 テスト設計の項目）において「アジャイルソフトウェア開発では、テストオラクルはプロダクトオーナーかもしれない。実際の結果の正しさを判断する方法なしにテストケースを実行すると、付加価値または利点が非常に少なくなり、多くの場合、無効なテストレポートやシステムに対する誤った信頼につながる」
心に残った理由
- アジャイルでは多くの場合重厚長大なドキュメント（設計・仕様）を用意している時間がないと思う
- そうなってくると「この機能の振る舞いはこれで正しいのか」「ユーザーにとって正しい動作は何なのか」ということをテストするには、プロダクトオーナーとのコミュニケーションが重要になるよなぁ
- 他の部分でも「終了の基準」や「特定のユーザーストーリーに基づいてテスト分析を行う」などの文言があり、アジャイルにおけるコミュニケーションや完成の定義の重要性が伝わる文章な気がした
- テストをする前に「何が正しいのか」・・・仕様的な正しさ、ユーザー目線で見た時の正しい動作ということを明確にしておくことの重要性を感じた
bun913テストのアナリストのシラバスより
心に残った部分
p25(2.リスクベースドテストにおけるテストアナリストのタスク）において以下のようなことが書いてある部分。
- リスク識別プロセスでは、可能な限り幅広いステークホルダーを招集することにより、重要なリスクをかず多く検出することが可能となる。
-
テストアナリストは多くの場合、テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している。
- そのドメインの専門家やユーザーとともに行う専門家へのインタビューの実施
- etc
心に残った理由
- テストアナリストにビジネスドメインに関する知識が必要だということだよね
- 以前開発者の同僚と話した時にも、「テスト技法を知ってても、ドメイン知識ないとあまりいいテストかけないのでは？」みたいなことを言われて「わかるわ」と思ったことが、言語化されているように感じた
- スクラム開発現場では専任のQAエンジニアがいないというのはあるあるで、開発チームで頑張ってテストを書いていくことが多いと思う
- 開発や設計という観点だけでなく、テストという観点でもやっぱりドメイン知識って大事だよね。ということに改めて気づかせてくれて、ありがてぇ。ありがてぇ。
bun913テストアナリストのシラバスより
心に残った部分
p29（3. テスト技法 の最初のページ）より
以下のブラックボックステスト技法が K4レベルとなっており、これまでの項目よりも理解だけでなく、実際に現場において使いこなすことが要求されている部分。
- 同値分割法を適用して、特定の仕様アイテムを分析しテストケースを設計する。
- 境界値分析を適用して、特定の使用アイテムを分析しテストケースを設計する。
- デシジョンテーブルテストを適用して、特定の使用アイテムを分析しテストケースを設計する。
- 状態遷移テストを適用して、特定の仕様アイテムを分析しテストケースを設計する。
- ペアワイズテストを適用して、特定の仕様アイテムを分析しテストケースを設計する。
- ユースケーステストを適用して、特定の仕様アイテムを分析しテストケースを設計する。
心に残った理由
- 単純にテストアナリストを名乗るならこの辺りのブラックボックステストを使いこなそうね。という製作陣からの熱い息吹を感じた
- 急にこの分野からK4ばっかりになるもので、圧を感じまして（良い意味で）
bun913テストアナリストのシラバスより
心に残った部分
p31 (3.2 ブラックボックステスト技法）より
- ブラックボックステストは、通常、システム要件仕様やユーザーストーリーといった、何かしらの仕様ドキュメントに基づく。
- 仕様ドキュメントには、特に機能適合性に関するシステムの振る舞いが記述してあるべきである。
- そのため、要件からテストケースを導き出すことは、システムの振る舞いに対するテストの一部となることが多い。
- 場合によっては、仕様ドキュメントが存在しないことがあるが、旧システムからの機能適合性の置き換えといった暗黙的な要件は存在する。
心に残った理由
- 当然なのですが「仕様やユーザーストーリーといった、何かしらの仕様ドキュメントに基づく」が無いとダメだよねって思いました
- 同値分割や境界値分析を開発者が知っていて、それをベースにテストケースを書いたとしても、そもそもユーザーストーリーとかで求めたい振る舞いなどと乖離していれば何も意味がないよねって
- よく「TODOリスト感」が強いスクラムボードを見かけるが、機能の背景や思い、なぜ提供するのか、ユーザーにとって正しい動作はなんなのか、その辺は書いていかないとだよね。と感じたため。
bun913テストアナリストのシラバスより
心に残った部分
p32(3.2.1 同値分割法）より
- EP（同値分割法）は、テストする値の範囲をパーティションの境界まで広げる境界値分析と組み合わせて使用すると最も強力となる。
- EPは基本的な機能が動作していることを素早く判断できるので、一般的に、新しいビルドまたはリリースをすばやくスモークテストする場合に使用する。
心に残った理由
- 最低限の動作確認をしようとする時に、「各振る舞い」ごとに1ケースずつ代表値みたいなのを確かめていくことを自然としているなぁ・・・と思い返した
- 同値分割を自然と意識していたということと同時に、この「EPは基本的な機能が動作していることを素早く判断できる」という言葉を明言化しておくのって大事だよなぁと感じた
- 雰囲気で代表値を選んでるんじゃなくて、ある意味合理的な選択をしているわけよ
bun913テストアナリストのシラバスより
心に残った部分
p65(5.2.2 ユーザーストーリーレビュー）より
この章ではチェックリストによる使用によるテストベースのレビューについて触れられています。
その中で5.2.2でユーザーストーリーに対するチェックリストを作る場合、具体的にどのような質問が考えられるか例示されていた。
- ストーリーは対象のイテレーション / スプリントにとって適切か？
- ストーリーは要求者の観点で記述されているか？
- 受け入れ基準は定義されており、テスト可能か？
- フィーチャは明確に定義されており、他と区別できるか？
- ストーリーは他のいずれのストーリーから独立しているか？
- ストーリーに優先度が割り当てられているか？
- ストーリーは一般的に使用される形式に従っているか？
- <ユーザーの種類>として<あるゴール>をしたい、なぜなら<ある理由>だから
また、以下のようにも記載されている
ストーリーが新しいインターフェースを定義する場合は、前述のような汎用的なストーリーチェックおよび詳細なユーザーインターフェースチェックリストを使用することが適切である。
心に残った理由
- ユーザーストーリーって良くも悪くも組織によって書かれ方が全然違うなって思います
- 今まで「必ず受け入れ基準をちゃんと書きましょう」とはスクラムの中で言ってきたけども、これをIssueテンプレートで用意しちゃうのもいいかもしれないなと思った。
- また、最近だとGitHub Actions などでこの辺りを例えば生成AIにチェックさせるとかいうのも手法として面白いのでは？と思った
- いずれにせよ、絶対にブログか発表はしてみよう
bun913テストアナリストのシラバスより
心に残った部分
p76 付録Aより
ISO 25010 で提供されている表の抜粋を記載してくれている。
ISO 9126 でいうところの品質特性みたいなのが ISO 25010 でいうところの何にあたるか「シラバスに記載されている項目のみ抜粋」してくれている。
心に残った理由
ってことはここに出てくる品質特性は「テストアナリストが意識しておくべき」項目だよねっていうメッセージを感じたから。
bun913無事合格でき、アウトプットとしてもいくつかできたのでスクラップ終了。