ソフトウェアエンジニアが一定期間品質保証エンジニアとして働かなければならないのは良い考えだと思いますか？[閉まっている]

そうだと思います。どうして？

1. 私は、QAエンジニアよりも優れていると信じている多くのソフトウェアエンジニアに出会いました。しばらくQAエンジニアの仕事をし、それが独自で価値のあるスキルセットであることに気付くと、この信念を癒すのに役立つと思います。

2. ソフトウェアエンジニアが自分のプログラムをテストする能力が高ければ高いほど、ソフトウェア開発ライフサイクルの残りの部分でコードを作成する際に発生する時間のコストが少なくなります。

3. ソフトウェアエンジニアがプログラムがどのように壊れるかを考える時間を長くすればするほど、これらのケースを開発中に考慮する頻度が高くなり、最終製品のバグが減少します。

4. ソフトウェアエンジニアの「完全な」定義は常に興味深いものです。QAエンジニアとして時間を費やしている場合、この定義はソフトウェアの設計者により密接に一致する可能性があります。

誰かが雇われているポジションではないポジションで働くことは間違いなくその開発者を失うためのレシピであると認識しているので、私は小さな時間枠を念頭に置いて上記の提案をします。

皆さんはどう思いますか？

1.私は、QAエンジニアよりも優れていると信じている多くのソフトウェアエンジニアに出会いました。しばらくQAエンジニアの仕事をし、それが独自で価値のあるスキルセットであることに気付くと、この信念を癒すのに役立つと思います。

優れたソフトウェアエンジニアリングには、テスト、メトリック、統計などの品質の背景があります。あらゆる種類のソフトウェア開発を行う人は、高品質のソースコードを維持し、効果的なテストケースを作成/維持することに慣れている必要があります。時間の経過とともに、ソフトウェア開発者は、コードの品質、移植性、保守性、テスト容易性、使いやすさ、信頼性、効率性、セキュリティなど、品質のさまざまな側面を理解できると思います。

ソフトウェアエンジニアは、ライフサイクルの特定の側面（要件エンジニアリング、アーキテクチャと設計、構築、テスト、およびメンテナンス）に集中する場合があります。ただし、（仕事として、またはプロジェクトの現在の段階で）フォーカスに関係なく、品質を覚えておくことが重要です。

2.ソフトウェアエンジニアが独自のプログラムをテストする能力が高ければ高いほど、ソフトウェア開発ライフサイクルの残りの部分を実行する際にコードにかかる時間のコストが少なくなります。

それは本当かもしれません。ただし、いくつかの問題は開発の後半で最もよく見られます。たとえば、パフォーマンスと効率の問題は統合するまで見られない場合があります。優れた堅実なコードと効果的な単体テストは、ほんの始まりに過ぎません。品質は要件から始まり、メンテナンス活動全体を順守する必要があります。

3.ソフトウェアエンジニアがプログラムの破損の可能性について考える時間を長くするほど、開発中にこれらのケースを考慮する頻度が高くなり、最終製品のバグが減少します。

それは完全に本当の声明です。ただし、要件の競合がないことを確認するのは要件エンジニア、設計が実際に要件に対応していることを確認するアーキテクトなどです。誰もが自分の仕事に穴を開けようとし、適切な人々と協力して彼らをうまくきつく締めるべきです。

4.ソフトウェアエンジニアの「完全な」定義は常に興味深いものです。QAエンジニアとして時間を費やした場合、この定義はソフトウェアの設計者により密接に一致する可能性があります。

「完了」は、要件に対してのみ測定できます。要件が満たされていてプロジェクトが完了しているか、要件が不完全でプロジェクトが完了していないかのいずれかです。他の完全な尺度は役に立たない。

プログラマーにコードの説明責任を負わせ、自分のバグを修正するように要求することで、これを処理できます。それとボーナスや仕事の損失。

この経験が役に立たないというわけではありませんが、この考え方をどこまで活用できますか？テクニカルサポート、セールス、ベータユーザーは、トイレをこすります（これは謙虚な体験になります）。

