テストを始める前に確認すること

 「こんなにマトリクスもかいて網羅的にテストしてるはずなのに
　不具合がでてしまう・・・。」

そんな時には、基本も見直してみませんか。

ー　環境差分

ー　前提条件

ー　テストスコープ

環境差分

「リビジョンしか違わないのに、なんでバグがでるんだろうね」
なんてシーンを見たことがあります。

テストで新人のころに叩き込まれたりするのですが、
ビルドにかかわるものはバージョンを統一するのが基本です。
また、本番とテストサーバーの差分もリスクになります。
この辺は、運用でカバーしようとするとかなりの確率で不具合につながりますので、

テスト環境は気を遣うところです。

前提条件

テストデータの状態によっては、予想しがたい不具合だったり、

または不具合ではないものが結果として出てくる場合があります。

テストしたい項目以外はデフォルトで、というのも押さえたいポイントです。

また、アカウントの設定やブラウザバージョン、および設定など、

テストしたい項目の前後の操作や条件も気を付けたいところです。

テストスコープ

仕様のテストだけしていても不具合はきえません。
いわゆる、「行間を読む」というものですが、知見で左右されるものに思えて、
実は、有効なテスト技法もあります。
ここでは、扱いやすいものを挙げてみます。

• 3色ボールペン技法
• ６W2H　（HAYST法）
• ペルソナ
• ユースケース
• 意地悪漢字

それぞれの技法はここでは触れません（いい本や例がたくさんあります）。

また、操作要素（ボタン連打、ブラウザバックやフォワードなどのブラウザ特性、モバイル特性など、製品ドメインに紐づく要素）なども、テストセットにしておくと観点を見つけやすいです。

また、テストスコープについては、ビジネス開発者にレビューをもらうなど、

フィードバックの仕組みづくりも有効です。

（QAに一任されている、という約束がある場合は、レビューがない場合もあります）

テストケースを秒で書く話（上級者向け）。

心構え 

• 良い子はまねをしてはいけない

用意するもの

• 紙
• 筆記具
• 手練れ

やりかた

1. UIをじっと見つめて、HeaderとFooterなどの部品は省きます（別で作る）
2. UIに応じて、テストパターンを当てはめて、ぴっ、ぴっと線を書いていきます。
3. 完成。（仕様を混ぜ込むパターンもあり）

これなら、秒で書けますよね！？
↓某検索エンジンをサンプルにした、実物。だいたい２分。

ダイアログはページから切り離して
書くことにしています。

UIが少ない場合は、
ページ内の階層として
書くのもありだとおもいます。

もうちょっとUIわかるように書く方が
無難だとは思いますが。

説　明

さて、これがどういうことかというと、
HTMLで書かれるからには、UIは決まってくるわけで、
CSSはともかく、UIによってテストパターンが作れます。
これを線で表現します。

↓こんな感じで、プロジェクトの合間などに、
↓アプリに合わせたテストパターンを作りためておきます。

For UI

Check BOX
Drop Down List
Drop Down List item

Button

ボタン： button

ラジオボタン：radio button

チェックボックス： check box

ドロップダウンリスト： drop-down list

ドロップダウンリストアイテム： drop-down list item

テキストボックス： text box

テキスト： text

アイコン： icon

タブ： tab ページ： page
リンク：Link

