ユースケース駆動開発についての勉強まとめ そして思ったこと

先日、以下の書籍を使ってユースケース駆動開発について勉強をしました。

ユースケース駆動開発実践ガイド

経緯

私はキーワード駆動テストアプリケーションを作っています。
せっかく時間をかけたものなので、これを公開してもっと多くの人に利用してもらおうと思いました。

ただ、そこにはまだまだ実現したいことが多く残っていました。
そこで、私はアプリケーションを利用してくれる方の中から開発に参加してくれる方を募ると良いのではないかと考えました。

しかし、私は一つの課題があることに気づきました。
これがどういうものなのかが、私にしか理解できないものになっていたことに。

そこで、対象の構造を改めて誰もが分かる形で表現するにはどうしたらいいのか？と考え、
手に取ったのが本書でした。

本書を読んだのは、本当にたまたまです。
他にもUPやRUPの本、DDDやRDDの本も手に取りましたが、要求分析からテストまでの開発の流れを体系的に理解する必要がある今の私には、これが一番自分に合っていたからです。

ユースケース駆動開発において予備設計に進める上で重要だと感じた点

要求

機能要求…システムができること(非機能も含める)
振る舞い要求…機能要求からユーザーとシステムの対話を明らかにしていくこと。

ユースケースモデリング

要求を元に、アプリケーションの振る舞いをユースケースとして記述することで、アクターとシステム間の振る舞いを明確にする。

ドメインモデリング

問題とする領域を明確にし、現実に基づいたユースケースを記述する上での用語を明確にする行為。
何を解決しなければならないのかを明らかにするために、問題領域をドメインモデルとして明らかにする。

ポイント

ユースケース記述を、解決すべき領域（ドメインモデル）の用語を用いて叙述的に書くこと。
この記述が、オブジェクト自体やオブジェクト同士の関連を見つける目的で実施されるロバストネス分析の実施を補助することになる。

勉強のまとめ

私はJJUGに参加しているのですが、昨年参加した「ビール片手にLT大会」が今年は11/21に開催されるということでした。
ちょうど良い機会だと思い、勉強のアウトプットもかねて発表してきたので、備忘録として残します。

www.slideshare.net

様々な開発手法

ロバストネス分析の結果を明らかになった、バウンダリ／エンティティオブジェクト、コントローラからシーケンス図を作成し、
そこに表現されたオブジェクト間の相互作用、必要な属性をオブジェクトに反映し、抽象的に表現した図がクラス図になります。

ユースケース駆動開発であるICONIXは、このようなアプローチで開発を進めていく手法を採用しています。

一方、本書を読む中で「そもそもオブジェクトととは？」について調べる為に参照した下記書籍では、ユースケース駆動開発とはまた別のアプローチでオブジェクトをに他の手法が紹介されていました。
詳しくは別の機会にしますが、OOADというジャンルではオブジェクトを設計をしていくという目的は同じなのですが、そこへのアプローチの仕方は他にも様々あるのだなと感じました。

私が大切だと思ったこと

開発の話からそれますが本書だけでなく、日常生活からの体験も踏まえて思ったことがあります。

• 自分が何を大切にしていて、何かをするときに関わる人が居るときはその人は何を大切にしているのかを話してお互いに納得すること
• 様々なシーンでの役割を理解すること
• 良い仕事は良好な関係から生まれること

オブジェクト設計ではないですが、この世で生活をする上ではいろんなシーンがありそこでには自分の役割があるはずです。

• 職場での役割
• 家庭での役割
• 社会での役割

役割がなければ自分で作ればいいのかなと思います。
役割が合わないと思えば、合わせるか、変えていけばいいのです。
私はオブジェクト設計を通してこんなことを思いました。
変な人ですね(^_^;)

今後、UPやRUP、DDDのアプローチついて勉強するのが楽しみです。

デザインパターン学んで得られたこと

キーワード駆動アプローチのテストシステムを作る上でその構造について悩んだ時に読んだこちらの書籍と、そこから学んだことを受けて考えを巡らせた時のことについて書きます。

増補改訂版Java言語で学ぶデザインパターン入門

デザインパターンの書籍を読んだ感想

