2023年12月17日日曜日

Wモデルとテストアスペクトとテストピラミッドの話




今回は、Wモデルとテストアスペクトとテストピラミッドの話をします。

テストピラミッドは、Web製品のテストを行うテスターには、

よりなじみがあるかもしれません。

この1枚で一晩語れそうな図になってしまいましたが、順番に概要を説明します。


 *  *  * 


まず左の、テストアスペクトについてですが、これは、テスターの立場から想定する心配事と、エンジニアが想定する心配事があるよね、という図です。テストアスペクトについての論文は、InSTA2019という海外のカンファレンスで発表されています。


同時に、テスターのテストアスペクトはユーザーよりの観点でもあるので、ビジネスの責務だったり、Requirementだったり(受入テスト)など、より実際の使い方に近いところを深く考えるところです。

一方で、デベロッパーのテストアスペクトは、当然開発よりのテスト観点となります。これと、Wモデルやテストピラミッドとも重なるところがある、というのが今回の話の着眼点になります。具体的には、Unit TestやAPIテストなどは、開発の知識や観点がないとテストできない(しづらい)領域になります。そして、E2Eレイヤーは、ビジネスドメインの知識や、ユーザーの使い方、ブラウザやシステムなど、プラットフォームの知識、関係のあるオブジェクトの状態遷移など、より実運用に近いところがテストの関心事になります。


Wモデルと、テストピラミッドの説明は、他でたくさん資料があるとおもいますので、ここでは一旦割愛させていただきます。

テスト活動全体のバランスとして、各テストレベルの補償内容の全体最適だったり、最適化できない部分をどこで保証するのか、という、木ではなく森を見て全体の品質保証活動を安定させるには、これらの概念モデルは便利です。


私は、一番上に、ユーザーがいるイメージで、テストセットを作っています。


例えばこれからのキャリアプランにおいて、どの領域を強化していくかの参考にもなりますし、テスト保障戦略の長期プランを考える際の参考にもなります。


こうしたモデルを使って、パズルのように、テストを組み立てるのは、楽しいと思いませんか?


(この表については、まだまだかけることがあるので、今後アップデートしていきます。)

2023年4月25日火曜日

ブラウザ特性のテストパターン

キャッシュ

    キャッシュクリア

 既存キャッシュ

クッキー

 クッキークリア

 既存クッキー

タブ

 タブで二重操作

 片っぽのタブをクローズ

ブラウザバック

 ブラウザバックとフォワード繰り返し

ブラウザフォワード

 ブラウザバックとフォワード繰り返し

リロード

    課金操作などの途中でリロード

クローズ

    操作の途中でクローズ

最小化

 操作中に最小化

最大化

 操作中に最大化

サイズ変更

 ペインが消える程度にサイズ変更

タブ

 タブAとBで同じ設定をいじる

 途中でどちらかのタブをClose

 シークレットモードなどで別のセッションをもち、マルチクライアント状態にして操作

ブックマーク

 ログアウト状態からのブックマーク他

2023年4月11日火曜日

Webマニュアルテスターのキャリアプラン

 


細かいところはまだまだたくさんかけるのですが、一覧にしてみました。

現場の要求に応じて、順番が前後するケースもたくさんあるとおもいます。


あとは、Junior-middleぐらいのときにプログラムをやっておくのも良いと思ってます。

一つの参考になれば幸いです。

2022年12月11日日曜日

テストピラミッドツリーにテストプロセスや技法を飾ろう☆彡

 テストピラミッドツリーを用意してみました。

開発(根本)⇒リリース(☆彡)に向けて、
いろいろな形の付箋で技法やプロセスをくっつけて

テストピラミッドツリーを飾ってみてください!

(承認システムなので、リクエストを送っていただいて、

 こちらで承認する必要があります。
 面倒ですみません・・・)



https://miro.com/welcomeonboard/dEJMamx0bW5QVUJDVnZDZVdDcFRPb1AyVWRiWHRtbUxjNmlqREVKSEJZc3d3SlRzS3o5bDRzTE5sRFI1d013aXwzNDU4NzY0NTQwOTY4ODQ2MjY3fDI=?share_link_id=825418598217


たくさん飾れるといいなぁ。

2022年7月31日日曜日

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

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


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

ー 環境差分

ー 前提条件

ー テストスコープ



環境差分

「リビジョンしか違わないのに、なんでバグがでるんだろうね」
なんてシーンを見たことがあります。
テストで新人のころに叩き込まれたりするのですが、
ビルドにかかわるものはバージョンを統一するのが基本です。
また、本番とテストサーバーの差分もリスクになります。
この辺は、運用でカバーしようとするとかなりの確率で不具合につながりますので、
テスト環境は気を遣うところです。


前提条件

テストデータの状態によっては、予想しがたい不具合だったり、
または不具合ではないものが結果として出てくる場合があります。
テストしたい項目以外はデフォルトで、というのも押さえたいポイントです。
また、アカウントの設定やブラウザバージョン、および設定など、
テストしたい項目の前後の操作や条件も気を付けたいところです。

テストスコープ

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

  • 3色ボールペン技法
  • 6W2H (HAYST法)
  • ペルソナ
  • ユースケース
  • 意地悪漢字
それぞれの技法はここでは触れません(いい本や例がたくさんあります)。
また、操作要素(ボタン連打、ブラウザバックやフォワードなどのブラウザ特性、モバイル特性など、製品ドメインに紐づく要素)なども、テストセットにしておくと観点を見つけやすいです。
また、テストスコープについては、ビジネス開発者にレビューをもらうなど、
フィードバックの仕組みづくりも有効です。
(QAに一任されている、という約束がある場合は、レビューがない場合もあります)


2021年12月14日火曜日

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

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

用意するもの

  • 筆記具
  • 手練れ


やりかた

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

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

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

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
アイコン: icon
タブ: tab ページ: page
リンク:Link

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

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

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

For...
いろいろ。


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


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

  • データのCRUD+3(独自に三つ付け足してます)
  • ビジネスの単位でフロー作成
  • 組み合わせテスト
  • Regression Test
などなど、別のテストは、これもテストセットのマップとして
用意したものをそれぞれ作ります。

これらのセットの使いこなし方をチームの新人さんに把握してもらえば、
こっちのテストはあなたが作って!と、テストプロセスの標準化を
行って、作業を渡すこともできるようになってきたりします。
(今うちのチームはこれでやってます)
(ToCの製品はこれがやりやすいです。なぜなら、ドメイン知識の共有が軽いので)
これがお弁当QAでの、テスト作成の標準化とパターン化、
スピードアップのコツになります。

チームにインストールする際は、このマップの箱1こずつ
ワークショップを行って覚えてもらってます。
新人さんでもある程度テストが書けるようになったりします。

もちろん、トレーサビリティやエビデンスを文章の形で残しておく必要が
ある納品物などはこのままでは完成しないので、どうしても急ぐときは、
テストを先にやって不具合を出しておいて、エンジニアさんがFixしているあいだに
テストケースを後から書き起こしたりしていました。
手早くやらないと忘れますけどね!
今の現場ではそこまでお行儀の悪いことはやってません・・・。
(このぐらいのスピードが求められる現場は大変ですよねー・・・orz)

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

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

一応、今回は上級者向け、として、
いつもなら省いて書くところも少し書きました。
もちろんリスクもありますので、
ちゃんとコントロールできるくらいの手練れなら
使いこなせるかと思います。
 m(_ _)m。

2021年8月27日金曜日

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