誰かをテストに参加させるにはどうすればよいでしょうか?
-
25-09-2019 - |
質問
わかりました。当社の製品は機能します。ベータテスターは実際に作業を進めています。次の反復の時間です。しかし、品質を確保するにはどうすればよいでしょうか?テスターが必要です!
路上から出てきたばかりの人にテストを始めてもらうにはどうすればよいですか?自分でそれを行う方法がわかりません (私は開発者であり、テスターではありません)。
私たちは小さなチームです:
- 2 人のアーキテクト (ソフトウェアではなく建物の専門家です) を理解する 何 構築する
- 私がそれを作っています
- そして、リリースをプッシュする前にいくつかのテストを行う新しい人
これを専門的に行う方法については誰も知りません。これまでのところ、次のことができます。
- テストしたい構成にわたる多数の仮想マシン
- さまざまなバージョンの Windows
- ドイツ語と英語、お客様が使用する可能性が高い 2 つの言語
- 私たちが作成しているホスト ソフトウェア (Autodesk Revit Architecture 2010、エネルギー計算用のプラグインを構築しています)
- 私が行ったいくつかのテスト (リリース xyz のインストール、これを行った、あれを行ったなど) を説明したテキスト ドキュメント
- テスターが見つけたすべてのバグを追加できるバグ追跡システム
テストスクリプトが必要になると思います。しかし、どうやって?誰が?何?いつ?
解決
なぜ「通りから離れた人」を探しているのですか?私にとって、それは「新しいプログラマーを雇いたいのですが、どうすればその人を外に連れてきて、私のソフトウェアのプログラミングを早くできるようにするにはどうすればよいでしょうか?」と尋ねているようなものに聞こえます。すでにプログラマーである人を雇わずに、なぜそのようなことをしたいのですか?
テストについてあまり知らないというあなたの状況では、私ならこうします。 絶対に その分野での経験のある人を雇用することを考えてください。
具体的には、おそらく次のようなものを探すと思います。
- テストを実行した経験のある人 (実際にテストを実行してもらいたいため)。
- テスト計画などを作成した経験のある人。
- QA チームを運営した経験のある人。
最後の点はオプションですが、ソフトウェアの成長に合わせてチームも成長することが望ましいので、その役割でも成長できる人を採用するのは理にかなっているかもしれません(成長の時期と方法を決定するのに役立つ経験があることは言うまでもありません) QAチーム)。
他のヒント
さて、あなたはテスターでチームを広げるために探していますか?あなただけのコンサルティング会社からのテストの専門家を雇うと考えたことがありますか?
誰かにテストしてもらう前に、テストの要件を満たしていることを確認してください。少なくとも次のものが必要です。
仕様:アプリケーションが何を行うべきかに関する信頼できる情報源。これは、アプリが正確に何を行うべきかに関するあらゆる質問に答えることができる専門家である可能性がありますが、それがより多く文書化され、より正式に定義されているほど、より優れています。
時間:テストには時間がかかります。アプリケーションが公開される 30 分前にテスターにアプリケーションを渡して、価値のある結果を期待することはできません。ウォーターフォール開発を行っている場合、最後のテストには多くの時間がかかります。他の多くの開発モデルでは、開発と並行してテストを実行できるため、時間を大幅に節約できますが、使用するモデルに関係なく、テストにはテストしない場合よりも多くの時間がかかります。
この 2 つがなければ、品質保証は夢物語にすぎません。
これらを満たしていて、誰かをテストできるように訓練しようとしている場合は、ここに私のテストに関する短期集中コースがあります。
基本的に、アプリケーションをテストするということは、次の 2 つのことを確認しようとすることを意味します。
プログラムは本来行われるべきことを実行します。
プログラムは、本来行われていないことは行いません。
それが私が使っている基本的な考え方です。そこから構築して、私は行動という観点から物事に取り組み、次のことを検証しようとします。
- 期待された前提条件を持つ期待されたアクションは、期待された効果を生み出します。
- 予期しない前提条件を持つ予期されたアクションは、効果をもたらさないか、適切に処理されます。
- 予期しないアクションは効果をもたらさないか、適切に処理されます。
- 予期せぬ効果は発生しません。
項目 1 は仕様から直接引用されています。プログラムが期待どおりに動作することを確認します。
項目 2 と 3 では、テストの技術が役立ちます。どのような予期しないアクションや前提条件を実行できますか?間違ったパスワードを入力しようとする可能性があります。安全であると思われるページの URL を直接入力してみることもできます。奇妙な Unicode 文字をテキスト フィールドに貼り付けることもできます。SQL または JavaScript コードをテキスト フィールドに入力してみることもできます。
項目 4 は無限の無人地帯のテストであり、完全なテストを不可能にする部分です。(2 と 3 も無限ですが、考えるほど憂鬱ではありません。) だからといって、無視するわけではありません。あなたは何か異常なものがないか常に注意を払っています。また、インスピレーションが湧き、予期せぬ効果を引き起こす可能性のある方法を思いつくことがあります。「毎月第 3 火曜日の午後 11 時 59 分 59 秒から午前 12 時 00 分 00 秒の間にログインするとどうなりますか?ああ、これで私は管理者になれました。」技術的な知識とブラック ボックスの内部を覗いてみると、そのようなシナリオを考えるのに役立ちます。
テストについてはまだまだ言いたいことがたくさんありますが、私が考えることができる最低限のことは次のとおりです。技術的な要件と問題へのアプローチ。
理想的には、テスターに次の情報を与える必要があります。
- トレーニング テストする製品を知っているかどうかを確認するためです。
- ドキュメンテーション 期待される結果について。
- テスト計画 - 何をどのようにテストする必要があるか
- ある テスト追跡システム 何がテストされているか、何がテストに合格したか、何を修正する必要があるかなどを追跡します。このシステムはそれほど洗練されている必要はなく、プロジェクトの規模によっては Excel スプレッドシートで十分な場合があります。
自分のポッドキャスト#64 のでは、ジェフとジョエルは、どのようなスキルA(他のものの間で)議論します良いテスターは持っている必要があります。 トランスクリプトにも利用可能(約途中でページダウン)