Web Software DB test pettern：Webアプリのデータベースのテストパターン その２

■データインポートのテストパターン
　内部DBへの影響確認→
　Updateされる情報の影響範囲を確認→
　テストパターンを掛け算して作成

1.　内部DBへの影響確認
　インポートされるデータから、製品DBへ格納される項目を確認
　テキスト：テキストボックスのテストパターンと一緒
　数値：テキストボックスの数値テストパターン と一緒
　バッチの更新パターンなどを確認して、カレンダー系（後日リンクします）のテストパターンを確認

2．Updateされる情報の影響範囲を確認
　仕様書がない場合は、マインドマップ形式のデータフローを図に起こしておくと便利。
　少ない時間で必要なものが得られる。メンテナンスコストも少ない。
　影響の起点になる更新が発生する場合は、そこのつながりをテストする。

3．テストパターンを掛け算して作成
　テキスト、数値、カレンダー系などのテストパターンを、
　上記の要素に掛け算して作成
　深さはｎスイッチの扱い。

これからQAを立ち上げたいときに、気を付けたいこと

初めてQAを雇おう！というときに五里霧中になる話を最近ぽつぽつ聞くので
軽くメモ。

■テストフロー
開発とQAのタスクを明確にして、それぞれのステップで引き渡すべき情報をシェアする。
概ね、それぞれのプロセスにおいて、

• 仕様
• ステークホルダー
• 担当（開発・QA）
• スケジュール
• 注意事項（クレジットカードの扱いなど）

 など。

■テスト環境
テストサーバーはQA専用のものを用意したい。
テスト中にビルドがはいったり、データが入れ替わると
テスト結果を破棄してやり直す場合もでてくる。
テスターにはテストマシンはしっかり与えてくださいね☆
スピードが全然違います。
テスターなんて誰でもいいじゃん！は高リスク。

■チームパターンあれこれ
大体この三つ。

1. 第3者検証型
 テストリード＋（単価の安い）テストオペレーター複数人　の、スタイル。
実はコントロールコストがとても高く、かえって高くなる恐れもある。
総体はテストリードが監督するため、比較的人員の入れ替えに強い。

2. 精鋭型
一通りテスト計画から実行までできるテストリードレベルの精鋭プレイヤーが
それぞれのチームにいるスタイル。
アジャイルや、開発スピードを上げたい場合にこのスタイルであることが多い。

3.エバンジェリスト型
専門家に社内教育してもらうスタイル。
コストは実は一番安い場合もあるものの、浸透するまでに非常に時間がかかる。
悩んだ時に聞けるのは心強い。

Web Software DB test pettern：Webアプリのデータベースのテストパターン

■ソフトウェア視点からのデータベースパターン

• Create
• （Read)
• Update
• Delete

いわゆるCRUD（クラッド）のパターンにプラスして、

• 繰り返し
• 全消し
• 遷移
• 異常値

の要素を掛け算で加えて1セット。
Readは、通常のテストをやっていればほぼカバーが終わっている。

Readのテストを明示的に入れないとテストが危険と判断されるのは、ミッションクリティカル製品や、ユーザー数の巨大な製品、また、製品の開発精度に問題がある場合など。

異常値のテストは、製品特性によってパターンが変わる。
異常値の代表例

• 例外値
• 空白
• 規格外：　サイズ違い、フォント異常、文字コード範囲外など
• 入るべきではないデータ

パフォーマンステストはインフラ視点ととらえているのでこのセットには入らず。
別のテストセットの扱い。

適用すべきプロジェクトは、ケースごとに違うので、ケースバイケースで考えることになるのだけど、この辺の判断ポイントを可視化したいなあ。

WebUI Test Pattern：Text Box

For digits

• Max value
• Minimum value
• SBCS
• DBCS
• Minus value 
• Zero
• Marks: !"#$%&'()=~|`{+*}<>?_
• Tags: Links
• Scripts
• null
• Empty

For Texts

• Max value
• Minimum value
• Co
• SBCS
• DBCS: Fonts, Several country's fonts
• Mixed character sets: DBCS on the end text of Maximum input length
• Minus value 
• Zero
• Marks: !"#$%&'()=~|`{+*}<>?_
• Tags: Links
• Scripts
• null
• Empty

製品ローカライズテスト項目

■文化視点
表示言語
　 Punctuation marks
単位
　面積
　時間
　金額
  基本単位の数値
　変換時の小数点以下桁数
通貨
住所表記
　Zip
　表記順
電話番号
タイムゾーン
祝日
　正月
　国民の祝日

法務
習慣
　色
　レイアウト


■製品視点
レイアウト
ページング
ドキュメント
　ヘルプファイル
　UI

テストオペレーターのスキルを見える可する試み

QAのエントリーとして、テストオペレーターから入る場合もよくあることと
思いますが、テスト実行のみやっていてもなかなか
評価されない時代になっているように感じます。

