アジャイル開発・品質管理

まず、品質管理

1.1品質管理とは何ですか

次のように用語の解釈をBaiduの：

品質管理は、品質方針、目標と責任を決定することで、品質計画、管理、保証や改善活動の品質システムによってそれをすべて達成します。
最も経済的なレベルでのことができるようにと考慮しては、完全な品質を維持し、活動の質を向上させ、市場調査、設計、製造及び顧客の要求の条件の下で、アフターサービス、企業内の様々な部門の品質の開発を満たすためにAの一つとして構成します効果的なシステムの一種。
品質管理は、「活動の調整の質の面での指揮統制組織」です。

1.2品質マネジメント革命

品質管理における最初の革命は、専用のQC部門を確立することです。
第二の革命は、専用のQA部門の設立です。
第三の革命は、すべての部門（生産、購買、物流、マーケティング、など）内のすべてのQA作業に伝送されます。
第四の革命は、専用の品質部門を排除することで、またはこれは管理4.0の品質であること。

1.3品質マネジメント4.0品質部門の撲滅

伝統的な品質管理QAは、4つの異なるクラス（弁護士、警察、医師、教師）と3つのコア業務（監査、追跡、要約）を持っていますが、経営の質を4.0に変更乳母からQAスタッフの役割が懸念から、コーチを変更しました製品の品質は、プロセスの品質に焦点を当てます。これは良い生成しますサイクル：

QAスタッフは、もはや直接、製品の品質の問題を解決するに関与していない場合には、開発部門は、論理的に言えば、そのような役割を担うためのイニシアチブを取る、開発者がより良い人事問題の品質よりも知っている必要があります。
リード開発者は、最適化のプロセス（QAの役割）に焦点を当て始めるときや、品質のQA部門は、焦点品質マネジメントシステムのフレームワーク上でデザインは、さまざまなシステムを統合する必要が合理的であるとQMの役割にアップグレードすることができます。

ミッションは、人事部門の品質の品質を破壊することである、パラドックスのようですが、実際の結果はこれです。

品質管理は、制作スタッフによって行われた場合、ビジネス・プロセスの最適化は尊敬品質の人々はこれを明確に認識している必要があり、最後に来ていること、様々な機能部門、品質部門の責任です。

第二に、アジャイル開発・品質管理

アジャイル開発のために、この議論ではないが、1つの追加のシェアがあります

まず、アジャイルや滝の開発、品質のR＆Dチームが懸念されるかどうかを理解する必要性、品質管理を行うこともあります。チームの品質を心配されていない誰もが、長期的な発展に方法はありません。

リレーションシップ2.1アジャイル開発と品質管理

アジャイル開発のフォーカスアジャイル、変化に対する迅速な対応、インターネットの発展の影響を減らします。
品質上の品質管理の焦点は、製品の品質を確保し、長期的な利益をもたらします。

どちらの表面には何の関係もないように見えますが、実際には両者の間に補完関係です。品質管理は、アジャイルアジャイル開発、文化的な伝送の品質管理のために提供するために、アジャイル開発のための基盤を提供します。どのように理解するには？

アジャイル迅速な対応に開発の焦点が、長期的な敏捷性は本当の機敏です！

前方バルクヘッド反復を素早くスプリントを達成するためにした場合、一定期間の後に、あなたは、ボトルネックの多くを見つけるでしょう。たとえば：システムアーキテクチャの新しいタイプは、システムのニーズの再構築のニーズをサポートしていません。迅速な対応のために、オンラインの反復は、ユニットテストの開発を無視して、テストカバレッジ、ラインの問題の多くを無視します。品質管理は、早送り、長期的に行うために、アジャイル開発のためのアジャイル開発を基盤を提供することです。
重心の2品質管理が考えられている品質がすべてに関心事項となり、品質部門を破壊します。

アジャイル開発は、誰もが参加するために必要である、誰もが品質管理のアイデアを実装するために、アジャイル開発が招集されますが、確かに良い方法ではありません

2.2アジャイル品質管理を行う方法