テストシステムを構造化、アイディアを形に（実装）する上での良い参考例になりました。
特に「保守性」や「分かり易さ」が鍵になると考えていた次の要件を実現することができるようになったと思います。

• 継続的にメンテナンスしながら使用していきたい
• 他の人にもメンテナンスしてもらいながら利用してもらいたい

デザインパターンから具体的に恩恵を受けた点

具体的には次のような点でデザインパターンの恩恵を受けることができました

• 自分のプログラムを構造化できた
• 再利用しやすい構造にリファクタリングできた
• JUnitといったOSSのソースを読めるようになった（コードの意図を理解できるようになった）
• アプリケーション全体を設計する手法を知らないことにも気づけた

おかげで、OOADについて知り、ある方の紹介でユースケース駆動設計についても知る機会を得ることが出来ました。
jugemix.hatenablog.com

「ICONIX」では、デザインパターンは詳細設計フェーズでオブジェクト間の相互作用を構造化する一つの手法として紹介されています。
設計について勉強しようと思っている方は、デザパタの勉強から始められると、プログラムの構造設計からアプリケーションの構造設計へと思考を広げられるようになるので良いと思います。

実際に役立ったデザインパターン

ここからは実際にOSSの中で見られたデザインパターンや、テストシステムを構築する際に実際に役立ったパターンを具体例と合わせてまとめます。

チェーンオブレスポンシビリティ

目的の処理を持つオブジェクトをチェーンのように実行していく。JUnit4.x系ではStatementクラスとして採用されているパターンである。

次のソースのmethodBlockメソッド（281行目参照）を参照いただきたい。
github.com
ここでは、Statement抽象クラス型のstatementオブジェクトに実行するオブジェクトRunBefores/RunAfters等のオブジェクトが追加されていることに気づくと思う。

テンプレートメソッド

抽象メソッドで構成する処理の流れを具象メソッドにまとめ、抽象メソッドの実装はサブクラスに任せる。
これにより、具象メソッドで処理の全体の流れは強制しつつ、具体的な処理内容は個別の実装に任せたい時に有用。
共通の前処理と後処理の間に個別の処理を実装したいーといった時に効果を発揮する。

例えば、チェーンオブレスポンシビリティで紹介したBlockJUnit4ClassRunnerクラスは実際にインスタンス化されるランナーであるが、この継承元のParentRunner抽象クラスではこのStatementを実行するrunLeaf具象メソッド（321行目参照）が実装されていて、Statement自体の作りは各具象ランナーに委譲しているテンプレートメソッドパターンとなっていることが読み取れると思う。
github.com

少し脱線しますが、JUnitを使ったテストでテストの実行順や必要な処理を追加するような場合にカスタムランナーを作られると思いますが、その場合は、このStatement型オブジェクトに意図した順に実行されるロールのオブジェクトを追加することが妥当なランナーのカスタマイズ方法だと私は思います。
これを実践しているのが、PitaliumのPtlBlockJUnit4ClassRunnerWithParametersクラスですので、参照されると良いでしょう。
github.com

ファクトリーメソッド

オブジェクトを生成する側のクラスでnewをしないでオブジェクトを生成する。

一般的なプログラミングの入門書では、生成する側のオブジェクトが生成される側のオブジェクトをnewするような記述になっている。
しかしこの場合、生成される側のクラス名等に変更が発生した場合、生成する側のオブジェクト格納先、そのオブジェクトを利用するコードにも影響が発生するがある。

そこで生成する側のオブジェクトで、生成されるオブジェクトのインタフェースを受けとるようにファクトリーメソッドを記述したらどうだろうか。
インタフェースを実装するクラスに変更があっても生成する側には、生成する箇所にしか影響が及ばないようになる。
インタフェースを介しているので、インタフェースオブジェクトを利用するコードには影響が及ばないのである。

このようなことからファクトリーメソッドを利用すると、生成されるオブジェクトと、オブジェクトを生成する側のオブジェクトの結合度を緩やかにする効果がある。
WebDriverのPageFactory.initElementsはページオブジェクトを生成する際の良い例である。
github.com

ブリッジパターン

機能のクラス階層が実装のクラス階層のインスタンスを保持し、役割を保持する構造のパターン。
機能の追加、実装の追加を同時に行うことができる。

コマンドパターン

