問題タブ [manual-testing]

学生として、私はマニュアルテスターとしての最初の協力的な仕事を始めました。私はそれがコーダーと同じくらい知的で要求の厳しい仕事であることを知っています、しかし私は逆に考えざるを得ません。私はコーダーになるのが大好きですが、それが私の最初の仕事です。そこで、手動のブラックボックステストジョブを最大限に活用する方法、つまり、コーディングスキルを向上させるためにそれをどのように使用できるかについてアドバイスを求めています。どうもありがとう。

テスト エンジニアとして、探索的テストを行うことがよくあります。バグに遭遇したとき、どの手順が問題を引き起こしたのかがすぐにわかるとは限りません。したがって、明らかに、問題を再現するために必要な手順を見つける必要があります。状況によっては、これにはかなりの時間がかかる場合があります。

本当に役立つのは、マウスとキーボードのアクションを追跡し、場合によってはクリックされたコンポーネントのプロパティも保存するログ ツールです (AUT は Java で記述されています)。

適切なツールを見つけることができませんでしたが、検索方法が間違っている可能性があります。

誰かが私を正しい方向に向けることができますか?

私は、他の人がどのようにテスト スクリプトを編成しているかに興味があります。または、他の人が働いていた場所で、優れたテスト スクリプトが編成されているのを見てきました。また、これらのテスト スクリプトの詳細レベル。これは、自動テスト用に作成されたスクリプトではなく、手動テスト用に作成されたテスト スクリプトに特に関連しています。

私が見ている問題はこれです。テスト スクリプトには多くの複雑さがありますが、複雑または大規模なコード ベースを編成する際に使用される原則の利点はありません。コードの一部が何をすべきかを指定できる必要がありますが、それを読むときに誰かを退屈させないようにする必要があります。

また、テスト スクリプトをどのようにレイアウトしますか。データ入力タイプで実行するのに適した完全に指定されたスクリプトを作成することに熱心ではありません。それは私たちのチームではなく、それらを維持するためのオーバーヘッドが高すぎるように思われるからです。また、ここまで工程を細かく指定することで、実際に検査を行っている本人が品質の責任を負わないように感じます。すべてのボタン クリックと入力する値をユーザーが指定していますか? そうでない場合、どのレベルの詳細が指定されているか。

DST、Wanem などのさまざまなテストについて説明できる人はいますか。

現在、職場ではTracを使用してテストケースを管理しています。ただし、チケットの代わりにテストプランのwikiページにリストされているTCがかなりあります。

私のマネージャーは最近、手動テストの結果をより適切に文書化することに興味を持っています。これは高潔な目標であり、QAチームの何人かの人々はこのアイデアにかなり熱心ですが、正しく実行されない場合、そのようなシステムのオーバーヘッドは悲惨なものになる可能性があると実際に感じています。実際、私が考えることができる唯一の正気の非Trac統合ソリューションは、単純なタスクマネージャーであり、次のようなよりカジュアルな結果を保存および管理できます。 "。ウィキからいくつかのTC番号などを移植するには時間がかかると思います。「Xは、時間YでTC 23423432を検証し、合格しました」などのシステムは、テストケースが非常に多い（そして小規模な）場合の自動テストにのみ適しています。チーム）。

テストプランなどを作成して結果を報告できるTracのプラグインをいくつか見てきましたが、それほどエキサイティングなものはありません。誰かがこれらのツールを使った経験がありますか？tracとの統合によりオーバーヘッドが大幅に削減されますが、すべてのTCがチケットとして提出されるわけではないという問題があります。これに対処する必要があります。

そのようなプロジェクトに何を提案しますか？あなたは同じような状況にありましたか？このような小さなチームで手動テストを過剰に編成することは有害であるという私の意見のために、私がチームの唯一の否定的な発言者になり、怠惰に見えることを望まないので、あなたの意見を大いに歓迎します。

誰でも良いテスト スクリプト テンプレート (MSExcel) を投稿できますか? -- ソフトウェア テスト プロジェクトのおかげで

QA プロセスでは、通常、バグの原因となる一連のアクションを記述する必要があります。

通常、これを行う最善の方法は、テキスト メッセージで状況を説明することです。スクリーンショットが役立つ場合もあります。しかし、ビデオやスライド ショーは QA チームを支援し、QA チーム (開発者のイテレーション) の時間の損失を減らすべきだと私は信じています。

私たちのチーム (ほとんどの QA チームは他の都市にいます) では、重要な状況を説明するためにTeamViewを使用しています。しかし、接続のセットアップに多くの時間がかかり、ショーの時間のために開発者の作業を停止する必要があります。このバグを他の開発者に見せる必要がある場合は、このプロセスをもう一度繰り返す必要があります。ビデオカットは、新しいプロジェクトを完全に知ることができない初心者開発者にとって良いアイテムです。このアプローチの多くのプラスを見つけることができると思います。

このアプローチの欠点は、説明のサイズが大きいことです。

ユーザー画面のアクションをビデオまたはスライドショーに記録できるツールはありますか? このツールが無料になるとよいでしょう。

このツールの優れた機能は、「過去 2 分間のスライドを取得する」ことです。たとえば、QAエンジニアはバックグラウンドで動作し続け、バグを引き起こすようなことをしようとします. QAE は、最後の 1 分間のアクションがバグを引き起こすと考えています。このツールで 1 分前のアクションを保存できるようになれば、非常に便利です。

私たちにはたくさんの開発者がいますが、QA 担当者はほんの数人です。開発者は、自動化されたテストを作成することで、開発プロセス全体を通して QA に関与するようになりましたが、QA の実践はほとんど手作業です。

私が望むのは、私たちの開発手法が BDD と TDD であり、堅牢なテスト スイートを成長させることです。問題は、このようなテスト スイートを構築する際に、テストに対して何を信頼できるか、何を手動でテストし続ける必要があるかをどのように判断できるかということです。

自動化の実装を開始したい。これがリソースの有効利用になるかどうかはわかりません。アプリケーションは指数関数的に成長していますが、自動化がどの時点でテストに役立つかはわかりません。

手動テスターがいるのに自動化する理由を教えてください。

テストは、主に手動テストと自動テストに分類できます。これに関して、ある疑問が頭に浮かびます。

それらには以下が含まれます：

• 2 種類のテストの基本的な違いは何ですか?

• 手動テストと自動テストの両方に含まれる課題の要素は何ですか?

• 手動テストと自動テストのそれぞれで、ソフトウェア テスターが必要とするさまざまなスキル セットは何ですか?

• 手動テストと自動テストをそれぞれ行うソフトウェア テスターの仕事の見通しと成長の機会の違いは何ですか?

• いずれにせよ、手動テストは自動テストよりも低く評価されていますか? はいの場合、どのように？

• 企業の世界では、自動化されたテスターと比較して、手動のテスターはどのように扱われますか? （それらが本当にそのような用語で区別されている場合）