上記の品質管理4.0の時代が始まった、4.0と組み合わせアジャイル開発と品質管理することの必要性
私は考えるとき、ここで終了する前にポイント「上限の品質、品質の下限を」「テストは、左」

アジャイル開発は、「道路」と「車」、品質管理として見た場合、チームは「先に駆動するために、」物事を行うことです

識別し、最小質量を遵守し
、物事は長い下限の品質などとして行わどのように悪いに関係なく、製品が適格であると考えることができる品質の制限手段を定義します。
アジャイル開発は、応答効率が向上し、許容可能な品質を保証する高速応答の質の下限に基づいて遵守と組み合わされます。限り「道」存在として、「車」まで実行することができます。
質量の上限を挑戦し続けて
製品を作るためのより良い方法で、より良い品質の出力ラインの品質上の課題を
一緒にアジャイル開発と組み合わせるには、「アスファルト」に「石の道」としての品質制限を改善して、高道」にすることです車はスポーツカー「「に置き換えることができます」「そうという」こんなに早く、より機敏になるために。
品質管理は、開発アジャイルの負担にならない
ように、特定の適切な「道」を提供する「車を。」チームのエネルギーが限定されている「道」に完全に集中するならば、彼は、「高速道路」を修復するために必要がない場合、それは「ドライブ」も「道」、「車」または「アルト」することが必要です逆に、「ドライブ」への努力がない、すべての後に、「宛先に到達するために車は」キーです
アジャイル品質管理に関与するすべての人々のチーム
「車」と「ロード」それをすべて持っていますが、「目的地」にオープン「車両」はまだ早い、「ピットロード」注意してください！
アジャイル開発は、高速なツールを提供し、それが唯一のツールすべての後に、本当の目標は、プロセスの完了に注意することもありますさ。

人員配置の品質で2.3アジャイル開発の役割

従来の品質管理の役割（QC、QAとQM）

品質管理4.0の究極の目標によると、「品質部門を破壊し、」もはやスタッフの必要な品質ではありません。

QMは、QAは、この段階でのQC担当者が非常に重要と言うにも欠かせないままように、しかし、この究極の目標を達成するためには予備的な作業の多くの必要性は、彼らが「自分自身を破壊する」に向かう必要があり、闘争を続け

アジャイル品質システムの確立にQMポストは、私たちは本当に経営の質、アジャイル開発、品質のアーキテクチャの定義を理解する必要があります。QMは、（すべてのレベルでボス、ディレクター、スーパーバイザを含む）組織に、必要に応じて拡張することができます
品質文化の普及による質量の上限は、同じ理由で、QA担当者、継続的な改善と持参のチームのために他の方法との回線の品質を上昇。
提供するために、チームのための機能試験、探索的テスト、および他の方法によっても、QCのスタッフ品質の制限を

実際には、図の役割に比べアジャイル開発における人材の役割の品質は、半歩です。QA QCの必要性は、完全な組織へのQM部門を基礎を知るためにいくつかの仕事、QA QMの必要性をすることができません。最も基本的なQCテストは、排除されるので、アジャイル開発という

あなたは伝統的なQCの位置に釘を所有している場合は、基本的に死にました。
あなた自身QAを見詰める場合は、品質の明確な理解を持っているので、あなたは、思考の独自の方法でシステムをアップグレードすることができます。
あなたがQMに自分自身を設定する場合は、品質システムの主催者になります

第三に、アジャイル開発＆QA

3.1アジャイル開発＆QA

アジャイル開発は、ソフトウェア製品の品質ではなく、QAのタイトルを持つ特定の人を担当するチームが必要です。アジャイルQAチームがアジャイル開発に関わるすべての関係者、必ずしも特定のフルタイムのテスターことができます。イニシアチブを担当する一切のチームの担当者は、まだこの役割にリードを取るために誰かを必要としないときには、担当の試験者は、最も適した候補です。

だから、QAスタッフはアジャイル開発で何を行うことができますか？

共同は、品質の限界を決定します

