テストの品質はメンバの成長により確保されるか
それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。 言い換えれば、プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。
このエントリを読んで感覚がわからなかったことがこのフレーズでした。どうして、プロダクトの品質がメンバの成長と関係性を持っていると思ったのか。
この文章で表現されていない暗黙の前提があるのではないか、と思うのです。それは、
品質はメンバの成長で維持される
ということです。
そうかなぁ。それは甘え過ぎていないか、と顧客の立場でも、プロジェクトマネージャの立場でも思うのです。
顧客の立場であれば、プロダクトに対する品質要求を満たしたメンバでチーミングするものでしょう、と思っても当然です。品質要求を満たされる前提で対価を支払うのですから。
プロジェクトマネージャの立場でも同じです。プロジェクトの品質要求を満たすメンバでチーミングをしなければ、それはリスクですから。
画面キャプチャをやめたい
あるプロジェクトのテストで決められていたエビデンス、つまりテスト計画どおりに試験を実施した確証として画面のキャプチャが決められていたのです。
最初は苦労して画面のキャプチャを取っていましたが、同様の構成の他の環境を試験する際に同じように画面キャプチャを取らないといけないときに、前回実施した画面キャプチャを取ることがとても面倒になったようで、それをやめられないかと相談なのか苦情なのかはたまたサボりなのか判別のつきにくい相談を受けたのです。
なんと答えたか
なんと答えたかというと、
同質の確証を得られるのであれば、提示して欲しい。理解し、同意できれば顧客に変更を説明する
と伝えたのです。例えば、GUIの表示に関するキャプチャをログでテストの正当性を検証できるのであれば画面キャプチャに拘らないのです。
チームのメンバは、プロジェクトマネージャから見たら専門家です。代替案で品質要求を満たしていることを説明できるエビデンスならなんでもいいのです。
結果は、そのテストでは従来どおりの対応となりました。
どのようなプロジェクトのアウトプットであっても通常は文書名のみで合意されているものです。つまり、文書名は決まっているが内容までは提示次第なのです。この事例から分かる通り、品質はメンバに依存する関係性を持つことはありません。メンバの技術レベルにより品質要求に到達しているかいないかしかありません。
そこに違和感を感じたのかもしれません。