処理をオブジェクト化することで、その処理のメンテナンス性と拡張性の両方を兼ね備えることができる。

その他役立ちそうなデザインパターン

その他にも役立ちそうだと思ったパターンを簡単にまとめます。

イテレータ

対象データをコレクションとして扱い拡張for文を使うことで、そのコレクションに格納しているデータを繰り返し操作できるようになる。
データを保管するクラスを作る時に、イテレータを実装するとデータの取り扱いが容易になることがある。

アダプター

既にあるAPIを利用して、必要とするAPIを作ることができる。
無理にオーバーライドせず、必要とするクラスを作ることができる。

シングルトン

インスタンスを複数作らず、使い回したいときに有効。リソースを節約できる。
PitaliumのWebDriverはWebDriverManagerシングルトンクラスにより、テスト間で使い回し可能な作りになっている。

ステート

状態を具象クラスとして扱う。そのクラスが状態に関する共通の処理をインタフェースとして実装する。
この結果、状態に応じて処理を呼び出す側は、状態インタフェースを実装したクラスのオブジェクトを保持することで、現在の状態を気にする必要がなくなる。

まとめ

一般的に知られているデザインパターンを知り使うことで、誰にでも分かりやすいコードが書けるようになることが分かったかと思います。
今後、詳細設計を行う際には、このようなパターンの適用も視野に入れて開発に取り組んでいきたいと思います。

JUnit4.13のソースを追っかけてみた

先日参加したSQiP「キーワード駆動テストシステムを作ろう」で学んだ、ランナーの役割をJUnitでも実践できるのかを検証する為に、JUnit4のソースコードを読んでみました。

作ったクラス図

折角、なんちゃってクラス図を書いたので公開します。

参考にしたサイト

最初は「ランナーってなんだ？」というところから入って、こちらのサイトを参考にし始めたのですが、分かったような分からないようなままになっていました。

www.mscharhag.com

もやもやしたまま、SQiPのチュートリアルを迎えて、ランナーの役割が分かったところで、JUnitのソースを読むと不思議と頭に入ってきました。

途中、こちらのサイトも参考にさせて頂いたり

d.hatena.ne.jp

ihirokyさんは、super.runChild()をオーバーライドしたrunChild()の中で呼び出しています。これも一つの方法ですよね。

BlockJUnit4ClassRunnerを継承したカスタムランナーなので、必ずBefore/Test/Afterの間に実行されるようになります。

また、こちらのサイトを参考にさせて頂いたりしました。

dev.classmethod.jp

渡辺さんのカスタムランナーは記事でも書かれているように、ユニットテスト以外のテストにも利用されています。なので、run(notifier)からinvokeTest(notifier, testcase)を実行するような作りでカスタムランナーを作られています。面白いです。

結局何がいいのかというと、JUnitを使ってどんな風に「テストを実行したいか」が重要なのかなと思いました。

渡辺さんも書かれていますが、JUnitは「テストケースがクラス毎にメソッド単位で定義されている」というところが原則です。ですから、この考え方に沿ってJUnitを利用するのが、自然な使い方かなと僕も思います。

僕がカスタムランナーを作るとしたら

自分が作っているキーワード駆動テストシステムで共通した画面操作を共通処理に移すにはこうすると思います。

例えば、毎回ログインログアウトが必要なシステムだとします。

これをいちいちテストに書くのは面倒なので、共通処理化してしまいます。

案１）

・カスタムランナークラスの定義

　public Class LoginTestLogoutRunner extends BlockJUnit4ClassRunner

・methodInvokerのオーバーライド

　@Override protected Statement methodInvoker(...) {

　　return new CustomInvokeMethod(method, test);

　}

・@Testを実行するInvokeMethodのを継承したカスタムInvokeMethodの定義

　public class CustomInvokeMethod extends InvokeMethod

案２）

もしくは、JUnitのStatementクラスが「Chain of Responsibility」パターンを利用している事を利用して、Statementのサブクラスを追加しちゃうのも面白いかもしれませんね。

@Testでは、キーワードスクリプトが処理をして、その前後で共通処理を実装できればよいので。

そうすると、テストクラスはシナリオのパターン分できますが、@Testの前後で共通の処理を固定的に実行することが出来ますね。

