ソフトウェア品質保証上まず、経験
1、ソフトウェアの良いか悪い品質の定義：ソフトウェアの品質が良いか悪いかは、主にユーザーのニーズを満たすかどうかを指します。そのため、「顧客」に焦点を当てたソフトウェア品質保証は、コアです。コード位相：顧客の需要がある場合は、テストソフトウェアを満たしていないバグ：上の顧客のニーズを満たすために、テスト・フェーズに基づいて、最高度のリスクとコストを削減するために：、顧客のニーズを達成するためにコードを書くソフトウェアのステージを開発します。
2、ソフトウェア品質保証の一般的な概念：品質保証ソフトウェアは、ソフトウェア品質の予備手続きコードの品質、ソフトウェア工学、ソフトウェアテスト、ソフトウェアの品質と後で、小型で複雑な多くの側面を維持し、多くの側面が含まれては、良いか悪いかを構成します決定的な要因。そのため、単独のソフトウェアの品質テストは、リスク管理、コスト管理、内部ソフトウェア品質メトリクスの完了のためのソフトウェア開発プロセスへのインデックスの最初の包括的にカバーするためのプログラムコードの精度から独立していません最終的ソフトウェアテストに、ソフトウェアの品質は、それが並行して相互に包括的として、各ステップそれらはステップによって保証されていることはあまりありません。
3、コンクリートは、ソフトウェア品質保証部門を手順：
まず、ソフトウェアプログラム= +ソフトウェア工学
利用可能なソフトウェアプログラムの品質+品質=品質ソフトウェアエンジニアリング
（1）プログラムの品質を保証：異なるソフトウェアの異なるニーズの複合指標多次元特性によって測定されるように総合指数は同じではありません。
（2）品質工学ソフトウェアアシュアランス：CMMIの実装
あなたがQAプロジェクトであれば第二に、あなたはあなたの仕事の責任はどう思いますか
-
プロジェクトのソフトウェア品質保証の作業を行うための責任1.会社。
-
2.より多くの開発者とプロジェクトのリアルタイムの理解のプロセスが通信し、交流します。
-
3.プロジェクトの品質保証プログラム、計画、定期報告書プロジェクトの状況として、QA活動の実施を開発。
-
4.製品の納入は、安定性と信頼性であることを確認するための活動の信頼性を促進するためのプロジェクトの開発プロセスを実施します。
-
5.監視する製品および監督を修正するプロセスは、プロセス制御、品質及び信頼性を変更確保します。
-
上記抽出手順から6.継続的改善のプロセスを促進するために必要な活動を改善しました。
-
7.参加内部監査は、ポイントシステムの改善、及びモニタープロジェクト品質テスターは一緒に見出さ。
-
8.ドキュメントを書いて、ソフトウェアテストに関与します。
あなたがプロジェクトマネージャー、フルタイムQAであれば第三に、あなたのプロジェクトのニーズをあなたと思いますか？それとも、ただのテストを持つことができますか？問題は、あなたがどう定義するか発生した場合、誰が責任を負うのですか？
1、QAとテストの違いとの接続に関するすべての話の最初の。
試験：特定のプロセスおよびツールを使用すると、ソフトウェアは、検証機能を可能にし、特に規定機能仕様（スペック）ワークプロセスと結果と一致する行動規範は、通常、定量化可能であることを確認するために、事前に設計された機能します。
QA：ソフトウェア工学のすべての段階で目標を達成するためのチームを助けることができるソフトウェア品質のソフトウェアを確実にするための様々な手段を使用し、ソフトウェアチームは、ソフトウェアが事前に定義されているとテストを含め、行わ品質基準を満たすことを可能にするすべての活動があります。
この定義の下では、テストは、実際にQAの適切なサブセットであると言うことができます。
QAのための2、：
私はフルタイムのQAは非常に必要だと思います
QAは全体ソフトウェアエンジニアリングの品質保証で、製品全体を通してQA要件は（またはプロジェクト）全体のプロセス、監督のプロセス全体、プロジェクト検査の現在の進捗状況を、持っていただけでなく、検証機関、組織プロセス定義、リスク管理を完了するために、およびその他の関連プロセス。各プロセスが完了すると、仕上げ作業の段階、この管理定量的、成功と失敗の後に、それ以降の製品の品質を向上させるために、知識の同じ時間の蓄積で、その理由を分析する必要があります。だから、ソフトウェアの一部のQA品質保証が不可欠です。
テスト3：
私はフルタイムのテストを設定する必要はないと思います
、フルタイムのテストを設定する必要がない場合には（1）QAテストおよびQAとして含まれます
（2）の存在について話誤解テストである：テストすべての規制のテスト作業はプロジェクト全体の終わりに行きました。このような場合には実際には、後半のプロジェクトで問題を発見した際に、根本的な原因は、この時点では、多くの場合、早期に決定し、プロジェクトの設計の一部で、その後、より困難修正し、十分ではありません。実際には、これは積極的にソースからの問題を回避するために介入を開始しますプロジェクトからテスターが必要です。その結果、私はそれがソフトウェア工学（コーディングプログラム）の初期段階にあるか、ソフトウェアの設計プロセスの後半では、テストの監視が不可欠であるかどうかのテストは、独立していない仕事と感じています。あなたは全体の時に遅れて修理物事を修正するために予め取り付けられうちの脆弱性STAGEを避けたいのであれば、テストからプロセスの開始時に終了するプロセスに関連しています。もしそうなら、それは開発者がこの作業の開始時ほど良好ではありません。テストは、プロジェクト全体で監視する必要がありますので、だからそれは、第一の理由です。
（3）第三个原因就是参考资料主要谈论的问题，“不懂开发的人必然做不好测试”。因为没有人比开发人员更了解整个软件工程，在发现漏洞的时候也没有人比开发人员更快的找出问题所在，并找到解决的办法.
（4）第四个原因就是，书上质量保障这一章提到的：出现问题之后，开发人员和Test人员之间责任的推诿，和分工明确会造成画地为牢导致的局部最优和全局未必最优的情况。
4、出现问题之后责任的界定
首先作为项目经理，没有及时发现问题，很大一部分责任在我。我会反思自己在整个工程期间的工作，是因为自己没发现潜在问题还是出现了本不该出现的问题，若是前者，我会承担自己作为项目经理未做好本职工作的责任，若是后者，我会具体情况具体对待，细化究竟是哪个进程出现的问题即由哪个进程的负责人和我一起担责任。我觉得项目出现问题不会一个人的主要责任，同负责一个项目，应该一起面对所有的问题。