ソフトウェアのテストは実際に専門的なプロジェクトで行われていますか？
私は長い間開発者であり、請負業者でもあるため、いくつかの会社で多くのプロジェクトに携わってきました。
20％未満のプロジェクトが系統的にテストされていると思います。体系的にテストされているということは、臨時の計画テスト以外のテストを意味します。
私はまた、プロジェクトの10％未満がチームの一部として専任のテスターを配置している徹底的に体系的にテストされていること、テスト計画文書、開発者が自動テストを作成し、テストカバレッジと測定を追跡していることも推定します結果。
2つの質問
- この問題についての推定パーセンテージは何ですか？
- ソフトウェアテストに関する専門的な経験は何ですか？
追記
系統的テストの質問はかなり偏った回答を得る可能性があるため（人々は他の人より優れていることを自慢したい）I 励まし他の開発者（系統的テストにさらされていない開発者）も回答を提供するため、そうでなければ、テストはどこでも行われているように見えます...あなたの会社を除いて。
私のキャリアの中でのテストで見たパターンは、プロジェクトの失敗のリスクとの強い対応を示しています。大規模なプロジェクトは小規模なプロジェクトよりもテストされる可能性が高く、ミッションクリティカルなアプリケーションは、オフサイトのWebサイトよりもテストされる可能性が高く、社内システムは一般に公開されているものよりもテストされる可能性が低くなります。
とはいえ、過度にテストされたプロジェクトと十分にテストされていないプロジェクトはまだありますが、これらは少数派です。
私たちが生産するものはすべて完全にテストされています。社内のQAチームが過負荷の場合、プロジェクトをテストするオフショアチームがあります。彼らは私たちの内部チームほど良くはありませんが、それは別のトピックです。
はい。
テストの量は、アプリに必要な信頼性とプログラマカルチャーの成熟度に比例します。
多くの場合、Webサイトはバグホールをたどっています（リンク切れare欠陥）。
ビデオゲームはしばしばバギーです。
Windows（ついに）はかなり信頼できます。
ルーターは非常に信頼できる
病院は「壊れない」を監視
障害の財政コストも信頼性と相関していることに注意してください。
10年間、正式なコードテストを行うプロジェクトに携わることはありませんでした。
私の現在の仕事では、機能テストのみを行っています。
問題は、管理職の誰もコードテストに気づいていないことです。テスト部門は、テストコードについてさえ知りません。ハイレベルでは、ハイレベルの仕様に従って、動作/機能の観点から、それらが仕様に準拠していることを確認します。
適切なコーディングを強制する有能なソフトウェアリーダーがいない。その結果、スパゲッティコード、多くのリグレッション、見逃されたスケジュールなどが発生します。
私のサンプルは割合を推定するために非常に小さいですが、とにかくここに行きます。
1つは、熱狂的なテストを行ったファブレスチップ+ファームウェア会社でした。数十の設備での24時間年中無休の自動テスト。それぞれが数十のユニットを並行してテストします。テストソフトウェアの開発に専念するソフトウェアチーム。テストリグの構築に専念するハードウェアチーム。数十の競合他社に対する互換性テスト。ヘック、彼らはチップがファウンドリを離れるときにファブが実行するいくつかのテストを開発してデバッグするために数百万ドルのチップテスターを購入しました。
もう一つは銀行でした。これは完全に異なる環境です。製品はリリースされませんが、継続的に実行し続けるための社内ソフトウェアがたくさんあります。これらの人たちは、彼らが行ったすべての変更からcr * pをテストしました。彼らは、DEV/QA/PROD環境の非常に厳密な分離、自動回帰テスト、本番環境にリリースする前にエンドユーザーによってサインオフされた必須のQAテストなどを持っていました。
ええ、人々は系統的なテストを行います。しかし、ご存じのように、私は典型的なコンピューターユーザー向けの典型的なGUIソフトウェアを出荷する場所で働いたことはありません。
私は現在、ワイヤレス医療機器を製造する小さな新興企業向けの組み込みファームウェアを書いています。私たちは厳密なテストを行う必要があり、CEOに直接報告する担当者が率いる完全に独立した品質部門があります。私はこれまで、別のテスターによってコードをそれほど徹底的にテストしたことがありません（比較するのは、約15年前に衛星テレビシステムで作業していたときだけです）。
私たちのテスト結果はFDAに提出されます（これまでに2つのFDA認可を得ています。各提出は約500ページの長さでした）。私たちの開発方法論とテスト方法論はどちらも定期的な監査の対象です。
したがって、多くの正式なテストを行うのは大企業だけではありません。
注-私は25年以上の契約プログラミング/コンサルティングで、正式なテストをほとんど行わなかった多くの企業で働いてきました。それらのほとんどはもう存在しません。
私が過去15年間働いてきた3つの会社にはすべて、自動的に実行される単体テストがありました。
それらの会社の2つで、私はそれらを紹介するようにプッシュしました。
過去9年間、私は基本的に受け入れ/回帰テストのみに会いました。単体テストはわずかしかありませんでした。
私たちは南アジアの中規模のオフショア会社です。ただし、米国ベースのプロジェクトは常に行っており、米国企業から送信された要件に直接対応しています。
構築するすべてのアプリケーションに系統的なテストを適用します。おそらく、テストの品質は標準に達していないかもしれませんが、私たちはそれらを採用しています。
私の純粋主義者と同じくらい、厳格にテストするか、または正式なテストを行うかどうかの決定に組み込まれたリスク管理が必要であることを受け入れたくありません。プログラミングプロジェクトの大きな割合を占めると思われる内部アプリの場合、バグをリリースし、気づいた後すぐにパッチを適用するコストは、完全なテストチームのコストを上回る場合がありますときどき。もちろん、それはアプリと失敗の潜在的なコストに依存します。
とはいえ、リスク管理計画が正式なテストが不足している理由ではないと思います。それは、技術者ではない管理者が提供する価値を理解せず、コストのみを確認した結果だと思います。
私のキャリアの過去20年間、8社ほどの会社で、私はされなかったテストを行うプロジェクトに取り組んだことがありません。テストの量は会社ごとに異なりましたが、これまで取り組んだすべての専門能力開発プロジェクトは正式なテストを行いました。これは、中小企業にも同様に適用されます（「小規模」とは10人未満の従業員を意味し、「中規模」とは数千人以下の従業員を意味します）。
自動テストがあまりなかった会社もあれば、手動テストがあまりなかった会社もありましたが、少なくともどちらかがありました。
私がこれまで行ってきたほとんどすべての企業は、系統的なテストを行っていました。私の現在の会社にはいくつかの基本的なユニットスタイルのテストがありますが、それだけでは不十分です。このため、品質に問題がありました。自分以外の誰もが使用するプロジェクトについては、独立した完全なテストを行うことを強くお勧めします。費やしたお金はそれだけの価値があります。機能しないアプリケーションは使用されません。これは、内向きだけでなく外向きにも当てはまります。
それは顧客のニーズに依存します。契約状況では、おそらく受け入れテストがあります。社内では通常、ほとんどテストを行わないスラップジョブです。消費者向けのものは通常、頻繁な機能で高度にカバーされていますが、端が荒れています。
短い答え：はい
長い答え：
私は最初のカテゴリーの良い見積もりはありません（おそらくゼロからの距離ですが、どれくらいですか？）が、私の経験は実際に2番目の見積もりで裏付けられています。テストの量とタイプは、開発中のアプリケーションの種類、利用可能な時間枠、開発者のスキルセット、およびプロジェクトの実行方法に依存するため、意味のあるパーセンテージを与えることは困難です。実際には、開発者にとって最も重要なハードルは、請求目的にとって重要なマイルストーンであるため、受け入れテストです。しかし、それはまた、予期しない事態が発生する可能性があり（より多くの要件）、トラブルシューティングと克服に必要な時間に加えて、（この段階で）可能でタイムリーなアドホックテストを実施して問題を解決するようにプレッシャーをかけられる場合もあります。予期もせぬ出来事。
私は上記のさまざまな要因の組み合わせでさまざまなプロジェクトを経験してきました。
正式な単体テストはなく、統合テストのみ、ほとんどがアドホックテスト
単体テストから、専用のQAリソース、自動テスト（テスターが独自のツールセットを使用して実施）、コードカバレッジレポートを含む詳細なテスト計画まで、非常に正式なものです。しかし、これらはマネージャーにとってだけでなく開発者にとっても常に意味があるわけではありません
個人レベルでは、私が扱っているテクノロジーに適した適切なテストを書くことに関して私の選択肢の理解を維持し、自分の裁量でそれらを行使するよう努めています。基本的に、実際に私の仕事にとって意味があり、有益なものであり、数をそれほど多くしていません。
たとえば、Perlプログラミング言語用に提供されたソフトウェアのコアボディであるCPANライブラリについて考えてみましょう...
いつでも、毎回この[vast ...]ライブラリからパッケージをインストールすると、パッケージ作成者が提供する自動化されたテストスイートがマシンで実行されます。これらのテストのいずれかが失敗した場合、パッケージはインストールされません。
そして「CPANTS」があります。 https://cpants.cpanauthors.org/
CPANTSは、CPANディストリビューションのテストサービスです。その目標の1つは、Kwaliteeと呼ばれるある種の品質基準を提供することです。それは質のように見え、聞こえますが、Kwaliteeスコアが高いからといって、分布があなたにとってより有用であるとは限りません。 CPANTSメトリックのほとんどは過去のツールチェーン/ QAの問題に基づいているため、インストール、マニュアルの形式、ライセンス、または移植性の問題が発生する可能性が低いことを確認できます。
はい...この自動化サービスは、さまざまな種類のハードウェアおよびソフトウェアプラットフォームで、新しいCPANパッケージのリリースを常にテストします（パッケージがサポートするはずの...）およびテスト実際にそうする場合。
もちろん、これを日常的に行うライブラリ（または言語）はこれだけではありません。
ずいぶん前に、「テスト駆動開発」の個人的な価値に気づきました。クラスを作成してから、そのテストを作成します。システムに追加し続けると、常にすべてのテストを実行します。
"Suh-prize !!"
うわー...どうやってこれを壊したの？ ...まあ、私は私たちがそれを早く見つけたことを嬉しく思います！それが本番に出たら、それは非常に厄介だったでしょう！
うん。プロジェクトの唯一の開発者である場合でも、自分でそのレッスンを学ぶと、忘れないです。