テストエンジニアのお仕事 導入編

  • このエントリーをはてなブックマークに追加
  • LINEで送る

テストエンジニアのお仕事は、テストをするだけではない

久々にしたためます。

ほぼほぼ思い出したことを置いていくだけの書き方なので、読みにくいかなあと思いながらも、誰かに「ふうん」と思っていただけるだけでこのお話は十分なので、それでいいかなとぼんやりしつつ。

テストのお仕事は、テストするものを使って、なんかテストする、だけではありませんでした。

実際、私自身もその世界に入る前は漠然と、そんなイメージでしかなかったのですが、やることはそれなりに多いです。

業界、媒体、主旨、期間、方針、状況などによって色々と枝分かれも多いテーマではありますが、私がやってきたことを、つらつらとまとめてみます。

①アサインとKOM(キックオフミーティング)

私がある程度の工程管理までお任せいただいた時代のお話です。

まず、チームリーダーから案件のアサイン勧告と、事前情報をいただきます。例えば、「対象はアプリ」「〇〇のキャンペーンページ」「リリースはいつ」。

開発側と、案件の担当である私と、保護者のような形でテストチームのリーダーを交え、打ち合わせに臨みます。その時、開発からテストの概要と、そのテストの仕様、導線はどうなっていて、こうなっているのを見てほしいとか、ざっくりと共有。

事前情報から、テスト側としても観点を大まかに想定し、開発側にも確認します。この時点では、詳細まできっちり把握しなくても大丈夫。その打ち合わせで、リリース日から逆算し、テスト計画もボリュームを鑑み、ざっくりと決め、よろしくお願いします!となり、プロジェクトが始まります。

準備・テスト実施期間が、この時は仮で設定されています。

②タスクの登録

当時は、タスク・工程管理にJIRAを使っていました。JIRA好きです。

チームリーダーにも相談しつつ、ゴールをリリース日として、それまでに「やらなければならないこと」を整理し、JIRAに時系列に沿ってタスクを登録していきます。

「この日までに観点を整理して、〇〇さんに確認してもらう」とか、「この日までに工数見積もりを作って、マネージャーにダメ出ししてもらう」とか、「この日までにテスト端末を選定する」とか。

そのタスクが達成できれば、JIRAの機能を使ってクローズ。すると、工程が次のタスクに移る感じです。(これが好き)リリースがゴールなので、それまでにやらなければいけないことを見える化して、消化していく形です。やり忘れの防止にもなります。

③観点の整理

まずやらなければいけないのは、「テストで何を見ればいいか?」それが整理できると、「それにはどのくらい時間がかかるか?」が見えてきます。開発には開発の「見て欲しい」観点があります。それと同時に、「テスト側の視点で見ておいた方が命拾いできるのでは」観点も必要となります。

その為、開発からいただいた仕様書、導線(ワイヤーフレームとか Cacooとか使っていました)を観点の基準としつつ、それ以外の部分も多角的に検討します。

多角的に…と言っても、そこまで複雑なことではなく、テスト側=ユーザー側でもある為、ユーザーが辿りそうな導線は何か?と言うことを想定します。また、

開発:「この次はこのリンクを踏むから、そしたらこのページに飛んで」

ユーザー:「この次はえーっといやこっちのページ見てからにしよう(違うリンクを踏む)」→「あれ、前のページに戻ってこられない?(離脱)」

とか、これはちょっと極端な例ですが、導線はイレギュラーについても検討する必要があります。

正規ルートが基本ではありますが、それ以外のルートももちろん、機械ではなく人間が相手なので…

案件によってももちろん大きく異なりますが、一番の悲しみは「このプロジェクトの最大の目的(例:事前登録、キャンペーンへの応募)が達成されない」ことなので、それをできるだけ防ぐ為に、その辺りを重視しつつ、またテスト期間とリリース日も考慮して、検討します。

観点の整理ができれば、チームリーダーや開発担当者に確認していただき、OKがでれば、テスト項目の作成に入ります。

④テスト項目の作成

私もあまり多く作ってきている訳ではないので、それなりに狭い範囲でのお話にはなりますが、「見るべきところ」と「そこまで頑張って見なくてもいいところ」と「1回だけ見ておけばいいところ」と「見なくてもいいところ」があります。

