24日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。
🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄
この図なんだけど、当日お伝えできなかった話。
講演では、各役割のお気持ちになるのがテストをするときは大事！って話をしたんだけど、 常に４つの役割になるのは難しくて、実際は帽子を被り直す（役をチェンジする）こともやっています。 （必ずではないし混ざってることもたくさんあるけど）
で、今日は、エンジニアの帽子をかぶる瞬間のお話です。
私の場合は、以下が多いかなーと思います。 * テスト中にこれはパターンを増やしたほうがいいな！ってなる時 * バグの報告をする瞬間
ひとつずつ書いてみます。
テスト中にこれはパターンを増やしたほうがいいな！ってなる時
テスト設計中とかにもあるけど、テスト実行中にも想定よりも多くテストをしたくなるときがあります。
（自分のテスト設計がゆるいだけかもしれない）
いわゆる、境界値とか組み合わせを増やしたいとかになるのかな。
そのときは、プログラマーだったころの自分や、そういうところに多くのバグが潜んでいるという経験からきているのかもしれないです。
なんか、、、あやしい。
これはもうちょっとやっておかないと不安だ。
みたいな気持ちでやっています。
そして不具合を見つけます。（たぶん不具合をみつけるときの多くはこのときに見つけてるか、画面を表示した瞬間に見つける気がする。気のせいかもしれない）
バグや改善案の報告をするとき
これは、修正するときに不具合の箇所をわかりやすくする、調査をしやすくするという点と 改善したほうがいい、不具合であるとエンジニアに納得しやすくする材料をできるだけ提供するときです。
例えば提供するものとしては以下は書くことが多いです。（うっかりつけ忘れることも多くて指摘されることもありますごめんなさい） * タイトル * 詳細 * Steps（再現手順） * 実際の値 * 期待値 * エビデンス スクリーンショットや動画、ログなど * テストをした環境 ブラウザやスマホならOSバージョン、機種 ** アプリのテストなら実施したアプリビルドバージョン
これは、修正箇所やバグの原因の特定に必要な情報として提供します。
また、詳細とか期待値では、修正または改善してほしい根拠を考えたり提案するために考えるときに 修正しやすい落とし所を考えています。 その際にエンジニアの帽子を被り直すことが多いです。
不具合だろうと納得してもらうときは Aの動きならOKだったが Bの動きならNGだった という情報を提供することにより、修正のあたりをつけやすくしたりします。
テストになれていない場合、BがNGだったしか報告しないことがあります。 そうすると、エンジニアはデバッグでAを自分で見つけることや実施する必要があります。 なので、テストをする人は、先に他のパターンでOKだったりしないかも確認してあわせて報告してあげたほうが修正しやすくなると思っています。
また、仕様としては載っていない改善があった場合でも、エンジニアの帽子をかぶることが多いです。 例えば、二つの入力フィールドを条件にして、バリデーションチェックの結果を返すようなものがあったとします。 基本的には一つ一つの入力フィールドの下に各々バリデーション結果を表示している場合だと、このような複数要因でバリデーションメッセージを表示した場合に、どこに表示するかがわからないときがあります。
このとき、ユーザー視点でいうと、この画面が複数修正する箇所がある場合、一気に修正したいので、全部バリデーションメッセージを表示して、かつ、その内容を確認しながら修正したいと思います。
一方でエンジニアの帽子をかぶると、複合要因のメッセージ表示はダイアログなどで一気に表示したいかもしれません。 どのような実装かでつくりやすさが異なります。 ただ、ダイアログの場合、入力画面の上に表示されて入力するためにはダイアログを閉じる必要がある場合があります。
その場合、一気に表示するけどユーザーも使える提案がしたいです。 例えば、ダイアログではなく、入力画面にエラー表示をするエリアを設けることで、双方が合意しやすい提案をするなどです。 （実際は、UIの変更をするならデザイナーにも相談します。）
今回書いていない場所でもエンジニアの帽子をかぶることもあるはずなんですが、また次の機会に書くかもしれません。
