メニュー

ソフトウェアテストドキュメントガイド（なぜそれが重要なのか）

software testing documentation guide

問題を排除するために楽器を試してください

私のソフトウェアテストのキャリアでは、ソフトウェアテストのドキュメントについて多くの人が話しているのを聞いたことがありません。ドキュメントのテストに関する一般的な意見は、自由な時間がある人なら誰でも、テストケース、テスト計画、ステータスレポート、バグレポート、プロジェクト提案などのドキュメントを作成できるというものです。

ドキュメントについてはあまり強調しませんでしたが、すべてのデータを白黒で配置し、他のデータも更新するのが私の習慣だと言えます。

ソフトウェアテストドキュメントガイド（なぜそれ

アルファテストとベータテストとは

学習内容：

私の経験

私の経験をあなたと共有したいだけです：

私たちは、クライアントの1人（怒っているクライアント）にプロジェクト（その問題は不明）を提供しました。そして、彼らはクライアント側で問題を発見しました。これは私たちにとって非常に悪い状況であり、いつものように、すべての責任はQAにありました。

問題は、1つのWebサイトの互換性に関するものでした。私の場合、ウェブサイトの互換性も確認する必要があるという要件文書を入手できなかったという証拠がありました。私は無事だった神に感謝します。

それが私にとっての教訓でした。ドキュメントの重要性に気づき、その日からドキュメントの作成を開始し、テスト計画、テストケース、健全性テストのチェックリスト、バグレポートなどのテストドキュメントを作成しました。

「インクは最高の記憶よりも優れている」–中国のことわざ

テストドキュメント：それは何ですか？

私たちは皆、テスト技術と方法に関するさまざまな記事を読んでいますが、ドキュメントに関する記事を見た人はどれくらいいますか？間違いなく少ないですが、書類は重要ではないのでしょうか？いいえ、しかしそれは、ドキュメントの重要性をまだ認識していないためです。

しかし、私たちが観察すると、事実は、 すべてのドキュメントを含むプロジェクトは、成熟度が高くなっています。

ほとんどの企業は、ソフトウェア開発プロセスに与えるほど、ドキュメントを少しでも重要視していません。 Webで検索すると、さまざまな種類のドキュメントを作成する方法に関するさまざまなテンプレートを見つけることができます。しかし、それらのうち実際に組織や個人によって使用されているものはいくつありますか？

事実は 注意深い文書化により、組織の時間、労力、および費用を節約できます。

あらゆる種類の認定を取得する際に、ドキュメントに重点が置かれる理由は、個人や組織にとってクライアントとプロセスの重要性を示しているからです。どんなに優れた製品であっても、ユーザーにとって快適なドキュメントを作成できなければ、誰もそれを受け入れることはできません。

私の経験では、機能が少しわかりにくい1つの製品を所有しています。

作業を始めたとき、マネージャーにヘルプドキュメントを頼んだところ、「いいえ、ドキュメントがありません」と答えました。それから、QAとして知っていたので、誰もその方法を理解できないので、それを問題にしました。ドキュメントやトレーニングなしで製品を使用してください。そして、ユーザーが満足していない場合、その製品からどのようにお金を稼ぐのでしょうか？

「文書の欠如が受け入れの問題になりつつある」– Wietse Venema

同じことがユーザーマニュアルにも当てはまります。 Microsoftを例にとると、適切なドキュメントを使用してすべての製品をリリースします。Office2007の場合でも、そのようなドキュメントは非常に説明的で、どのユーザーにとっても理解しやすいものです。これが、すべての製品が成功している理由の1つです。

中小企業では、提案文書に簡潔で表現力のある言葉がなく、組織の能力を示すために、「提案またはキックオフフェーズでプロジェクトが拒否される」と常に耳にしました。

セレンでの暗黙的な待機と明示的な待機

中小企業が質の高いプロジェクトを提供できないわけではありませんが、能力を表現できないのです。 （私も80人の従業員の小さな組織で働いています、そして私はこれを何度も聞きました）

個人的には、それを可能にするのは品質だけだと感じています。私たちはこれについて議論することができ、私たちの組織に成功する未来を提供することができる唯一の部門です。

すべてのディスカッションを品質の観点からいくつかのポイントにまとめましょう。

–品質目標と方法を明確にする
–タスクの明確さとパフォーマンスの一貫性を確保する
–クライアントの作業における内部調整を確実にする
–予防措置に関するフィードバックを提供する
–計画サイクルに関するフィードバックを提供する
–品質管理システムのパフォーマンスの客観的な証拠を作成します

テストドキュメントの目標を達成するための10のヒント

