127. テストプロセス その⑨

127. テストプロセス　その⑨

さて、テスト実行です。

テスト実行では、今まで準備してきたことを進めていきます。

語ることも多くはありませんので、作者の経験の話を書いておきます。

作者はWeb系App系ゲーム系なわけですが、システムテストのテスト期間はおおよそ3日程度、長くて5日くらいが多い印象です。

大変だったのはゲームでした。

イベントが週替わりで回っていまして、システムテストの期間は3日間、テストケース数は1万件くらいでした。ガ〇ダムなゲームで、ステータスの反映など確認がかなりありました。テスト実行も大変でしたが項目を作るのも大変だったことを覚えていますｗ

（イベント一つずつにQA担当者1名、テスターは25名くらいの体制）

ゲームもアプリも期間も短くやることも多いですから、とにかく事前準備が命。

そこがミスっていると、もう取り返しがつかない状態に陥ったりするわけです。

さらに計画してたからといってそれ通り進むかというとそうもいかず、リーダーをやっていた時は毎朝「今日はこういう風に攻めていって、誰々さんと誰々さんにはこれを任せて、もしこうなった時はこっちの計画に移して……」と考えながら会社に通ってました。ちょっとした軍師気分ですねｗ

CPM法

126. テストプロセス その⑧

126. テストプロセス　その⑧

さて、テスト実装です。

テスト実装では、テスト設計でハイレベルテストケース（具体的な数値などではないテストケース）をローレベルテストケース（具体的な数値などが決められたテストケース）に落としていきます。

あとは、マンガでも描いたように「テスト実行のために必要な準備を全部やっておく」プロセスです。

作者の経験上、テスト環境の準備やテストデータの準備なんかは早め早めに着手した方がいいことが多かったです。

開発者に依頼する必要があることがあったりするんですよね。

ギリギリに言うと向こうが困ることもしばしば。（大抵は「いえいえ、大丈夫ですよー」って返ってくるけど、無理させてる場合も結構ある）

他にもテストで使うツールの準備、テスト管理ツールの準備、新しく入ってきたメンバーの初期教育（テスト入る前までに基本的なアプリの知識をつけておいてもらう）みたいなこともありますね。

テストデータの準備の自動化は費用対効果が高いことが多かった

125.テストプロセス その⑦

125.テストプロセス　その⑦

テスト分析では「何をテストするか」を考えました。

ただ何をテストするかを考えただけでは、それをどのようにテストすればいいかは考えられていません。

（何をテストするかだけ考えて、仕様と照らし合わせて確認するだけという現場もたくさん見ました）

テスト設計では、テスト分析で挙げたテストするモノ・コトをどうテストするかを考えていきます。

この時、「テスト技法」を使ってパターンを出していったりします。

例えばマンガに描いたように同値分割法などです。

テスト技法の話は……たぶんそのうちテスターちゃんでも描くかと思います。

きっと。

テスト設計では「ハイレベルテストケース（高位レベルテストケース）」に落としていきます。

124.テストプロセス その⑥

124.テストプロセス　その⑥

今回はテスト分析です。

やり方の例など細かな話はまた後で行う予定です。