例えば、「違う案件でがっつり見た仕様と同じものを使ってるから、今回はさらっと流して動作確認するだけでOK」とか、「テキストは基本的に仕様に影響しないから、(今回は)1パターンだけ見ればOK」とか。

案件や仕様によってもちろん異なりますが、そういう見極めも重要です。テスト期間は限られているので、効率的に、できるだけ無駄のないように見る必要があるからです。

実績のフォーマットをできるだけ流用し、今回の案件用にカスタマイズしていきます。そして、レビューをお願いします。

⑤その他準備と工数見積もり からのレビュー

事前に仮で設定したテスト計画、テスト実施期間ですね。それが、本当に「妥当」であるかをチェックするタイミングがあります。

仕様によって、テストに使う端末やその種類は違ってきます。スマートフォンだったり、PCだったり…そして、OSや端末の会社など。テストをする端末の種類が増えれば、それだけ工数は増えます。それをすべて踏まえて、テスト工数を試算します。

事前に設定した、例えば「2日間でこのテスト項目を2人で消化する」が、妥当であるかどうか。試算した結果、「ちょっと足りないかも」と思ったら、テスターを増やす調整などをします。

そして、「よし、きっとこれなら大丈夫!予定通り行けるはず!!」を、マネージャーに報告して確認していただきます。(私のいたところは)

そのレビューで、「ちょっとここ観点足りないんじゃない?」とか、「ここ、念のためにPCでも見ておいて」とか、そういう指摘があれば、反映します。

⑥テスト

チキンレースです。見積もり通りにテストを終わらせる為に、ひたすらテストをします。(大体半日~1日くらいは余裕を見るのですが)

仕様書と観点、テスト項目に沿ってテストをしていれば、不具合の他、「ん?これでいいのかな?」と言った仕様に直面したりします。むしろ無いと怖いです。

いつでも、「仕様通りに結果がでていればそれでいい」ではなく、ユーザー目線で、「本当にこれがベターなのか」と言う疑問をためらいなく持つことを大切にします。

開発には、開発の理想と想定があります。それを尊重することは大前提ですが、同時にユーザーにとってもそれが本当に一番良いものなのか、と言うことも、必要に応じて開発にお伝えし、納得いただくことも必要です。

不具合報告には、今まではJIRAの他、Redmineなどを使っていました。不具合報告をするときには、「チケットを切る」と言う言い方をしていました。切符…

開発とのコミュニケーションも重要で、やり取りは基本リモートで行っていました。ツールは色々ありましたが、Slackがやっぱり使いやすかった気がします。

不具合は修正していただき、もう一度テストをして、OKなら、不具合のチケットもクローズ。全てクローズしなければ、テストは終わりません。

⑦テスト終了、報告

無事にすべての項目を消化し、不具合も修正していただいた。あとはリリースのみ!…と言う段階で、私がいたところでは、最後にマネージャーへの報告と言うものがありました。

(どこも同じなのかはよくわからないのですが…)

マネージャーの「チェック」ではなく、「報告」。それは、「これこれこういう感じでテストは終了し、不具合はこういうものがありました。全て修正していただき、この案件に問題はないと私は判断します。よろしくお願いします!!」と言うものです。

あくまで、テストを担当した自分が太鼓判を押すという考え方です。そして、それをマネージャーに報告して、「うん、わかった。よし、行ってみよう!(リリース)」と言う締め方です。

これで、1つの案件は終了です。正確には、本番リリースした後の軽い動作確認までがお仕事ですが。それも、案件や仕様によって、色々です。

 

思ったより長かった

 

今回はざっくり…と言う考えでつらつら書いておりましたら、思ったより長々となってしまった。申し訳ない。

それぞれの工程はもっと複雑だったり、大事なことや気を付けていたことなどたくさんあるので、そのうち掘り下げて書いてみたいなと思います。

特に、最後のマネージャーでの報告は(未熟な私が)号泣(した)エピソードもあるので、折を見てご紹介したいなと思います。

長らくお付き合いいただき、ありがとうございました。

  • このエントリーをはてなブックマークに追加
  • LINEで送る

SNSでもご購読できます。