実際には、経験の浅い設計者によるテストケースより、
ベテランのテストオペレーターのほうが
網羅的にテストしてくださったりなんてこともあるある、に見受けられますが、
これはとてももったいないこと。
そこで、テストオペレーターのスキルを、コストをかけすぎずに実務レベルで
見える可する方法の仮設を立ててみました。

例：Webシステム

記録手段
　探索的にテストを行っていただき、何をやったか記録してもらう
　粒度は、テスト項目・手順を記載の程度

計測

1. switchの数え方は0からスタート
2. アイテム1個 のデフォルト＝0 swichと定義

• ラジオボタン
• チェックボックス
• テキストボックス＋入力内容1回分
• ドロップダウンリストのリストアイテム

            など
 
　　3.　 遷移1回 =  +1 switchと定義
　         上記の0switchを受けて、レスポンスが得られるものからささらに
　         べつのオプションを入力して違うページに遷移する、など
　　　　　(n switch × chow's coverage)

　         例：
　         1.画面AでラジオボタンをONにして次のページへ：1+1 switch
　         2.次のページで、チェックボックスをONにして次のページへ：1+1switch
　         3.最後に、テキストであえて不具合をいれて、結果をみる:1+1switch
　         →6point

           例：
　        1.画面AでラジオボタンをON,チェックボックスを3つONにして次の画面へ：
　         （プロパティベースの3swtch、Chow's coverageでは0swtch) 3+1switch
　        2.次のページで、テキストに不適切な文字を入力、実行：
　         （プロパティベースの0swtch、Chow's coverageでは0swtch) 1+1switch
           3. エラーリカバリしたあとに適切な文字を入力して次の画面へ
　         （プロパティベースの0swtch、Chow's coverageでは0swtch) 1+1switch
           4.登録完了画面でテキストを確認
       　   →本文のチェック行為が必須の前提条件として、8point


という風に、それぞれに記載した手順を、ポイント化して計測すると
実行時間単位のパフォーマンスが
見える化できるのではないか、という仮説です。

例えば、1時間探索的テストをやったとして
　Aさん：　0swtch 10件、1swtch3件　3swtch1件
　Bさん：　0swtch 0件、3swtch8件　5swtch1件
だとすると、テストフェーズにもよりますが、どちらがクリティカルを取りに行けるのか、
目安になると思うのです。

これは、手順を見ただけでカウントできるのと、
勉強などのイニシャルコストがほとんどかからないと思います。

0+1swtchのテストだけで終わっている例もまま見かけるのですが(本当です）、
経験でフォローしてバグを取っているオペレータが
事なきを得る製品づくりに貢献しているけれども、あまり評価されてない例があるのが
残念だとおもって用意してみました。

現在チームを持っていないので、検証ができないのですが・ｘ・


文章だとわかりずらいと思うので、次回は図柄にします :-D

ISTQBのCBT。

ISTQBを受けたくていろいろ調べているのですが、思った情報があまり
簡単に手に入らなくて時間がかかっております。

以前、カナダの委員会に問い合わせた時には、
カナダの住所と、ID二つが必要だといわれました。
それ以上問い合わせていませんが、国際運転免許がIDになるならそれでも
クリアできそうな気もします。

CBTがあるはずなので、調べています。
お持ちの方はどうやって受けたのでしょう・・・。

るびたんと戯れる。

知人に勧められて新しい言語を少し始めました。
メインで使っているサーバーの設定に妙にてこずってやっと動くようになりました。

思えば、昔は、技術書は5千円を下らなかったのに、いまなら2千円くらいから買えるし
インターネットもあるし、ハードルはだいぶ下がっている気はするのです。
こういうのも何かの積み重ねなのかな。

ユーザー操作をスイッチととらえたカバレッジについて

普段Webアプリケーションのテストケースを書くことがおおいのですが、
毎日デプロイがありそうなアプリでは、素早い仕上がりが求められることもあり、
テストの工程をだいたい二段にわけています。

1つ目：
ユーザー操作（クリック、ドラック、ブラウザバックなど）を0スイッチととらえたテストケース。
便宜上UTと呼んでいますが、当たり前品質を保証するもの。
お弁当QAではテンプレートがあるので、どなたが作ってもだいたい同じ粒度のものが出来上がります。

2つ目：
ユーザー操作をスイッチととらえて、2スイッチぐらいまでのもの。
PCリテラシのないテスターを想定して、シナリオ形式にしたり、練度の高いテスター向けには
マトリクスのまま提供することもあります。
ここでリスクを考慮してシナリオ、組み合わせ、ストレス、いじわる系、タイムライン、ステータス遷移などなど、いくつか既存の技法を用いて用意します。
UTでUIごとの単体動作が保障されているのを前提に起こり得るものを確認します。

ユーザー操作もテンプレートにしています。
ここは、B2BとB2Cやユーザー層など、初期インプットをベースに使うテンプレートを考慮します。

つまり、考えることをある程度使いまわしているので、作るのが早くなりました。
これを冷凍化と呼んでいますが、ここまできたら、自動テストのシナリオ作成自体が
工場の組み立て作業的なものになっています。

プラスアルファで、経験をベースにした勘所を足します。
秘伝のたれ？