案３）

@Ruleとして必ず実行させるような仕掛けにしてしまうのも、ありかもしれません。

9/25追記

案４）

カスタムランナーを作らずに済ませる簡単な方法は、@Testに共通処理を書いてしまって、意図した順番で実行する―というのも、一つの手かと思いました。

github.com

これなら１クラス＝１テストケースとして取り扱うことが出来ますね。

渡辺さんが仰っているように、JUnitの構造上は「１メソッド＝１テストケース」ですから、この点を気にしなければこの方法が一番簡単かと思います。

自動でテストを流す時に、実行するクラスが増えますが、Suiteランナーで実行するクラスをまとめてあげれば問題ないと思いました。

まとめ

いづれにしてもJUnitはまだまだ奥が深いし、これを使ってやりたいことはまだたくさんあります。内容を紐解いて自分がやりたいことを深堀した結果を公開したいと思います。

SQiP2016 併設チュートリアルに参加しました （キーワード駆動テスト）

SQiP併設チュートリアルのキーワード駆動テスト勉強会に参加してきました。

www.juse.jp

目的

• キーワードの粒度、他の方がどのように設計しているのか知りたい。
• 他の方のシナリオテストの準備、検証をどういう考えで実装しているか知りたい。

内容

今回は.NET Frameworkを使った計算機アプリのシナリオテストを、Friendlyというフレームワークをベースとして書かれたMS PowerShellで実装していくという内容でした。

講義

キーワード駆動の概念といった基礎的なお話から、キーワード駆動とテストスクリプトの違い、メリット・デメリットについて教わりました。

デメリットについては、特に「テストケースの増加に伴い、キーワードスクリプト間で重複する部分が出現し、テストのメンテナンスコストを下げる可能性がある」という点が紹介されました。

チュートリアル

キーワードスクリプトを変更するところから始まり、キーワードテストランナーの改修といった点を学びました。

このクラス図は、チュートリアルの資料の取扱いについて小井土さんから許可を頂いたので、テスト実行の入力となるデータも追加して全体の構造を表現してみました。

これが具体的なテスト流れRunTest.ps1の概要です。

（ループ部分は割愛してます）

アクティビティ図を見ると、今回の実装方針ではテストケース（キーワードスクリプト）の実行をつかさどるテストランナーと、テストケースの読み込み、テストセットの実行（テストケースの繰り返し実行）、テスト結果の比較が独立していることが分かります。

これは、今回のテストシステムの設計がキーワード駆動テストのデメリットである「共通部分の重複」を排除することを意識している為です。

これはテストケース実行処理部分＝テストランナーのフローです。

例えば、ログイン→商品選択→決済→ログアウトというシナリオがあったとき、①商品選択だけ１つも選ばない、②１つ選ぶ、③配送しきれないほど選ぶ―といったバリエーションを持たせてテストをたいとします。

これをキーワードスクリプトに書くと、スクリプト上に①～③で３回ログイン、決済、ログアウトが現れます。

今後のメンテナンスでログイン処理に手が加わったらどうなるでしょうか。

上記のテスト３スクリプトとも直さなければ動かないテストになってしまいます。

アプリケーションの修正に伴い、自動テストもメンテナンスは必要です。

この前提に立って、３つを直すより１つを直す方が運用しやすいという考えの元、ランナー側で共通部分を実行するように実装していました。

実運用ではアプリケーションのライフサイクルを考慮して、ランナーを設計することが望ましいと思います。（私見）

自動テストシステムにおけるランナーの役割は、テストの実行順や実行方法の制御だけでなく、キーワードスクリプトにおけるコードとして実装された共通処理を実行するという役割も担っていました。

後日　JUnitで実装する場合の調査

同じことを自分の作る自動テストシステムでも実現できるかな？と、JUnitのランナーの構造について後日調べてみました。

JUnitの場合は、@Beforeや@Testといったアノテーション付のメソッドブロックをその名もBlockJUnit4ClassRunnerが、methodBlockメソッドでStatementというテストの文脈（実行順のようなもの？と理解してます）オブジェクトを作り、ParentRunnerのrunLeafメソッドでオブジェクトの一つ一つを実行することでテストを実行しています。