「... QAエンジニアとして働かなければならない...」あなたはそれを敵対的または罰に聞こえさせます。

私はソフトウェア開発者です。私たちにはQA部門がありますが、QAエンジニアになることも仕事の一部だと思います。特定のことを達成するソフトウェアを提供するのが私の仕事です。そのためには、単体テストを作成し、ソフトウェアがそれらをパスすることを確認する必要があります。

私はQA部門と提携しています。私の目標は、彼らの仕事がより簡単になることです。ちょうど彼らの仕事が、それがすべきことをするソフトウェアを提供するという私の目標を達成するのを助け、それによって私の生活を楽にすることです。ユニットテストを行うのと同じように、私はそれらを第2の目であり、ある程度の安全策だと考えています。

ソフトウェアを開発することを選択し、ソフトウェアを開発したい。マネージャーが私のところに来て、それができないのでQAをしなければならないと言われた場合、そこで働くことはないので、新しいソフトウェア開発者とQAの人を見つける必要があると言います。私は自分のコードと同じように肛門ですが、創造的なプロセスとプログラミングのパズル/挑戦は私にとって非常に重要です。コードを書くことができなければ、フォークリフトの運転に戻りたいと思います。創造的であり、自分が絶対に地獄であるような挑戦を受けないという企業環境にいるからです。

一般的に、あなたが提示するオプションは非常に敵対的であり、恐ろしい開発者と本当に悪い経験をしたことがあるのだろうかと思います。私の考えでは、開発者は常に品質の問題とテストを認識している必要があり、ユニットテストでの厳格なテストとして公式のQA部門が使用するものとして合格するまで、作業が完了したとは見なさないほど十分に作業を誇りに思っている必要があります。同僚がいる場合、またはチームの技術リーダーであり、QAに対して「 'tude」を示す開発者がいた場合、態度を修正するために彼を連れて行ってくれます。ソフトウェア配信コインの両側が協力してチームとして機能できない場合、実際の文化の問題があります。私はそこで働きたくはありませんし、人事も、上級管理職とともに、頭に入れる必要があります。

プログラマをQAエンジニアとして働かせることは、最高の開発者を失うレシピです。プログラミングとQAには、異なるスキルセットと思考プロセスが必要です。

ただし、プログラマーがQAチームに渡す前に、自分の作業をテストおよび検証する技術に精通していることが重要です。開発者とQAは、さまざまなツール、知識、スキルにアクセスできます。開発者は、予期しない動作を探すコードのステップ実行、境界条件の単体テスト、競合条件を探すスレッドコードのストレスなど、つまり開発者の観点からのテストに熟練する必要があります。

QAは、ユーザーの観点からテストを行います。さまざまなタイプのユーザーのように考え、奇妙なエッジケースを発明し、あいまいな問題を再現可能にすることがQAスキルです。

必ずしもそうではありません-プログラマーとテスターの両方が異なるスキルを持っている必要があります。あなたが優秀なプログラマーだからといって、あなたが優秀なテスターに​​なれるわけではありません（多くの人はそれを理解していませんが、プログラマーであることは自動的にテスターに​​なる資格がありません）。

優れたテスターは、本当に悪魔的なスキルを持ち、ソフトウェアが実行するように設計されていないことを実行できる必要がありますが、ユーザーが実世界で実行できることを期待できます。それには、スキル、忍耐、どこで何がうまくいかないかを見る能力、ユーザーのメンタリティの理解、その他多くの要素が必要です。

プログラマーとテスターという言葉を使用していることに注意してください。ただし、ソフトウェアエンジニアであり、プログラマーとテスターのどちらになりたいかまだ決定していない場合は、これらの両方が含まれるため、少なくとも両方の経験が必要です決断を下す前の人生の最初の数年で。

だからといって、経験豊富なプログラマーを連れて行って、QAエンジニアの仕事の難しさを理解させるためにしばらくテストさせてもらうわけではありません。

