2018年12月16日日曜日

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


探索的テストの勉強会をやってほしいというリクエストがあったので、
サンプルを記載してみますね。
  1. データに注目する
  2. 作りに注目する
  3. 設定に注目する
  4. ブラウザ特性に注目する
  5. (言えないけど○に注目する)
仮に上記の4つを代表として、ECサイトの例をあげていきます。

1.データに注目する
探索的テストに限らず、Regressionなどでもそうですが、データの塊に注目して、
それらが表示される個所を探す方法です。

データクラスタの例:
  • ユーザー情報>個人情報>名前、住所、電話番号・・・
  • 購入情報>金額>個数>日付・・・
  • データに紐づく状態遷移 購入前、購入後、カートの中、など
影響範囲の例:
  • 表示か所→設定画面、ショッピングカート、個人情報変更画面、e.t.c.

2.作りに注目する
似たような処理を行っている塊に注目して探す方法です。
例:
  • 検索
  • アカウントの権限(料金プランなど)
  • ブックマークの処理
  • ログインの制御、など 

3.設定に注目する


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



4.ブラウザ特性に注目する

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

この辺の抜け漏れをなくすには、

  • テンプレート化
  • トレーサビリティマトリクス(T字マトリクス)
  • マインドマップ

などで書いておいて、時短します。

5番目は、お察しください。

2018年12月8日土曜日

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

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

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

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


2018年11月23日金曜日

5%の力

その昔、検索エンジンのローカライズテストをしていたときのお話です。

検索エンジンなので、究極には、すべてのユーザーの検索に対して
検索した期待値を表示することが求められますが、
たとえば「テスト」と検索したときに、ユーザーが

  • 検索を初めて使って、ただテストと入れてみた
  • 学校のテストの答えを探したかった
  • 適性試験の傾向を調べたかった
  • ソフトウェアテストの記事を探したかった
などなど、いろいろ考えられる中から、ユーザーの傾向を推測して
表示する、というようなことをしたりしていました。

リリースも落ち着いて、だいぶ検索結果の信頼性もおちついてきたころ、
検索エンジンのチューニングがあり、
「5%のジャンクは捨てても問題ないので、新しいロジックで実装する」という方針があり
検索してみたところ、体感としては5%以上の確率で、全く期待していない
結果がトップにくることがありました。

よくよく考えてみると、検索エンジンにとって5%というのは、
20回に1回間違った結果を表示することになります。
検索を20回、というのは、普段使っているユーザーにはほぼ確実に
目に入ることになります。

はたして本当に、そのチューニングは正しかったのでしょうか?

その後、どういう経緯があったのか知る機会はありませんが、
新しいチューニングは1か月もしないうちに元に戻っていたようです。

5%は、本当に無視してもいい数字なのか?
それ以来、時々思いだして考えています。


2018年11月18日日曜日

UTP2

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


2018年4月21日土曜日

おさしみモデル

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

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

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

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

2018年2月19日月曜日

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

2017年12月28日木曜日

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

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

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

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

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