開発テスト

開発テストは、ソフトウェア開発のリスク、時間、コストを削減するために、広範囲の欠陥防止および検出戦略を同期して適用するソフトウェア開発プロセスです。

組織のソフトウェア開発に対する期待に応じて、開発テストには、静的コード分析、データフロー分析、メトリック分析、ピアコードレビュー、ユニットテスト、コードカバレッジ分析、トレーサビリティ、およびその他のソフトウェア検証プラクティスが含まれる場合があります。

概要

開発テストは、ソフトウェア開発ライフサイクルの構築フェーズ中にソフトウェア開発者またはエンジニアによって実行されます。^[1]

従来のQAの焦点を置き換えるのではなく、それを補強します。^[2]開発テストは、コードがQAに昇格される前に構築エラーを排除することを目的としています。この戦略は、結果として得られるソフトウェアの品質と、開発およびQAプロセス全体の効率を向上させることを目的としています。^[3]

目的と利点

開発テストは主に以下の目的に適用されます。

品質保証- 欠陥や脆弱性をテストするのではなく、ソフトウェアに品質とセキュリティを組み込むことで、全体的な開発およびテストのプロセスを改善します。
業界または規制コンプライアンス-厳格なリスク削減と双方向の要件トレーサビリティ（要件、テスト、コードレビュー、ソースコード、欠陥、タスクなど）を必要とする業界または規制コンプライアンスイニシアチブ（例： FDA、IEC 62304、DO-178B、DO-178C、ISO 26262、IEC 61508など）への準拠を達成するため^[3]

VDCの調査によると、包括的な標準化されたプロセス内で開発テストプロセスを標準化して実装すると、ソフトウェアの品質が向上するだけでなく（開発活動を実証済みのベストプラクティスと一致させることにより）、プロジェクトの予測可能性も高まるとのことです。^[4] Vokeの調査によると、開発テストにより、ソフトウェア開発ライフサイクル全体を通じてソフトウェアの予測可能性、追跡可能性、可視性、透明性が向上するとのことです。^[2]

基本原則

上記の各アプリケーションでは、開発テストは、信頼性、セキュリティ、パフォーマンス、規制遵守に対する組織の期待を表すポリシーを定義することから始まります。次に、チームがこれらのポリシーについてトレーニングを受けた後、ソフトウェア開発活動をこれらのポリシーに合わせるために開発テストのプラクティスが実装されます。^[5]これらの開発テストのプラクティスには次のものが含まれます。

根本原因分析を通じてエラーの機会を減らすことを促進するデミングに触発されたアプローチを通じて、可能な限り多くの欠陥を防ぐ実践。
欠陥が導入された直後に欠陥を明らかにするプラクティス。欠陥を見つけて修正するのが最も速く、簡単で、安価であるとき。^[3]^[6]

幅広い欠陥防止および欠陥検出プラクティスの適用に重点を置くのは、さまざまな開発テスト手法がソフトウェア開発ライフサイクルのさまざまな時点でさまざまな種類の欠陥を明らかにするように調整されているため、複数の手法を同時に適用すると欠陥が漏れるリスクが減少するという前提に基づいています。^[3] 幅広いプラクティスを適用することの重要性は、よく参照される「ソフトウェア欠陥削減トップ 10 リスト」で Boehm と Basili によって確認されています。^[7]

静的解析

「開発テスト」という用語は、静的解析ツールの適用を説明するために時々使用されています。多くの業界リーダーは、静的解析は技術的にはテストではないため、この混同に異議を唱えています。コードのすべての行を「カバー」する静的解析でさえ、コードが想定どおりに動作することを検証することはできません。また、ソフトウェアが動的に実行されるときにのみ現れる特定の種類の欠陥やセキュリティの脆弱性を明らかにすることもできません。静的解析だけを万能薬と見なすべきではないと警告する人は多くいますが、ほとんどの業界の専門家は、静的解析が多くのセキュリティ、信頼性、およびパフォーマンスの欠陥を排除する実証済みの方法であることに同意しています。言い換えると、静的解析は開発テストと同じではありませんが、一般的に開発テストのコンポーネントと見なされています。^[8]^[9]