あなたの提案で見られるいくつかの潜在的な問題は次のとおりです。

1）新しい分野のソフトウェアエンジニアを短期間のQA部門に入れることを提案している場合、これは逆の効果をもたらすだけではありませんか？-彼らはあなたが初心者のときQAがあなたがすることであり、あなたが何をしているのか理解していないと思うかもしれません-結局、それは彼らのために働いた方法です。

2）しばらくの間非常に悪いテスターであることは、必ずしも彼らに貴重な何かを教えるとは限りません。しかし、彼らは、テスト部門で昔々6週間を過ごしたので、彼らは今、テストについてすべてを知っていると仮定するので、後で彼らを教えることができなくなる可能性があります。

3）彼らは明らかに短時間しか存在せず、QA部門はこれを知っていることを考えると、監督や理解をほとんど必要とせず、忙しいままにする比較的要求の少ない簡単なタスクのみが与えられる可能性が高い。これにより、1と2のみが強化されます。

4）1、2、および3を避けたい場合、テストに興味さえない人を指導し、監督するために多大なエネルギーを投資する価値があることをテスト部門にどのように説得しますか？（私はあなたに言うことができます、覚えておいてください、彼らのテスト適性のために選ばれていない誰かと仕事をするのは恐ろしい量とエネルギーを必要とします。あなたはテストチームに数週間追加リソースを提供していません彼らはあなたの初心者を教えている間に、彼らの最も経験豊富な人の数人を数週間失うように頼んでいます）。

そうは言っても、新しいソフトウェアエンジニアのテストに対する理解を高めるというあなたの全体的な目標は本当に素晴らしいと思います。グレッグの提案はそれを達成する可能性が高いと思います-開発チームとQAチームを緊密に連携させ、チーム間の障壁を取り除くことに取り組みます。（私は現在、テスターとプログラマーが同じチームに所属している会社で働いています-本当に素晴らしいですし、別のチームで働くことを決して望みません。）

プログラマーにQAを任せたい場合は、ここに提案があります。例によるリードです。最初に自分で行ってください。もしかしたら、チームのメンバーがすでに上手いときにやりたいことや、重複する分野に特化した他のチーム（テスト、DBAなど）と毎週少し時間を過ごすことで、その余分な力を得たいと思うかもしれません。そのように提示すれば、成功の可能性が高くなります。

私はあなたが通常見るものの逆のようなキャリアパスを並べ替えました。私は科学的に困難な物理学のソフトウェアサポートとして始め、その後、コンピューター会社のアーキテクチャ、プログラミング、アルゴリズムの交差点で働きました。その後、私は数年にわたって主要なエンジニアリングコードのパフォーマンス最適化を行いましたが、その作業でさえ使い果たしました。今、私は定年に近づいているので、同じコードでQAをしています。それは挑戦と骨の折れる仕事の組み合わせです。バグ修正に100％取り組んでいる本当に鋭い新しい人がいます。私は彼と一緒に多くの時間を費やしています。それはやりがいのあるポジションであり、それを行うことで多くを学ぶことができます。この時点で、職業開発における私の主な関心は、コンプサイエンス大学の新入生である双子の男の子に対するものです。そのため、私は彼らのキャリア、特に応用数学に関連するものを学習（または再学習）することに新たな興味を持っています。QA /検証に関心を持っている今、物事の異なる視点を持っていますが、前の四半世紀では速度、速度、速度を犠牲にしました。

ソフトウェアテストは、建設的というよりも破壊的なプロセスです。しかし、プログラマーは、製品を期限内に予算内で完成させるために、製品に建設的だと考えています。ソフトウェア開発者が自分の製品を破壊したいと考えている場合、次に製品を構築するのは誰になります。そのため、ソフトウェア開発サイクルの各部分は、開発サイクルの各部分に割り当てられた人が行う必要があります。2つ以上の分野に携わっている場合、あなたはそれらのいずれかで完璧になることは決してないので、プログラマーまたはQAまたは他のオプションのいずれかを行い、その上で完璧になります。