テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

3回目のテスト(テスト仕様書兼結果報告書を見て再テスト)

f:id:underscore42rina:20180708013707p:plain

underscore42rina.hatenablog.com の続きです。

どうしてやるのか

最後の仕上げみたいな感じです。

やり忘れたものがないよね。

という確認の意味でやっています。

時間は、数十分~数時間程度になります。
また、大体2回目のテストでインシデント(Issue)を確認しているので、 ここでインシデントが発生することはほとんどありません。

何をやっているのか

テストベース

前回の underscore42rina.hatenablog.com

で作成した「テスト仕様書兼結果報告書」を使います。

やり方

「テスト仕様書兼結果報告書」のOKになっていない項目を中心に目視で確認します。
その際に、Issueの確認したなーとかという記憶ベースでチェックしています。*1
少なくともNGになっているのはIssueにあがっているので、トレースはある程度できます。

その中で、以下の項目について、Issueの内容を確認したり、再度テストしたりします。

  • あれ?これ本当に修正確認したっけ?
  • 何か怪しいと思う項目(この場合、OKも対象になります)

怪しいと思うもの

言語化できていないのですが、デグレしてそうな気がするものや
もう一度やっといた方がいいな。と思うものが対象になっています。

やらないどどうなるのか

「テスト仕様書兼結果報告書」で一度OKとなっていたものが、デグレによってエラーになる可能性があります。
*2

やるとどうなるのか

わたしのやれるべきことはすべてやった。ということで
自信をもって、「テストが完了しました」という報告をしています。

おわりに

以上で、わたしが今までおこなってきたテストのやり方をご紹介しました。

またご紹介したい内容や知恵袋があれば、また書きたいと思います。

*1:それはそれでだめかもしれない。

*2:Issueの確認時に一緒にテストすることが多いので、実際にここでインシデントが発生することはほとんどありませんが・・・

2回目のテスト(スクリプトテスト+探索的テスト、Issue確認)

f:id:underscore42rina:20180708013621p:plain

underscore42rina.hatenablog.com の続きです。

目的(何のためにやるのか)

一般的?に言う「テストをおこなう」のがココになります。

システムによって、いろいろなテストをおこなっています。

スクリプトテスト+探索的テストって?

システムのテストは、わたし一人でおこなうことが多く テストの割り振りをすることがほとんどありませんでした。
それもあって、スクリプトテストとか、探索的テストという切り分けをすることもありませんでした。
わたし的には「オール探索的テスト」なんだと思っていましたが、
スクリプトテストと探索的テストとわけたほうが、理解はしやすそうなので、エントリーではわけています。

スクリプトテスト

スクリプトテストと書きましたが、わたしがおこなうスクリプトテストは
「3日前にどこまでテストしたか忘れないため」にテストケースを残している。くらいのものです。 *1

次に作っているドキュメントなどをご紹介しますが、いずれもテスト実施中に書きます。
なので、設計時間というものが存在しません。
一回書く時間は、分単位じゃないかなーと思います。(何時間も、は、よっぽどじゃないとかからないはず)

スクリプトテストでは、「テスト仕様書兼結果報告書」と呼んでいるExcelファイルを作成しながらテストを実行します。

テスト仕様書兼結果報告書とは

Excelファイルを作成していました。完全ではありませんが、どこかから持ってきたのをいい感じに変更していったら、こんな形になりました。

フォーマットは以下のとおり*2 f:id:underscore42rina:20180709204850p:plain

  • 大項目(feature: 概要)
  • 中項目(Scenario:シナリオ)
  • 小項目
  • 事前準備(given: 前提)
  • 項目/テストパターン(step)
  • テスト結果/(then: ならば)
  • テスト者
  • 日付
  • OK/NG
  • 備考

括弧をみるとお気づきの方もいるかと思いますが、
一時期turnipの導入を検討していて、勉強した際にこの形にしました。
実際は概要といいつつ、メニュー名だったりしてまったく文章ではなく単語になっていたりします。

スクリプトテストのテストケース

また別の機会に書くかもしれませんが、 テストケースは、「忘れない」レベルのものしか書いていません。

例えば、ログイン画面だったら

  • 正しく表示できること*3
  • ログインできないこと
  • ログインできること

くらいしか書いていません。 (実際テストするパターンはその数倍のケースになるはず・・・)

図におこすもの

