テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

テスト実行のエビデンスを残すということ

百聞は一見に如かず　とりあえずやってみた

Screenpressoはやっぱり神だった

スクリーンショットツールは以前からScreenpressoを愛用しているのですが*1
ここでもScreenpressoを利用。

やっぱりすごい。
今は必要があれば動画もとるということで、今まで使用していなかった録画機能も使用。
gif動画がサクッと作れるのはすごい

何に貼るか　は大事だった

スクリーンショットをエビデンスとして残すのに、ExcelではなくConfluenceに残しています。
テストケースのとなりに貼る感じ。
これがストレス軽減にかなり役に立ってた。

以前シロメでExcelエビデンス作業したことがあったのですが、
こちらはTableにコピペするだけだし、ファイルが重くなるようなことも当然ないので、かなり楽でした。

役に立ったこと

人のテストケースの理解

今のところ一番はこれかも。テストケースが実際に何を確認したのかをエビデンスからも読み取れるのはうれしい。
後追いで他のブラウザのテストするときや、レグレッションテストするときには役に立ちそうだなと思いました。

バグの混入原因をさぐる？

冒頭のTweetはそういうことだったようです。
膨大なシステムとか、膨大なテストケースのときに、ちょっとした違いが役に立つのかもなぁと思いました。

お客さまへ証拠提出

昔そういう理由でおこなったことがあります。
実行結果を示す数少ない証拠になるのかなと考えています。

テスト実行のエビデンスを残すということ

もともとテスト実行のログもエビデンスも残すテストをやってこなかったので、かなり懐疑的であったのですが
テストするメンバーが複数人いたり、前述の理由もあって、一概に悪いって言えないなぁと思いました。

ただ、これの費用対効果がどのくらい高いのか、スクリーンショットを撮る作業になってしまって、”テスティング”できていないとか そのフラストレーションがある（人もいる）ことは注意してもいいのかもなぁと思いました。

*1:以前はインシデント報告およびマニュアル作成時に利用していました

わたしは老害になりつつあるのかもしれない

今年はとくに環境が変わって、面倒を見る側というか、チャレンジしている人を応援したり支える側になってきたと同時に
どうしても自分が老害なのではないかと気になってしまう。

説明が足りなかったり、配慮が足りなかったり
きちんと伝わらないことがあったり
色々難しいな。と思う。

老害ではなく先輩として生きたい。

とにかく自分をどうにかしないとどうにもならないんだなぁと
大事なときに大事な言葉をもらえることをしあわせに思って
目指したい大先輩たちを追いかけるかー

リモートワークはQOLが高まる

リモートワーク

QOLってなぁに？

Wikipediaより

クオリティ・オブ・ライフ（英: quality of life、QOL）とは、一般に、ひとりひとりの人生の内容の質や社会的にみた生活の質のことを指し、つまりある人がどれだけ人間らしい生活や自分らしい生活を送り、人生に幸福を見出しているか、ということを尺度としてとらえる概念である。QOLの「幸福」とは、身心の健康、良好な人間関係、やりがいのある仕事、快適な住環境、十分な教育、レクリエーション活動、レジャーなど様々な観点から計られる。

またQOLには国家の発展、個人の人権・自由が保障されている度合い、居住の快適さとの関連性も指摘される。

したがってクオリティ・オブ・ライフは、個人の収入や財産を基に算出される生活水準（英: standard of living）とは分けて考えられるべきものである。

ということらしい。まさしくクォリティ・オブ・ライフ！

わたしにとってのQOL

自分が生きていく上で、いくつかのポリシーがあるように思います。

お金について

わたしは、お金を使うことに抵抗がある方かなと思っています。
お金が減っていくのがこわい。

ただ、お金が増えていくことにもあまり執着がない方かなと思います。

  • 突然収入がなくなっても１～２年生活できるくらいの貯金
  • 平均世帯年収の年収が当面の目標（きっと1000万円とかは必要ないかな。あったらうれしいけど）
  • 老後のための貯金はこの先しないとなぁ・・・

