タグ付けされた質問 「qa」

これはすでに質問されている他の質問とよく似ていますが、実際は少し異なります。一般に、プログラマーはアプリケーションのテストの役割を実行するのが得意ではないと考えられているようです。例えば： Joel on Software- テスターがいない上位5つの（間違った）理由（強調） 大学のCS卒業生に、彼らがあなたのために働くことができると告げようとすることさえ考えないでください。私はこれを見てきました。プログラマーは優れたテスターを作りません。そして、交換するのがはるかに難しい優れたプログラマーを失います。 そして、この質問では、最も人気のある答えの1つが言います（再び、私の強調）： 開発者はテスターに​​なることができますが、テスターであってはなりません。開発者は、アプリケーションを破壊する可能性のある方法での使用を意図せず/意識せずに避ける傾向があります。それは、彼らがそれを書いて、大抵それが使われるべき方法でそれをテストするからです。 質問は、プログラマーがテストに苦手なのか？この結論を裏付ける証拠や議論はありますか？プログラマは自分のコードをテストするのが苦手なだけですか？プログラマーが実際にテストに長けていることを示唆する証拠はありますか？ 「テスト」とはどういう意味ですか？私は、単体テストや、ソフトウェアを作成するためにソフトウェアチームが使用する方法論の一部と見なされるものを意味しません。コードが構築され、ソフトウェアチームが「テスト環境」と呼ぶものにデプロイされた後に使用される何らかの品質保証方法を意味します。

36 testing  qa 

私の仕事では、バグを解決するすべての開発者は、このタイプのバグについて警告する新しいユニットテストを追加する必要があります（再び発生する場合）。単体テストが不可能な場合（たとえば、Webページのデザインの問題）、QA部門はテストケースを作成して手動でチェックする必要があります。 この背後にある考え方は、製品のリリース前に欠陥が検出されなかった場合、それを検出するための適切な単体テストがないためであるということです。そのため、開発者が追加する必要があります。 問題は、これはどのソフトウェア開発方法論でも一般的ですか？このテクニックには名前がありますか？私はそれについてもっと学びたいのですが、それから始めるにはいくつかの情報が必要です。

35 unit-testing  issue-tracking  qa 

私はBE（CS）に取り組んでいる学生で、私の質問は次のとおりです。 ソフトウェア分野でのテストが必要ですか？ 細心の注意を払ってソフトウェアを作成する場合、なぜテストする必要がありますか？ テストした後、私たちはすることができわから我々が行っているので、我々は（意図したとおりの製品/ソフトウェアが動作します）、この目標を達成していることをテストし、それのために？出来ますか？ 私の質問：ソフトウェアのテストは必要ですか？

33 testing  quality  validation  qa  verification 

私の会社の誰かが最近、コア製品の変更を提案しました。マネージャーは、私の会社が完全なQAサイクルと考えるものをトリガーする必要があると感じています（つまり、製品スイート全体を一からテストする）。QAが製品のQAサイクル全体を実行するには、12週間かかります。これに関する私の問題は、アジャイル（ほとんどの意見では半分ですが）開発をしようとしていることです。スプリント全体を実行した後、リリースを実行します。QAはこれを完了するまでに時間がかかります。問題は、QAが仕事をするのに12週間かかる場合、アジャイルをやろうとするのをあきらめてはいけないということです。このような状況でアジャイルをやろうとすることの意味は一体何でしょうか？

24 agile  qa 