UMLがほとんどわかっていないままなのですが、
仕様の整理が必要になる場合に、いくつかの図を書いています。(書くのはリストならExcel、図ならノートに手書きが多い)
私は文章よりも図で理解する(イメージを沸く)方が得意のようです。

が多いと思います。
とくに状態が複数でてくるものは、状態遷移図で理解するようにしていますし
「年度」が出てくるようなものは、図を書かないと理解できないので、
図に書いて、それでもわからないとか質問があったりするとその図を見せて教えてもらったりします。

テストデータ作成

わたしは手動テストしかしないのですが、同じようなデータを複数作成するときはSlenium IDEを愛用しています。
以前はExtentionでXMLのデータを順次読み込んで動作させることが可能でしたので
必要があれば、テストデータも作成していました。(とくにクレカ系のパターン違いとかはよかった。あと都道府県とか)

こちらは数分ではできなくて、数時間かけたりしていました。

探索的テスト

探索的テストをはじめるタイミング

タイムボックスなどでスクリプトテストと探索的テストの時間をわけていないので、気になる動きがあれば探索的テストのはじまりです。

nemorine.hateblo.jp

でパターンわけしていますが、Dパターン・・・になるのかな。きっと。

探索的テストってなんぞや?

探索的テストについては、資料やブログも公開されていますので読んでみるとよいと思います。
資料を読むと、私はこれらとまた違ってそうだったりします。。

www.slideshare.net

  • 探索的テストを勉強会でやってみる ameblo.jp

どんなテストをしているのか

PHPカンファレンス福岡2018で、実際にテストしてみましたのでご紹介します。
「Testing Live!!!」 フクダリナ - YouTube (4:25くらいからテスト実行をしています)

ただ、こちらの場合、先ほどのテストケースも全くなくやっているのですが
普段は前述のテスト仕様書を見て、項目を決めてテスト実行しています。
といっても、動画のように気になりはじめたらどんどん横道それてIssue書くこともままあります。

いろんな視点から整合性を確認する

www.slideshare.net

資料に掲載していますが、私のテストは「整合性がとれているかどうかをいろんな側面から確認する」感じです。

  • 前の画面と同じか
  • 上の情報と同じか
  • 他の権限と同じか
  • 他のメニューと同じか

規則性があるかを探している感じなのかもしれないです。*4

Issueの確認

テスト中に出た不具合やカイゼン案は、すべてインシデントレポートを作成します。

Issueの書き方

以前Issueの書き方勉強会をしたときのブログとSlideが参考になると思います。 underscore42rina.hatenablog.com

www.slideshare.net

エンジニアから戻ってきたIssueの確認方法

対応してもらった(または却下された内容)を読んで、
そのとおりに改修されているか確認します。

基本的には、そのとおりに動いていればCloseするのですが、いくつかテストを増やすときがあります

  • 改修内容が想像と違った場合
  • 改修内容で他の機能や画面にも影響がありそうな場合
  • 計算などでIssue以外に前回OKしたテストケースをもう一度実行したくなる
  • 他・・・・

ぱっと思いついたのがこんな感じなので、また別のエントリーに書くか、加筆すると思います。

テスト仕様書兼結果報告書

Issueを発行するときに、OK/NGの欄に「NG」と入力します。
ただし、エンジニアから戻ってきたIssueの確認時には、このNGのところはまだ残したままにすることが多いです。 *5
このNGは3回目のテストで使用します。

*1:忙しいときは同時期に9本のテストを抱えていたので、どれがどこまでしたかなんて全く覚えてられなかったのです・・・

*2:大中小と出てきたら危険なにおいしかしない気がするけど、やっぱり書きやすい。

*3:「正しく」ってなんやねん。と、通常書いちゃダメというセオリーを破っているスタイル。他者にこれ使っちゃダメ

*4:そうすると何らかのインシデントが発生する・・・

*5:一緒にOKを入力するときもあります。大きめのプロジェクトのときとか・・・かな・・・でも100%ではない

1回目のテスト(軽い探索的テスト)とは何か

1回目のテスト(軽い探索的テスト)とは何か

f:id:underscore42rina:20180708013206p:plain

underscore42rina.hatenablog.com の続きです。

目的(何のためにやるのか)

  • 2回目のテスト(スクリプトテスト+探索的テスト)を実行してよいか判断するため

