# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、エンジニアリングマネージャー兼QAリーダーのさみぃが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やレジスターのあなたと、 テストや品質の世界を広げていきます。 # 1人前のテストエンジニアとは？ こんにちは、さみぃです。 今日もワクワクしますか? 今回は、一人前のテストエンジニアとは何かについて言語化をしていきます。 先日のJUSTニイガタで何人かお話をさせていただきまして、 その中で次、自分のキャリアどうしていったらいいんだろう? みたいな相談もいただいたりしたんですね。 その中で、一人前のテストエンジニアって何なんだろう? というところを自分なりの定義というかを言語化してみたいなと思った次第です。 ということで、今回もこの一人前のテストエンジニアとはどんな人なのかというとこの要素というかポイント3つあるので、 ポイント3つあるので一つずつお話ししていこうと思ってます。 まず最初に3つですね。 一人前のテストエンジニアはテスト設計ができる、そしてバグ報告ができる、そして得意な視点がある。 この3つのポイントを話ししていきます。順番にお話ししていきます。 まず一つ目はテスト設計ができるですね。 テスト設計という言葉が良いのか、テストプロセスを一人で回せるというふうに表現するのかすごく迷ったんですけど、 ここで言っているテスト設計ができると言っているニュアンスとしては、上司のサポートなしで決められたやり方でインプットのドキュメントなどを集めてきて、 そこからテスト設計技法を選択しながらアウトプットとしてテストケースが作れるみたいなことをニュアンスをテスト設計できるという言葉で表現をしています。 JSTNQBのテストプロセスの横から照らし合わせると、もしかしたらテスト設計だけじゃないじゃんというツッコミがあるかと思うんですけど、そこは置いておいてですね。 ポイントは上司のサポートなしなので、基本的には一人で動けるというところが一つポイントとしてありますし、決められたやり方でという表現は微妙ではあるんですけれど、 決められたやり方というよりかは、どういう開発スタイルなのかという開発スタイルに合わせてという表現の方が正しいかもしれません。 ガッツリボタンホールで開発しているのか、アジャイルなのかとか、どういうプロセスで開発が進んでいくのかによってもテストのやり方というのは変わってくるので、 その沿ったやり方で動けるということもとても重要だというふうに考えています。 そしてですね、テストケースを作るためには必要な情報をかき集めてこないといけないので、そこをかき集めるということも必要になってきますね。 PRDとか仕様書とかフィグマなどのデザインなどがいろいろ集める必要があるので、そこがもし足りないのであればヒアリングをするなりして情報をかき集めるということも結構大事になってきます。 加えて、そのテスト対象をどのようにテストするのか、もちろん何をテストするのかというテスト対象を決めるというのは大前提あるんですけど、 その後にどのようにテストすると効果的なのかというのを判断するために一つテスト設計技法というものがあるので、 同時分割、境界値分析、状態線図、デシジョンテーブルなどなどですかね、そこら辺のテスト設計技法というものを選択しながら最終的にテストケースを作れるというのがまず一つ目のポイント、 一人前のテストエンジニアとして必要になってくるポイントかなというふうに考えています。 2つ目がバグ報告ができるです。 これどういうことかというと、ポイント3つあるかなと思っていて、一つが再現するのに必要な情報を提供できるということですね。 何か触ってたら壊れましたというのだけではバグ報告にはなるんですけど、 ここで言っているその一人前のテストエンジニアとして必要なバグ報告には基準には満たさないですよね。 いろいろ必要な情報があるわけで、多分おもうのそれぞれテンプレートとか持っていたり、個人だったり、組織でテンプレートあったりもすると思うんですけど、 例えば環境、どの環境で起きたのか、社内の検証環境のどの検証環境なのか、あるいはプロダクションの本番環境なのかというのがまず一つありますし、 例えばモバイルとかであればiOSで起きたのかAndroidで起きたのかとか、ウェブアプリケーションの場合はブラウザーがChromeなのかそれ以外なのかというのもあったりしますよね。 当然再現手順というものもあるので、どの手順でどうやったらこうなったというところをちゃんと事実を提供できる、再現するのに必要な情報を提供できるというのがとても重要な要素になっています。 他にもですね、簡潔に伝えられるかというのも結構大事だと思うんですよね。 人によってはバグ報告をめちゃくちゃ丁寧に書いてくださってありがたいんだけど、結局最後まで読まないと何が問題なのか分からないとちょっとよくなくてですね、 タイトルを読んで何が起きているのかが事象がきちんと分かるというのももちろん大事だし、説明文とか読んでこうなのねというのが分かるのも非常に大事です。 こうなのねというので特に大事かなと思っているのが、期待結果がどうで実際の結果がどうだったかというところを両方きちんと書くというのは大事だなと思います。 何か一個例を考えてみましょうか。NGとか良くないので、例えば新規登録できないというタイトルのバグ報告があったとしましょう。 新規登録できないというのは一体どういう状況なのでしょうか。 新規登録ボタンを押しても画面が遷移しないのでしょうか。それともメールアドレスとパスワードを入れても登録ボタンが非活性で押せないのでしょうか。 あるいは登録ボタンを押したんだけれども何もふんと結んでも言わなくて登録されたかどうかが分からないという話でしょうか。 登録ボタンした後にメールアドレスにメールが送信されるはずなんだけどそれが送信されていないのでしょうか。 こんな感じでですね、新規登録できないだけだと何も分からないんですよね。 そうではなくて例えば新規登録ボタンを押したんだけれども登録完了のメールが届かないとか、まだそのくらいの方が伝わりやすいんじゃないかなと思いますね。 あとあるあるなのかな、私が気をつけていることとしては期待結果と実際の結果がどうだったのかというところを明記するようにしています。 パッと見、文章を読んだとき再現手順で1これこれする、2これこれをする、3する、4こうだったというのだけ書いていくとですね、 そのこうだったの何が悪いのかがパッと見で分からないことがあるんですよね。 なので1こうする、2こうする、3こうする、そしたら4は期待結果としてはこの画面でこれこれが表示されている状態。 実際の結果はこうこうこうなっていますと。 こんな感じでですね期待結果と実際の結果は分けて書くというか一緒に書くと分かりやすい、何が問題なのかというのが伝わりやすくなります。 そしてちょっと余談で道それるんですけど、丸々できる丸々できないという言葉は私はバグ報告だったりテストケースの期待結果としては絶対使わないようにしてます。 レビューとかでもよく指摘をする事項です。 何でかというと丸々できる丸々できないというのはかなり主観が入りやすいからですね、人によって解釈が変わる余地があるので自分の中でNGワードとしています。 例えば先ほども新規登録できるあるいはログインできるというのを考えた時に何をもってログインができると判断するのでしょうか。 ホーム画面が表示されることが確認できれば良いのでしょうか。何か別のことを確認しなきゃいけないのかなどですね。 新規登録でも良いのですが何をもって新規登録できたと判断するのでしょうか。 データベースは見に行くのでしょうか。それとも新規登録のメール、登録完了のメールが届いたらOKとするのでしょうか。 その後ログインできることまで確認して新規登録できたと言えるのでしょうか。 こんな感じで人によってかなり感触ができてしまうので〇〇できる、〇〇できないという表現はテストの作成であったり不具合報告によっては使わないようにしましょう。 ということで本数値に戻ってきます。今話していたのはバグ報告ができる要素の3つの話をしていました。 ここ2つまで話したんですよね。再現するのに必要な情報を提供できるというのと簡潔に説明するということ。 そして3つ目が事実と推測を分けて書くということですね。 昔私もよくやってしまってたんですけど、事実としてどうだったのか。 1をやって、2をやって、3をやったら4という結果になりました。これは事実ですよね。 例えば難しいのは再現の条件ですよね。こういう時に発生する。 それは事実なのか、いろいろやってみた中での推測なのかというのは明記した方がいいですね。 じゃないと、バグ報告の情報を基に開発者が原因調査をしていくわけなんですけれど、 例えばその再現の発生条件、再現条件というものが事実として何回やってもそうなるということであれば、 発生するのであれば事実の可能性も高いですし、でも報告者としては推測のつもりで書いたのに事実として解釈されて、 なかなか再現しないんですけど、みたいなことになってしまうとコミュニケーションもより多く発生してしまうし、 調査に時間がかかってしまうというところもあるので、事実と推測というのは分けて書くようにしましょうという話です。 そして1,2枚のテストエンジニアの3つ目のポイントですね。得意な視点があるです。 どういうことかというと、例えばユーザー視点、システム視点、エンジニア視点、どれか一つでも構わないので、 自分の得意な眼鏡があると1,2枚のテストエンジニアなんじゃないかなというふうに思っています。 意味合いとしてはユーザー視点でテスト設計とかできるよねだったりとか、システム視点で、 システムってこういうところでバグが起こりやすいよねという視点でテスト作れるよねとか、 プログラミング経験があるからここ不具合はOKですよねと、勘どころがあるという感じですかね。以上です。 # 今日のほっこり話🍘 今日のほっこり話です。 ハッピーターンのお話をします。 おせんべいですね。 先日新潟に行って、やっぱり新潟といえばお米なのでおせんべいもたくさんあって、 ハッピーターンもたくさんいろんな味が売ってたんですよね。 お土産にもちょうどいいしと思って、会社へのお土産でハッピーターンのヨーグルト味っていうのを買いました。 どんな味か想像つきます? 全然つかなかったんですけど、ちょうど今日食べまして一つ。 なんかすごい不思議な味だったんですよね。 ヨーグルトはヨーグルト。 ちょっと酸味?ヨーグルトなんで酸味があって、 そのハッピーターンの甘い粉と酸味ってすごいなんか不思議な味でした。 他にも買ったのがあって、自分の家用なんですけど、 サド型味っていうのと、あと枝豆味っていうのを買ってみました。 なんかめちゃくちゃハッピーターンが食べたかった気分だったので、 なんと3箱も買ってしまったという感じですね。 食べるの楽しみです。 以上、今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回は発信する自信がないをどう乗り越えるという話をします。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は 是非、画面右下ハートマークでいいねを押していただけると、とっても励みになります。 9月からプレミアム放送を始めました。 チャンネルページのトップに放送固定しています。 そちらの放送でプレミアム放送とは何なのか、どういうことをやっていくのかについてお話をしていますので、 是非そちらもお聞きください。 それではまた明日お会いしましょう。ごきげんよう。