アジャイルプロセスが判断するのに役立ちます
どのプロセス、ほんの少しの利益の多くの部分顔通信に顔を行く存在しないことを意味するものではありませんアジャイル開発を、時間の不必要な廃棄物の量を減らします。QAが行われるように保持された、全体のアジャイルプロセスの開発に参加し、必要なリンクを識別するためにされる必要があり、品質保証プロセス
標準出力のさまざまな側面決定を支援します
（1）アジャイル開発研究開発の面に流れ込む製品の品質へのリンクを確保するために一定の基準を持っている製品は、スタッフのMRDの文書を取り除くために引き起こしますが、PRDの文書が出力またはPRDのために不可欠であること
（2）アジャイル開発は、開発者がより良い時間をテスト統合における適切な削減を達成するために、セルフテストフォームに開発を可能にすることにより測定された品質の言及を改善するために、コードを理解しているため目的は、TDD、BDDや他の開発モデルを提唱しています。標準速度の開発を通じて、リンクの開発を確保するために品質検査リンクの流入部のテストカバレッジを介して、
製品の最終的な保護者（3）テスター、品質は、ユーザ指向の前の最後の防衛線であるだけでなく、厳しい準を有します認定製品の標準を満たしています。
（4）デプロイヤとして運用、保守担当者は、あなたが棚を実行する必要があり、データベース・システムのカットオーバーパッケージなどの事項に直接配置サーバー指向の問題は、標準のライン上に展開する必要が少ないミスが発生しています

品質保証の制限

すべての後に、まだの遵守を監視する必要があるいくつかの基準については、人々は常に怠惰のように、監督期間なしで、誰も意識し、コンプライアンスを作るための方法はありません。その誰もが徐々に習慣を開発することができますので、品質のQAチームは、下限値の遵守を監督するように、
必要なQAは、品質改善作用を達成するために、右のコースにチームを導くためにアジャイルプロセスのあらゆる側面に参加し、スクラムマスタの役割として動作する必要がある場合

それはリスクが主要な勧告を提示ことがわかりました

QAは、システム全体を理解し、把握するために、開発プロセス全体関与する最も包括的なチームの内部であると言うことができます。潜在的なリスクのすべての側面を検出することも容易には存在し、昇給の懸念に引き続き
計画の製品、開発、テスト、運用、保守の面のための開発プロセス全体関与、人材の質は、いくつかの批判的なコメントを作るためにユニークな視点を立っていました

品質の限界に挑戦を奨励品質文化の普及

QAは、必ずしもこれらの交換のスプレッド品質文化の中で絶えずに人事交流のあらゆる側面、QAの必要性と通信する必要があり、開発プロセス全体関与しました
同時にQAのニーズは品質の文化を広めるだけでなく、チームメンバーを奨励回線の品質に挑戦。

統計、継続的な改善

統計によると、これはQAスキルを習得する必要があります。積極的に統計的なオブジェクトは、さまざまな統計データで分析しアジャイル開発を見つけ、製品などに追求するために、
継続的な改善、開発プロセスに参加する、統計の問題は、継続的な改善のための組織を発見し、全体的な品質を向上させます

何が必要な資質3.2アジャイルQA、