プロジェクトの状況に影響されるのですが(エンジニアスキルはそこまで影響されません。プロジェクトの方が切実)

ここで「これはバグかなりでるぞ」とかの手ごたえや
予定しているテストスケジュールどおり進めそうかという感触をつかむためにやっています。

やらないどどうなるのか

これをやらずに正式な?テスト実行を始めてしまうと、以下のような問題が発生する可能性があります。
(もちろん1回目のテストをすると必ず食い止められるわけでもありませんし、2回目以降で同じような問題が発生することもあります)

  • 同じような不具合が頻発する  (例;バリデーションメッセージ系のバグが管理系の登録画面すべてに発生してしまう)
  • デザインに統一性があまりにもない場合、検討しなおす必要がある
  • システム要件が大きく違い、お客様に確認する必要がある(開発スケジュールの調整が必要なレベル)

上記を調整後、同じテストを必ずおこなう必要がでるため、無駄なテスト工数が発生してしまう

やるとどうなるのか

1回目のテストが長引いている場合はプロジェクトの雲行きが怪しいです。

テスト進捗も0%と報告するので、双方にとってブルーです。

または、1時間で10個近く出てきた場合、1回目のテストの途中でもテストを止めることがあります。(一度仕切りなおした方がプロジェクトスケジュールもスムーズになると思うため)

逆にテスト仕様書を書き始めていたら、スムーズにテストが始められていいる状態です。その場合、テストスケジュールも順調に終わりそうな予感がしてHappyです。

1回目のテストの前にやること(エンジニアからの説明)

underscore42rina.hatenablog.com

の続きです。

テストを始める前に、テストをするシステムの説明をしてもらいます。
私がおこなうテストのシステムは、仕様書のドキュメントがないこともあり
(そして私もまた他のテストをしていて時間が取れないこともあり) テスト実行直前に聞くことが多かったです。

どんな感じに話すかを、PHPカンファレンス福岡2016で少し紹介しています。

underscore42rina.hatenablog.com

説明にかかる時間

規模にもよりますが、数分~1時間くらいの時間です。
エンジニア1人+わたしが多かったですが、場合によってはエンジニア数名+わたしの構成もありました。

エンジニアの説明で聞くこと

  • どんなシステムなのか
  • 使用するブラウザの種類
  • どのくらいの規模(どのくらい開発に時間がかかったのか)
  • 難しかったこととか気になる機能とか

「どんなシステムなのか」と「使用するブラウザの種類」が必ず聞くことです。

説明中に考えること

説明の間は、「ヤバそう」と思うところを考えたりします。
リスク分析・・・とまでは言えないと思いますが、その類ではないでしょうか?

テストコードでできないか

テストコードで簡単に実現できそうな割に手動テストだと時間がかかりそう
と思うところ(コスパがよさそう、ROIが高そう)は、テストコードかけないかエンジニアに相談します。

  • 権限まわり
  • 計算まわり

スコープの範囲の相談

業務系システムの場合、あまりにも仕様が複雑で見当がつかない場合は、
スコープの範囲を限定することがあります。
(そのレベルになると、仕様ドキュメントが何もないことはないので、
ドキュメントに書かれている範囲ではテストをします)

その場合は、お客さまとプロジェクトリーダーやエンジニアチームで
確認をしてもらうことになります。

説明中に書く図

例えば転職サイトのシステムで、直接会社に応募した場合と、リファラル採用で入社した場合のお金の流れについて
説明があったとします。 f:id:underscore42rina:20180708011108p:plain

説明中に、こんな感じでお絵かきをします。
この話中で、システムの登場人物の把握や、システムの概要を図で理解しています。

絵心がないので*1、見てのとおり人には伝わらないですが
わたしはこの図で大体の話の流れを思い出せます。

*1:中学の美術部部長とはなんだったのか

リナ流テストのやりかた

はじめに

わたしは今まで「オール探索的テスト(というか、事前にテスト設計をしないテスト)」をやっていたのですが、
そのテストのやり方のまとめです。

テストする人をやっていたとき、ほぼこのやり方で、ひとりで複数案件のテストを回していました。

このテストのやりかたは、ひとつの案件につき、3回のテスト実行をおこないます。

  1. 1回目のテスト(軽い探索的テスト)
  2. 2回目のテスト(スクリプトテスト+探索的テスト、Issue確認)
  3. 3回目のテスト(リグレッションテスト) f:id:underscore42rina:20180708013034p:plain