この辺を説明するとなると先が長くなりそう……なんて思ってしまいますね(^-^;

その際は恐らくマインドマップやテスト観点出しのお話になるかと思います。

気になる人は以下の「マインドマップ本」を読んでみるとよさそうです。

［改訂新版］マインドマップから始めるソフトウェアテスト

作者は、テスト分析とテスト計画をよく行ったり来たりしていました。

テスト分析すると「あ、これもあった！」となり、テスト計画に記載しているテストのスコープやアプローチなどを修正したりするわけですね。

まだテスターちゃんではテストコントロールの話に行ってないので書いていないですが、テスト計画は作りっぱなしではなく更新していきましょう。

絵にかいたモチになってしまいます。

 

不安だから全体的に

作者が前職でよくやっていたのは、開発者や企画者に

「不安なところはありますか？」

とヒアリングしていました。（テスト計画時のリスク出しの時に行っていたけど）

そうすると開発の人からは

「～～～の部分がレガシーコードをいじるからコワイ」

とか、企画の人は

「～～～は他サービスとの依存関係が複雑だからミスるとヤバい」

など話を聞いていくと、資料からはわからないことや内部的な話など様々なことが聞けたりします。

作者はずっとwebやapp系でQAをやってきていますが、「これを見ればわかる」ような資料がそろっているところなんて見たことがないです。

関係者からしっかり話を聞く、気になったところを質問する、関係者の頭の中にだけあるものを形として出力してもらう、ということが必要だったりします。

2022クリスマススペシャル「勉強会で学んだことの活かし方」

2022クリスマススペシャル「勉強会で学んだことの活かし方」

この記事は「ソフトウェアテスト Advent Calendar 2022」の24日目の記事です。

その昔いた会社でこういった話が出たことがあります。

「テスト系の話はフワッとしたイイカンジの話をしてるけど、結局どうやればいいかわからない。現場でのやり方を教えてくれ」

気持ちはわかりますし、テスターちゃんが生まれた背景もこういったことからだったりします。

ただ、こういったお話をする人は「これさえやればうまくいく！そういう方法がある！」という思考がありそうに感じます。

やり方は一例を示すことはできます。

ですがそれは自分たちのやり方であって、それが他の人でも再現性があるかというと、マンガで描いたように条件が異なるのでうまくいかないことが多いです。

なので、聞いたことをそのまま鵜呑みにするのではなく自分で考えることが大切です。

「イイカンジの話だけど結局どうやるの？やり方教えて」

から

「イイカンジの話を聞いた。自分のとこで使うにはこういったことをすればいいんじゃないか」

への思考のグレードアップです。

今回はそんな話をマンガにしたためたつもりです。

具体化すると可能性を狭める

123.テストプロセスその⑤

123.テストプロセスその⑤

さて、ここからのマンガの流れとしては、まずは全体像ということでそれぞれの項目の紹介といったところです。

そこから各項目の説明を書こうかと思っています。

各項目の説明では「作者はこんな感じでやってた」みたいな自分のことをベースとした内容になるかなーと思います。

がんばりますが長くなりそう感ありますね(^-^;

テスト計画については、作者は前職でこういった記事を書いていたりします。

現場によってやり方は変わるわけですが、一例として挙げておきます。

www.lifull.blog

マンガについて

「忙しい」を言い訳に全然描いてませんでした＞＜

忙しいといっても全く絵を描く時間が取れなかったわけではなく、優先度とモチベーションが下がっていたのでしょうね。

そんな中、テスターちゃんを紹介する記事を書いてくださった方がいまして！

work-ch.com

この記事を読んで

「見てくれている人もいる。待ってくれている人もいる！」

と気づかされました！

本当にありがとうございます！

作者は単細胞ですので、ほめられるとモチベーションが超超超爆上がりしますｗ

今年はそろそろ終わりなわけで24日のadvent calendarの更新で終わりですが、来年は更新頻度を上げていっちゃいます！

バンバン描くぞ～！！お～！！

122. テストプロセス その④

122. テストプロセス　その④

テストプロセスは「アジャイル開発だから向かない」は関係がない

今回の話は前回ブログに書いた内容についてです。

最初マンガには「私たちアジャイルなの！」みたいな感じで話を進めていたのですが（これ燃えそう……）と思ったの色々書き換えて今の形になりました(笑)

testerchan.hatenadiary.com

テストプロセスがいかにも流れっぽく見えるためか、はたまた重量級プロセスに見えるためか、ウォーターフォール開発用のプロセスのような勘違いがあるようです。

テストプロセスの説明をその昔の現場でしたとき「アジャイル開発だから向かない」と言われたりしたものです。

121.テストプロセス その③

121.テストプロセス　その③

テストプロセスは、テストの準備からテストの終了までの一連の作業を指しています。

テストプロセスを知ることで、テスト全体の流れを知ることができます。

全体の流れを知ると、現状足りなかった部分なども見えてくるでしょう。

テストプロセスには以下の活動があります。

概要や個々の活動の話は次回以降のマンガで行う予定です。

1.  テスト計画
2. テストのモニタリングとコントロール（テストプロセス全体を通して行う）
3. テスト分析
4. テスト設計
5. テスト実装
6. テスト実行
7. テスト完了

テストプロセスが適用できるのはプロジェクト全体だけではない

テストプロセスの話をするとたまに勘違いされるのが

「ウォーターフォール開発の時の話でしょ」

といったことです。

テストプロセスはいかにもプロジェクト全体の流れに見えるからでしょうね。

テストプロセスは「ジェネリックタイプ」のプロセスです。

ジェネリックタイプのプロセスとは、テスト全体に対しても、テストの一部である個々のテストレベルにも適用できるような「汎用的なプロセス」のことです。

なので例えばプログラムでテストする「コンポーネントテスト」を考えるときも、計画もしますし、何をどうテストするか分析も設計もします。そして実装して実行し、実行結果を確認、整理しますよね。

「いやウチ、アジャイル開発だから」

という話も同じです。

アジャイル開発でも、例えば1週間スプリントとして、そのスプリントでどうテストを組むか（計画）、何をテストするのか（分析）、それらをどうテストするのか（設計）、必要なものを用意（実装）、そして実行、結果を確認して次のスプリントのために整理（完了）などしますよね。

（というか短いスプリントなら余計に何をどうテストするかは考える必要ありそうですよね）

120. テストプロセス その②

120. テストプロセス　その②

さて、前回の話に例示を付けただけのような回でしたので今回は特にこれといって説明はなしです。

その昔はノリエさんのようなPMさんとそこそこ出会っていたのですが、最近は出会っていません(笑)

テストというのは、やり方によってどこまでも非効率になります。

何をテストするのかを決めず実行段階になってから「何をテストすればいいんだっけ？」とあたふたして、どのようにそれをテストするか決めず人海戦術で手あたり次第に触ってみる。UnitTestでテストした方がいい機能を見つけたけど伝えるには遅すぎる。誰がどこをテストするか決めていなかった結果みんな同じ機能を見ているし、人気がない機能はちょっと触って終わり。ひどいときは見ていない。

結果、本番障害……。

冗談のように聞こえます。

作者はこういった現場も見たことがあります。

逆に、何に対してどのようにテストをしていくか、そういったことを決めていると本当に本当に進めやすいです。

次回からきっとテストプロセス自体の話に入っていくはずです、きっと！

今回は「テスト完了」の話がこれだと入れられないと思っていたのですが、話を進めながら入れていきます。

119. テストプロセス その①

119. テストプロセス　その①

テストは「テスト実行」が全てではない

テストについてあまり知らない人は、テストの実行する部分だけしか活動が見えておらず、それが全てだと思っていたりします。

そして、アプリをなんかいっぱい動かして「ちゃんと動くね！」とやればOKだと思っていることさえあります。

しかしこれでは、非効率な上に抜け漏れだらけのテストになってしまうのです。

限られた時間の中で確認すべきことをしっかりと確認するためには、テスト実行の前に、何を、どの段階で、どのようにテストすればいいのかを計画、分析、設計しておく必要があるわけです。

またテストが終わった後も次のテストのために整理をしておく必要もあったりします。

こういった一連のテスト活動を「テストプロセス」と呼びます。

今回からはこのテストプロセスの説明をしていきます。

テストプロセスについてはJSTQBにあわせて説明する予定です。

昔作者はこのシチュエーションはよくあったけれど

その昔はプロジェクトの最後に突然つっこまれて「ちょっとテストして！」ということがよくありました。

テスト＝リリース前に仕様通り動くか軽く触って確認する活動、みたいな雰囲気の時代です。

ここ数年は、業界全体のリテラシーが上がったのか、はたまた作者の運がいいのか、そいうことにはならなくなっていますｗ