特徴の交差の扱い
最近、フィーチャー交差に関するこの記事で説明されているものと同様の問題がますます多く見られます。私は通常、これらの問題を可能な製品構成の形で遭遇するのに対して、私はこれらを実際には異なる製品に帰する傾向があるものの、製品ラインと呼ぶこともあります。 このタイプの問題の基本的な考え方は単純です。製品に機能を追加しますが、他の既存の機能の組み合わせにより、どういうわけか物事は複雑になります。最終的に、QAは、これまで誰も考えていなかった機能のまれな組み合わせの問題を発見し、単純なバグ修正であったはずのものが、大きな設計変更が必要になることさえあります。 この機能の交差問題の側面は、驚くほど複雑です。現在のソフトウェアバージョンにN機能があり、1つの新しい機能を追加するとします。また、各機能をオンまたはオフにすることしかできず、2^(N+1)考慮できる機能の組み合わせがすでにあると言って、説明を簡略化しましょう。表現や検索用語が不足しているため、これらの組み合わせの存在を特徴の交差問題と呼んでいます。（より確立された用語のリファレンスを含む回答のボーナスポイント）。 ここで私が苦労している問題は、開発プロセスの各レベルでこの複雑な問題にどのように対処するかです。明らかなコスト上の理由から、それぞれの組み合わせに個別に対応することは、ユートピア的なところまでは非現実的です。結局のところ、私たちは正当な理由で指数関数的な複雑さのアルゴリズムに近づかないようにしていますが、開発プロセスそのものを指数関数的なサイズのモンスターに変えることは、まったくの失敗につながるはずです。 では、予算を爆発させず、まともな、有用な、専門的に受け入れられる方法で完全な体系的な方法で最良の結果を得るにはどうすればよいでしょうか。 仕様：新しい機能を指定する場合、他のすべての子とうまく機能することをどのように保証しますか？ 既存の各機能を新しい機能と組み合わせて体系的に検査できることがわかりますが、それは他の機能とは切り離されています。一部の機能の複雑な性質を考えると、この分離されたビューはすでに非常に複雑であることが多いため2^(N-1)、他の機能によって引き起こされた要因はもちろん、それ自体が構造化されたアプローチを必要としています。 実装：機能を実装する場合-すべてのケースでコードが適切に相互作用/交差することをどのように保証しますか。 繰り返しますが、私は純粋な複雑さについて疑問に思っています。2つの交差する機能のエラーの可能性を減らすためのさまざまな手法を知っていますが、妥当な方法で拡張できる手法はありません。ただし、仕様中の優れた戦略により、実装中は問題を回避できると思います。 検証：フィーチャーをテストする場合、このフィーチャーの交差スペースの一部しかテストできないという事実にどのように対処しますか？ 単一の機能を分離してテストしても、エラーのないコードの近くには何も保証されないことを知るのは十分に困難ですが、これを2^-N数分の1に減らすと、何百ものテストがすべての海洋の1滴の水をカバーしていないように見えます。さらに悪いことに、最も問題のあるエラーは、フィーチャの交差に起因するエラーであり、問題につながるとは予想されませんが、そのような強い交差が予想されない場合、これらのエラーをどのようにテストしますか？ 他の人がこの問題をどのように扱っているかを聞きたいのですが、私は主にこのトピックをより深く分析する文学や記事に興味があります。そのため、個人的に特定の戦略に従う場合、対応するソースを回答に含めるとよいでしょう。