現象だけでは、開発側が動けない
QAエンジニアやテストエンジニアの報告で問われるのは、敬語の巧拙よりも、誰が同じ操作をしても同じ結果を確認できる順序で情報を置けるかです。「エラーになりました」「動きません」だけでは原因を切り分けられず、確認の往復が増えます。
外国人材がつまずきやすいのも、文法そのものより、日本語の不具合報告で省略されがちな前提をどこまで書くかという点です。短く済ませようとして端末、権限、操作順、期待結果を落とすと、説明にかかる時間はかえって長くなります。
起きたことと、正しいはずの状態を混ぜない
品質・テストの報告では、画面で起きた事実と、仕様から期待する結果を分けて書きます。「ログインできない」は結論のようでいて、現象なのか仕様確認なのかがわかりません。
たとえばチケットには、「パスワード再設定後、ログイン画面で新しいパスワードを入力すると、認証エラーが表示されます。再設定後はログインできる想定です。」と書けます。前半は確認した現象、後半は期待結果です。「想定です」は断定を避けるためではなく、何を確認したい報告なのかを示します。
会話でも同じです。
テスター：「この操作ではエラーが出ました。仕様上、エラーになるケースでしょうか。」
開発者：「どの権限のアカウントですか。」
テスター：「一般権限です。管理者権限では再現していません。」
早い段階で「バグです」と決めるより、仕様との差を切り出したほうが、QAとしての判断が伝わります。
再現手順は初報に入れる
再現手順を求められてから追記することもありますが、テスト自動化エンジニアを含む開発チームでは、初報に操作の骨格があれば調査を始められます。番号をきれいに並べることより、分岐になる条件を省かないほうが実用的です。
「商品を登録したら保存できません」ではなく、「未入力のまま保存すると警告が出ますが、警告後に商品名だけ入力して保存すると、画面が読み込み中のままになります」とします。この場合、再現の鍵は「警告後に」です。
チャットなら、こう伝えられます。
「手元では、未入力で一度保存したあとに再現しました。端末はスマートフォンです。」
「同じ手順で確認いただけますか。」
「毎回ではなく、十回中二回ほど確認できました。」
回数が少ない現象を「たまに起きます」で終えると、優先度を判断しにくくなります。正確な回数が取れていなければ、「断続的に再現」「現時点で二回確認」と、観測できた範囲を書きます。
「確認しました」に対象と結果を足す
品質・テストの連絡では「確認しました」がよく使われます。ただ、確認したのが画面表示なのか、ログなのか、修正後の回帰テストなのかで意味は変わります。敬語を重ねるより、対象と結果を一つ足します。
修正連絡への返答なら、「修正版で再現手順を実施し、エラーが表示されないことを確認しました」と書けます。関連箇所まで見た場合は、「主要な登録・編集・削除の操作も確認済みです」と範囲を続けます。未確認の範囲まで「問題ありません」と言い切らないことも、品質保証の仕事では必要です。
曖昧な副詞を、判断できる情報に置き換える
「ちゃんと」「普通に」「かなり遅い」は日常会話には便利でも、テスト記録には向きません。「画面遷移に時間がかかる」なら、比較対象や発生条件を添えます。
テスター：「一覧画面から詳細画面への遷移が、通常時より長く感じます。」
開発者：「どの程度ですか。」
テスター：「同じ端末で、検索結果が多い条件に限って待機表示が続きます。計測値はこれから取得します。」
計測前の体感まで隠す必要はありません。ただし、体感を事実として固定しないことです。不具合チケットを起票する前に、再現条件、期待結果、確認範囲の三点を見ます。たとえば「一般権限で、未入力の保存後に二回確認。期待結果は保存完了」と一行足すだけで、次の担当者は確認を始められます。