くらいです。

住まいについて

わたしの住まいは、祖父が住んでいた家をリフォームしているので築30年のおうちです。 せっかくなので、壁紙は遊んでしまえ！と、仕事部屋の壁紙とかは遊んでしまっています（おかげでちょっと部屋暗い気がする）

お部屋がかわいいと思えたら、古いとかはあまり気にならない気がします。 毎日おうちがかわいいと思えるのはほんとに楽しい。 十分な部屋数（仕事する部屋と、寝る部屋と、家族で過ごす部屋）があるのは、リモートワークする十分なきっかけになりました。*1

毎日、こんなおうちに住めてありがたいなぁと思っています。*2

家族について

週末は家族でおでかけ！みたいなイベントことを全くしないのですが、 平日も普通にみんなでご飯たべて、ごろごろして、夜になったら寝る。という 普通のことが普通に毎日できるのはありがたいです。

友人と過ごすこと

今のところは、オンラインで連絡が取りあえる環境があれば、頻繁に会う必要はないかなぁと思っています。

リモートワークでQOLがあがったこと

前回書いたブログもだいたい同じこと書いてるかな underscore42rina.hatenablog.com

お金について

外にでないので、つい買ってしまうものが減った（特にコンビニのもの）ことと
その分、外にでたときは、多少ガッと買ってもいいや。ってメリハリができているのはすごく満足度が高いです。

今は、好きなものを　ちょっとだけいいものを買うことができたりするのが楽しいです。（数百円の話だけど）

衣食もまさにそんな感じ。着ていくための服を増やさなくてよくなってきたので
好きなお洋服だけを（バーゲンだけど）買えたり、
コーヒー屋さんのコーヒー豆を買って、自分で挽いて、毎日の仕事に飲んだりと
きちんと選んだもので過ごせるのってとってもしあわせです。

住まいについて

せっかくリモートワークできる環境になってしまったので、それをフルに活かせるのはうれしい！

せいかつ

朝起きて、自宅になった梅で作った梅シロップのジュースを飲んで、
庭におりて、お庭の整備をして
身支度をして
9時にPCを起動する。

快適な温度の部屋で、仕事用にふんぱつした自分好みの色のパソコンチェアに座って
コーヒーの香りだったり、好きな匂いに包まれる。
庭のお花が咲いている時期であれば、仕事部屋に活けて彩りを添えてみて
いつもどおりの仕事をする。 f:id:underscore42rina:20180803162742j:plain

午前は30分の読書会で、お互いの意見や、今後の会社についてできることはないかとか考えて
午後は6分間の体幹トレーニングも同僚とおこなう。

18時には子どもが帰宅して、おかえりとあいさつして
仕事を中断したり、終えて、ピアノの練習につきあう。

夕飯ができていれば一緒に食べて、
そうでなければ朝の続きにとお庭の整備してお風呂。

家族で一緒の時間をすごして、22時にみんなで就寝。

普通に暮らして普通に仕事してるって普通にしあわせ。

*1:仕事部屋がなければリモートワークするってならなかったと思う。

*2:というほど立派じゃない。害虫マジヤバい

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 の続きです。

目的（何のためにやるのか）

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

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

スクリプトテスト＋探索的テストって？

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

スクリプトテスト

スクリプトテストと書きましたが、わたしがおこなうスクリプトテストは
「３日前にどこまでテストしたか忘れないため」にテストケースを残している。くらいのものです。 *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:忙しいときは同時期に９本のテストを抱えていたので、どれがどこまでしたかなんて全く覚えてられなかったのです・・・

*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時間くらいの時間です。
エンジニア１人＋わたしが多かったですが、場合によってはエンジニア数名＋わたしの構成もありました。

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

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

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

説明中に考えること

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

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

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

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

スコープの範囲の相談

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

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

説明中に書く図

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

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

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

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