ソフトウェアの現代の世界は非常に白黒で、2つの陣営に分かれています。あなたはオープンソースアプリケーションであるか、クローズドプロプライエタリアプリケーションです。 いいえ、もちろん、オープンソースプロジェクトにはさまざまなライセンスがあり、オープンソース（hi、Google、Facebook、Microsoft）に部品を広めるためのクローズド製品のある種の進歩があります。 しかし、これは原則として問題の本質を変えるものではありません-オープンな製品を取り、その中にあるすべてのものを見ると、それを評価し、連絡する価値があるかどうかを判断できます。 プロプライエタリなソフトウェアを購入したい場合は、ナイチンゲールを注いでいるメーカーの売り手、内部のすべてがいかにクールで、信頼性があり、高速で、モダンであるかを信じることだけです。 さて、あなたはおそらくそのような会議やプレゼンテーションで、スーツを着た男性が出て行って、製品のバージョン18.1.1ですべてが良くなった経緯と、今すぐ購入する必要がある理由について1時間こすりました。 多くの場合、1週間の限定トライアルモードを実行できます。これにより、「限定トライアルモードは1週間どのように機能しますか？」という質問に正確に答えられます。 買い手は常に、リスクを負うか、またはリスクを冒すか、または関与しないかの決定を任せられます。 決定を下す客観的なデータはほとんどありません。 同時に、それらはもはや存在しないように思われます-クローズド製品のメーカーは、商業的価値があるのでソースを投稿しません。
それは思われる-行き止まり？ そして、次の考えを考えてみましょう-もし私たちがメーカーにソフトウェアにテストを公開するように
1.メーカーは、テストがあることを示しています。 製品が良好であると自動的に言ったわけではありませんが、テストがまったくない場合は、製品が不良であると完全に保証されています。 つまり 「悪魔はそこで誰がそれをテストしたかを知っている」という評価から、「人々がテストしようとしているように見えるように」評価に進みます。
2.メーカーは、製品のソースコードを開きません。 はい、テストは個々のモジュールの構造とそれらの相互作用について何かを伝えることができますが、それに直面しましょう-デバッガーと逆アセンブラーはそれ以下を伝えます。
3.潜在的な購入者は、テストコードの品質を評価できます。 はい、これは製品自体のコードではありませんが、テストは通常、同じ人が同じスタイルで、同じ態度で、コードの品質、エンティティの命名を同じ徹底度で記述します。 購入者にコードの品質を評価するスキルがない場合は、監査のためにサードパーティのコンサルタントを雇うことができます。
4.テストを実行できる場合もあります。 もちろん、これにはメーカーからの追加作業が必要になります-コードを個別の分離コンポーネントに削除し、追加のモックを作成します。 しかし、何が悪いのか教えてください。 このアプローチにより、優れた製品コードを作成することができます。つまり、すべての人に利益をもたらします。 さらに、テストを実際の製品で実行できる場合-エラーの診断、テクニカルサポートとの通信に使用できます。
5.テストは、ニーズに合わせて拡張できる場合があります。 たとえば、データベース内の1000ドキュメントのストレージをチェックするテストがあります。 そして、100,000件のドキュメントが確実に保存されることを保証する必要があります。 ソフトウェアの製造元に質問すると、「はい、もちろんすべてが機能します！」（販売者に連絡した場合）または「わからない、そのような数量をチェックしなかった」（エンジニアに連絡した場合）のいずれかが聞こえます。 どちらの答えも役に立たない。 1000個のドキュメントに対する既製のテストがある場合、そのディメンションを簡単に変更でき、それを起動すると、質問に対する答えがわかります。
6.テストは製品ドキュメントとして機能する場合があります。 これは特に、開発者にSDKを提供するソフトウェアに当てはまります。 つまらないドキュメントを読むことと、既製のコードを取得して実行し、編集を開始することはまったく別です。
7.製造業者は、「誰にも何も保証されない」という恥ずべき言葉遣いの代わりに、最終的にライセンス契約で、少なくとも「製品に添付されたテストの通過が保証されます」と書くことができます。 これは、今日提供されているバッグに入っている猫よりもはるかに優れています。
8.オープンソースとクローズドソースのソフトウェア間の衝突の深刻さは、それほど血にならないでしょう。 「部分的にオープンな」ソフトウェアから、GNU派の目撃者はすでに少し血が少ないでしょう。 ここでは、当然、多くは解釈とPRに依存しますが、それでも一歩前進することは現在の直接的な対立よりも優れています。
9.ユーザーと話し合うことがあります。 多くのマーケティングチームとPRチームは、ユーザーから適切なフィードバックを得て、会話に引き込み、追加のモジュールとテクニカルサポートを販売しようとしています。 残念なことに、そのような会話はむき出しの基盤から始める必要があることが多く、会話は接着されていません。 そして、会話がすでに実質的に開始するときとはまったく別の問題です。テストが失敗し、機能を追加する要求があり、なぜこことここでそのようなパラメーターがテストに渡されるのかという質問があります。 「など...技術専門家の会話が問題のローカライズまたは新しい機能の開発の必要性につながる場合-これはすでに将来の取引を議論するための良い基盤になります。
プロプライエタリソフトウェアのテストコードを開く可能性についてのあなたの意見は非常に興味深いです。