品質保証 (QA) 部門は、大まかに言うと、アプリの正体を暴き、リリースのゴーサインを出し、アルファ/ベータ プログラムを処理するテスターの集まりです。そして、はるかに。
しかし、ソフトウェア会社に QA 部門がなければ、現場で頻繁に問題が発生し、問題の修正に多くの費用がかかります。ただし、ほとんどの企業はガレージから始まり、1 人の従業員が自分自身であり、その後ソフトウェア会社に成長します。
そのような部門を作るのはいつですか？会社の規模や直面する問題に何か関係がありますか?
2910 次
12 に答える
22
余裕ができ次第。QA部門がなくても、QA部門があるほど信頼できる製品はありません。プログラマーは優れた QA 担当者にはなりません。また、アプリの動作をレビューする 2 人 (またはそれ以上) の人がいる方が常に良いでしょう。
すべての優れたソフトウェア会社、およびプログラムを作成する優れた IT 部門を持つ組織には、qa チームがあります。ソフトウェア開発には欠かせません。
于 2009-02-05T22:05:58.387 に答える
5
品質保証 (QA) 部門は、大まかに言うと、1 日中アプリの正体を暴くテスターの集まりです。
QAが最終製品への障害物であるかのように、QAを「あなたのアプリを暴く多くのテスター」と見なしていることに私は困っています. あなたは過去に QA で嫌な経験をしたことがあると思います。代わりに、QA が会社にもたらす価値に目を向けてみてください。エンド ユーザーが最初から製品を信頼できるようにしたい。エンド ユーザーが問題や欠陥を見つけ、アプリや Web サイトに不満を感じている場合、エンド ユーザーはアプリをますます信頼しなくなります。QA は、ユーザーがアプリに対する信頼を失うリスクを軽減することになっています。QA がそれを行わない場合、アプリケーションに必要な価値を提供していません。その時点で、新しい QA が必要になります。ボタン押しだけではありません。開発者と同じようにアプリケーションを熟知している QA。
最後に、開発者は QA ではないということです。開発者は、絶対に必要な場合にのみ QA の帽子をかぶるべきです。開発者が 1 人か 2 人の小さな会社では、これは大変なことです。ですから、できるだけ早く QA を受けるという他の人たちの意見に同意します。大規模なソフトウェア開発会社の私が勤務している現場では、厳しい締め切りを守らなければならず、QA の時間が貴重な場合にのみ、開発者は QA の帽子をかぶっています。QA の帽子をかぶったとしても、テスト プロセスはその開発チームの主任 QA の 1 人によってレビューされ、開発者がアプリケーションを完全かつ効果的にテストしていることを確認します。開発者がテストした部分のテスト レベルに QA リーダーが満足するまで、QA リーダーはその部分を承認しません。
于 2010-10-08T23:45:50.340 に答える
5
成功しているソフトウェア会社の元 QA マネージャーとして、最初のプログラムをリリースしたらすぐにそれを成長させてください。（可能であれば、前に）。本当に、余裕ができ次第。しかし、開発者は、開発サイクルの最後だけでなく、開発サイクル全体で多くのテストを自分で行う必要があります。QA の仕事は (どの本を読むかによって異なります)、多くのレガシー テスト、SMOKE テスト、リグレッション テスト、実世界のテストを処理し、自動化されたテスト手順、プロセス、計画などを作成することです。
アドホック テストは、QA が行うべきことのほんの一部にすぎません。QA には、主に 2 つの重点分野があります。1) ソフトウェアは本来の機能を実行し、顧客が使用できるように要件を満たしていますか? 2) ソフトウェアは本来の機能を果たしていないか?
計画的、手続き的、アドホックなテストは、QA の基礎です。いずれかのタイプのテストのみを行うと、QA サイクルが成功しないことがわかりました。
私は自分で作業するときに QA なしでソフトウェアをリリースしましたが、どれだけテストしても、常にエラーが発生しやすいと言えます。ソフトウェアにとっては、2 番目以上の目のセットが最適です。
ADD 肛門保持型のコンピューター オタクからチームを構築するようにしてください。そうすれば最高の結果が得られます。:)誰かのソフトウェアをBOOMにできると誇りに思う人...へー..（冗談です..ADDを持っていないQAテスターをたくさん知っています）...
于 2009-02-05T23:13:25.427 に答える
4
悪魔の擁護者を演じるには：「QA部門」は赤いニシンであり、多くの場合、警官です。
まずレッドニシンに対処しましょう。「部門」とは、誰が誰に報告するかを示す組織構造のステートメントです。それは二次的なものです。「QA」は包括的な用語であり、特別な意味はありません。（信じられませんか？ここにテストがあります。「品質を保証」したくないですか？もちろんそうではありません。誰もがそれを望んでいます。）
ここで本当に欲しいものは何ですか？ユーザーよりも先に、ソフトウェアの障害モードについて学びたいと考えています。
ソフトウェアに現場で「問題」がある場合、それは故障モードを把握する作業が完了していないことを意味し、それを行うためのチョップを持つ人を雇うことができます.
私はたまたま、開発者の職務記述書には少なくともその一部を含めるべきだと考えています。もし私がテスターを雇うなら、彼らが故障モードを見つけるために一生懸命働かなければならないことを望みます. テスターが手を置いてから数秒以内にアプリがクラッシュした場合、開発者は直接それについて聞くことになります. 「重大な欠陥」という言葉が頭に浮かびます。
コップアウトに。真実は、事後に品質を製品に入れることはできないということです. しかし、「テスターを何人か雇うべきだ」というのは、許容できるレベルの品質をはるかに下回るコードを赤字で改ざんした多くの開発者の叫びです。（私は知っています - 私は彼らの一人でした。）
したがって、テスト経験のある人を雇う場合、私がすべき正しいことは、彼らを開発者と一緒に働かせることです。同じマネージャーに報告します。同じ使命を持って: そもそもそれを正しくする.
于 2009-02-05T23:28:37.783 に答える
3
私たちは、開発者が 1 人の小さなスタートアップです。追加のリソースを追加することについて話すときはいつでも、私の最初の応答は QA 担当者を雇うことです!
于 2009-02-05T22:09:55.603 に答える
3
QA 部門を有機的に成長させていると思います。ソロのプログラマーであっても、QA 担当者が行う作業の 一部を行う必要があります。
たとえば、1 人が QA 活動に 10% の時間を費やしている場合、10 人になったらすぐに 1 人を QA に専念させることができます。
于 2009-02-05T22:10:37.347 に答える
2
場合によります。小規模な会社で効率的なチームが少なく、エラー率が低い場合、これはおそらく解決する必要がある最大の問題ではありません。
市場がより迅速に作成するよう圧力をかけ、開発者の数が増え、エラー率が顧客との関係を損ない始めている場合は、プロセスをより形式化することでプロセスを修正することを検討できます。
小さな会社で生き残る秘訣は、プロセスの価値が自然に報われるときにのみプロセスを実装することです。品質を向上させるために人を雇っている場合、それ自体に支払うにはかなりの金額が必要です。つまり、以前は、品質がかなり悪い (そしてビジネスに損害を与えている) 必要があります。
多くの場合、優れたサポート プロセスのほうがはるかに重要です。最高の QA グループでさえ、バグが公開されることがあるためです。修正/パッチを適切に処理すれば、クライアントはあなたにもっと感銘を受けるでしょう (以前のバージョンがすべて非常に悪いものでない限り、バグの大幅な減少に気付くことはありません)。
ポール。
于 2009-02-05T22:36:52.303 に答える
1
ええと、コードのテストを書いたプログラマー以外の誰かが必要です。これは、QA 部門が必要だという意味ではありません。多くのショップでは、ビジネス アナリストがテストも行います。これは、要件分析や設計ではなく、ビルドの後半でしかテストできないため、はるかに経済的です。非常に小さなショップでは、おそらくビジネス アナリストという言葉を使用することさえありませんが、私が何を意味するかは知っています。つまり、コードを書かない製品または設計担当者です。非常に大規模な企業であっても、このモデルには利点があります。テストグループは、独自の生活を送ることができます。
于 2009-02-05T22:10:53.243 に答える
1
コードベースが大きくなりすぎて、1 人ではすべての詳細を知ることができなくなるとすぐに。
この背後にある理由は、プログラマーがシステムの残りの部分に対するコードの全体像と潜在的な副作用を認識していないために、回帰の 90% が行われているということです。そのような場合、age パラメータなどに -1 を指定してはならないことさえ知りません。ほとんどの場合、インターフェイスは明確でエラー チェック機能を備えている必要がありますが、大規模なコード ベースでは、締め切りに間に合わせようと急いだり、長時間作業したりすると集中力が低下します。
したがって、ワンマンショーであっても基本的なテストを行う必要がありますが、コードが十分に大きくなったらすぐに、ユニットテストや同様の自動テスト機能などを使用する必要があります。システム全体を把握することはできません。
于 2009-03-13T09:34:41.220 に答える
0
1 ～ 2 人の会社でテスターを雇うのはやり過ぎかもしれません。時間をかけて自分でテストしてみてください。または、友人の開発者 (チームに属していない) にアプリでしばらく遊んでもらいます。または、友人 (非開発者) に尋ねてください。ユーザー受け入れテストとほぼ同じです。
ソフトウェアの販売を開始するとき、3 人以上の開発者がいるとき、テストを行うために 2 つの多くのことを考えているとき (つまり、実際にテストすることを意味するのは、「自分のマシンで開始する」のではなく、「私は数時間試してみましたが、まだうまくいきます. たぶん、私は本当に創造的になる必要がありますか？
于 2009-11-03T19:56:13.830 に答える
0
私は現在、ガレージ スタートアップのソフトウェア会社を経営しています。現在、Q & A 部門を家族や友人に置き換えています。彼らに電話するか、ビールを飲みに来てもらい、私の製品を試乗してもらいます。
この「廊下」テストはこれまでのところかなりうまく機能していますが、私の製品は技術的に熟練したユーザーを対象としていません。
すぐに利用できる家族や友人がいない場合は、地元の広告やクレイグリストに広告を掲載することをお勧めします.最低賃金をテストする学生や誰かを見つけるのは難しいでしょう.
フルタイムの QA 担当者をいつ採用するかについては、会社の財務状況にのみ依存すると思います。
于 2009-02-05T23:19:43.463 に答える
0
QAなしで動作するはずですが、
- CI ソフトウェア
- 会社のプログラミング（および分析と設計など）のガイドラインと、プログラマーにそれらを「強制」するためのいくつかのツール
- 時々いくつかのレビュー
- チームテスト環境、統合 (すべてのアプリケーションを一緒に)、および統合 (統合と同じですが、本番データのコピーを使用) などのテスト段階
- 必要に応じてリリース計画グループ
- そして..まあ..優れた職人プログラマー
于 2009-02-05T22:20:16.487 に答える