私たちは、同じgitリポジトリで複数のプロジェクトに取り組んでいる大きなチーム（10〜12人の開発者と4人のqa）です。そのスプリングブートベースのバックエンドWebサービス。優れたgit分岐および展開戦略を探しています。また、機能が期待どおりに機能することを保証するqaチームもあります（ある程度のバグはありません）。 いくつかの記事を読んだ後、Gitflowモデルは私たちにとってうまく機能するだろうと感じました。ここに私の質問が来ます。 QAチームはどこで機能をテストする必要がありますか？ 彼らが機能ブランチでテストすれば、彼らはバグを発生させ、開発者はそれを修正し、それがQAテストに合格したら、開発のためにマージします。また、QAは開発ブランチで整数化テストを再度行います。 すべての機能をマージして（ユニットテストと開発者による基本的なテストの後）ブランチを開発し、そこからqaテストを行います。修正とテストもすべて開発中に行われます。 他の人にとってどのアプローチがうまくいったのか知りたいです。

23 testing  git  branching  qa  gitflow 

すべてまたはほとんどのコーディングがスプリントの終了まで行われない場合、テストはコーディングと同じスプリント内でどのように処理されますか？（スプリント内の単一のPBIの「スープからナッツ」への開発とテストに言及しています。） 私がオンラインで見た回答のほとんどはQAの自動化に関係していますが、自動化されたテストを記録または作成するための機能的なUIが一般的に必要なので、それも実際には不可能です。機能を開発し、新しい要件を発見するにつれて進化し続けるストーリーボードしかありません。 私の場合、新しいデスクトップアプリケーションを開発しています。通常、デスクトップアプリは自動テストにあまり適していません。自動化された単体テストがいくつかありますが、QAの専門家が行う手動の機能/統合テストではありません。 ですから、私が今いるのは、私のスプリントが明日で終了するということです、私はまだコーディングを終える必要があります、そして私のQAの人々はまだテストするものが何もありません、そして私が手を持たずに私が彼らに与えるものをテストする方法がわかりません。 私はこのジレンマを持っている最初の人ではないと確信しています。 過去に、パイプラインを実行しました。現在のスプリントでは、テストチームが前のスプリントで実装された機能をテストします。私の現在の仕事では、PMはこのアプローチを「ウォーターフォール」と呼んでいます。

22 agile  testing  unit-testing  scrum  qa 

私の現在の立場では、QAがボトルネックになっています。QAがテストを終了できるように、現在のビルドでは機能が保持されないという残念な事態が発生しました。つまり、開発中の機能は、開発者が既に移行してから2〜3週間はテストされない可能性があります。開発者がQAをより速く進めることで、この時間差は大きくなるだけです。 私はCode Completeのコピーをめくり続け、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探します。誰かがこの概念を裏付けるいくつかの研究を教えてくれますか？私は、QAのボトルネックが彼らが考えるよりもはるかに費用がかかるという力を説得しようとしています。

18 development-process  qa 

チケットの推定時間を作成するとき、テスター（QA）にかかる時間をチケットの推定に含める必要がありますか？以前は、テスターの時間なしで常に見積もっていましたが、常にそれを含めることについて話し合っています。チケットがあと1週間でかかる合計時間を知る必要があるため、現在のスプリント、リリース前の最後のスプリントには意味があります。 チームのリソースを制限する傾向があるため、見積もりは開発者向けの時間であると常に理解していました。同僚は、テスターの時間より前に働いていた場所はどこでも含まれていると言っています。 明確にするために、これは、開発者が適切なカバレッジでユニット、統合、およびUIテストを記述しているプロセスのためのものです。

17 agile  scrum  estimation  qa 