もしテスト実行の共通処理をまとめるのなら、BlockJUnit4ClassRunnerのサブクラスでmethodBlockメソッドをオーバーライドするか、methodBlockが呼び出すInvokeMethodクラスのmethodInvokerサブステートメントを実装する感じになりそうでした（JavaDocにもそう書いてありました）

この為、JUnitを使う場合でもカスタムランナーで吸収することは出来そうです。

これもParentRunnerがrunChildメソッドを子クラスに委譲してくれているおかげかなと思います。

ただ、JUnitの構造を理解するところから理解する必要があり、長くなりそうなのでまた後日記事にまとめます。

参加してよかったこと

• ランナーを使ったテストケース間で重複したテストコードの排除の方法
• 想定結果の準備方法
• テスト結果の検証方法はテストの目的によって異なるので、自動化する前にテストを設計すること
• 回帰テストは前回のテスト結果と比較すると良いこと
• バグの再現手順をテストケースとして実装すると良いこと

自分がキーワード駆動テストシステムを作る上で参考になる知見、気づきを得ることが出来ました。もっと実践と研究を繰り返すことで、世の中の自動化に寄与するアイディアを生み出せるんじゃないかなーと思うようになりました。

参加してよかった。

Java SE Javadoc Hobber の日本語文字化けを正す手順

コーディング中にJavaSE標準のAPIにマウスカーソルをかざすと、Javadocがホバーしますよね。

私の環境（Windows 7/Eclipse Mars）では以下の問題が発生していました。

• Java SEのJavadoc参照先が見つからない
• 参照できるようになっても文字化けして閲覧できない

ネットで情報を調べても分かりにくかったので私の解決方法をシェアします。

1. メニューから、「ウィンドウ＞設定」をクリックします。

   

2. 設定画面で、「Java＞インストール済みのJRE」をクリックします。続けて、プロジェクトでビルドに使用しているJRE/JDKを選択し、「編集」ボタンをクリックします。

3. JREの編集画面で、「JREシステム・ライブラリー」をCtrl+Aキーで全選択し、「Javadocロケーション」ボタンをクリックします。

   

4. 開いたJavadoc画面で、「Javadocロケーション・パス」に「https://docs.oracle.com/javase/jp/8/docs/api/」を入力し、「検証」ボタンをクリックします。このパスには、「手順2」で選択したJREのバージョンと同じバージョンのjavadocを指定してください。インターネットで、「Java SE 8 japanese docs」と検索すると以下のサイトが検索できますので、これを指定します。

   

   ※1 英語のサイトもあるので、お好みでどうぞ。※2 「アーカイブ内のJavadoc」では、Oracle社のWebサイトからJavadocをダウンロードして、ローカルファイルから参照することもできます。

5. 次のようなメッセージが表示されたら、コーディング中にJava SEのAPIにマウスをかざすことで現れるHobberに日本語のJavadocを表示することが出来ます。

6. 結果は、下図のようになります。

7. この時、「手順2」で指定したjreを使用しているプロジェクトの設定が「手順8」のような設定になっていないと、下図のように化けてしまうので注意が必要です。

8. パッケージエクスプローラで、「手順2」で指定したjreを使用しているプロジェクトをクリックし、Altキー＋Enterキーを押して、そのプロジェクトのプロパティー画面を表示します。ファイルのエンコードの種類は、ご利用の環境に依存する場合があるので、ご注意ください。

初めて使うAPIの場合、Javadocの有/無によって生産性が変わってくると僕は思いますので、直しました。皆さんの生産性もこれで上がればいいなと思います。

 

スプリントと振り返りについて思ったこと ～ウォーターフォールとアジャイルの議論より～

こちらのサイトで紹介されていた「スプリント」、「振り返り」の考え方を自分の置かれた状況で活かすと、長期的みて仕事の効率が上がるのではないかと考えたのでメモします。

blogs.msdn.microsoft.com

まず、このようなことを考えた経緯をまとめます。

ウォーターフォールとアジャイル

6月21日（火）にJJUG会長の鈴木さんが主催されたワークショップに参加しました。

ita-ws.connpass.com

そこでは以下のような紹介をされていました。

アプローチの考え方の違い

このワークショップではそれぞれの方法論を、マネジメントの観点からそれらの違いについて説明されていました。

