用語を定義するということ 〜ユニットテストってなに？自動テストってなに？パフォーマンステストってなに？〜
こんばんみ、halspringです。
ソフトウェアテストの小ネタ Advent Calendar 2019 の22日目です。
伝達の不具合
この記事のメインです。
「考えていることを伝える」ということは、思っている以上に難しいといった話です。
まず、我々は自分の考えを人に伝えるときに、主に言語を用います。
「考え」を「言葉」にコンバートするわけです。
既にタイミングで、
- 選択する言葉の誤り
- 情報の欠落
- そもそもの「考え」の誤り
の不具合が発生している可能性があります。
そして、言葉を伝えるときに、
- 伝達情報の欠落
- 伝達順序の誤り
- 言い間違い
などの可能性がありますね。
さらにはそれを受け取る相手がいるわけで、
- 聞き逃し
- 聞き間違い
- 認識の錯誤
- 知らない用語の補完ミス
などの要因で伝達ミスが起こり得ます。
防ぎたい不具合
例として口頭でのやり取りを挙げましたが、
これらは文章でもあり得ますし、絵でもあり得ます。
手段によって細かな部分のポイントは異なると思いますが、
考えや意思を伝達する上で大事なことは、「認識を揃えること」だと思います。
知らないことを想像するのは難しく、
曖昧なものは曖昧なまま補完され、
認識のズレたものは誤解を生みます。
そして、もう一度先程の混入し得る不具合を見ると、
防ぐことが難しいものと、防ぎやすいものがあると思います。
言い間違いや聞き間違いについては、注意していても防ぎきれません。
当人達以外に環境に影響されることもあります。
また、起こってしまっても言い直す聞き直すことが対応できるので、大きな問題にはなりません。
防ぎやすいのに大きな問題になりやすいのが、
「選択する言葉の誤り」「認識の錯誤」「知らない用語の補完ミス」
です。
ここをなるべく防ぎたい。
不具合の例
たとえば、「ユニットテストって大事だよね」と言われて何を思うでしょう。
それは、
テストレベルの文脈におけるユニットテストなのか、
TDDの文脈におけるユニットテストなのか、
はたまたそれ以外のユニットテストなのか、絞り込むことができません。
「自動テスト」はどうでしょう。
e2eのシナリオのようなテストなのか( その場合、e2eとはなんなのか )、
APIの返り値を見ているのか、
手動でないテストすべてを指しているのか、わかりません。
また、「パフォーマンステスト」と言われても、
想定されるリクエストより多くのリクエストを送って落ちないことを見るのか、
1リクエストあたりのレスポンス速度を見たいのか、
DBへのIOやバッチ処理に異常がないことを確認したいのか、
負荷がかかったときにスケーリングされることを確認したいのか、わかりませんよね。
取り組もう
特にソフトウェアテストに関しては、個人/組織/現場で特にこれらの認識がバラついているように思えます。
業界・組織レベルでこれらをうまく揃えることは難しいかもしれません。
ですが、プロジェクト単位であればどうでしょう、数人のチーム内ではどうでしょう。
規模の小さいところから、ガラパゴスな使い方になってしまっても良いので、
まずは用語を定義して認識を揃えることで、伝達時の不具合による不幸が減るかもしれません。
もちろん、ガラパゴスを推奨しているわけではありませんが、
所謂 公式（or のようなもの）にこだわり過ぎず、わかりやすい言葉を作ってみても良いと思います。
説明できない引用されただけの言葉より、説明できる非公式な言葉の方が健全です。
おわりに
はい、偉そうなことを言いました。
ですが 自分が思っていることで、大事にしていることなので、
自分の考えていることが少しでも何かのお役に立てばと思います。
ちなみに言葉の引用を否定しているわけではありません。
公式なものは共通して認識されている可能性が高いので、知っていることはとても大事です。
しかし、みんなが知っている可能性が高い故に疑いにくいです。
相手なくして「伝える」ことはできないので、
相手のことも考え、どの言葉なら錯誤が起きにくいか、曖昧な言葉はないかと考えてみると、
より「伝える」ことが楽しくなるかもしれません。