私の会社では、アジャイルプラクティスでの作業に成功していますが、反復は使用していません。主な理由は、反復サイクルでQAに適合するクリーンな方法を見つけることができないからです。 QAは、特定のビルド（リリース候補）に対する追加の検証として、このビルドが顧客に展開される前に理解します。ポイントは、1つの悪意のあるコミットがリリース全体に損害を与えることを避けることです。あなたはそれがどれであるかを決して知らないので、QAはリリースのすべての機能/コミットがビルドに含まれるまで待つ必要があります。（有名な最後の言葉「それはほんの小さな変化でした」は許可されていません。） QAがリリース候補でバグを見つけた場合、開発者はそれぞれのリリースブランチでこれらのバグを修正します（そして、トランクにマージします）。すべてのバグが修正されると、QAが再テストするために新しいビルドが展開されます。特定のリリース候補にバグが見つからない場合にのみ、検証のために顧客に提供されます。 これには通常、リリースごとに約2〜3つの候補、約1週間かかります。通常、修正を記述する時間は、テスト作業よりもはるかに短いです。したがって、開発者を忙しくしておくために、彼らはリリースN + 1に取り組み、QAはNに取り組みます。 反復を使用しなくても、リリースNとN + 1の作業を重複させることができるため、これは問題になりません。しかし、私が理解していることから、これはスクラムやXPのような反復ベースのアプローチと互換性がありません。彼らは、すべてのテスト作業がイテレーションに組み込まれ、イテレーションが最後にリリース可能であることを要求します。 これは必然的に次の望ましくない結果のいずれかにつながることがわかります。 （A） QAはリリース候補を確認する時間が必要であり、バグ修正作業が開発者を完全に忙しくしていないため、開発者はイテレーションの終わりにアイドル状態です。 （B）最初のリリース候補の準備が整う前に、QAがすでに機能し始めています。これは、Stack Exchangeで最も推奨されるものです。しかし、テストされた特定のリリース候補がないため、それは私の会社がQAとして理解しているものではありません。そして、すべてを壊す「小さな変化」は、気付かれずに導入される可能性があります。 （C）バグは次の反復に引き継がれます。これはStack Exchangeでも推奨されます。私はそれがまったく解決策だとは思わない。基本的に、バグ修正が行われるたびに、新しい未検証のコミットが同じブランチに追加されるため、検証済みビルドが取得されないことを意味します。 このジレンマから抜け出す方法はありますか？

17 agile  teamwork  qa  sdlc 

次のような「最小限のシステム要件」で出荷されるソフトウェアの例は数多く見られます。 Windows XP / Vista / 7 1GB RAM 200 MBストレージ これらは一般的にどのように決定されますか？明らかに特定の制約がある場合があります（プログラムがディスク上で200 MBを使用する場合、それは厳しい要件です）。これらの状況とは別に、RAMやプロセッサなどの場合は、多くの場合、ハードな制約なしで、より高速で高速であることがわかります。これらはどのように決定されますか？開発者は、合理的と思われる数字を作成するだけですか QAは、許容可能なパフォーマンスを備えた最も低い設定を見つけるまで、さまざまな要件をテストする厳密なプロセスを実行しますか？私の本能は、後者でなければならないが、実際にはしばしば前者であると言います。

17 documentation  requirements  qa 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ソニーは最近、SQLインジェクションでハッキングされ、ユーザーのパスワードはプレーンテキストで保存されました。これらは新人の間違いです。そのような大企業では、これはQAにどのように合格しますか？これよりもよく知るよりも良いチームがいないのはどうしてですか？ ハッキングされた会社の規模の大きさにより、これは異なります。私たち全員が、いつかこのようなことを担当するチームに自分自身を見つけるかもしれないので、私たち全員に影響を及ぼします。それで、これにつながる要因は何ですか、どのようにそれらを防ぐのですか？

15 security  qa  mistakes 