• ウォーターフォールは、ゴールまでの計画が見通せる作業のときに効果的
• アジャイルは、ゴールまで見通しが立てづらい作業のときに効果的

 私の理解を一言でまとめるとこんな感じです。

その理由は、感嘆するほど納得いくものでした。

ゴールまでが見通せるているなら、最初に計画を立てたほうが管理しやすいから。

一方で、見通しが立てにくい事柄に取り組まなければならないなら、見通しが立てにくいと失敗もしやすいので、それを見通しを立てやすいタスクまで分解して、その単位で計画的に進めていく方が成功しやすいから。

こんなブログに突っ込む人なんかいないでしょうけど、原理的な思想については、詳しくないので突っ込まれても困ってしまいます（笑）

今はこういう説明に納得しているというだけです。

マネジメントの観点

PDCAという言葉がありますが、鈴木さんはマネジメントの基本はこれだと仰っていました。

有期性のある活動（仕事）において、それがうまくいかない場合はこれのどれかが失敗しているということだと。

それぞれの方法論には粒度は違えどフェーズ（設計、製造、テストなど）があるので、フェーズごとにPDCAを実践する点においては本質的には違いはないんだなあと思いました。

おかれている状況によって、採用する仕事の管理方法が違うだけ。

方法論の目的、技法の適用シーンを理解することの大切さ

仕事を上手に進めるには、その仕事で採用する方法論の目的、適用すると効果が上がる状況をきちんと理解して、採用するのが妥当だという鈴木さんの意見には私も賛成でした。

テストをされている方ならわかると思いますが、テスト方法論やテスト技法についても似たようなことが言えますよね。

例えば、（短絡的な例えですがー）設計書が無くて、テスト対象に対して深い知識やテストスキルが高い人がいるような状況なら探索的テストをやろうかとか－です。

効率的に仕事を進める為に

今の仕事は、開発以外にも見積や問合せへの応対など様々な作業があります。

色々な経緯から仕事量自体が去年より減ったのですが、正直もっと仕事をしたいと思っています。

こんな思いで悶々としていたときに、今の仕事をもっと早く終えられれば、同じ時間でもこなせる量は増えるよな－なんて思った訳です。

 

そこから自分の作業時間を測って自分を管理しようと考え始めました。

毎日の作業をログに残して、ログには作業時間を書きます。そうすれば自分の力量が見えるだろうと思ったわけです。

始めてから1ヶ月立つのですが、集計が大変で全然できていないのが現状でした。

スプリントと振り返り

そんな時に冒頭で紹介した記事を読んで、アジャイルプラクティスであるスプリントと振り返りを参考にしてみようと思いました。

 

幸いなことに、私はタスク管理表を付けているので、一定のスプリントで作業計画を立てることは出来そうです。タスクを細かい作業単位に落とし込むというところを今までやっていなかったので、ここを細分化して取り組んでみたいと思っています。

大変にならない程度にやってみて、スプリント終了時に振り返りをしてみたいと思います。

 

これで作業見積りの精度が徐々に上がっていけばよいですし、人に作業をお願いもしやすくなると思います。

状況を判断する力

私の場合は、このような仕事の仕方だったので適用できそうです。

しかし、既に仕事内容がマニュアル化されていて、その手順で最高の結果を最高のパフォーマンスで出せるのならそれでいいと思います。

私もそれに従います。

状況によって適切な方法を判断して、自分の力として利用できるように知識として持ってように常にアンテナを張っておきたいな、と思いました。

WACATE2016夏に参加して、成長しそうな予感の私のテスト

6/18土,6/19日に「WACATE2016 夏」に参加してきました。

 

2日間にわたり、テスト分析、テスト設計を体験するという、たいへん良い体験をしてきました。

 

しかし、テスト分析についてはモヤモヤしたままになっていた点があったので、振り返りることにしました。

自分なりにうまく消化することが出来たので、忘れないうちにまとめておきます。

 

自分はこう考えているーという方は、コメントやリツイート頂けると幸いです(^∇^)

 

また、WACATE的に不味そうな点は訂正しますので、ご指摘ください。

 

テスト分析

「テスト要求、テスト対象を分析して、テストしたいことを洗い出すこと」

 

