すべてのテスト実践者は、ビジネステストからテスト開発エンジニアへの変革を望んでいます。これは、しきい値、レベル、自分自身を高め、個人的な価値を向上させるための重要な推進力であるためです。
テスト開発エンジニアは実践的な役割です。開発エンジニアと比較して、テスト開発エンジニアはコードを書く能力を持っているだけでなく、オペレーティングシステム、データベース、ネットワーク、ソフトウェアテストおよびその他の関連分野の知識を習得する必要があります。テスト開発エンジニアは、ビジネステストエンジニアと比較して、テストスクリプトの作成、テストフレームワークの設計、テストプラットフォームの構築、テスト環境の保守などのスキルを持っていますが、ビジネステストエンジニアの専門的なビジネス知識のバックグラウンドを持っていない場合があります。テスト開発作業は、基本的に、テストを正しくスムーズに実行できるようにするために行われる作業です。テスト開発はビジネステストに役立つはずです。テスト開発はビジネスとは別に存在しません。ソフトウェアシステムのライフサイクルでは、ビジネステストエンジニアとテスト開発エンジニアが共存し、相互に置き換えられることはありません。
それで、あなたは変革の準備ができていますか？
1.2ビジネステストの課題
1.2.1テスターの課題と新しい要件
一定の時間内に迅速に反復し、非常に同時性の高いタスクをテストすることは、テスターとテストチームが常に直面する課題でした。さらに、変化するユーザーのニーズに対応する必要があると同時に、業界全体での開発者とテスターの比率が不均衡であり、従来のテスト以外のタスクには明確な方向性とキャリア開発パスが欠けています。これらはテスターです。私たちが直面している問題。ビジネスの多様化、会社の戦略の調整、業界全体の継続的な発展により、テスターはますます多くのスキルを必要とし、その責任はますます大きくなっています。従来のテストの役割は、作業のニーズを満たすことができませんでした。人々はまた、これまで以上に技術的になりたいと思っています。今日の作業では、テスターが以前よりも高い実行能力を持ち、迅速なフィードバックを提供できるようにする必要があります。テスターだけでなく、開発者も必要な場合があります。
プロセスの観点から見ると、テストは製品と開発の間にあり、製品担当者や開発者とのコミュニケーションが必要です。作業の特性によって、テスターが直面する課題も決まります。今日、多くの企業がアヒルのテストエンジニアを採用している場合、システムをよりよく理解し、より深い欠陥を見つけ、開発者とコミュニケーションをとるために、申請者は特定の開発スキルを習得する必要があり、ますます包括的なテストの才能が必要になります。また、より効率的になり、製品担当者とのコミュニケーションにおいてより建設的な意見を提示することもできます。将来的には、テクノロジーやコードをまったく理解していないテスターは、業界によって排除される可能性があります。
課題に対処する唯一の方法は、適応と改善を続けることです。テスターは、自分の役割がどのように変化しているか、さまざまな環境の利害関係者に最高のサービスを提供する方法を理解する必要があります。テスターは、高い柔軟性と適応性を持ち、常に新しいスキルと方法を学び、新しい役割と活動を進んで引き受ける必要があります。これは、テスター自身が習得しなければならないコアスキルです。
作者のチームの実際の状況と組み合わせることで、チームの目標は、迅速に対応し、迅速なビジネスの反復をサポートできると同時に、テスターを重い反復作業から解放し、内部および外部の「エンパワーメント」を提供し、優れたテストプラットフォームを提供し、使いやすくすることです。テストツールと効率的なテスト方法。これにより、テスターにいくつかの新しい要件が提示されます。
1.1。コードを書く能力
コードを記述できることで、問題を報告するだけでなく、独立してテストの効率を向上させたり、開発者が問題を特定するのを支援したりできます。これは、テスターがプログラミングプロセスを理解し、考え方を改善し、テストのイメージを向上させるのにも役立ちます。
2.2。ツール思考とツール開発能力
ツール思考は、テスターが人的資源を節約できる作業ポイントを鋭く発見するのに役立ちます。ツールを開発する能力を持つことは、重い反復作業から本当に自分自身を解放することができます。
3.3。学び続ける能力、考えることを学ぶ
継続的な学習は態度であるだけでなく、能力でもあります。新しいテクノロジーや新しいアイデアを継続的に学習したり、新しい動的な傾向を理解したりすることで、テスターは変化にうまく適応し、変化を進めることができます。このトピックについて考えることを学ぶことは、リスク回避、プロジェクトの推進、問題解決など、テスターが必要とする他の多くの認知プロセスを含め、非常に幅広いものです。ただし、テスターが学習を続けることができない場合、彼の思考も制限されます。継続的な学習と継続的な思考によってのみ、未知の未来に何を提供できるか、そしてその価値をどのように反映すべきかを知ることができます。
4.4。強い心
テストは、絶え間ない質問と質問のプロセスです。テスターは毎日多くの重労働に直面し、いつでもどこでも他の人から挑戦を受ける可能性があり、仕事で疑問や誤解に遭遇する可能性があります。仕事を続けるためには、テスターにとって強い心が非常に重要です。
5.5。テスト思考
テスト思考は、テスターがこのテストの道をどこまで進むことができるかを決定します。テストのコアスキルはテスト理論やテストツールではありませんが、テスト分析、テストデザイン、テスト構造、テスト補足：「成長する美しさをシミュレートし、道を緩める」は常に作者のチームです。タスクの分析と区別を学ぶ統一された計画能力を備えた優先順位は、仕事に相乗効果をもたらすことができます。変革の基礎と必要性
変革とは、ビジネスニーズをより適切に満たし、システムの品質をより適切に保証するだけでなく、会社の戦略とより適切に一致させることです。各チームが変革を行っているかどうか、および変革の動機と基盤は、特定の状況によって異なります。著者のチームは主にビジネステストを担当します。1年後には経験豊富なテストマネージャーが追加されるため、テスト開発のポジションもあり、チーム変革の利点でもあります。
著者と同じ状況にあるチームはたくさんあると思いますが、そのようなチームが迅速に変革するためには、最初にどのような問題を明らかにする必要がありますか？
1.1。変革の目的
業界の発展傾向を考慮しつつ、企業の戦略に合わせたビジネスニーズをよりよく満たすために、チーム全体の技術レベルを向上させ、チームと個人の共通の成長を実現し、好循環を実現する
2.2。変容の方向
ユニットテストは非常に重要であり、実装する必要があります。アジャイル開発モデルの作業慣行では、開発者はユニットテストの作業を引き受けます。会社の戦略の調整により、UIレイヤーの自動テストはチームの焦点ではなくなりました。したがって、テストツールの開発と組み合わせた自動インターフェイステストは、作成者のチームの変革のための好ましい方向です。完全なインターフェーステストシステムは、製品の品質を大幅に保証でき、投資のこの部分はすぐに結果を達成し、テストツールの開発により、テスターは大量の手動の反復作業から解放され、効率が向上します。
3.3。変革の基礎
チームの変革では、変革の目的と解決すべき問題に基づいて変革計画を選択する必要があります。一般的に、準備は、変革の意欲、変革の時間、変革の計画、変革の前後のスキル、および適用の観点から選択できます。
（1）変革への意欲
チームが成功裏に変革したい場合は、ビジネスニーズや業界のトレンドなどの外部環境要因に加えて、チームメンバーの変革への意欲も考慮する必要があります。チームメンバーが積極的に変革する意欲は、変革を成功させるための重要な要素です。強制変換とアクティブ変換の違いについてここで説明する必要はなく、達成される変換効果も異なります。チームメンバーの主観的なイニシアチブを十分に発揮することで、変革を迅速に完了し、驚くべき結果を達成することができます。
（2）変換に必要な時間
チームの変革は、学習と実践のプロセスを経る必要があり、このプロセスには時間がかかります。ただし、テスト作業の性質上、最も不足しているのは正確に時間であると判断されます。では、今回はどこから来たのでしょうか？チームメンバーは、暇な時間を費やして抵抗を感じることを避けるために、コンセンサスに達する必要があります
（3）変革計画
チームは変革を成功させたいと考えています。変革を開始する前に、変革期間中のスキル、学習の進捗状況、練習時間、習熟度の評価、バックアップ学習資料、バックアップ計画など、変革期間全体を計画する必要があります。計画に従って、変換が整然と実行されるようにします。
（4）変革前後のスキル
チーム変革の目的によって、チームに求められるスキルは同じではなく、望ましい効果も異なります。チームは、ビジネスの特性と直面する問題の緊急性に応じて、習得するスキルを決定する必要があります。テストの基本的な知識、ビジネスの背景知識、データベース関連の操作機能、主流のプログラミング言語開発機能（できれば会社の開発言語と一致する）など、変換前に必要なスキルは基本的に同じです。
（5）アプリケーション
チームの変革で良い結果を達成するためには、実際の戦闘は考慮しなければならない問題です。実用的なアプリケーションがない場合、理論的なサポートは紙にしかできません。変革の過程で、実際のプロジェクトにトレーニングスキルを適用してみることができます。プロジェクトがない場合は、ターゲットを絞った実際の戦闘を人為的に作成できます。実際のアプリケーションを通じてのみ、問題を発見して解決し、変換を実際に機能させ、良好な結果を達成することができます。
1.3チーム変革の目標と計画
1.3.1変革への道の混乱
自動テストは、ソフトウェアテストの開発の必然的な結果です。ソフトウェア技術の継続的な開発に伴い、テストツールも大幅に開発されました。人々はテストツールを使用して、反復的なタスクを実行できるようになりました。ソフトウェアテストの特徴は再現性です。繰り返しは人々を退屈に感じさせ、繰り返しは作業負荷も2倍にするので、人々は繰り返しの問題を解決するためにツールを使用したいと考えています。
現在、自動テストは業界で宣伝されている時期です。多くの専門家は自動テストを高く評価しています。一方、モバイルインターネットの時代では、企業の生活環境は大きく変化しました。大手インターネット企業は独自の開発パスを模索しており、企業の変革は避けられません。傾向。会社が変革したいのであれば、従業員は従い、変化しなければなりません。これまでのところ、作者はチームメンバーがコンポーネントテストについて最初に聞いたときの目新しさを忘れることはできません。やり方とやり方についての議論のラウンドで、チームメンバーはこれが長い道のりであり、その間に混乱と苦痛がなければならないことにゆっくりと気づきました。しかし、より苦痛で深刻な課題は、チームの変革です。変革は期待される期待に応えることができますか？
多くのチームは、基本的に次の2つの問題にさまざまな程度で直面します。
（1）スタッフのレベルが不均一
チームの変革は1人の変革ではなく、通常、12人または20人の同時変革を伴います。一人一人のレベルが不均一で、学習能力も異なります。たとえば、ほとんどの人は以前に機能テストに従事しており、自動化ツールやフレームワークを開発したことも、多くの自動化ツールを使用したことも、開発を行ったこともありませんでした。したがって、これには、オンライン学習とオフライントレーニングという2つのアプローチを同時に採用する必要があります。
（2）何をすべきかそしてどこから始めるべきか
当初、Microsoftには、STESoftware Testing Engineerと呼ばれる、コードを記述せずに手動テストのみを実行する立場もありました。現在、テストエンジニアのすべての役職はSDET（テスト中のソフトウェア開発エンジニア）と呼ばれています。後者はプログラミング能力を習得する必要があり、プログラミング能力を習得することはより良いテストのためであることが名前からわかります。
STEからSDETに移行するための十分な条件は、テスターがソフトウェアと要件を十分に理解していると同時に、ユーザーの観点から要件を理解していること、および品質を重視することでプログラムのやり直し率が大幅に低下していることです。必要な条件は、開発を達成することです。担当者が持つ設計能力とコーディング能力。あなた自身の欠点を認識し、以下の分野であなたの能力を継続的に向上させてください。
（1）プログラムアーキテクチャの概念の理解：要件レビュー、設計レビュー、およびコードレビューに参加して設計知識を学びます。
（2）コーディング能力：ユニットテスト、自動テスト、テストツールおよびテストフレームワークの開発を通じてコーディング能力を向上させます。
混乱から抜け出し、頑張る目標を持って、必死に頑張れば、やがて成功の方向性が見えてきます。
1.3.2目標の設定
私たちは、私たちが行うすべてのことに目的を持たなければなりません。目的を持って、対応する目標があります。次に、この目標に基づいて、目標を達成するための関連アクティビティの実装を実行します。同様に、自動化を実装するときは、最初に自動テストの目標、つまり自動テストがもたらすメリットと解決できる問題を明確にする必要があります。自動化のために自動化することはできません。自動テストを実装する前に、自動テストの目標を明確にする必要があります。
1.1。テスターの達成感と幸福感を向上させ、手動テストでの繰り返し作業を減らします
現在、ほとんどのSMEでは、手動テストが毎日のテスト作業の大部分を占めています。テスターは、開発チームに従って、代替の開発とテストを継続的に実行する必要があります。機能モジュールは、テストサイクル全体で10回以上繰り返しテストされる場合があります。
この現状を変更するにはどうすればよいですか？自動テストは間違いなく良い選択です。対応するスクリプトを作成した後、繰り返し実行できます。テスターはボタンをクリックするだけでテスト作業を開始し、テスト結果を確認できます。これで、手動テストに長い時間がかかっていた作業が完了します。このとき、自発的に試験作業の達成感や幸福感が生まれ、テスターはさまざまなプロジェクトで自動試験の徹底的な実施を積極的に推進していきます。
2.2。テストケースの実行効率を改善し、迅速な自動回帰テストを実現し、開発チームに質の高いフィードバックを迅速に提供します
手動の方法を使用してテストケースを実行します。実行速度は非常に遅い必要があります。人間は機械ではなく生き物であり、長時間労働は必然的に疲れを感じ、テストの実行速度は自然に遅くなります。多数のテストケースの場合、すべてのテストケースをテストするための時間コストは非常に高くなります。
手動テストの代わりに自動テストを使用する場合、テストケースの実行者はマシンになります。マシンは24時間継続的に実行でき、テストスクリプトによって割り当てられたテストタスクを飽きることなく迅速に完了することができます。この方法は、テスト実行の効率を大幅に向上させ、テストケースの実行時間を短縮し、テスト実行の精度を向上させることにつながります。
現在、アジャイル開発モデルは、さまざまなソフトウェア会社で普及し、適用され始めています。アジャイル開発では、開発した製品の品質フィードバックに対する要件が非常に高く、ビルドバージョンを毎週または毎日開発してテスト環境に展開する必要があります。同時に、テスターが迅速な品質フィードバックを提供できることが望まれます。現在、大規模なアジャイル開発プロジェクトの品質フィードバック要件を真に実現できるのは、自動テストによってのみです。自動テストがないアジャイル開発プロジェクトは、プロジェクトの失敗のリスクを大幅に高めます
この目標が達成されているかどうかを確認するために、以前の手動テストの実行時間を比較して、テストケースの実行時間が大幅に短縮されているかどうかを確認し、プロジェクトの品質フィードバック速度が製品の迅速なリリースに大いに役立つかどうかを開発者に尋ねることができます。 。
3.3。テスターの数を減らし、開発とテストの比率を高めます
企業の人件費を節約するほとんどのIT企業の運営費の中で、5006-706の費用は人件費です。人件費をより適切に管理する方法は、企業の発展にとって非常に重要です。自動化されたテスト方法を使用すると、必然的に手動テストの作業負荷が軽減され、それによってテスターを削減するという目的が達成され、それによって企業の人件費が削減され、企業の収益性が向上します。
4.4。オンライン製品の動作ステータスの監視
製品の開発とテストが完了すると、製品は実稼働環境にリリースされ、ユーザーに正式にサービスを提供します。ただし、実稼働環境の運用中は、さまざまな理由により、製品に何らかの問題や障害が発生します。そのような問題をすばやく見つける方法は？「問題が発生した場合、顧客サービスに電話をかけるユーザーがいるため、実稼働環境の問題を発見できます。」このアプローチを使用すると、必然的に製品に対するユーザーの満足度が低下します。また、熱心なユーザーからのフィードバックがない場合、本番環境の問題が発見されるまでの時間が大幅に遅れます。したがって、顧客のフィードバックのみに依存することはお勧めできません。
実稼働環境の問題を迅速かつ時間内に確実に発見するために、自動テストスクリプトを記述して、製品の主要な機能ロジックをテストできます。テストスクリプトを定期的に実行して、製品システムが引き続き正常に機能するかどうかを確認します。テストスクリプトの実行後に問題が見つからない場合は、一定時間スリープした後にテストスクリプトを実行して、製品システムの実行ステータスを確認します。テストスクリプトが製品システムの操作上の問題を検出し、数回の再試行後に製品システムの問題がまだ存在することを確認した場合、テストスクリプトはシステムの操作と保守を担当する担当者にアラームメールとテキストメッセージを自動的に送信します。アラーム情報を受信した後、関係者は手動処理を実行できますシステム障害が発生し、検出および
障害管理システムで初めて本番システムのリアルタイム監視の目的を達成します
5.5。大量のテストデータを挿入する
システムレベルのテストのプロセスでは、システムの処理能力を検証するために、大量のテストデータが挿入されることがよくあります。たとえば、テスターが100個の注文を挿入する必要があり、各注文にはビジネス要件が必要です。これらのデータを手動で挿入すると、必然的に長い時間と労力がかかります。ただし、「
6.6。よくある間違った目標：自動テストを使用して手動テストを完全に置き換える
一部の人々は、変換後、自動テストはもはや必要ないと考えています。どのプロジェクトでも、自動テストが推奨されますが、これはお勧めできません。自動テストの処理方法を決定する前に、まず自動テストを明確に理解する必要があります。自動テストは、手動テストを補足するものです。多くのデータの正確さ、インターフェースの美学、およびビジネスロジックの満足度は、テスターの手動による判断と切り離せません。手動テストのみに依存すると、テストの効率が低下します。特に、回帰テストの繰り返しの作業負荷は、テスターに大きなプレッシャーをかけます。したがって、手動テストと自動テストの両方が不可欠であり、重要なのは適切な場所で適切なテスト方法を使用することです。
上記の内容は、この記事の全内容です。上記の内容は、皆様のお役に立てれば幸いです。助けられた友人は、いいねやコメントを歓迎します。
ソフトウェアテスト、インターフェイステスト、自動テスト、およびインタビューの経験を交換したい場合。興味があれば、私に従ってください、グループ313782132を追加してください、私たちは同僚と技術的な交換をします。
ソフトウェアテストは、IT関連業界で最も簡単に開始できる科目です〜開発者の論理的な思考は必要ありません。また、運用および保守担当者は24時間体制で電話をかける必要はありません。必要なのは、慎重な態度とIT関連の知識の幅広い理解です。業界に参入してから専門家になるまでの各テスターの成長経路は、ソフトウェアテスト、自動テスト、およびテスト開発エンジニアの3つの段階に分けることができます。
これが私がまとめた情報です。自習をもう一度体験したくない場合は、情報が見つからず、誰も質問に答えず、数日後にあきらめたいと思う場合は、さまざまなソフトウェアを含むソフトウェアテスト交換グループ313782132を追加できます。テストデータと技術交換