以前の投稿で述べたように、一般的に、ソフトウェアテストのドキュメントについて理解することは、「自由な時間がある人だけが行うことができる」ということです。この考え方を変える必要があります。そうすれば、プロジェクトでドキュメントの力を活用できるのは私たちだけです。

ドキュメントを正しく作成する方法がわからないわけではありません。それが重要だとは思わないだけです。

テスト戦略、テスト計画、テストケース、テストデータからバグレポートまで、あらゆる種類のドキュメントの標準テンプレートが必要です。

これらはいくつかの標準（CMMI、ISOなど）に従うだけですが、実際の実装に関しては、これらのドキュメントのうち実際に使用されているものはいくつありますか？品質プロセスを文書化標準および組織内の別のプロセスと同期させる必要があります。

あらゆる種類のドキュメントに従うのが最も簡単なこと プロジェクトのダイナミクス、ドメイン、目的、およびテクノロジーを理解しているキックオフフェーズからの人をプロジェクトに参加させることです。そして、これに関してQA担当者よりも優れている人は誰ですか（もちろん、これを行うためにテクニカルライターが存在しますが、テクニカルライターが存在しない中小企業の一般的なシナリオを考慮します）。

テストと文書化というこの目標を達成するには、いくつかの点に焦点を当てる必要があると思います。

テストドキュメントの目標を達成するのに役立つトップ10のヒントは次のとおりです。

＃1） QAとドキュメントが連携して機能するように、QAはプロジェクトの最初のフェーズに関与する必要があります。

＃二） QAによって定義されたプロセスは、技術者が従う必要があります。これは、非常に初期の段階でほとんどの欠陥を取り除くのに役立ちます。

＃3） 作成と維持のみ ソフトウェアテストテンプレート 十分ではありません、人々にそれらを使用するように強制します。

＃4） ドキュメントを作成して残すだけでなく、必要に応じて更新します。

＃5） 変更要件はプロジェクトの重要なフェーズであり、リストに追加することを忘れないでください。

＃6） すべてにバージョン管理を使用します。これにより、ドキュメントを簡単に管理および追跡できます。

＃ 7） すべての欠陥を文書化することにより、欠陥修復プロセスを容易にします。欠陥を文書化する際には、欠陥の明確な説明、手順の再現、影響を受ける領域、および作成者に関する詳細を必ず含めてください。

Javaで整数の配列をソートする方法

＃8） 自分の仕事を理解するために必要なものと、必要なときにいつでも利害関係者に提供する必要があるものを文書化するようにしてください。

＃9） ドキュメントには標準のテンプレートを使用してください。他のExcelシートテンプレートやドキュメントファイルテンプレートと同様に、すべてのドキュメントのニーズに対応します。

＃10） すべてのプロジェクト関連ドキュメントを1つの場所で共有し、すべてのチームメンバーが参照できるようにアクセスできるほか、必要に応じて更新することもできます。

手順を適用することで突然の結果が得られると言っているのではありません。この変更は1、2日で発生しないことはわかっていますが、少なくとも、これらの変更がゆっくりと発生し始めるように開始できます。

結局のところ、「ドキュメントにはドキュメントが必要です」。そうですね。

ソフトウェア開発とテストのライフサイクルで使用されるドキュメントは何百もあります。

重要なソフトウェアテストドキュメント

ここに、定期的に使用/維持する必要のあるいくつかの重要なソフトウェアテストドキュメントをリストします。

1）テスト計画
2）テスト設計と テストケース仕様
3）テスト戦略
4）テストサマリーレポート
5） ウィークリーステータスレポート
6）ユーザードキュメント/マニュアル
7）ユーザー受け入れレポート
8） リスクアセスメント
9）テストログ
10） バグレポート
十一） テストデータ
12）テスト分析

また、ソフトウェアテスターは定期的に次のドキュメントを参照する必要があります。
1） ソフトウェア要件仕様
2）機能文書

結論

ソフトウェアテストドキュメントは、プロジェクトの開発/テストフェーズで常に重要な役割を果たします。したがって、可能な限り常に文書化してください。口頭でのコミュニケーションに頼らないでください。常に安全を確保してください。

ドキュメントは、あなたを救うだけでなく、長期的には、トレーニング、さらに重要なことに、開発およびテストドキュメントの不足によって引き起こされた問題の修正に数千ドルを節約するのに役立ちます。

指さしを避けるためだけに文書化しないでください。ただし、文書化の習慣は確かにテストプロセスに体系的なアプローチをもたらし、アドホックテストを残します。

著者について： この記事はSTHチームメンバーによって書かれました テジャスウィニ。彼女は組織のQAマネージャーとして働いています。

毎日のテスト活動で他にどのような文書を維持していますか？

推奨読書

^