配信されてくるIT系ニュースの中にQCDという言葉がありました。Quality、Cost、Deliveryの頭文字だそうですが、初めて聞きました。不勉強を恥ながら、その意図するところを読みました。イントロは･･･

～～～～～～～～～～～～～～～～

システム開発におけるテストの比重が高まっている。負担が大きい／回数を上げて品質を確保したい／スピードを上げたい等、テストの実施に課題を感じている人が多い。そこでテストの品質／コスト／納期の全てに影響を及ぼす“自動化”を検討する企業が増えている。しかし自動化の価値を最大化するためには、プロジェクトやシステムに適したツールの選定が重要

～～～～～～～～～～～～～～～～

新語に共通する取り立ててアピールするほどのことがないテスト自動化のためのツールの宣伝でした。このブログでは、OSの開発、CASEツールの開発、営業支援システムの開発、リソースマネジメントシステムの開発などを通して実際にテストをし、仕様通り動くことを確認して稼働させてきましたが、安定稼働を続け機能を発揮したそれらはいずれも受賞の対象となっています。

品質を保証するためのテスト工数を減らす試みは汎用機時代からあり、使えるか否か／テスト工数削減になるか否かを判断したことがありました。そのツールは、ソースコード（アセンブラ）を読み込んで分岐、判定、境界条件などを見つけてチェックリストを作るものでしたが、結果は･･･残念ながら不可でした。つまり、使えないという結論でした。

時代は汎用機からサーバ、パソコン、ネットワークが前提の時代になりましたが、品質というかシステムの信頼性を保証するためのテストが必要なのは変わっていません。一方、システムで処理する対象業務が多岐に亘ってきた今、テスト工数が増えてきました。そのマーケットをビジネスチャンスと捉え、テスト作業を支援するツール類が増えて来るのは自然です。しかし、仕様通り機能するかのテストを疎漏なく行えるツールを作れるのでしょうか？作るために必要な知識はあるのでしょうか？テストには、システムが対象とする業務を理解している必要がありますが、それは･･･

OSの開発時、バージョンup、リビジョンupの際には、山の様なPCL（program check list）を作りましたが、テスト項目とそのテスト方法のレビューをやりました。テスト方法のレビュー？簡単に言えば、そのテスト方法でテストしたことになるのか？というものです。多種多様の機能から成り立ち、機能を果たすための条件が複雑に入り組んでいるために、タイミングを中心にテストの方法については、設計の各部門がそれぞれの立場（切り口）で意見を述べ合い、確実に当該機能をテストしたと言えることを確認し、テスト方法を合格にしてから、保証されたその方法でテストを行い、メモリダンブリストなど証拠となるものを添付し、合格したテスト項目に○をつけました。各種アプリケーションが動く土台となるOSのテストなので、そのくらいの厳しさでテストするのは当然のことでした。

では、アプリケーションならそこまでやる必要はないのか？そんなことはありません。金融システム、医療システムなど生命財産の関するものはもちろん、万が一の事故の際には大惨事になる航空、鉄道をはじめ、製鉄、石油などの危険物を扱う製造業でも、同じです。

DXDXと騒いぎ、開発パワーが足りないと騒いでいる皆さん向けに、ローコード、ノーコードの開発支援ツールが出回り、導入事例などが喧伝されていますが、そのツールで作られた多数のアプリケーションの品質はどうやって保証するのでしょう？ということで、冒頭掲げたQCDなど指標ができ、その実現を支援するテスト自動化ツールが登場するわけです。実務経験豊富で賢明な皆さんは乗せられないとは思いますが、乗せられてしまう方々もいるようです。

一般的に、品質を保証するためには、適当にピックアップした幾つかのケースでテストするのではなく、処理の対象となる業務、作業で起こりえる全てのケースでテストをしなければなりません。テスト漏れがないようテスト項目が洗い出されているか、そのテスト方法で機能の確認ができるのかを含めてのレビューが必要になりますが、これは自動化できません。また、テストの中に処理時間、レスポンス時間という性能の要素があるとしたら、更に自動化は困難です。

テストの自動化はできないと思ってテスト項目を作り、そのテストをクリアすれば品質が保証されるのかを含んでレビューを行い、一つずつ地道にテストをすることを勧めます。私の指揮した総ステップ数100kを超える院内統合情報システムを開発したプロジェクトではそうしてきました。

テストは実際に仕様を作った実務を熟知している現場の医師、看護師、薬剤師、栄養士、検査員、医事会計メンバが、『この場合はこうならなければならない』という視点で、実務に則してテストしました。

効率よくテストを行う方法を模索することは大切ですが、常にそれで品質を保証できるか否かという視点を忘れないことは、もっと重要です。

※質問はosugisama@gmail.comにどうぞ。
※リブログを除き、無断で本ブログの内容を転載、流用することを禁じます。

QCD（Quality、Cost、Delivery）という新語