UTP2

UTP2を勉強したときに作ったテストステラテジーです。
実運用するには、シナリオテストのあたりをもう少し細分化する必要があるかとおもっております。日々更新中。

おさしみモデル

先日、D3～グルメなテスト～　に、お越しの皆さま、ありがとございました。
当日のパワーポイント（ちょびっとだけ変更）をアップいたしますね。

https://www.slideshare.net/SaoriEgawa1/osashimi-94565996

気が付いたらつのまにか、時間の経過につれて
状態の変わっている商品のテストパターン対策にどうぞ。
（在庫切れとか、支払条件の変わるものとか、定期購入とか、それらの繰り返しとか）

白がグレーになっていて、モダンなお刺身になってしまった・・・　・ｗ・；；

Webなテスト屋さんがきになる法務

■個人情報保護法

■プロバイダ責任法
■電子消費者契約法
■特定商取引に関する法律（食品、古物、ほか）


■クレジットーカード関連
http://www.fujitsu.com/jp/solutions/business-technology/security/secure/pci-dss/about/
http://www.sist.ac.jp/~kanakubo/network_literacy/netshop.html
■電子商取引に関する主な法律
http://www.sist.ac.jp/~kanakubo/network_literacy/netshop.html

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