マガジンのカバー画像

アドカレ2023

25
2023年のアドベントカレンダー
運営しているクリエイター

記事一覧

テストベース

テストベース

HAYST法が重いという誤解があるようなので、アドカレ500文字程度で書いていく。

まずは左上の「テストベース」。
「テストベース」とはテストをつくって実行するための基盤となる情報のこと。

土台がしっかりしていなければ地震に強い家は建たないのと一緒で、テストベースが足りないとたいしたテストにはならない。

ということで、集めまくるんだー。
顧客から入手した資料、要求、システム仕様書、ソフトウェ

もっとみる

テスト戦略

アドカレ2日目は「テスト戦略」。

戦略と聞くと、「それって、元帥とか大将といった偉い人が集まって立てる難しいものでしょう?」と引かれてしまうが、テスト戦略(※)はそんなに難しいものではない。

戦略は、ドラクエの「作戦」のことだから。

ドラクエの作戦とは、「ガンガンいこうぜ」 「いのちだいじに」 「めいれいさせろ」 「まほうつかうな」 「いろいろやろうぜ」「みんながんばれ」「バッチリがんばれ」

もっとみる
D-Case

D-Case

アドカレ3日目は「D-Case」。

「テストベース」でテスト戦略の選択に必要な情報を集め、「テスト戦略」で戦略を選択するところまで書いた。

今回は「D-Case」を使って選択したテスト戦略を合意する話だ。
と言ってもD-Caseの説明はしない。必要な人は、『はじめてのD-case』を読むべし。なんといったってD-Caseの第一人者の松野先生が書いている(私も少し書いている)お勧めの入門書だから

もっとみる
テスト要求分析

テスト要求分析

アドカレ4日目は、「テスト要求分析」。
「テスト分析」と読み替えてもらっても構わない。

上の図で「1. テスト戦略」と「2. テスト要求分析」の背景色が白と黄で異なることと、横に並んでいることから分かる通り(←わかんねーよ)、テスト戦略はテストマネージャーの役割で、テスト要求分析はテストアナリストの役割となっており、並行実施できることがわかる。(←だから、わかんねーってば)

さらに図を見ると、

もっとみる
5. 6W2H

5. 6W2H

アドカレ5日目は「6W2H」。

上の図の最源流にある「テストベース」を木構造で書き写したものが「6W2H」である。書き写す目的はテストベースをだいたい頭に入れて、FV表を作成するためだ。

だから、前回の繰り返しになるが、すでに丸太(=大きいテスト対象)を薪であるバックログ(=小さなテストアイテムやテスト条件)に分割(スライス)できていたり、ごく小さな機能拡張なら不要な活動だ。

まずは、6W2

もっとみる
6. FV表のF

6. FV表のF

アドカレ6日目は「FV表のF」。FはFunctionのF。

テスト要求分析の回で、ホールケーキをショートケーキに切り分ける例で、「うまく切り分けないと兄弟喧嘩になる」と書いた。テストベース(特に機能仕様書)はホールケーキであり、FV表の各行は切り分けられたショートケーキだ。そして、FV表のFは切り分ける単位である「目的機能」である。

FV表については前にManiaXというテストの同人誌に『詳説

もっとみる
7. FV表のV

7. FV表のV

アドカレ7日目は「FV表のV」。
VはVerificationのV。

さて、具体的にVに何を書くかだ。
スクラムでユーザーストーリーをバックログ管理しているケースなら、そもそもFV表は不要で、バックログにアクセプタンスクライテリア(AC:Acceptance Criteria)を書いておけばよい。

FV用のVもACと全く同じで構わない。さらに言えは、書いたものは「ハイレベルテストケース」となる

もっとみる
8. FV表の表

8. FV表の表

アドカレ8日目は「FV表の表」。← ふざけてみた。

HAYST法の中間成果物には「FV表」や「FL表」という表があるが、構造的には表ではない。「表」を辞書で引いてみる。

太字で示した箇所がポイント。
「関係を理解」するためのツールが表である。

さらに我々は、エンジニアである。エンジニアが表という場合は「データモデルとしての表」も考えるべきだ。ただ、その場合は「表」ではなく「テーブル」と呼ぶこ

もっとみる
9. テスト設計

9. テスト設計

アドカレ9日目は「テスト設計」。

テストでは、「FV表」を1行ずつ実行すれば良いが、各行は目的機能やユーザーストーリーなので“概要しか書いていない抽象度が高い、ハイレベル・テストケース”となる。

例えば、「旅行者として、新幹線のチケットを購入したい。旅先に着きたいからだ」というユーザーストーリーがFV表に書かれていたとする。

こちらのユーザーストーリーのテストをするためには具体化しなければな

もっとみる
10. ラルフチャート

10. ラルフチャート

アドカレ10日目は「ラルフチャート」。

ラルフチャート(Ralph's chart)についてもFV表と同様に、前にManiaXというテストの同人誌に『詳説ラルフチャート』というタイトルで書いている。

ラルフチャートがどのようなものかは、上記『詳説ラルフチャート』に乗っているフォーマットと、例を見るのが早い。

ラルフチャートは、目的機能1つに対して1枚描く。こういうと、「えー。それは大変だ! 

もっとみる
11. 有則のテスト

11. 有則のテスト

アドカレ11日目は「有則のテスト」。

ラルフチャートを描くことで、テスト対象の仕組みを理解する。その上でラルフチャートの特徴によって3つのタイプのテスト技法を適用する。

3つのタイプのテスト技法とは上から4行目までだ。なお、1行目の「少ない」は、HAYST法のテスト対象外(開発者本人による単機能テストでHAYST法の前に実施する)である。

ソフトウェアテスト技法には様々なものがある。

上記

もっとみる
12. 無則のテスト

12. 無則のテスト

アドカレ12日目は「無則のテスト」。

無則のテストは、表の3行目にあたる。

ラルフチャートの入力のところにある複数の因子の間に論理的関係(有則)が無いことを無則と呼ぶ。無則のテストの出力は正常系に限定する。

無則の因子の具体例を示す。

上記の画面のテストをしようとしたときに、それぞれの単機能のテスト(例えば“スマート句読点”スイッチのテスト)を実施する。次に複数の設定項目の組み合わせテスト

もっとみる
13. 状態遷移テスト

13. 状態遷移テスト

アドカレ13日目は「状態遷移テスト」。

状態遷移テストは、表の4行目にあたる。

上記表の最終行が、ラルフチャートを書いた結果、状態遷移テストを実施すると判断する材料である。

入力のところは「-」である。これは入力の有無は考慮しないということで、入力はあってもなくても良い。(通常、広い意味での入力により、状態は遷移する。)

次の状態変数がRead/Writeになっている点がポイントだ。状態を

もっとみる
14. FL表

14. FL表

アドカレ14日目は「FL表」。

FL表は、上図の有則のテストと無則のテストが合流しているところにある。両方ともテストデータをつくる前にFL表で因子・水準の検討をした方が上手くいく。

四角だから成果物(つくるもの、残すもの)を表している。

ソフトウェアテストをつくるときにテスト条件やテストケースをつくると言うが、どちらも文章なので、書くのが面倒だなあと私は思う。だから、その代わりにFL表をつく

もっとみる