(あれ、まだパターンあまりブログに書いてなかったな・・・）
(タブオーダーも抜けてたな・・・）（別の資料ではこのパターンを書いてあります）

For ブラウザ特性
新しいページ向けテストパターン
ほか

For DB
Webアプリのデータベースのテストパターン
Webアプリのデータベースのテストパターン　その２
ほか

For...
いろいろ。

要するに、テスト項目をあらかじめテンプレート化しておき、
暗号的強度でテスト項目のチェッカーだけ書く、ということですね。
テスト項目の適用パターンが頭に入ってないと書けません＆実行できません。
ゲームなどで扱うには工夫が必要ですね。

（データクラスターのテンプレ化はできると思いますが）

もちろん、これだけではUIと仕様のテストまでしかできないので、

• データのCRUD+3（独自に三つ付け足してます）
• ビジネスの単位でフロー作成
• 組み合わせテスト
• Regression Test

などなど、別のテストは、これもテストセットのマップとして

用意したものをそれぞれ作ります。

これらのセットの使いこなし方をチームの新人さんに把握してもらえば、
こっちのテストはあなたが作って！と、テストプロセスの標準化を

行って、作業を渡すこともできるようになってきたりします。
（今うちのチームはこれでやってます）
（ToCの製品はこれがやりやすいです。なぜなら、ドメイン知識の共有が軽いので）
これがお弁当QAでの、テスト作成の標準化とパターン化、

スピードアップのコツになります。

チームにインストールする際は、このマップの箱１こずつ

ワークショップを行って覚えてもらってます。

新人さんでもある程度テストが書けるようになったりします。

もちろん、トレーサビリティやエビデンスを文章の形で残しておく必要が

ある納品物などはこのままでは完成しないので、どうしても急ぐときは、

テストを先にやって不具合を出しておいて、エンジニアさんがFixしているあいだに

テストケースを後から書き起こしたりしていました。
手早くやらないと忘れますけどね！
今の現場ではそこまでお行儀の悪いことはやってません・・・。

（このぐらいのスピードが求められる現場は大変ですよねー・・・orz）

１時間半で書くぐらいのものが、２分になったら、それなりに
年間での生産性はあがるかと。

もしこれで、テストがもれなく早くなったよ！なんて
お話があったら、聞かせていただけると嬉しいです。

一応、今回は上級者向け、として、
いつもなら省いて書くところも少し書きました。
もちろんリスクもありますので、

ちゃんとコントロールできるくらいの手練れなら
使いこなせるかと思います。

 m(_ _)m。

Browser test pattern for new pages : 新しいページのブラウザテストパターン

Browser test pattern for new pages

• Brower Back
• Browser Forward
• Browser Close
  
• Browser size change
• Page Refresh
• Cashe (CRUD)
• Tab conflict
• Cookie settings (CRUD)
• Bookmark

Test Strategy map

 Here is Test Strategy Map for Web front system.
This is specialized for our team.

The most of activities of our team are here.
One method is original modeling.

「自分で自分を鍛える」を、見える化する

この文章は、脱初心者を目指すモチベーションの高い（？）
テストエンジニアさんを読者に想定して書いています。

さて。
現在わたしは10人ほどのテストチームのリードをしておりますが
メンバーのスキルがみえないと、伸ばす方向がわからないので
こういったスキルマップを作成しました。

ほとんどのスキルはインターネットで調べられので、
詳細の説明はここでは割愛します
使い方としては、自身の習熟度に合わせて
色を載せていきます。同系列の色を、3色選んで、
色が濃いほど、習熟度が上がるように塗っていきます。

1.  知識がある　■
2.  使っている　■
3.  教えられる　■

自己評価なので、自分で判断して色を塗ります。

これを、3か月ごとぐらいに見直して、自分の成長を可視化すると

少し楽しくなりませんか？

すでにご存じの方はお気づきと思いますが、
TPI NEXTを参考に、自分のチームで運用しやすいように
アレンジしています。

さらに効率よくスキル獲得がしやすいように、
関係のあるスキルをマインドマップでマッピングしたものを添付しています。

線が伸びているスキルを習得すると効率がよいでしょう。
マインドマップは本当に便利ですね。

スキルのマスをうめるのは、おそらく先輩がやったほうがいいでしょう。

先を見据えてどういったスキルが必要かなどは、ボトムアップだと
なかなか計画的に洗い出すのは難しいということと、

どういう知識を持っていてほしいのかを全体感をもって
伝えることができると思います。
色付けは、プレイヤーが自分でやります。

セルフエデュケイションなので、自主的に取り組んでアピールに
使っていただきたい、というのと、いろんな技法があることを伝えると
チームのみんなは興味をもってくれたようでした。
やはり、自分で納得して動機を得るのが、一番意欲的に取り組めますよね。

こちらは特定のチーム用ですので、例えば英語など不要なものもあるでしょう。
もちろん製品ごとに、必要な知識はちがうので
もし同様にアレンジされた方がいらしたら、
お話させていただけると嬉しいです。

探索的テストのテストパターン

探索的テストの勉強会をやってほしいというリクエストがあったので、

サンプルを記載してみますね。

1. データに注目する
2. 作りに注目する
3. 設定に注目する
4. ユーザーの使い方に注目する
5. (言えないけど○に注目する）

仮に、ECサイトの例をあげていきます。

1.データに注目する

探索的テストに限らず、Regressionなどでもそうですが、データの塊に注目して、

それらが表示される個所を探す方法です。

データクラスタの例：

• ユーザー情報＞個人情報＞名前、住所、電話番号・・・
• 購入情報＞金額＞個数＞日付・・・
• データに紐づく状態遷移　購入前、購入後、カートの中、など

影響範囲の例：

• 表示か所→設定画面、ショッピングカート、個人情報変更画面、e.t.c.
  

まとめ方の例：

• テンプレート化
• トレーサビリティマトリクス（T字マトリクス）
  
  

2.作りに注目する

似たような処理を行っている塊に注目して探す方法です。

例：

• 検索
• アカウントの権限（料金プランなど）
• ブックマークの処理
• ログインの制御、など　

3.設定に注目する
設定=テスト条件、として探していく方法です。

ソフトウェア的なものの例：

• アカウントに紐づく設定
• 購入プラン
• サブスクリプションプラン
• 分岐条件になるもの（性別、年代、地域、などのセグメント）、など

ハードウェア的なものの例：

• OSの設定
• 状態遷移、など

まとめ方の例：

• 状態遷移図
• 状態遷移表
• トレーサビリティマトリクス

４.ユーザーの使い方に注目する
ユーザーの使い方の例は多岐にわたし、製品の成長フェーズ、ユーザー数、品質ポリシーによってかなり内容が変わります。自分たちの求める品質に合わせて設定します。

洗い出しの例：

• ペルソナ
• ラルフチャート
• 6W2Hでの洗い出し
• ユースケース図（UML)
• ブラウザ特性/モバイル特性、など

    ブラウザ特性の例

• ブラウザの種類（開発環境と違うものに注目）
• キャッシュ
• クッキー
• ブラウザバック
• ブラウザフォワード
• ブラウザクローズ
• ブックマーク、など

まとめ方の例：

• マインドマップ
• チェックリスト

5番目は、あえて書きませんので、お察しください。

バグ分析をすると一定の傾向（原因）などが見えてくることもあるので

そういうポイントも注目します。

テスト観点という言葉について

「テスト観点を出しておいて」
と伝えた場合、以下のものが返ってくることがあります。
- テスト項目、そのカテゴリ
- 機能、そのカテゴリ
- 振る舞い
- 注意点
- 目的　など
これらはテストの内容としては全く異なるものになりますよね。

で、テスト観点を出しておいて、といわれ、出してみると、これじゃない、となり
すり合わせだけで妙に時間を使うこともあります。
いまはメジャーな言葉であり、これだけで一晩語れそうな方々が
いらっしゃるぐらい奥深い用語ですよね。

私の場合、最初のイメージとしては振る舞い、目的に近いのですが、
本当に人それぞれで、お酒の席などで話題にすると、しばらく尽きないようです。