黒柴的ソフトウェアテスト考 #14
テスト工程を計画することで実現するシフトレフト
#13に引き続き、2024/03/28に開催された、Findy主催のオンラインカンファレンス「伊藤 由貴さん、ブロッコリーさんに聞く！シフトレフトテストの推進と今後の展望」の感想をまとめておく
今回のメインテーマは「シフトレフトテスト」ということになるが、この「シフトレフト」という言葉は、JSTQBのFoundation Level シラバス最新版（Version 2023V4.0.J01）でも、2.1.5 シフトレフトアプローチとして、節を分けて説明されているので、一読しておくのが良いと思う
この図は、前回も用いたが、黒柴がかかわってきた大体のプロジェクトは、プロジェクト計画時にこのようなマスタスケジュールを設定していた
このマスタスケジュールによると、製造工程がある程度進んだところで、ようやくテスト工程が開始される
逆にいうと、その時点までテスト工程に関する作業は一切着手されないのだしかし、ウォーターフォールによる開発を行う場合、もっと早い段階でテストに関する作業を開始できる
というか、開始した方が良いのだと思う
上図は、よく見るISTQBで定義されさるテストプロセスを示したものである
過去のプロジェクトの進め方では、テスト工程で実施されているのは太枠で定義されているテスト実装、テスト実行、テスト管理であり、かろうじてテスト設計らしきものも行われるのだが、テスト分析などはまともに行われた記憶がない
だから、単体テスト、結合テスト、総合テストなどと工程の名称を定義しても、前回述べたように、「過去の経験では、こんな感じだったから、今回も同じかなぁ」という曖昧な内容のまま、テスト工程は進んでいった
上図は、ウォーターフォール型の開発における各テスト工程のテストベースを示したものである
例えば、総合テストのテストのテストベースを要件定義書とした場合、その要件定義書の作成が完了した後の工程として、総合テストのテスト分析に着手することが可能である
そこでは、ブロッコリーさんの発表にあったように、PO、Dev Engineer、QA Engineerの三者がそれぞれの立ち位置で要件定義書を分析することで、QA Engineerの観点での指摘事項を設計に盛り込むこともできるのだと思う
シフトレフトを上手く取り入れることで、より良い設計、テストのやり易さによる品質の向上が見込めると思うが、シフトレフトを行っていくためには、大きな問題がある
それは、ウォーターフォールによる開発を行う場合、要件定義工程の終了後から総合テストのテスト分析を開始するようなマスタスケジュールをたてることは、要員のアサイン、ひいてはプロジェクトの予算に影響を与えるからだ
JSTQBのシラバスには、以下のような記述がある
2.1.5 シフトレフトアプローチ
早期テストの原則（1.3 節参照）を、シフトレフトと呼ぶことがある。
（中略）
シフトレフトアプローチのために、ステークホルダーがこの考え方に納得し、受け入れることが重要で ある。
ここで示されているように「ステークホルダー」、特にお金を管理する層にどれだけ理解してもらえるかが重要だと思う
「シフトレフト」という言葉・概念は、JSTQBのシラバスにおいても上記したV4.0でようやく1節を設けられるようになった新しいものである
しかし、これを上手く取り入れていくことで、より品質の高いものを、より簡単に、より安価に製造できるようになるのではと思う
この記事が気に入ったらサポートをしてみませんか？