スタートアップは、プロセスの早い段階で専用のQAを用意する必要があります。多くの場合、QAはかなり遅れて追加されます。
私の2部構成の質問は次のとおりです。
- 専用のQAを最初にスタートアップの取り組みの一部にする必要があるのはいつですか。その理由は何ですか。
- 最初のQAメンバーはどのようなスキルを持っている必要がありますか（テストスクリプトの作成と実行、一般的なツールを使用した自動化のテスト、単体テストの作成、複雑な負荷と安定性のテストの計画と実行など）？
5055 次
13 に答える
29
私は型破りな見方を提供するつもりです：
スタートアップの最初の QA メンバーは、プロジェクトを適切に指定していない場合に開発チームに伝える (そして、この目標を達成するのを助ける) スキルを持っている必要があります。
私にとって、品質保証は単なるテストではありません。テストは品質管理 (QC) です。しかし、製品が何をすべきかを知らなければ、製品のテストを設計することはできません。これは、スタートアップ環境では非常に一般的な状況です。コーダーは、何を構築しているのかを決定せずに、猛烈にプロジェクトに取り組んでいます。
品質保証のプロセスは、コーディングの前に始まります。
- プロジェクトの要件をテストするのに十分具体的に定義します。
- ベスト プラクティス、ツール、方法論などを使用してプロジェクトを実装します。
- 構築したものが、構築しようとしているものと一致することを確認するためのテスト (これが QC です)。
そのため、最初の QA 活動は要件仕様フェーズに含める必要があります。
于 2009-09-20T02:25:36.553 に答える
15
私はアジャイルでリーンなソフトウェア開発を強く信じています。素晴らしい Mary Poppendieck の欠陥に関する引用の後に、ここを見つけてください。
- 「欠陥を見つけるための検査はムダ。欠陥を未然に防ぐための検査は不可欠です。」
- 「テストの仕事は欠陥を見つけることではなく、テストの仕事は欠陥を防ぐことです」
- 「品質プロセスは、品質をコードに組み込みます。検証中に定期的に欠陥を見つける場合、そのプロセスは欠陥があります。」
最後に:
- 「テストと修正のサイクルが分かれていると、テストが遅すぎます。」
したがって、あなたの質問に答えるために、私の見解は次のとおりです。
- QA の仕事は、欠陥を事実上不可能にするテスト駆動型の環境を作成することです。このように、QA は開発に先行し、その後には続きません。ですから、はい、できるだけ早く QA を開始してください。
- 理想的には、テスターを製品開発チームに組み込みます。反復中にテストに取り組んでもらいます。各反復で完全に機能し、テスト済みのインクリメントを出荷するようにしてください。
- この目標を達成するには、非常に熟練した人材が必要です。テスト領域と関連ツールのほとんどを習得する必要があります。テスト計画の作成、(自動化された) 受け入れテストの作成、テスト データの設定、最終的には負荷テストの実行などです。BDDの知識は大きなプラスとなります。開発チーム。
于 2009-09-20T03:54:31.413 に答える
4
スタートアップの唯一の開発者として、私の意見を述べさせてください。
- いつ？あなたがそれを買う余裕があるとすぐに。私は、2人目の開発者ではなく、今は専用のテスターを好みます。私は自分のアプリをテストするのが恐ろしいです。私は無意識のうちに物事を成し遂げるための正確な方法を知っています。そのため、実際のユーザーがアプリを使用する方法のバリエーションを常に見逃しています。
- スキル？良いほど、私は、アプリケーション上で手動で実行されているチェックリストを実行するために、ボディに落ち着きます。何でも役立ちます
于 2009-09-20T02:20:14.753 に答える
4
通常、QA は 1.0 の後まで必要なく、製品に収益源があります。
それはただ「働く」必要があります。
于 2009-09-20T02:47:18.803 に答える
3
本業の QA エンジニアとして、できるだけ早く QA に専念するのは良いことだと思います。初期の開発サイクル中、QA は機能計画に別の視点をもたらします。これはどのくらいの速さで実行する必要がありますか? スケールはどのくらいですか？1 つのインストールで同時にサポートできるユーザー数は?
優れた QA エンジニアは、常に問題を解決する新しい方法を見つけています。プロセスの後半に QA を持ち込むよりも、最初からそのことに集中する方が常に優れています。新しい QA 担当者が何百ものバグ レポートを積み上げるまで、かなりうまくやっていると思っていた開発者の士気をくじき、トリアージする必要があります (これはバグでさえありますか? QA が最初から関与していた場合、彼らはこれが意図された動作であることを知っていたでしょう! など) そして実際に修正されました。
そして、ここで正直に言いましょう...スタートアップについて話している場合、彼らはテスト計画を書いたり、有用な自動化を作成したりすることはありません. 安定した製品ができて、UI 全体が変更されないという保証があれば、テスト計画は素晴らしいものです。また、自動化はリグレッションを検出するのに最適ですが、開発の初期段階ではリグレッションは発生しません。 t は、まだ後退するものを何も出荷していません。
実際、優れた QA エンジニアに必要な重要なスキルは、コミュニケーション、頑固さ、および迅速に対応する能力です。QA がバグを見つけても、それがどのように発生したか、何をしていたか、どのように再現したかを明確かつ簡潔に説明できない場合、その有用性は急速に低下します。
于 2009-09-20T02:31:30.867 に答える
1
QA は役に立ちますが、製品を確実に完成させるための資金が得られるまで、テストのためだけに本体を追加するのは危険です。新しい開発者を追加することで、資金がなくなる前に製品を確実に完成させることができる場合は、優先順位を変更して新しい開発者を獲得する必要があるかもしれません。
開発者は QA を行う必要があるかもしれませんが、その場合、機能の開発を行った人はそれをテストするべきではありません。
たとえば、QA 担当者に継続的インテグレーションのビルドも担当してもらいたい場合があります。その場合、チームの全員が複数の帽子をかぶることになるため、QA 担当者は複数の帽子をかぶる必要がある場合があります。開発者が自由に開発できるように、非常に柔軟に対応できる人を見つけてください。
于 2009-09-20T02:26:18.017 に答える
1
ここには素晴らしいアイデアのログがあります。できるだけ早く QA を開始することが最善であることに同意します。いくつかの戦術については、Snehal Mohite に同意し、Q3 を追加します。
Q3) QA を機敏に構築し、できる限り手作業を自動化します。小規模なグループが物事をより簡単に達成できるようにするための「取引ツール」があることを確認してください。たとえば、Applitools Eyes などのツールを追加して、機能テストと並行してビジュアル テストを有効にします。これにより、より少ないリソースでより多くのことを行うことができます。チームが適切なツールを使用して開始することは、あなたとあなたの顧客のための強力な基盤を構築するのに役立ちます。
于 2014-12-21T17:13:43.433 に答える
1
私によると、答えは次のとおりです。
最初の質問に関しては、要件分析中に QA が関与する必要があります。このようにして、QA はプログラマーと一緒に座ってシステム エンジニアと話し合い、要件を完全に理解することができます。このプロセスでは、QA は要件を明確に把握できるため、プログラマーがコーディングを開始するときにテスト ケースを書き出すことができます。
その結果、プログラマーと QA はそれぞれの仕事を同時に終えることになります。
2 番目の質問に関しては、QA は、作業する必要がある環境、テストの方法論、および自動化テストの基本的な知識についてかなりの知識を持っている必要があります。それがスタートアップ プロジェクトである場合、彼は自動化に取り組む時間を得て、回帰およびサニティ テスト ケースを自動化します。したがって、管理者が製品を提供するための時間と労力、およびお金を節約できます。
于 2009-09-22T10:43:04.460 に答える
1
私が経験したほとんどのスタートアップでは、QA/テスト担当者がフルタイムで参加することはめったにありません。
前述のように、1 つのオプションは、複数の帽子をかぶることができる人を獲得することです。
別のオプションは、必要に応じて請負業者またはフリーランサーとして雇うことです。
あなたのビジネスモデルに適している場合、リモートで作業できる人を検討または見つけるためのクラウドソーシングテストのアイデアもあります.
于 2009-11-08T22:58:18.567 に答える
0
あなたの会社が十分な規模と収益性を持ち、専門化が可能になったらすぐに。
ほとんどの中小企業は、人々がジェネラリストであり、複数の帽子をかぶることを求めています。
ここに魔法の答えはありませんが、中小企業にとって重要なことは、すべての人が支払われるよりも多くの収入をもたらさなければならないということです。倍数は増分よりも優れています。IT 部門がどれだけ独立したテスターを必要としているとしても、これは事実です。
中小企業は創造的で、友人にお金の代わりにギフトカードのアルファ版をテストするよう依頼したり、信頼できるクライアントと協力したりする必要があると思います.
于 2009-09-20T02:30:18.500 に答える
0
QA、テスターなどに関して利用できるリソースはたくさんありますが、あなたの質問 (非常に良い質問) には簡単な答えがありません。いつ、何人、どこで、どのくらい早くプロセスに関与するかなどについての魔法の公式はありません。
おそらく最初に把握すべきことは、実際のニーズが何であるかということです。ほとんどの人は (残念ながら) QA を単なるテストとみなしています。テストは、QA チームの 1 つの側面にすぎません。ほとんどの人は、「本物の」QA チームに成長する前に、専任のテスターから始めます。
品質保証は予防保守に重点を置いていますが、テストは事実の発見に重点を置いています。
あなたはテスターか何かを求めていますか？
テスターのスキルに関しては、ナンバーワンのスキルは、製品のドメインの専門家であることです。他のすべては二次的なものです。
于 2009-09-21T01:04:33.677 に答える
0
QA の前に、ビジョンと組織を持つプロダクト マネージャーがいて、開発があります。最初の QA 担当者を雇う前に、プロダクト マネージャーは QA の帽子をかぶって、要件を定義し、最初のテスト フレームワークで物事を進めることができる必要があります。その後、プロジェクトが初期段階から抜け出すと、QA を雇って、プロジェクト マネージャーからプロジェクト管理タスクを引き受けることができます。重要なことは、開発が QA や設計の帽子をかぶる必要がないように、十分なスキルを持つ QA とプロダクト マネージャーを雇うことです。
于 2009-09-22T16:31:11.923 に答える
0
専用の QA を最初に立ち上げ作業の一部にする必要があるのはいつですか?またその理由は?
回答: 私自身が QA であると考えていますが、QA は品質保証の問題であるため、常に開始時から関与する必要があります。QA は、プロセス全体、製品に含まれるすべてのコンポーネントの動作を知る必要があります。
QA の主なタスクは次のとおりです。
a) 顧客からの要件の収集。
b) 「顧客は王様」と言われているため、要件を確認し、ニーズを理解します。
c) 収集した情報に基づいて、テスト計画、テストケース、労力見積もりなどを設計します。
d) 最後に、テストとバグの報告 (注: バグを明確に報告し、再現するテストについて言及します)。
上記のポイントは、QA が立ち上げ段階から関与する必要がある理由を明確に説明しています。
Q2) 最初の QA メンバーにはどのようなスキルが必要ですか (テスト スクリプトの作成と実行、一般的なツールを使用した自動化のテスト、単体テストの作成、複雑な負荷テストと安定性テストの計画と実行など)?
1) QA が持つべき最も重要なスキルは、「顧客の要件を理解する」ことと、製品に含まれる製品の動作と機能全体を理解することです。
2) 基本的な UI と機能に関連するテスト ケースを作成する要件に基づいています。
3) QA は、テスト範囲内にあるものとそうでないものを区別することもできなければなりません。
4) 締め切りに応じて、P1 優先度のテスト ケースを除外し、それらを最初に実行できる必要があります。
于 2013-05-04T06:59:29.597 に答える