とても静かな？迅速なQAをしないでください
、あなたがソフトウェアの欠陥モードに集中する前に見て静かにしている場合は、アジャイルチームを入力してくださいあなたは適していない長い時間が発生する可能性があり、。QAは、受動的に手を完了するために、ソフトウェアのを待つことができない俊敏なので関わらず、欠陥が自発的に修理に開発者を待っている見つけることができないかどうかのテストを行うことを見つけます。あなたは、ソフトウェアのライフサイクル全体を通じてソースソフトウェアの介入、完全な参加から開始する必要があります。
悪い態度？可能な限り早期に放棄する
あなたは、このような場面を経験している場合は重症例では、いくつかのビットの小さなレストランは、あなたがそのようなスペースのエッジとして、食事客の終わり近くに立つ必要がある、知っていない、と一部の人は、食事の終了後、次を無視することができます心配そうに待っている観客は席が熱心にチャット占拠しています。この動作は非常に良いではありませんが、それは、フリップ側は理解できるが、非常に少数の人々は他の人と、独自の方法を検討することを拒否することができますので、この人の心理は、非常に強力であり、この「能力」アジャイルQAは非常に便利です。
あなたは常に他の人がどう思うか心配し、あなたが一目権をし、左の場合は、それを考えた後、直接あなたの判断や意思決定に影響を与えます。
PM、ビジネス、コード、建築に興味を持っていませんか？アジャイルQAはあなたのためではありません
QAは、QAの観点から、不足している一部または不当なビジネスを見つけましたので、ヘルプビジネスアナリストとチームへと、ビジネスとシステム全体と馴染み、十分なニーズアジャイル。
あなたがアジャイルQAを行うには、いくつかのコーディング能力を持つことができる場合にも、それはまた、非常に便利です。もちろん、手術に特化した業界は、各QAコードを記述することを必要としませんが、コードが開発者に聞いて喜んでいくつかの興味、である必要があり、そのロジックを説明し、実現し、質問をすることで自分の考えを理解しています。
優先順位は仕事に管理していませんか？QAは、アジャイル行うことは困難である
アジャイルQAが最大の課題である、同時に多くのことに取り組んですべての時間は、多くの人と通信するために、開発プロセスのニーズのQA完全参加アジャイル、常にリスクに注意を払う、というように。自分のタスクを管理し、優先順位付けが不可欠な資質であります

第四に、アジャイル開発＆テスト

アジャイル開発とテストの間の関係、敏捷性テストを言及する必要があり、
読解の敏捷性テストでは、お勧めしますあなたはあなたがアジャイルテストが何であるかを知っている作ること

4.1アジャイルテスト＆テスト

テストのテスターがする必要がどのようなアジャイル？
ユーザーニーズの分析、エージェントPO（プロダクトオーナー）
アジャイル開発PO大きな責任ではなく、プロキシPOヘルプ補足製品の担当者、洗練された需要として機能するように忙しいPO、不足している時、アジャイルのテスター必要があるでしょうそして、ユーザーストーリーを向上させます。
テスターオブジェクト指向の製品は、実際の製品の品質は、ニーズを理解するための最も重要であることを確認します。

筆記テストケースがあり、テスト要件（品質の定義）だけでなく
だけでなく、テストアジャイル書き込みテストケースに必要な、あなたはまた、テストポイントに製品需要点に基づいて製品の要件、にテスト要件に応じて、製品需要を完全に理解するかどうかをテストする必要があります。
テスト要件管理のために、研究開発が角度のニーズをテスト変換するだけでなく、ビジネス要件を明確にする助けを立って、より深い理解を持っている開発者は、他のニーズのためのテスターを可能にします。
同時にテスト変換ニーズではなく、品質の定義について。テスト要件に追加しなければならないプロセスにテスト要件では、品質の需要がまあのような定義ではありません

品質の視点を維持するために、評価プロセスに参加するために
、開発プロセスアジャイルは、このようなニーズアセスメント、設計レビュー、そして上のようにレビューのいくつかの重要な側面があるでしょう。アジャイルのテスターは、これらの分野に参加するが、需要が予測不可能のデザインかどうか、およびその上で、明確ではないか、不完全なアウトライン設計あれば、このような要求のループかどうかなどの開発問題の品質の視点を維持するのと同じように。

顧客と開発者と緊密に協力
第二位のチームは、テスターは、顧客（事業）との定期的または頻繁コミュニケーションと協力を必要とする、ほとんどの人が知っている必要がありますように、仕事の性質に応じて、および二次コンバータの需要、あなたもの開発を追跡する必要があります誰が密接に協力しています。
コミュニケーションのチャンネルを利用するデモ（UATの受け入れ）と他のセクター、顧客とのletテスター通信チャネルの連携（ビジネス）の設立を、リリース、直接通信は、あなたがより良く理解求めることを可能にする
、アセスメントテスト要件を開発プロセスの必要性これらの問題は、問題が迅速かつ簡単な位置決めになっ議論する需要を作るために緊密に協力し、テスターと開発者に必要

