D.Horiyama's output

JSTQB ALTAシラバス ch1 (1/x)

ISTQBJSTQBテスト技術者

出典: 

http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TA_Version2012.J01.pdf

古い (ISTQB最新は2019版)

1. テストプロセス

1.1 イントロダクション

2019版更新点: 各活動がISTQB FL(2018)シラバス時点ですでに分割されてる

テストアナリストの主な仕事は:

  • テスト分析
  • テスト設計
  • テスト実装
  • テスト実行

「テストの計画作業、モニタリング、およびコントロール」がない

1.2 ソフトウェア開発ライフサイクルにおけるテスト

2012 J

テスト活動は、選択したソフトウェア開発ライフサイクルモデル（シーケンシャル、イテレーティブ、またはインクリメンタルのいずれか）と整合している必要がある。

2019 I

Testing activities must be aligned with the chosen SDLC whose nature may be sequential, iterative, incremental, or a hybrid mix of those.

ハイブリッドSLDCについて言及されてますね

https://glossary.istqb.org/app/en/search/test%20bed

test rig / test bed … test environmentのシノニム

アジャイルプロジェクトでは、一般的に、公式度の低いプロセスを使用し

In an Agile project, it is common to use a less formalized process …

less formalized

「公式度の低い」…formal/informal reviewと同じような意味合いかな

埋め込み型イテレーティブモデルの場合、テストアナリストは標準的な計画作業および設計の側面に関与することが期待されるが、

In an embedded iterative model, Test Analysts should expect to be involved in the planning and design aspects, but …

embedded iterative development model — http://istqb-glossary-explanations.blogspot.com/2013/08/embedded-iterative-development-model.html

  • 高水準の設計はシーケンシャルモデルで。ドキュメントとかも書く
  • 低水準の詳細設計やコーディング、テスト等はイテレーティブ

expectするのはTest Analysts → 「計画および設計に関与するつもりであるべき」というTest Analystsとしてあるべき心構えを説いている気がする

but would then move to a more interactive role as the software is designed, developed and tested.

裏を返せば、計画や設計への関与はless interactive roleだと言っている

  • 高水準の設計はシーケンシャルモデルで。ドキュメントとかも書く
  • 低水準の詳細設計やコーディング、テスト等はイテレーティブ

イテレーティブで実装担当者と密に連携する、くらいの意味かな

1.3 テストの計画作業、モニタリング、およびコントロール

2019版シラバスからまるごとdropしてる

1.3.1 テスト計画作業

テスト計画を、機能テストに限定されないようにする。すべての種類のテストをテスト計画内で考慮

test type (JSTQB FLシラバスより)

  • 機能テスト
  • 非機能テスト
  • WBテスト

  • 変更関連のテスト

    • 確認テスト
    • リグレッションテスト

テストマネージャと連携してテスト見積りをレビュー

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

5.1.2 テストマネージャーとテスト担当者のタスク

「テストマネージャーの典型的なタスク」より抜粋

プロジェクトの背景を考慮した上で、テスト目的とリスクを理解してテスト活動を計画する。これにはテストアプローチの選択、テストにかかる時間/工数/コストの見積り、リソースの獲得、テストレベルやテストサイクルの定義、欠陥マネジメントの計画を含む。

5.2.6 テスト見積りの技術

専門家の知識を基にする：テストのタスクの所有者の経験、または専門家による見積りを基にしてテスト工数を見積る。

https://ja.wikisource.org/wiki/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%BB%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A3%E3%83%BC%E3%81%8C%E7%9F%A5%E3%82%8B%E3%81%B9%E3%81%8D97%E3%81%AE%E3%81%93%E3%81%A8/%E4%B8%80%E7%95%AA%E3%81%86%E3%81%BE%E3%81%8F%E8%A6%8B%E7%A9%8D%E3%82%82%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%AF%E3%81%9D%E3%81%AE%E4%BB%95%E4%BA%8B%E3%82%92%E3%81%99%E3%82%8B%E4%BA%BA%E3%81%A7%E3%81%82%E3%82%8B (プロジェクト・マネジャーが知るべき97のこと/一番うまく見積もれるのはその仕事をする人である)

テスト分析,設計,実装,実行までこなすことになっているテストアナリスト自身がいちばんよく見積もれるはず

構成テスト

http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf

構成テスト（configuration testing）： portability testing を参照のこと。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

以下は非機能テストの例である。…
• システムテストでは、サポート対象のすべてのブラウザーやモバイルデバイスで表示が正しく動作することをチェックするために移植性テストを設計する。

「構成テスト」: 移植性テストの古い呼び名

「移植性テスト」は例えばシステムテストレベルで実施される非機能テストの一種

ドキュメントのテスト

静的テスト

インストール手順のテスト

参考: https://ja.wikisource.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%8C%E7%9F%A5%E3%82%8B%E3%81%B9%E3%81%8D97%E3%81%AE%E3%81%93%E3%81%A8/%E3%81%99%E3%81%B0%E3%82%84%E3%81%8F%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%80%81%E3%81%93%E3%81%BE%E3%82%81%E3%81%AB%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4 (プログラマが知るべき97のこと/すばやくデプロイ、こまめにデプロイ)