更新/明確化私のクライアントは社内テストの必要性を理解しており、彼らは常に「より良い」（つまり何かをする）ことを誓いますが、それは起こりません。彼らは外部テストのための予算を持っていません。「テストを早く、頻繁にテストし、ターゲットマシンのエトスでテストできるのは何なのか」と質問しているのでしょうか（漠然と認めていますが）。 質問：実稼働プロジェクトで「そのままテスト」するのではなく、新しいリリースの問題を明示的にテストして報告する時間をユーザーに促す方法。 背景：私には、マルチメディアプレゼンテーションツールのスイートを作成した小規模のクライアントがいます。彼らは素晴らしいクライアントであり、私たちは良い関係を持っています。このプロジェクトは進行中であり、機能を追加しています。 私には2つの問題があります。 機能の定義はオンザフライで行われ、多くの場合電話で行われ、変更、修正、逆転の対象となります。（ケネディの「月に行って他のことをする」みたいなものです。私はいつもその「他のこと」の部分に面白がっています） 実質的にQAテストは行われません。 私は＃1に多かれ少なかれ対処できます。これは、会議の前に仕様書を読むだけでなく、仕様書を書き上げるクライアントでさえありません。慣れてます。私が問題を抱えているのはアイテム＃2です。彼らは新しいリリースをテストしないか、テストしません。彼らがしているのは、それらを本番用に使用して、バグが発生したときに回避策を見つけて報告しないようにするか、プロジェクトに取り掛かるのが急いで、バグ報告が曖昧になるようにすることです。 私たちはこれについて多くの議論をしましたが、私はそれらを少しだけ調整することができました（たとえば、問題追跡にgithubを使用していますが、ほとんど使用しています）。根本的な理由は2つあります。彼らは小さなコンサルティング会社であり、テストのためのリソースを持っていません（または、外部委託する予算もありません）。そして文化的：彼らは自分たちを「開発者」と考えていますが、彼らは本当にマルチメディアソフトウェアパッケージのユーザーにすぎません。（例えば、彼らは「本物の」開発者の詳細に対する強迫神経症の注意をまったく持たない）。 これはあなたが期待するように私に影響を与えます：フィードバックなしでは、機能が完全かどうか（＃1を参照）または他の結果があるかどうかわかりません。また、私は少し怠け者になっています。

14 client-relations  qa 

自動受け入れテストでユーザーストーリーを100％網羅したBDDを使用してプロジェクトを実行する場合、テスター/品質保証担当者の役割は何ですか？ 開発者が受け入れテストを製品所有者と一緒に書くことを想像していると思いますが、それが馬鹿げた仮定のように思えたら教えてください。

13 testing  team  qa  bdd  acceptance-testing 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 そうだと思います。どうして？ 私は、QAエンジニアよりも優れていると信じている多くのソフトウェアエンジニアに出会いました。しばらくQAエンジニアの仕事をし、それが独自で価値のあるスキルセットであることに気付くと、この信念を癒すのに役立つと思います。 ソフトウェアエンジニアが自分のプログラムをテストする能力が高ければ高いほど、ソフトウェア開発ライフサイクルの残りの部分でコードを作成する際に発生する時間のコストが少なくなります。 ソフトウェアエンジニアがプログラムがどのように壊れるかを考える時間を長くすればするほど、これらのケースを開発中に考慮する頻度が高くなり、最終製品のバグが減少します。 ソフトウェアエンジニアの「完全な」定義は常に興味深いものです。QAエンジニアとして時間を費やしている場合、この定義はソフトウェアの設計者により密接に一致する可能性があります。 誰かが雇われているポジションではないポジションで働くことは間違いなくその開発者を失うためのレシピであると認識しているので、私は小さな時間枠を念頭に置いて上記の提案をします。 皆さんはどう思いますか？

12 code-quality  skills  qa 

私は、QA組織としてのテスト効率の測定に関する経営陣との議論に参加しようとしています。この背後にある主な理由は、私たちのチームの半分が外注されており、私たちのビジネスは私たちがどれほど効果的/効率的であるかのいくつかのメトリックを提供したいので、私たちは請負業者のサービス契約と契約パラメータを交渉するための基礎データを持っている。 このテーマについて私が見つけた意見のほとんどは、開発者の効率性に関するものです。コードの行、配信されたストーリーポイント、導入された欠陥などです。 しかし、テスターはどうですか？テストは主に要件ベースで、手動、半自動、自動のテストが混在しています（すべてを自動化していないためではなく、テストシステムで自動化できないものがあるためです）。

11 testing  efficiency  qa  metrics