セッションで福良さんは、このように紹介してくれました。

 

WACATEに参加するまで、私はテスト分析で何をするのか理解できていませんでした。

 

ドリル本では、テスト対象に関係しそうな項目を、画面からや、6W2Hの観点から分析されており、私には少し難しいイメージがありました。「分析」なんて言葉がついていますしね(笑)

 

ですから、「テスト条件」を「テストしたいこと」ーと言い換えたり、その成果物イメージを掲載してくれていたことにより、私にはスッと入ってきたのでよかったです。

 

この２つが無ければすんなり理解出来なかったでしょう。

 

分析の手順

やり方を以下のように、実行可能な作業単位に分けられていた点も、とてもありがたかったです。

何をすれば分析出来るのかすぐに分かりました。

 

• 分析方法を決める
• 情報を整理する
• 成果物を確認する
• 顧客の要求（テスト要求）を分析する
• 設計書（テスト対象）を分析する
• 分析結果を整理する 

分析方法を決める

いくつか有名なフレームワークが紹介されていましたが、まずはやりやすい方法で進めようということで、リストや樹系図、この他以下の方法を紹介してくれました。

 

私は3色ボールペンしか知らなかったので、それを選びました。

 

一方で、ほとんどの皆さんはマインドマップを使われていたようです。

 