確認テストおよび回帰テストを実行するための時間も計上する必要がある。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

5.2.5 テスト工数に影響する要因

「テスト結果」より抜粋

  • 検出した欠陥の数と重要度
  • 必要な再作業の量

テストベース、テスト条件、およびテストケースとの間に複雑な関連性が存在することがある。たとえば、多対多の関連性がこれらの成果物の間に存在することがある。

https://www.ipa.go.jp/sec/publish/tn10-005.html (SEC BOOKS：高信頼化ソフトウェアのための開発手法ガイドブック p.19)

トレーサビリティマトリックスでは多対多を表現できる

1.3.2 テストのモニタリングとコントロール

テストのモニタリングとコントロールは、通常、テストマネージャの担当であるが、テストアナリストは、コントロールを可能にするための測定を行う。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

5.1.2 テストマネージャーとテスト担当者のタスク

「テスト担当者の典型的なタスク」抜粋

  • テスト条件を識別して文書化し、テストケース、テスト条件、テストベースの間のトレーサビリティを確立する。
  • テストケースとテスト手順を設計し実装する。
  • 詳細なテスト実行スケジュールを作成する。
  • テストケースを実行し、結果を評価して、期待結果からの逸脱を文書化する。
  • 性能効率性、信頼性、使用性、セキュリティ、互換性、移植性などの非機能特性を評価する。

1.4 テスト分析

テスト計画作業では、テストプロジェクトのスコープを定義する。テストアナリストはこのスコープを使用して、次のことを行う。

  • テストベースを分析する。
  • テスト条件を識別する。

I (2019)だと追加されてる

Analyze the test basis
• Identify defects of various types in the test basis
• Identify and prioritize test conditions and features to be tested
• Capture bi-directional traceability between each element of the test basis and the associated test conditions
• Perform tasks associated with risk-based testing (see Chapter 2)

  • テスト分析のために利用するテストベースにそもそも欠陥が入っていまいか？
  • 優先度

  • 双方向のトレーサビリティ

    • JSTQB FL(2018)シラバスでも100回くらい出てくる頻出テーマ

テストベースの欠陥ってどんなのがあったか？

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

1.4 テストプロセス 抜粋

テストベースとテストアイテムを評価して、以下のようなさまざまな種類の欠陥を識別する。

  • 曖昧
  • 欠落
  • 不整合
  • 不正確
  • 矛盾
  • 冗長なステートメント

1.5 テスト設計

テスト設計のプロセスに含まれるアクティビティ

やはりI2019の追加分がある

  • テスト条件・テストケースを支持するテストデータの識別
  • テスト環境の設計、必要なインフラやツールの識別
  • 双方向のトレーサビリティ(頻出)

テスト設計における留意点

一部のテストアイテムは、手続き化されたテストを定義するよりも、テスト条件のみを定義することで、より適切に対処できる。この場合、手続き化されていないテストに対するガイドとして使用できるように、テスト条件を定義する必要がある。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

4.4 経験ベースのテスト技法

4.4.3 チェックリストベースドテスト

チェックリストにあるテスト条件をカバーするように、テストケースを設計、実装、および実行する。

チェックリストはハイレベルのリストであるため、実際にテストをする際には複数の解釈が発生しうる。その結果、広範囲に網羅できるが、記載された内容のまま同じテストを再現するのは困難になる。

これと同様の特徴・留意点がありそう

あと、やはり追加分がある

Test design effort must be prioritized and balanced to align with the risk levels and business value.

優先度づけ、リスクとビジネス的価値(≒コスト)のバランス

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

1.1 テストとは何か？

ソフトウェアテストはソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する 1 つの手段である。

1.5.1 具体的テストケースと論理的テストケース

ISTQB ALTA (2019)だと「1.4.1 Low-level and High-level Test Cases」

メリデメが箇条書きになっててわかりやすい

1.5.2 テストケースの作成

ISTQB ALTA (2019)だと「1.4.2 Design of Test Cases」 (テストケースの設計)

「テストオラクル(test oracle)」

oracle … 「神のお告げ」的な意味

要するに「これを正とする」ってやつ

https://glossary.istqb.org/app/en/search/oracle

A source to determine an expected result to compare with the actual result of the system under test.

http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf

「コードであってはならない」

cf. テストベース(test basis)はコード含む

プロジェクトリスク（文書化する必要のあるもの、文書化してはいけないもの）

「文書化してはいけないプロジェクトリスク」って何だろう…

• Project risks (what must/must not be documented)

「義務」じゃなくて「推量」のmustではあるまいか？

「文書化されているに違いない/されているはずのないプロジェクトリスク」

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

5.5 リスクとテスト

5.5.2 プロダクトリスクとプロジェクトリスク

アジャイルライフサイクルのような一部のプロジェクトでは〜

I2019で消えてる。なぜ？

The exit criteria for test analysis and test design…

I2019追加分

doneの定義、次工程のreadyの定義の話