FC2ブログ

ISTQB 2.7 終了作業を読む

終了作業とは主に下記の四つ

1.全テストの実施完了確認と発見不具合の対応確認
2.成果物を必要な場所(人)に渡す
3.振り返りミーティングの実施
4.テストウェア、テスト環境等を開発システムバージョンと関連付けて構成管理する


修了作業は重要だけど、結構無視される。
なので、プロジェクト計画段階で明示的に組み込んでおく
いろんな理由をつけてやりたがらないので
受託契約のときは契約内容に組み込んでおく

テスト終了作業の確認するための判断基準の例としては
・実行したテストケースの割合
・再利用可能なテストケースの割合
・自動化したテストケースと自動化予定のテストケースの割合
・未解決の欠陥とレポートした割合
・成果物として認識し保管したものの割合

最後の判断基準、なんとなく分かるが何語だ
スポンサーサイト



テーマ : ソフトウェア
ジャンル : コンピュータ

ISTQB 2.6 終了基準の評価とレポートを読む

テストプロセスとして、終了基準を満たしているかを
判断するために、いろんな情報が必要なので
キチンと進捗も含めてモニタリンクしておく。

要は終わりを決めておかないと
エンドレスになるのは分かってるから
終わらせる基準は決めておいて、
それに必要な情報をあつめておきましょうって話。


終了基準には、
・テスト項目数、実施数とその結果
・発見バグとその修正状況は、影響度(重要度?)
・仕様変更の発生、リリース回数、各リリースまでのテスト消化数
・予算と実績(金の話≒稼動時間)
・日程の状況(遅れ、進み)
・リスク情報とその対策状況
・テスト進捗阻害要因に費やした時間
・再テストしたアイテム
・テスト時間の予測と実績
こんな感じみたい。

Ieeeではレポート作成のためにサマリレポートの構成を定義てある。

なお、テストレポートについては
テスト全体が終了したときだけじゃなくて
テストレベル(単体、結合)の区切りの時にまとめることもできる。

ISTQB 2.5 テスト実装と実行を読む

2.5.1 テスト実装

テスト実装ですることは
・テストケースの準備
・テスト手順の作成
・テストデータとテスト環境
・テスト実行スケジュールを立てる(優先順位を考えてね)
・テストレベルの妥当性
・テスト支援ツールの準備

いろいろ在るけど、テスト実施前に実施中に起ると思われることの
すべての準備をしておくということ。

例外として、エラー推測や探索的テストといった
経験ベースのテスト技法はテスト実装とテスト実行が
同時進行することもある。
ただその場合回帰テストが面倒。

2.5.2 テスト実行

テスト実行はテスト対象がきて準備が整ったとき(=開始基準を満たしたとき)に開始する。
基本、テスト手順通りに進めていくけれど、手順の逸脱もある程度はOK。
でも、そのときは逸脱した手順をシッカリ記録しておくことが重要。
自動テストの場合は手順逸脱はない(あったら自動の意味がない)

テスト実行で一番重要なのはテスト結果と期待結果の比較。
ここでしくじると、テストすべてが台無しになるので。
結果と期待値の差異はインシデント。
テスト仕様が間違っていないことを確認する。
これは間違ったテスト仕様で行っている可能性があるから。

テスト実行の記録は結果としてしっかり記録する。
コレをしないと、戻り作業が発生するから。
テスト環境も進化していくのでテスト実行時のバージョンを特定できるようにする

プロダクトごとに記録すべき内容はかわってくるけど
要は情報として使えるものは記録しておけってこと。


ほっとき過ぎて、CMが入ってた…終わってるなぁ
Advancedのテストもあることだし、またぼちぼち始めます。

ISTQB 2.4 テスト分析と設計を読む

とりあえずこの章は「識別」て単語がやけに出てくるが
元のidentifyの意味で考えたほうが分かりやすい


テスト計画の時には一連のテストの目的を決定する。
テスト分析と設計のプロセスではこの目的を基に
・テスト条件の決定
・決定されたテスト条件を実行するためのテストケースの作成。
が行われる。


リスク分析とテスト計画を基に決めた優先順位の基準を全プロセスに適用する。