「マインドマップってつかえて当たり前なんだ・・・」と少しカルチャーショックを受けました(^-^;

 

マインドマップを覚えたら便利そうですね。

他のグループの発表やチームメンバーの発表を聞いて、そう思いました。

 

以前Naitで池田さんの本を勉強されていたようなので、ポチって使えるようになりたいなと思ってます。

 

テストしたい「こと」？ テストしたい「ところ」？

テスト分析の手順を振り返っていて、混乱してしまったのがここでした。

• "システム"（ドキュメントすべて）に対して分析をしたら、テストしたい"こと"、"ところ"って粒度が異なる"こと"、"ところ"がたくさん出るよなあ
• 粒度の違うテスト条件、どうやって整理するんだろう？
• 粒度が異なるから、それぞれの粒度か、テスト条件が一度にたくさん出てきてしまい、まとめきれないんじゃないの？

などなど

情報（分析する対象）の整理

ここで、この混乱を解く為に重要な鍵となるのが「情報（分析する対象）の整理」でした。

ここでの分析対象は、配布された資料です。

当日、テスト分析、テスト設計の為に配布された資料(顧客要求、仕様書)はたくさんありました。テスト設計まで行うので仕方のないことです。

ですが、これらを整理すると、いくつかに分類できることに気づきます。

• 新旧業務フロー画面遷移図
• 各種定義書
• テストに関する顧客要求

テストし易い単位から分析すれば、その単位（同じ粒度）でテスト対象を洗い出せるのではないか、ということに気づきました。

分析対象が何かというと、上記の整理した資料です。ですから、同じ分類や粒度が同じ分析対象を、一つずつ見ていけば良かったのです。

落ち着いて考えれば当たり前なことでしたが、情報を整理しないと、こういう混乱を招くという良い教訓になりました。

いきなりすべての資料(システム全体)に対して、分析をするのではなかったのです。分析対象が大きすぎますしね(^-^;

また、これに関連して気づいたのは、テストレベルが対象とする単位、粒度で考えてもよかったなということです。

V字モデルではテストをする順番は単体（単機能）テスト、統合（複数機能）テスト、システム（機能全体）テストですから。

しかし、私はやはりテストレベルから考えるより、分析対象を整理してから、その整理した情報ごとに分析をしていく方がしっくりくるようでした。 

テスト設計技法が適用できるテストレベルはある程度示されていますが、テストレベルに対応するテストタイプは、テスト対象によるーとなってしまうと思うからです。

限定された業界や業務ならば、後者の考え方でテストタイプを限定しても良いかもしれません。

分析をすることのメリット

ただ、やはり分析をすることにはメリットがあります。

グループワークの発表や秋山さんの講義でも紹介されていましたが、どうやってテスト対象を導きだしたのか考え方を人に伝えられる、という点です。

「ちゃんとテストした？」と聞かれる人(私を含め)には、とても効果的だと思いました。

テスト分析の結果として、やるべきテストが決まる

昔「やるべきテストはテストレベルごとに決まっている」と私は思っていました。そういうものだと、思い込んでいました。

• 単体テストでは何をしたらいいの？
• 結合テストでは何をテストしたらいい？
• システムテストでは何をテストしたらいい？

などなど 

何をテストしたらいいのか分からないのは、テスト分析ができていないから

ここまでくると自分が何をすべきかは、もう分かります。

分析が上達すれば、テストするところはここだよって言えるようになるわけです。

ですから、私のテスト上達の鍵はテスト分析が上達することだと分かりました。

WACATEに参加した一番の収穫です。
振り返りしなかったら気づけなかったと思います。やっといてよかった。

分解

テスト分析の上達の為に大きなヒントになりそうな手法が、「分解」です。

秋山さんが講師として紹介してくださいました。 

講義では要求が大きい場合、分解を利用して、具体的な要求を引き出していくと良いと教わりました。

USDM のような思考のフレームワークを使うと、上手に分解できるそうです。

例）USDM

• 時系列
• 構成
• 状態
• 共通部分

分解した結果を説明できるように一枚にまとめる

振り返っている今だから分かるのですが、テスト分析結果がこれに当たるのかなと思いました。

 

例えば、「画面定義書」を構成の観点で分解すると、色々な要素が出てきます。

 

• テキストボックス
• チェックボックス
• ラジオボタン
• ラベル
• ボタン

など

 

これらに対して、確認したいことを書き出していきます。

 

例えば、

• テキストボックスなら、「入力可能な文字列を入力できること」
• チェックボックスなら、「チェックボックスを１つも選択しなくて良いこと」

などなど

 

次に、確認したいこと毎に、具体的な確認対象を明記します

 

例えば、テキストボックスなら

• 氏名
• 住所

など

 

そして、これらを確認する観点を洗い出します。

 

テキストボックスで見ると、

最小文字数、最大文字数、全角、半角など

どんな文字が入力できるかで分解するといいです。

 

要素種類で分解するのがミソですね。

個別の要素を見ないので、要素種類に共通してテストしないといけないことが分かります。

 

いきなり具体的な要素名から見ていくと、共通のテストしないといけないことを、個別の要素ごとに考えることになるので大変です。

 

この辺の手順はテスト分析の効率に影響するので、大事だと思いました。

 

成果物の確認

以上の分解によって成果物が出来上がります。

テスト分析の成果物は、テスト設計のインプットとなります。

あとはテスト分析の成果物に対して、テスト技法を適用してテストを設計（テストケースを作成）していくだけです。

ここまでで、テスト分析がテストの質を左右することが容易に分かりますね。

これをテスト計画やテスト者への指示に反映することで、チームとしてより良いテストが出来そうだと思いました。

チームの方への感謝

グループワークの最後に細川さんから、「テスト分析、テスト設計出来た？」という質問がありました。

私たちのチームは、テスト設計は「う～ん」でしたが、分析は「出来たと思う」人がほとんどでした。

テスト設計は個人ワークにして、やりきることを考えていたからだと思います。

 

逆に、細川さんが仰っていましたが、沢山議論が出来ていたから、分析については納得感があったのだと思います。

 

２日間を振り替えるとチーム内では、初対面ながら沢山話をしたなあと思います。進行も円滑でしたし、みなさん、コミュニケーション能力の高い方たちだなーと思いました。

 

テスト技術を学びに来たわけですが、みなさんのおかげで良いチームワークでよい学習が出来ました。

 

本当にありがとうございました。

SNSで繋がっていますので、今後ともよろしくお願いします(^∇^)

 

成長しそうな予感の私のテスト

2日間のワークとその振り返りを通して、私の考えた"ちゃんとしたテスト"は少し成長しようとしています。ちゃんとしていなかった点が分かったからです。

 

これからは「ちゃんとしたテストした？」と聞かれたら、

「これがテスト分析結果です。これを元にテスト設計をしました。分析対象は◯◯工程で作成した設計書です。」

と、言えるようになっていると思います。

 

成長させるのは自分次第なので、バシバシ手を動かしていきたいと思います。

 

WACATEに参加して良かったです。

 

運営の皆さん、参加者の皆さん、どうもありがとうございました。