-
- いいね！2
ふじふじ
@fuji_fuji_test
お気づきかもしれませんが、各チームが行っている作業は抽象度が異なるだけで本質的には同じです。こういった各チームのワークを対比して見られたのは個人的にはとても興味深かったです。 #wacate
2016-07-13 00:20:44
ふじふじ
@fuji_fuji_test
Aチームは、テスト計画のインプットとしてはプロジェクト自体のスケジュール、仕様書や顧客の要望、予算などがあるとし、アウトプットとしてはマスターテスト計画、すなわちテスト全体における戦略、方針とレベルテスト計画（より詳細なスケジュール、担当割りなど）があるとしました。#wacate
2016-07-13 01:08:34
ふじふじ
@fuji_fuji_test
Aチームは、同様にしてテスト分析についてもインプットとアウトプットを考えていきました。そのあと、テスト計画から実際に検討を進めていきます。#wacate
2016-07-13 23:38:08
ふじふじ
@fuji_fuji_test
テスト計画では「お客さんの使いたい機能を実現する」という大目標を立て、そのためにまず業務フローパステストを考えました。 テスト分析において、業務フローの各項目に対してマインドマップを使用して必要なテストを洗い出していきます。#wacate
2016-07-13 23:41:43
ふじふじ
@fuji_fuji_test
あとはマインドマップをもとに確認対象や確認手段をテスト項目へと落とし込み、テスト分析の成果物としました。#wacate
2016-07-13 23:44:21
ふじふじ
@fuji_fuji_test
対して、Bチームです。Bチームは、テスト計画ではテストのスコープ、優先度、時間が決定されるとして、そのインプットとしてはユースケース、システム要件、プロジェクト憲章、今回のワークでの憲章依頼のドキュメントがあるとしました。#wacate
2016-07-13 23:46:22
ふじふじ
@fuji_fuji_test
この後テスト分析へと進むわけですが、テスト分析のインプット候補としては機能性/非機能性、ソフト/ハード(DB/AP)、利用環境（端末、OS、ブラウザ）、利用者（申込者、実行委員）といった、テストで気にすべきポイントを洗い出したものがあるとしました。 #wacate
2016-07-13 23:48:34
ふじふじ
@fuji_fuji_test
これらのポイントは、あくまでテストベースをもとに導いているのがポイントです。 このポイントを抑えることで、まずはテストベースに対する網羅性を確保しようという方針です。#wacate
2016-07-13 23:49:30
ふじふじ
@fuji_fuji_test
この後は、ここで挙げたポイント（機能性/非機能性など）に対して、ISO25000の品質特性を手掛かりにして確認すべきポイントをより具体的なレベルで列挙していきます。 例えば、機能性であれば合目的性、正確性、相互運用性などがキーワードになります。 #wacate
2016-07-13 23:51:31
ふじふじ
@fuji_fuji_test
ここでBチームが工夫したのが、「具体的な項目を検討しすぎない」ということです。 これは、後述しますがここで挙げたテスト条件を分類する際に、あまりに具体的な項目を列挙しすぎていると収拾がつかなくなるためです。 このために、あえて抽象度をコントロールしていました。#wacate
2016-07-13 23:53:29
ふじふじ
@fuji_fuji_test
さて、ではここで出てきた、良い感じの抽象度で揃えられたテスト条件をどのようにグルーピングしていくのでしょうか。今回Bチームが選択したのは「テストレベルによる分割」でした。#wacate
2016-07-13 23:54:32
ふじふじ
@fuji_fuji_test
なぜでしょうか？それは、たとえ確認項目自体は同じものであっても、テストレベルによって確認の手段や対象は変わってくるからです。#wacate
2016-07-13 23:56:26
ふじふじ
@fuji_fuji_test
例えば、「データがDBに登録できる」と一言で言っても、単体テストと結合テストでは認識が異なります。 単体テストではDBへの登録処理そのものが動くかどうかが気になりますし、結合テストではDBに登録した値が画面から見られるかが気になったりします。#wacate
2016-07-13 23:57:32
ふじふじ
@fuji_fuji_test
そういった、確認のレベルが違うものが混在した状態ではテストがしづらいのではと考えたBチームは、テスト条件をテストレベルごとに分類し、それぞれのテストレベルで確認すべき項目を明確にしました。#wacate
2016-07-13 23:58:32
ふじふじ
@fuji_fuji_test
また、テストレベルで分けて一覧にすることにより、重複した項目が出てくるのに気がつきました。 しかしそれは、先の説明の通り、テスト実施時期、確認対象に差が出るため厳密には同じテストではありません。#wacate
2016-07-13 23:59:56
ふじふじ
@fuji_fuji_test
さて、チームごとに発表を行いました。Aチームへは、「お客さんのやりたい機能」というのを、マインドマップのブランチを出していくときに意識したか？という質問が出ました。 そこまでは考慮できなかった、との回答でした。#wacate
2016-07-14 00:01:48
ふじふじ
@fuji_fuji_test
最初に決めた大方針を、実際にマインドマップのブランチを出していくときにまで意識するのはなかなか難しいです。そう言った時は、テンプレートを利用するなど緩やかな制約をつけることである程度出てくる項目をコントロールすることができます。
2016-07-14 01:09:12
ふじふじ
@fuji_fuji_test
Bチームへは、品質特性を手掛かりにして抽象的なテスト条件を出していくところで、マインドマップを活用できるのではと藤沢より意見を出しました。 具体的すぎる項目を出さないように、という制限付きでマインドマップを使ってみるということです。#wacate
2016-07-14 00:05:17
ふじふじ
@fuji_fuji_test
マインドマップは何も考えずに使っても良いことはあまりなくて、しっかり使い方や使いどころを見極めることが重要です。#wacate
2016-07-14 00:06:16
ふじふじ
@fuji_fuji_test
まとめです。 Aチームは、「お客さんのやりたい機能を実現する」という、あくまで利用者目線に近い視点からテストを考えました。 業務フローをもとにテストを考えようというアプローチに至ったのがその証拠と言えます。#wacate
2016-07-14 00:07:20
ふじふじ
@fuji_fuji_test
この目線は基本的かつ非常に重要で、Bチームも後々はそういった高いレイヤーでの確認（シナリオテストなど）を検討することは必要になるのです。 今回、Aチームのメンバーはここを特に気にする人が多かったため、利用者目線のテストから先に検討することになりました。#wacate
2016-07-14 00:08:45
ふじふじ
@fuji_fuji_test
対してBチームは、厳密な定義付けや先を見据えた進め方をしていたのが特徴的でした。 テストレベルでテスト条件を分類するのは、特に実施段階になって確認する項目がうまく分離されておらず困ることのないように、と考えた結果だと思います。#wacate
2016-07-14 00:10:37
ふじふじ
@fuji_fuji_test
また、品質特性を「網羅」するためではなくあくまでテストの「ガイドワード」的に用いていたのも良いポイントです。品質特性はそもそも、テストの網羅性を確保するためのモデルではありません。#wacate
2016-07-14 00:11:34
ふじふじ
@fuji_fuji_test
例えば、合目的性には一部、正確性が内包されていることがあります。 正確ではないユーザ情報の登録は、合目的性も満足できませんから。 なのでそもそも品質特性はMECEな、階層がきちんと揃って網羅性を確認できるモデルではないのです。#wacate
2016-07-14 00:13:02