読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

テストに必要な知識を獲得するには?

Test Process TestDesign

 今回は、テストに必要な知識をどう獲得するか、どのような道筋で進めているかモヤモヤしているので、過去のプロジェクトを思い出しながら書き出してみます。

どのような状況か?

 普段は保有している知識+αで開発製品のテスト業務を行っているが、1~2年に1度の割合でドメインが異なる製品のテストを担当することがあります。開発者は、数多くの詳細設計を限られた人数で行う状況なので、テスト仕様まで手が回らないことが多々あります。また、テスト技術に特化したメンバーは私以外にいないため、ドメインが異なっていてもテスト仕様としてテスト実行できるようにする必要があります。

ドメインが異なる製品で初めにやったこと

 ドメインを理解するために下記を問いかけながら、具象化しました。

  • 製品の用途は何か?
  • 製品を取り巻くステークホルダは誰か?
  • 各ステークホルダのリスクは何か?

 初めに製品はお客様が抱える問題を解決する道具ですので、「何の問題があり、解決するための手段として製品はどう振る舞うのか?」をポンチ絵で描きながら用途を具象化します。
 次に「製品を利用する側」「製品を購入(投資)する側」「製品を開発する側」「製品を開発するためにマネジメントする側」「製品を開発するために投資する側」と製品と周りに関わる方々を挙げ、製品と周りの繋がりを明確化します。
 最後に「製品と周りの繋がりから、損失が発生する要因」を過去の失敗事例(市場不具合対応など)を参考にして、想定されるリスクを挙げます。

 上記の過程で分からないことは、開発者や開発リーダに聞いたり、検索サイトで関連しそうな情報(規格や業界組織、業界標準など)を得て、理解を進めます。

何を確認するか?

 先述の「製品と周りの繋がりから、損失が発生する要因」を見つけるため、ISO25010の製品品質特性や自組織で蓄積された市場不具合の教訓をベースに、「損失が発生する要因」を知るための手段を挙げます。また、過去のテスト仕様からテストの目的を読み取れるものがあれば利用します。

最後に

 これまで経験した製品ドメインで原理・原則や思考の足跡を多少でも整理すると、異なる製品ドメインでも応用が利くことがありますので、これまでやったことの棚卸しを時々行うとよいと思います。