3

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

4

14 に答える 14

6

手動テストで頻繁に行う簡単なことを自動化します。これは必ずしも実際のテストを意味するわけではありません。ほとんどの場合、自動化された機能テストは難しくなり、コードから離れるほど、またインターフェースや人間の脳に近づくほど、時間の節約になります。

たとえば、テストするとき、ソフトウェアを実行するためにファイルをコピーしていくつかの値を入力する必要がありますか?それを自動化します。テストを支援するためにデータベースにデータを入力する必要がありますか?それを自動化します。単純なものが自動化されてスムーズに実行されると、難しいものに取り組むことができます。

もう1つのアドバイスは、可能であれば見つけたバグを修正するソースコードのコミットを読んで理解することです。この方法で多くを学ぶことができます。

于 2008-10-08T18:52:54.420 に答える
6

テストは、開発よりも挑戦的でやりがいのある場合があります。私が一緒に仕事をしているチームでは、テスト エンジニア出身の優れた開発者がかなり多くいます。

まず第一に、この作業は、開発の見通しについて独自の視点を与えることができます. 一部の開発者は、テスターは意地悪で好き嫌いがあり、完全に優れたコードの問題を見つけると信じています。一部のテスターは、開発者は怠け者であり、未熟なコードに満足していると信じています。

フェンスの両側から状況を見ることは、後のキャリアでの誤解や誤解の量を減らすため、間違いなく価値のある経験です。

次に、テスターはテスト ケースを作成します。テスト ケースは、クラスやそのメソッドやプロパティなどではなく、システムの機能について考えるのに役立つため、優れています。ソフトウェアを作成する目的は、優れた有用なソフトウェアを作成することであり、コーディング スキルで卓越性を達成することではありません。 . したがって、その角度からアプリケーションを考えることは間違いなく役に立ちます。ここでテスト ケースを作成すると、後で優れたアーキテクチャ ドキュメントを作成するのに役立ちます。

チーム/会社を自動化のテストに向けて前進させることができます。テスト担当者が自動化コードの書き方を知らず、記録と再生のインターフェイスを使用しようとするため、これが失敗することがあります。しかし、実際にテストをコーディングできれば、成功する可能性がはるかに高くなります。自動化は大変作業であり、軽視すべきではないことに注意してください。古典的な本では、労力が 2 倍になり、自動化と並行して手動テストが行​​われると書かれています。私は同意する傾向があります。

于 2008-10-08T18:46:16.757 に答える
4

計画中:

  • 時間をかけて、割り当てられた領域の機能仕様または変更要求を理解してください。プログラミングの知識があれば、ここで優位に立つことができます。
  • 矛盾と穴に疑問を投げかけます。開発がまだ進行中である間に、設計ドキュメントにアクセスできることを願っています。テストが始まる前に、不明確な設計ドキュメントに質問することで、製品の問題を特定することがよくあります。
  • すべての境界ケース、負の条件、および条件の組み合わせについて考えてください。疑わしい場合は、開発に取り組みます。彼らが使用している実際のコードを知る必要はありませんが、プログラミングのバックグラウンドがテスト モデルを作成するのに役立ちます。
  • 自動化について心配する必要はありません。すべての新しいテスターがやって来て、テストを改善するための 100 の方法を目にしますが、通常、自動化はリストの一番上にあります。ブラック ボックス テストで自動化する必要があるのは、テスト対象の機能とは無関係で時間のかかるアクションである場合のテスト セットアップだけです。(たとえば、自己登録シナリオをテストするために、学習管理システム (LMS) で 20 のコースを自動的に作成します。コースの作成は焦点ではないため、数時間の無意識の作業を節約することが望ましいです。) 自動化について質問しても問題ありません。しかし、あなたが最初にそれを考えると思い込まないでください。

テスト中:

  • 明確で詳細な特定のバグ レポートを作成します。誰かがあなたのコードにバグを発見した場合に必要となるすべての情報について考えてください。問題を、一貫して問題を解決する最小の特定のアクションに分解します。再作成する手順とテスト データの例を含めます。
  • 問題が見つかったら、壊れた機能に代わるものをテストして、問題を絞り込むようにしてください。(簡単な例として、ブラウザーベースの製品で、閉じるボタンでダイアログを閉じるときにエラーが発生します。ウィンドウの閉じるボタン (X) で閉じたときにもエラーが発生しますか? 答えが何であれ、バグに含めます。報告。
  • 親切に。テスターとプログラマーは同じチームです。開発者があなたの言っていることを何も理解していない馬鹿のように見える場合は、バックアップして、あなたが理解していないのだと思い込んでください。それは多くの不幸を救い、あなたの態度を素早く変えます。謙虚で教えやすいと、コミュニケーションが取りやすくなります。
于 2008-10-09T05:24:05.550 に答える
4

コーダーとしてそれを壊してみてください:)

Sqlインジェクション、スクリプトインジェクションなど:)もっと面白くなるはずです:)

于 2008-10-08T18:45:32.017 に答える
3

私は数年前にあなたと同じ立場にあり、私にとってテスターであることはコーディングの際に大いに役立ちました。