追加アクティビティ

フロー解析やユニットテストなどの静的解析のさまざまな実装に加えて、開発テストには主要な品質活動としてピアコードレビューも含まれます。コードレビューは、ソフトウェア開発における最も効果的な欠陥検出および予防方法の1つとして広く考えられています。^[10]

参照

参考文献

^ McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. ISBN 0-7356-1967-0。
^ ab voke Market Mover Array Report: Testing Platforms、Theresa Lanowitz、Lisa Dronzek、voke、2012 年 6 月 5 日
^ abcd Kolawa, Adam; Huizinga, Dorota (2007). 自動欠陥予防: ソフトウェア管理のベストプラクティス。Wiley -IEEE Computer Society Press。ISBN 0-470-04212-5。
^ VDC Research による「組み込みソフトウェア品質の自動欠陥防止」ホワイトペーパー
^ 開発への大きな期待 - 政策自動化による、ウェイン・アリオラ著、SD Times、2011 年 7 月 28 日
^ ソフトウェア開発、テスト、検査の再考 2013-05-07 にWayback MachineにアーカイブMatthew Heusser 著、CIO、2012 年 2 月 1 日
^ ソフトウェア欠陥削減トップ 10 リスト、Barry Boehm および Victor R. Basili、Computer、2001 年 1 月
^ ソフトウェアエンジニアリングにおける静的解析ツール、Wayback Machineで 2012 年 10 月 15 日にアーカイブ、Dr. Paul E. Black 著、CrossTalk: The Journal of Defense Software Engineering、2009 年 3 月/4 月
^ 組み込みおよび安全性重視の開発における静的解析でよくある 3 つの間違い、Arthur Hicken 著、EE Catalog、2012 年 9 月 25 日
^ SIL 要件を満たす: E/E/PE 安全関連システムの機能安全の確保 2016-03-04 にアーカイブされたWayback Machineの記事 DevelopmentTesting.com

[codecomplete-1] McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. ISBN 0-7356-1967-0。

[voke-2] voke Market Mover Array Report: Testing Platforms、Theresa Lanowitz、Lisa Dronzek、voke、2012 年 6 月 5 日

[adp-3] Kolawa, Adam; Huizinga, Dorota (2007). 自動欠陥予防: ソフトウェア管理のベストプラクティス。Wiley -IEEE Computer Society Press。ISBN 0-470-04212-5。

[vdc-4] VDC Research による「組み込みソフトウェア品質の自動欠陥防止」ホワイトペーパー

[sdtimespolicy-5] 開発への大きな期待 - 政策自動化による、ウェイン・アリオラ著、SD Times、2011 年 7 月 28 日

[cio-6] ソフトウェア開発、テスト、検査の再考 2013-05-07 にWayback MachineにアーカイブMatthew Heusser 著、CIO、2012 年 2 月 1 日

[cd.umd-7] ソフトウェア欠陥削減トップ 10 リスト、Barry Boehm および Victor R. Basili、Computer、2001 年 1 月

[8] ソフトウェアエンジニアリングにおける静的解析ツール、Wayback Machineで 2012 年 10 月 15 日にアーカイブ、Dr. Paul E. Black 著、CrossTalk: The Journal of Defense Software Engineering、2009 年 3 月/4 月

[9] 組み込みおよび安全性重視の開発における静的解析でよくある 3 つの間違い、Arthur Hicken 著、EE Catalog、2012 年 9 月 25 日

[DevelopmentTesting.com-10] SIL 要件を満たす: E/E/PE 安全関連システムの機能安全の確保 2016-03-04 にアーカイブされたWayback Machineの記事 DevelopmentTesting.com