以降で、それぞれのテストでやっている

  • 目的(何のためにやるのか)
  • テスト実行にかかる時間
  • テストの開始条件
  • テストの終了条件
  • テスト終了時にできる成果物(アウトプット)
  • メモ(わたしのつぶやき)

をご紹介します。

注意事項

このテストでは 動いていることを保証する ための活動に重きを置いていません。 わたしがやっているテストでは、事前のテスト設計もしませんし
最終的に成果物としている「テスト仕様書兼結果報告書」には、
すべてのテストケース(やテストデータ)を記載していません。

わたしがやっているテストでは
限られた時間内でできるだけ効率よくインシデントを見つけ出し
少しでもシステムがよりよくなって、お客さまが使いやすいようなカイゼン提案を出し
エンジニアにとって最小の負荷ですむ

ように積み重ねて最適化した結果です。

また、これをやるためには、以下のような条件もあるかなと思います。

  • テスト活動を一人だけでできる
  • エンジニアとの距離が近い
  • システム規模がわたしが把握できるくらいの規模

テストをはじめる前に

エンジニアからシステムの説明をしてもらいます。

詳しくはこちらに書きました。
1回目のテストの前にやること(エンジニアからの説明) - テストする人。

1回目のテスト(軽い探索的テスト)

目的(何のためにやるのか)

  • 2回目のテスト(スクリプトテスト+探索的テスト)を実行してよいか判断するため

テスト実行時間

  • 新規のときは1時間~1日くらい(1回の実行で)
  • 追加開発はしないときも多い

テスト開始条件

  • 動くものができたら

テスト終了条件

  • テスト仕様書兼結果報告書かくかーと思えるまで
     このテストでIssueが大量に出てくる場合はIssueを対応するまで待つことがあります。

成果物

  • Issue

わたしのつぶやき

この時点では「進捗・・・ありません」と報告します。
次の2回目のテスト以降で、はじめて進捗として考えています。

くわしくは

1回目のテスト(軽い探索的テスト)とは何か - テストする人。

2回目のテスト(スクリプトテスト+探索的テスト)

目的(何のためにやるのか)

  • いわゆるテスト実行です。テスト設計も必要があれば、ここで一気にやることが多いです。

テスト実行時間

  • 案件規模による(数時間~数週間)

テスト開始条件

  • 1回目のテストで「よし、(Excelにテスト仕様書兼結果報告書)作りながらやるかー」ってなったら

テスト終了条件

  • テスト仕様書兼結果報告書が全画面分書いてOK/NG/-が埋まるまで
  • Issueがなくなること

成果物

  • Issue
  • テスト仕様書兼結果報告書

わたしのつぶやき

この時点で進捗を報告できるようになります。

くわしくは

ブログ作成中(ちょっと待ってね)

3回目のテスト(テスト仕様書兼結果報告書を見て再テスト)

目的(何のためにやるのか)

  • Issueの修正でデグレや影響がないことを確認する
  • 想定したテストが終わっていることを確認する
  • 一部リグレッションテスト

テスト実行時間

  • 数時間程度が多い

テスト開始条件

  • Issueがなくなったとき

テスト終了条件

  • テスト仕様書兼結果報告書が全画面分書いてOK/-の2つになること