ほとんどの場合、ユーザー入力、孤立したリンクなどにはより注意を払い、一般的にはより詳細になります。私の経験からすると、それは非常に良いポジションであり、プログラミングのスタイルを確実に変えたと思います。

于 2008-10-08T18:48:15.257 に答える
2

手動テストを行うために雇われた場合は、そのことに集中する必要があります。

自動化されたテストは素晴らしいものであり、あなたの会社がそれを行っていないのであれば、そうすべきです。ただし、あなたは彼らにビジネスの運営方法を教えるためにそこにいるわけではありません。どんな仕事でも一番大事なのは、与えられた仕事をこなすことです。それは特にエントリーレベルに当てはまります。

これを、開発者としての将来のキャリアに役立つ学習体験にする方法についての私の提案は、他の人のコードで見つけた問題の種類に注意することです。よくある間違いを知ることは、自分のコードで同じ間違いを犯すことを避けるのに役立ちます。

たとえば、一部のバグは、配列をループするときに 1 つずれているなど、単なるコーディング エラーです。その他は、要件の誤解、高レベルの設計の欠陥、または予期しない/無効な入力のチェックの失敗です。

また、バグが報告された後、開発者にフォローアップして、問題の根本原因、開発者がどのように修正したか、プロジェクトへの影響についてより多くの情報を得るようにしてください。この点だけは注意してください。プログラマーと QA テスターは、不利な関係にある傾向があります。彼らは、特に上級レベルのものはうまくいかないとあなたが言うのを好まないでしょう。批判するのではなく、これから学ぼうとしていることを彼らに知らせてください。可能であれば、開発者の中からこの部分を支援する「指導者」を選びます。そうすれば、あなたとこの種の会話をすることを期待している主要な連絡先が 1 つあります。

この協同組合からおそらく得られる主なことは、ソフトウェア開発が現実の世界でどのように行われているかを確認することです。テスターとしての立場から、初心者レベルの開発者としてよりも「全体像」をより多く見る機会が得られます。

QAまたはプログラマーとして、この会社で将来を考えているなら、これは彼らの製品と業界について学ぶ良い機会です. 最高のプログラマーは頭を下げた猿だけではありません。彼らは、自分のコードが何をするかだけでなく、それがなぜお金を払ってそれを使用する人々にどのように利益をもたらすかを知っています。

幸運を。

于 2008-10-08T19:16:03.063 に答える
2

あなたはできる:

  • 問題を切り分ける方法を学びます。バグを見つけたら、そのバグを再現するアクションの最小のサブセットを見つけるようにしてください。プログラマーはこれに感謝し、重要なスキル セットを習得したことになります。

  • 技術的な問題を適切に伝える方法を学びます。優れた詳細なバグ レポートを作成するには、多くのスキルが必要です。

  • 極限のケースとシステムのねじれた使用の観点から考える方法を学びます。これにより、後でより適切な単体テストを作成できるようになります。

私は、すべてのプログラマー (上級プログラマーを含む) が、別の視点から物事を見て、一緒に作業するテスターに​​敬意を払うためだけに、毎年手動テストに時間を費やすべきだと心から信じています (そして、私自身もそれを実践しています)。 )

于 2008-10-08T19:26:41.077 に答える
2

テストの一部を自動化してみてはいかがでしょうか。

手動テスト用にアプリケーションを準備するいくつかのスクリプトを作成します (開始、ログオン、テスト データ セットのロードなど)。

以前のバージョンからの出力と、テストしているバージョンからの出力を比較するいくつかの回帰スクリプトを作成します。

于 2008-10-08T18:38:42.310 に答える
1

Web 関連の場合は、キーストロークやマウスクリックをスクリプト化して、一種の偽の単体テストを実行できるフレームワークの 1 つを見つけてください。それはあなたの生産性を向上させ、その前にある50ページに対処することなく、本当にテストする必要があるものに到達するためにそれを使用して忍者のようなものになることができます.

自動化されたテストの扉に足を踏み入れることになる可能性があります。人々に感銘を与えれば、スクリプトが本当に上手であることは明らかなので、開発部門に入ることができるかもしれません.

于 2008-10-08T18:53:15.370 に答える
1

自動化について述べたことに加えて、ライフサイクル全体に関心を示すようにしてください。テストで見つけたものは、要件に適切に文書化されておらず、実際に目にする前に適切に単体テストまたは統合テストされていなかった可能性があります。以前の一連の出来事を改善するためにあなたができることは、あなたを教育し、すべての人の生活を楽にするのに役立ちます.

エゴに気をつけて、エゴを見つけたら慎重に行動してください。

于 2008-10-08T18:46:39.423 に答える
0

*Unit フレームワークを学び、さまざまなケースをプラグインします。

于 2008-10-08T18:39:06.240 に答える
0

マルチタスクとプログラミングの練習は、空き時間ごとに行ってください。粗末な古い Perl ビルド スクリプトを保守する退屈な仕事をしていたとき、仕事をしていないときはいつでも、より高度な Perl を学習し、新しいアルゴリズムを調べ、Haskell でプロトタイプを作成していました。

于 2008-10-08T21:04:14.513 に答える