テストエンジニアの姿勢として、アンチパターンだと思うことを列挙してみた
先日の勉強会で、
「テストに『これが正解』というものはありません。でもアンチパターンはあります。」
という趣旨のコメントがありました。
もうちょっとちゃんと言うと、
「標準が機能するには3つの条件を満たす必要がある」というお話で、
その3つとは、
・どうすればいいか、やり方がわかっていること
・やり方が当分変わらないこと、または横展開できること
・使っている人が、それが良いことだと思っていること
というものでした。
ソフトウェア開発というものはそもそも1番目の条件に該当しないから、「正しいやり方」という意味での標準を作るといっても無理があるよね、と。
ただ、「確実に失敗するやり方」つまりアンチパターンはありますよというコメントがあったのでした。
ということで、ソフトウェアテストを通じてプロダクトの品質に貢献するということを考えた場合に、自分なりに、「これがアンチパターンだと思う」ことを列挙してみます。ソフトウェアテストの技法のアンチパターンというよりは、テストに携わる者としての姿勢を意識しています。
・アンチパターン1「ソフトウェアの内部構造に関心をもたない」
コードを書いた人と別の人がテストを設計＆実行する人によくあるパターンです。
ユーザ企業の受入テスト担当の方とかをイメージしてもらえると分かりやすいです。
外部仕様ベースのブラックボックステストだけでも70点くらいは目指せるかもしれませんが、100点は目指せません。
内部構造の部分は開発会社と責任範囲をきっちり分けて、機能/非機能含めて隙間なく検証してますとかであれば大丈夫だと思います。
・アンチパターン2「座学を軽視する」
「座学をしたところで、現場にそのまま持ち込むことなど夢のまた夢である」を学習してしまった人によくあるパターンです。そういう人が車輪の再発明に貴重なリソースを使います。
要件が発生した時点で「どうテストするか」を考えておかなかったばかりに、「テスト実施不可能」とされた数多のテストケースのこと、時々でいいから思い出してください。「それは開発者が考えることだから関係ないでしょう」と言っていいものでしょうか。
・アンチパターン4「表面的なメトリクスを埋めればよいと思っている」
勉強会でも出た話題ですね。出荷基準を満たしていれば、高い品質が担保されるのでしょうか。
・アンチパターン5「ユーザーがそのソフトウェアをどう使うのかに関心がない」
ソフトウェアを実際に使うのはユーザーです。そのユーザーにソフトウェアを提供してよいかどうかの確認をするのは誰なのでしょうか。営業さんでしょうか。広報さんでしょうか。
・アンチパターン6「一度決めたルールを守ることにこだわる」
テクノロジーは日々進歩しています。プロダクトが何年もの間変わらないのであれば、ルールを厳密に決めて守ることが効果的になるかもしれませんが、ある程度の期間を設けて、定期的にルールをアップデートしていくのが、少なくとも2018年現在は有効だと思います。
・アンチパターン7「検証よりも計画に多くの時間をかける」
厳密な計画を立てたところで、検証した結果、ほぼ確実に修正は必要になります。さっさと検証しましょう。テストケースの一言一句に拘っている場合ではないです。
・アンチパターン8「用語を軽視する」
意味が伝われば、表面的な言葉はぶれても良いと思います。でも、用語を雑に扱って「『単体テスト』とはこういうテストです。それが常識でしょう。あなたはものを知りませんね。」とか言わないでください。
・アンチパターン9「『私は特別な存在である』と思い込んでいる」
検証できる人って、そんなに偉いですかね。コードが書ける人、サーバやネットワークを触れる人、営業できる人、社内で調整役ができる人、それぞれが強みを持ち寄ってプロジェクトチームが出来上がっているのではないでしょうか。
どうして、特に開発者に対して、上から目線でものを言えるのでしょうか。
・アンチパターン10「ソフトウェアテスト以外のことに関心をもたない」
ソフトウェアの開発には、様々な人が関わっています。良いソフトウェア(ほぼイコール、よく売れるソフトウェア)を作るためには、ビジネスの視点や、デザインの視点、アーキテクチャの視点など、テスト以外の視点が欠かせません。テストを設計したり実行する人が、そこに全く無関心でよいのでしょうか。
・さいごに
もちろん全部自分へのブーメランです！