迅速なフィードバックの提供
アジャイル開発することは、テスターのための迅速なコミュニケーションとフィードバックが同じである提唱しています。高速な図ああとの取引を行うために、迅速なフィードバックシステムの問題、。
例えば、重要度スモークテストのために、システムは高速で実行できることを確認し、テストを避けるために、時間の無駄にすることはできません。より詳細なテスト要件に応じて、できるだけ早く補足抜けが存在することを確認するための簡単なチェックを開発、テストの問題に遭遇し、迅速なフィードバック解決;警告保守要員にテスト進捗高速フィードバックが早いというように介入する準備ができて

テスト仕様書にテスト戦略と
アジャイル位置決め要員の品質の現像ロール、テスト担当者のためのフロント確保する下限の品質。どのようなアプローチ下限の品質を確保するためにテスターを許可する、人材の質が重要な要素ですが、あなたはすべてのテスターの品質を保証することはできませんが、すぐにアップグレードすることができ、この時間は、テストプロセスを標準化し、最も基本的な保護です。
テスト戦略は大きな問題である、より詳細な説明については、テスト戦略Liuchenメイ先生の「建築家のロードテストの実践」を読んでお勧め私はこの本のためにも行ってきた読書共有を

テスターやアナリスト役割融合
敏捷性テストはテスターテスターやアナリストとの統合を必要とするが、需要のビューの合理的なポイントの試練に耐え、テスタビリティ解析システムは、テスト角が立っていました。
問題を解剖することに慣れアナリスト、およびテスターは、問題について「重要」のビジョンをもたらすでしょう、両者の統合は剖検問題が内在する「欠陥」うーんを見つけたということではありません

マスター探索的テスト（適切な探索的テスト）
最初の必要性は、システムなどの境界に、境界、ロジック、境界デプロイメント環境を探求し続けるシステムのロジックに従って、機能テストが完了した後に理解するために探索的試験、探索的テストを簡単に理解します、より多くの問題を発見します。
適した探索的試験、探索的テストは全く通常のブラインドテストではないではありません、それはまた、これを述べた同じ規則の条件Liuchenメイ先生の「テストアーキテクトの道の実践」を必要とします。
探索的テストに落ちてはいけない、あなたの根底にある基本的な機能はまだ完全なテストを模索していきましたではありません、それはどんな意味がありません

テストの自動化された回帰
アジャイル開発の効率を向上させることにある、とテスターのために同じことが、効率を向上させるために必要な、ハイボリューム・オートメーションの古い需要の古いバージョンに戻り、すぐに多くの時間を節約しますが、新機能のために使用することができ、新たな要件探索的テストはまだ？しかし、同じ重点は効率にある自動テストのアジャイル開発を覚えています。
UIオートメーションのために、それは自動化メンテナンスUIを助けることができる、POモードは確かに良い選択である共通仕様のIDを開発するために、IDの標準化とフロントページ要素で推奨される
UIに関しては、インターフェースがより適切である可能性があります自動化は、同じパターンは、メンテナンスコストを削減し、PO管理UIを学ぶことができます

BDD（トピックオフ）
多くの企業が書き込みコードにユニットテストを書くために、TDD開発モデルをご紹介します。TDDの場合には、あなたがBDDを入力し続けることができない場合は、ビジネスのニーズのための白いボックスは、より多くの可能性が高い問題を見つけるために、ブラックボックスよりかもしれすべての後に、問題が可能性が高い直接発見し、システム全体を呼び出すよりも、内部関数を呼び出すことです。

参考1 https://www.sohu.com/a/128624542_177747
リファレンス2 https://wenku.baidu.com/view/b9080553ed630b1c58eeb564.html
リファレンス3 https://www.cnblogs.com/mikeyond/archive/2011/ 6月30日/ 2094274.html
参照4 https://segmentfault.com/a/1190000019268535
参照5 https://www.jianshu.com/p/d5496e5247c7