成果物

  • テスト仕様書兼結果報告書(Excel

わたしのつぶやき

これが終わると「やった!終わった!おつかれさまでした」とエンジニアに報告します。

おつかれさまでした。

くわしくは

ブログ作成中(ちょっと待ってね)

おわりに

今回のエントリーでは、テストのやり方をざっくり書きました。
このあと、がんばれたら、1回目のテスト~ もう少し掘り下げてエントリーを書こうと思います。

わたしのTwitterのつかいかた

わたしの周りのクラスタのみなさんや
IT界隈のみなさんは
Twitterを使っている人も多いと思います。

わたしは、まぁまぁつぶやいている数が多いのかな・・・と思うのですが、
仕事中のTwitterの使い方を書いてみます。

仕事中

頭の中を(NDAに反しない範囲で)たれ流す

自分のTwitterポリシーは、「たれながし」です。もちろんNDAに反しないとか、
読んで気持ちのよくないものは書かないようにしているつもりです。

プログラマーのときに席でひとりごと言ってたのが、そのままTwitterでつぶやいているのと一緒なのかもしれないです。

なので、とくに誰かに読んでもらいたい、かまってアピールとは限りません。

やりとりするのは通知がきたものだけ

Twitterを開いていますが通知画面(https://twitter.com/i/notifications)にしています。
なので、必然的に常に見ることもありません(そんな通知こない)

わたしがつぶやいているものは、お仕事の話も多くて(仕事中だもんね)、それに対するアドバイスがあるので
お返事したり、追加で質問したりしています。

お仕事中じゃないとき

フォロワーさんのつぶやきを見るのは、ここです。
前は通勤時間中と自宅で読んでいたんですが、今はお昼休みとか、お仕事が終わったあととにで読んでいます。

読む対象のリストを作っている

読む対象のフォロワーのリストを作っています。
このリストは、ほぼ全部遡って読むようにしています(たまにシンポジウムとかTLの流れがはやすぎると読めないときもあるけど)

まぁまぁ時間取られるので、仕事中は読めないのです。。。

TwitterクライアントはTwitRocker2

読むためのTwitterクライアントはTwitRocker2を名前が気に入ってずっと使っています♡
過去の既読ツイートから追える(最大800ツイートくらい)のも使っている理由です。

とはいえ、他のクライアントアプリを数年使ってないので、もっと便利なものはありそう・・・

iOSAndroidもあります。

Twitterをうまく使おう

お仕事中にTwitterなんかして!とかって言われたり思われたりするかなーと思うのですが
脳内整理ができることもあるし
お仕事の解決策が見つかることも多々あるし
休憩代わりにつかってもいいのかなーと思うので

自分にあった使い方をみつけると なんとなくしあわせになれるんじゃないかと思います♡

そして、もっとうまい使い方があれば教えてください!(もうがっつりパターン化しちゃってる><)

「これだけ!KPT」をざっくり読んで、ひとりKPTをはじめてみた

ほんと今さらで申し訳ないくらいなのですけど、ようやく「これだけKPT」を読みました。

これだけ!  KPT

これだけ! KPT

(去年、著者の天野さん直々にKPTのワークをしてもらったというのに・・・)

KPTはもちろん知っていたのですが、
やっぱりちゃんと読んでおきたい というのと
今のお仕事で、チームとしてもKPTをもっと効果的に使えないか と思って読みました。

本の読み方

お休みの日に、ごろっごろしながら1日で最後まで流し読みしました。

  • とにかく、積み本をなくしたかった
  • KPTはワークも受けていたし、セッションも聴いていて概要はわかっているつもりだったのでとりあえず1周目しようが今回の目的
  • 今から実践するために読んだので、これからちょいちょい読み直す必要がでるとわかっている
  • 実践しながらふりかえるとより身に付くはず!きっと!

と思って、ほんとにざっくりしか読んでないです。ごめんなさい。

でもやっぱり、今私に必要そう!

今のお仕事では、リーダーのようなお仕事をしているので、今までと全然勝手が違う。
慣れていない環境で毎日全然うまくいかないな・・・と思っていたところに、「あ、やっぱりKPT私に必要」という内容がでてきました。

また、自分でも立てていた方針「カイゼンをすること、続けること」が本書にもでてきて
これは、やっぱりやってみなきゃ。ってなりました。

ひとりKPTはじめました

f:id:underscore42rina:20180618183531p:plain

やり方

壁にKPTボード作ってもいいなと思ったのですが、そもそもが「ひとり朝会」の派生でやりたかったのでTrelloを使えないかと模索。 underscore42rina.hatenablog.com

ということで、Trelloをそのまま採用。ひとり朝会のボードにラベル管理できるか実践

はやくも、併用するとKPTぽくなくなっちゃう。

ということで、別のボードを用意しました。
今は、スプリント代わりに1週1スプリントとしてできるかやってみています。
それと、1つ持っているプロジェクトの経過を自分なりにKPT管理したかったので、2ライン(1つは1週ごとに増えていくけど)でやりはじめました。

感想

はい。慣れないお仕事(環境とちょっとやり方やポジションが変わると)で毎日へこむことだらけだったのですけど
ちゃんとふりかえると ちょっとだけ前に進められそうな気がしてきました(週末のPHPカンファレンス福岡効果もあるけど)

こちらも引き続きやってみて、効果がでたらいいなぁと思います。