■データインポートのテストパターン
内部DBへの影響確認→
Updateされる情報の影響範囲を確認→
テストパターンを掛け算して作成
1. 内部DBへの影響確認
インポートされるデータから、製品DBへ格納される項目を確認
テキスト：テキストボックスのテストパターンと一緒
数値：テキストボックスの数値テストパターン と一緒
バッチの更新パターンなどを確認して、カレンダー系（後日リンクします）のテストパターンを確認
2．Updateされる情報の影響範囲を確認
仕様書がない場合は、マインドマップ形式のデータフローを図に起こしておくと便利。
少ない時間で必要なものが得られる。メンテナンスコストも少ない。
影響の起点になる更新が発生する場合は、そこのつながりをテストする。
3．テストパターンを掛け算して作成
テキスト、数値、カレンダー系などのテストパターンを、
上記の要素に掛け算して作成
深さはｎスイッチの扱い。
2017年12月28日木曜日
2017年12月14日木曜日
これからQAを立ち上げたいときに、気を付けたいこと
初めてQAを雇おう！というときに五里霧中になる話を最近ぽつぽつ聞くので
軽くメモ。
■テストフロー
開発とQAのタスクを明確にして、それぞれのステップで引き渡すべき情報をシェアする。
概ね、それぞれのプロセスにおいて、
■テスト環境
テストサーバーはQA専用のものを用意したい。
テスト中にビルドがはいったり、データが入れ替わると
テスト結果を破棄してやり直す場合もでてくる。
テスターにはテストマシンはしっかり与えてくださいね☆
スピードが全然違います。
テスターなんて誰でもいいじゃん！は高リスク。
■チームパターンあれこれ
大体この三つ。
1. 第3者検証型
テストリード＋（単価の安い）テストオペレーター複数人 の、スタイル。
実はコントロールコストがとても高く、かえって高くなる恐れもある。
総体はテストリードが監督するため、比較的人員の入れ替えに強い。
2. 精鋭型
一通りテスト計画から実行までできるテストリードレベルの精鋭プレイヤーが
それぞれのチームにいるスタイル。
アジャイルや、開発スピードを上げたい場合にこのスタイルであることが多い。
3.エバンジェリスト型
専門家に社内教育してもらうスタイル。
コストは実は一番安い場合もあるものの、浸透するまでに非常に時間がかかる。
悩んだ時に聞けるのは心強い。
軽くメモ。
■テストフロー
開発とQAのタスクを明確にして、それぞれのステップで引き渡すべき情報をシェアする。
概ね、それぞれのプロセスにおいて、
- 仕様
- ステークホルダー
- 担当（開発・QA）
- スケジュール
- 注意事項（クレジットカードの扱いなど）
■テスト環境
テストサーバーはQA専用のものを用意したい。
テスト中にビルドがはいったり、データが入れ替わると
テスト結果を破棄してやり直す場合もでてくる。
テスターにはテストマシンはしっかり与えてくださいね☆
スピードが全然違います。
テスターなんて誰でもいいじゃん！は高リスク。
■チームパターンあれこれ
大体この三つ。
1. 第3者検証型
テストリード＋（単価の安い）テストオペレーター複数人 の、スタイル。
実はコントロールコストがとても高く、かえって高くなる恐れもある。
総体はテストリードが監督するため、比較的人員の入れ替えに強い。
2. 精鋭型
一通りテスト計画から実行までできるテストリードレベルの精鋭プレイヤーが
それぞれのチームにいるスタイル。
アジャイルや、開発スピードを上げたい場合にこのスタイルであることが多い。
3.エバンジェリスト型
専門家に社内教育してもらうスタイル。
コストは実は一番安い場合もあるものの、浸透するまでに非常に時間がかかる。
悩んだ時に聞けるのは心強い。
Web Software DB test pettern：Webアプリのデータベースのテストパターン
■ソフトウェア視点からのデータベースパターン
Readは、通常のテストをやっていればほぼカバーが終わっている。
Readのテストを明示的に入れないとテストが危険と判断されるのは、ミッションクリティカル製品や、ユーザー数の巨大な製品、また、製品の開発精度に問題がある場合など。
異常値のテストは、製品特性によってパターンが変わる。
異常値の代表例
別のテストセットの扱い。
適用すべきプロジェクトは、ケースごとに違うので、ケースバイケースで考えることになるのだけど、この辺の判断ポイントを可視化したいなあ。
- Create
- （Read)
- Update
- Delete
- 繰り返し
- 全消し
- 遷移
- 異常値
Readは、通常のテストをやっていればほぼカバーが終わっている。
Readのテストを明示的に入れないとテストが危険と判断されるのは、ミッションクリティカル製品や、ユーザー数の巨大な製品、また、製品の開発精度に問題がある場合など。
異常値のテストは、製品特性によってパターンが変わる。
異常値の代表例
- 例外値
- 空白
- 規格外： サイズ違い、フォント異常、文字コード範囲外など
- 入るべきではないデータ
別のテストセットの扱い。
適用すべきプロジェクトは、ケースごとに違うので、ケースバイケースで考えることになるのだけど、この辺の判断ポイントを可視化したいなあ。
2017年12月8日金曜日
WebUI Test Pattern：Text Box
For digits
For Texts
- 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
登録:
投稿 (Atom)