2.4.1 テスト条件の識別
テストをどうやっていくかを明確にするため
テストベースとテストの目的を分析してテスト条件を明確にする。


テストアイテムの機能的、非機能的特性を基にして決定したテスト条件レベル構成は以下のことに使える
1.テストベースの粒度の設定
2.プロダクトリスクへの対応
3.マネジメントレポートとその情報のトレーサビリティに対する要件
4.テストケースを開発せずにテスト条件だけで作業するかどうかの判断


2.4.2 テストケースの生成
テストケースの設計はテスト戦略で決定したテスト技法を用いて
テスト条件を洗練しつつ、段階的かつ入念に進めていく
これらは繰り返し、検証、要件トレースができなければならない。


テストケースの設計では以下を特定する
・事前条件
・テストデータ要件
・期待結果と事後条件


期待結果については、単体なのか複数なのかをきちんと定義する必要がある。

テストベースが明確になっていれば単純だが実際はそうなっていないことのほうが多い。
そういった場合に、テスト担当者に専門的知識があることや、
情報のありかが明確になっていることが重要になる。


テスト条件、テストケースの開発の間にテストの成果物としてドキュメントが作られる。
それらのドキュメントの基準としてIEEE829がある。


テスト分析と設計ではテストのスコープで品質特性を緋もつけられる。
ISO9126にその辺のことに使える情報が書いてある。


テスト分析と設計プロセスはレビュー、静的解析を組み合わせて行うといい。
テスト、リスク分析テスト計画などテストの成果物でもレビューや静的解析をすべき。


テスト設計では必要となる詳細なテストインフラストラクチャの要件を定義する。
テストインフラストラクチャにはテスト対象、テストウェア以外のものも含まれる。
※人を含めた実際にテストが実施できるようになるものすべて


テスト分析と設計をモニタリングするためのメトリクス
・テスト条件による要件網羅の割合
・テストケースによるテスト条件網羅の割合
・テスト分析から設計の間に検出された結果の数


もうめんどくさいのでピックアップ。



ISTQB 2.3 テスト計画作業とコントロールを読む

テスト計画


『テスト計画作業のほとんどはテストに関わる活動を始めるときに着手し、テスト戦略で
識別された使命や目的を達成するためのすべての活動やリソースを識別し実装する』

(引用箇所 32ページ 4行目)

すいません、何語ですか?
何を言いたいんだかが全く分からん、大変、素晴らしい直訳日本語ですね(笑)

テスト計画は開発プロジェクト開始とともに着手して、テスト戦略にしたがって計画する

多分、こんな感じのことが言いたかったのだろうね。
で、テスト戦略の意味の説明をしたかったがために
余計な説明を入れて分かりにくちゃったねぇ。
って国語の時間ですか?

リスクベーステストは、リスク軽減に向けて、必要となる軽減策を
テスト計画プロセスに反映するために使う。

リスク対策は計画に入れておけってことだね。


これによりテスト活動の相対的な優先順位もテスト計画プロセスに反映できる。

テストベース、テスト条件、テストケース、テスト手順の(テスト計画の?)成果物は
それぞれ複雑に関係しているので、よく理解しておく必要がある。

テスト計画するには、様々なことの兼ね合いがあるんで一通り知っていたほうがいいと。

まあ、実際には計画なんて、顧客やエライ人の一言でさくっと換わることのほうが多いが

金払ってる人が一番強いのだよ(笑)


テストコントロール


テスト実施ための継続的な活動です。
進捗や、計画からの逸脱などの状況報告も含まれる。

テストコントロールではテスト結果やプロジェクトなどの様々な状況の変化に対応しなければならない。

世の中上手くいかないことのほうが多いんで、ちょくちょく状況見て悪くならないように舵取りをするってこと

テスト以外でも真っ当なところでは当たり前にやってることだね。

頭にテストをつけただけなので細かいところは省略。


テスト計画とテストコントロールをモニタリングするためのメトリクス
・リスクおよびテストカバレッジ
・欠陥検出およびその情報
・計画したテストウェアの開発およびテストケース実効時間と実時間の比

なんだか、ほぼ引用だな。
プロフィール

Thefool

Author:Thefool
FC2ブログへようこそ!

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード