フレームワークの選定をする基準の１つに「テストのしやすさ」を加味する人がいるそうだ。
しかし、テストのしやすさを取るあまり、例えば開発効率が落ちるのならば本末転倒。
ゆめゆめよく考えないといけないものだと思っている。
まあ、その開発効率は慣れの問題かもしれないが…もっと、それより重要な問題がある。それは…
（継続的にプロジェクトを回す）PMにテスト工程の手順というか、テスト文化を推奨して理解して実施するマインドがないと、そもそもフレームワーク時の「テストのしやすさ」を選んだとしても、その基準はなんの意味もないってことになる。
テストをする能力がプロジェクト・メンバーになければ、それまでだ。
まあ、それはPMが後でブロードキャストできるならば、問題はない。
QAエンジニアがBARで愚痴をたれるかもしれない未来まで誰も想像しないのだ。
プロジェクト立ち上げ時の言語や環境に携わっているが、最後まで私がプロジェクトの面倒を見ることなんて決まっていない。新しいことに取り組んでいく気概が私にはあるので「文化」を作り出すことには意義を感ずる。しかし、それを所属する組織に「文化が大切」だと認めてもらうことを求めるのは筋違いだとしても、先にも述べた「テスト文化を推奨する」マネージャーに就任はしない確率のほうが高い。したがって、一貫したプロジェクトの方針を掲げることのプライオリティは低い。長期的なプロジェクトなんて存在しないし（長期的なプロジェクトは、短期的なプロジェクトやサブプロジェクトに分割される）、プロジェクトの目的は時間が経過すれば変化する。人の配置も変わる。
しかし、プロジェクトに携わる人と行動に成功の可否は関わってくる。
会社より、プロジェクトは短い命かもしれないが、そこに携わる人への働きかけを一番考慮しないといけない。
結局、一貫したソフトウェア文化をつくるなんて誇大妄想を、SESのSEが持つなんて「ありえない」と一緒にふされること必至。ましてやPMでもない…こんな話は、誇大妄想で実験思考なので、誰にも言うことができない。どうしてそんなどうでもいいことを考えているの？ってところから説明しないといけなくなる。
そして、結局、シンプルで誰でも取り回しが利くように計らっておくことが、企業とプロジェクト、プロジェクトに新規参加する人への配慮だということに行きつく。
いけてるテストツールは使えないかもしれないけれど、バグがそれで減るならテストは楽になるさ。
後のことは考えない、ご都合楽観主義者より。
コメント