my unexpected journey becoming software tester
「あなたは成功した人生を築きます…一度に1日…」
ソフトウェアテスターとしての私の旅は、少し意外に始まりました。
開発の機会だと思って、最初の面接に出ました。正直なところ、他のすべてのコンピュータサイエンスの卒業生と同様に、私はテストを進めることに少し懐疑的でした。
しかし、ついに、私はそれを試してみることにしました。私の好奇心がこの分野で私を助けてくれることを願ってのみ。
この質問をしなければ申し出を受け入れることができませんでした–テストに興味がない場合に備えて、開発に切り替える機会はありますか？ :)。
私を信じてください-私はその後、テストを離れることさえ考えませんでした。
最高のドライバー更新ソフトウェアウィンドウズ10
テクニカルラウンドに出場したとき、私はそれ以上の準備はできていませんでした。 ソフトウェアテストの基本概念 。私を導いた唯一のことは、私が理論的にではなく論理的に評価されているという考えだったと思います。
これはテストでの私の最初の学習でした–私は私たちがどのように（ 新鮮な ）評価されました。
今日でも、チームに新入社員を採用する際に同様の手法を使用しています。私は彼らの論理、粘り強さ、そして問題へのアプローチを何よりもチェックします。
推奨読書=> QAテストマネージャーとしての旅で学んだ4つの重要なこと
私はQA研修生としてザイカスに参加し、3日目または4日目に製品が割り当てられました。それは会社の最大の（当時のコンセプトでした）そして最も野心的な製品の1つでした。最初の数週間落ち着いた後、私には後戻りはありませんでした。
私たちは2人のQAチームとしてスタートし、数か月後すぐに私だけがテストの取り組みを推進しました。最初の2〜2。5年で、機能、パフォーマンス、セキュリティ、UI、使いやすさなどのさまざまなカテゴリで3000近くの欠陥を記録しました。 多言語 、マルチテナンシーなど。
テストチームに新たに追加される前のかなりの時間、私は強力な15〜16人のメンバー開発チームと対戦していました。追加した後でも、QC：Devの比率はあまり健全ではなく、テスト、配信、処理のすべてを考慮すると、成功した旅だったと誇らしげに言うことができます。
ここで強調したい重要な点は- これはすべて、理論だけでなく、実際のテストを理解したことによるものです。
私はソフトウェアテストの分野に6年近くいます。それは非常に多くの異なる経験とたくさんの実りある学習を伴う素晴らしい旅でした。
現在、私はシニアQAマネージャーとして、5〜6個の製品とモジュールの世話をしています。しかし、私に本当の喜びと幸せを与えるのは、30人以上の幸せで情熱的なテスターのチームを率いることです。
もちろん、多くの人が私の学習に貢献してくれましたが、それでも私の経験と知識のほとんどは困難な方法（そしておそらく最良の方法）、つまり自分で学習/解決したと言えます。
'経験は最良の教師であります。'
私はこれを言っていますが、ソフトウェアテストに関する文書化された理論を学習したり従ったりすることで利益が得られないと言っているわけではありません。私が信じていることは、これは確かに役立つでしょうが コンセプトを根底から理解し、大胆に問題に立ち向かうことに勝るものはありません。
文書化されたものはあなたに教えないだろうと私は信じています 実際のテスト 、それはあなたにいくつかの方向性を与えることができますが、それからあなたはあなた自身です。少なくとも私の場合、正確な問題を解決するために文書化されていない可能性のある問題があったか、時間内にそれらを見つけることができませんでした。私の唯一の選択は、核となる問題/状況を理解し、私が正しいと思ったアプローチでそれに対応することでした。
例–さまざまな状況でどのようにアプローチしたか
私が直面していた問題/状況と私がそれらにどのようにアプローチしたかを助けて、これを説明させてください。
＃1）ビジネスの理解は、テストの理解よりも一段高い
さて、皆さんはこれを知っています。テストとは、いくつかの検証をテストして検証を行うだけではありません。
テスターとして、私たちは考えられるすべてのシナリオを視覚化することになっています。実際のユーザーが使用している可能性のあるすべてのテストデータを検討することになっています。
このすべてのために、 私たちはビジネスを完全に理解することになっています。
ビジネスアナリストと同じかそれ以上にビジネスとユーザーベースを理解する必要があると言っても間違いではありません。
私も同様の可能性に直面していました。
私はするはずでした 複雑なビジネスシナリオを理解する 調達ドメインで、新しい要件をブレインストーミングし、ユーザーの観点からそれらを比較検討します。私は自分のケースを解決するだけでなく、各反復の要件フェーズと設計フェーズにも貢献することになっていました。ここでさえ、私の思考力と推論能力を除けば、すぐに参照できるものはありませんでした。
ビジネスをよりよく理解し、シナリオ/ケースをよりよく設計するために、 ペンと紙のように機能するものはありません。
また読む=> 5テスターが生活を楽にするための非テストツールが必要
行く前に 要件の議論 ミーティングでは、私は事前に考えられる疑問/修正/不明確な点を書き留めていました。以前は、テストケースを試したり構築したりするシナリオを書き留めていました。時には、シナリオを描くことさえ魅力のように機能します。
あなたが書く/描くとき、それはより明確にあなたの心に入り、そしてあなたの心はこの情報に取り組み、より多くのシナリオを生み出し、より明確になります。これは、あなたがその完了感を得るまで続きます!!!
＃2）オッズに逆らってプレッシャーをかけて実行する
私は、30人のエンジニアのチームが3年間継続して販売可能なレベルに到達するのに十分なほど巨大で複雑な製品に取り組んでいました。
初期段階のほとんどで、私はジュニア、ミッドシニア、シニアレベルの15〜20人の開発者のチームと対戦するか、1人または数人の他のテスターが同行しました。それらはすべて、製品に絶え間なく新しい機能を追加しており、テスト側からの同等かつ並行した注意が必要でした。
要件会議の一部であり、ケースを作成し、それらを実行し、探索ラウンドを行い、サーバーを保守し、展開することは、オプションではありませんでした。
その時まで、私は方法論を知りませんでした、 ベストプラクティス 、コースまたはそのような問題の解決策を私に示すことができる本。今日でも、地上の現実と向き合うのに正確に役立つものがあるかどうかはわかりません。
私がやっていることは、攻撃的で 探索的テストの迅速なラウンド （それまでは名前を知りませんでした）各機能を1つずつ繰り返します。このソリューションは、思考をシフトし、状況/シナリオをフレーム化する速度に純粋に作用します。
もちろん、これは本当に速くて攻撃的な仕事を要求しました、しかしそれは私のために働きました。
アグレッシブラウンドとは、 一度に1つのものをターゲットにします （一度にフォームの1つの要素を言う）そしてそれを独立してそして他のリンクされた要素/物と関連してテストする。
推奨読書=> 生産性中毒になる方法（特にテスターとして）
例えば。 テキストボックスをテストする方法。
ここでテストできるのは次のとおりです。
- データをそのまま受け入れて保存するかどうか
- データ型の検証
- 最大長の検証
- 特殊文字の処理
- XSS処理
- 多言語データ処理
- 空のスペースの処理/データなし
- タブとEnterキーの動作
- エラー処理（クロスブラウザー）
- UIアラインメント（クロスブラウザー）
- データの貼り付け/リンクデータのドラッグをテキストボックスにコピー
- 最も重要–このフィールドの動作w.r.t.他のリンクされた要素（このフィールドのデータに基づいて他のフィールドに何かを入力するなど、このフィールドにリンクされたビジネス上の期待）
上記のテストについて考えることで、この分野で実際に問題が発生する可能性はほとんどないという自信が得られますか？
ええと、一度に一つのことをターゲットにすることはいつも私のために働きました、そして私もいくつかの仕事の完了を得ていました。
＃3）「予期しない」ことに反対しているとき
今までやったことのないことをすることになっているときに、突然「ハウツー」に役立つ本はどれだと思いますか？
具体的に話せば-なし。
プロダクトリードが不在だったとき、私は他の数人のジュニアおよびミッドシニアメンバーと一緒に、アプリケーションをデモ（当時は本番）インスタンスに初めてデプロイすることになっていたことを覚えています。これは、当社製品の初めてのデモにとって非常に重要でした。
ええと、やりましたが、試行錯誤がたくさんありました。理由は、私たちの誰も専門知識を持っていませんでした Linuxとシェルスクリプト 。実稼働サーバーで間違ったコマンドを実行しているという懸念が、IT部門から（すべて誠意を持って）当時のマネージャーに提起されたことを覚えています。たぶんこれは単なる触媒であり、シェルスクリプト/ Linuxは私の自然な興味でしたが、その後すぐに、5つから6つの環境を同時に維持およびアップグレードする責任を負うことになりました。
ShellとLinuxは私の興味を非常によく捉えたので、すぐに私が内部トレーニングセッションを開始しました。
＃4）あなたのパフォーマンスが測定されるとき、あなたの経験はそうではありません
私のキャリアの非常に早い段階で、私は周りの非常に進化した経験豊富なテスターと比較され、測定されていました。私はあなたの多くが同様の状況を経験し、それらの余分な期待があなたに何をするかを知っているに違いないと信じています。
ここでの救済策は 自分をプッシュして進化させる 。
前進する唯一の方法は、自分の経験がどれほど少ないかを考えないことでした。成長/学習する速度を測定する世界の基準に制限されませんでした。リードを開始するまでの時間と、リードする前に必要なタイトルという世界の基準に制限されません。
さて、この点については、あなたがどの分野に属しているかに関係なく、ロビン・シャーマの「タイトルのないリーダー」を読むことをお勧めします。それはあなたがあなたの中にあるものを解き放つのを助けるでしょう。それはあなた以外の誰もあなたを抑えることができないとあなたに言うでしょう。
経験を数文でまとめる必要がある場合は、次のようになります。
「あなたの好奇心、細部への注意、規律、論理的思考、仕事への情熱、そして物事を分析する能力はすべて、破壊的で成功するテスターになるために重要です。それは私のために働きました、そして私はそれがあなたのために働くと強く信じています。あなたがこれらの資質を持っているなら、それはあなたのために働かなければなりません。」
さて、ここまで読んで、私がより深い理論的知識よりも基本的な人間の資質を促進していると考えているなら、それは完全には真実ではありません。私は何かから始めてそれで成功を味わうと信じています、それはあなたが学んだ情報よりもあなたの作り付けの資質に少し依存しています。ただし、どの分野でも遠くまで行くには、教訓、原則、経験を学ぶ必要があります。
私の場合も、キャリアを積むにつれて、用語、概念、理論をある程度学ぶ必要がありました。理由は、テスターとして、それらの用語で話す複数の人々と対話する必要があり、それを理解する必要があります。
リードまたは共同テスターとして、事実、定義、および用語に関する独自の知識を備えた、世界のどこかから来た新しいテスターがいます。ここでも、これらのことに消極的になることはできません。あなたはそこで使われる/言われる最大の可能なことについての予備知識を持っている必要があります。
学習は避けられません。
どこで無料でアニメをオンラインで見ることができますか
さまざまな種類のテスト、それらを実行する方法、および適切な段階でチーム内の人々にテストを説明する方法について、さらに学ぶ必要がありました。新しいアイデアやツールを評価し、それらを実装する必要がありました。はしごを上るにつれて、新しい概念と方法論を学ぶことも同様に重要になります。
続きを読む=> 最適な自動化の選択に関するAtoZガイド
結論
私が何年にもわたって学んだ主要で細かいことをすべて書き留めることはほぼ不可能ですが、これは箇条書きに要約する私の試みです。
- テストを定義するのは非常に困難です。誰かが素晴らしいテストを行うことができ、それを言葉で定義することができないかもしれません。ご覧のとおりです。
- 誰もが独自のテストの定義を持つことができます。私のは単純だった- 「あなたには何かが与えられます–欠点を見つけて、それをより良くしてください。」
- 破壊的なテスターになるために、必ずしも大きな理論、複雑なマトリックス、またはISTQBは必要ありません。 あなたは 奇妙な 、集中力があり、情熱的で、論理的に考え、分析能力を持っています。 ただし、余分なことを知っていても害はありませんが、核心を失うという犠牲を払うことはありません。
- 伝統的なアプローチ/コンセプトにも独自の重要性があり、それらが必要なだけの世界の良い部分があるという事実を考慮して、私はそれらに等しく敬意を払っています。テストだけでは進化できません。そのために周囲も進化しなければなりません。
- テスターとして、 新しいことを学ぶ 前進するためのツール、テクニック、および方法論 。テスト計画、さまざまなタイプのテストを実行するためのより良いアプローチ、状況テストなどがいくつかあります。
- テストは流動的であるため、適切であるという定義も組織ごとに大きく異なります。破壊的または優れたテスターであることは、運が良ければ給与小切手を受け取るのに十分かもしれませんし、従来の企業でテストがどのように機能するかについての追加の知識が必要な場合もあります。どちらもそれぞれの場所にあります。例えば私はテストの定義に従って人材を採用しています（もちろん、候補者の経験やプロファイルによって少し異なります）。
- コーディング、運転、料理のスタイルがあるので、 テストのスタイルもあります。 自分のやり方でやらないと楽しめないかもしれません。つまり、テストにはガイドラインがありますが、マイクロプロセスに縛られるべきではありません。
- 効果的なリード 彼のチームに割り当てではなく仕事を選ばせる必要があります。彼は時々それを製品の改善のために変えることができます。
- 関心のある分野で、そしてあなたが彼らを訓練させたい場所と一緒にあなたの人々を訓練するようにしてください。チームの考えと努力を最終目標である「最高の品質」に合わせます。
- あなたの人々を管理しようとしないで、彼らを導いてください。フレンドリーで親しみやすい、それは仕事をはるかに簡単にします。
- チームのすべてのメンバーは、自分が行っている作業を愛し、製品に愛着を持ち、周りの人々に愛情を持っている必要があります。そうすれば、それらの最高のものだけが出てきます。
- テストの世界は進化しなければなりません。 世界のかなりの部分は、探索的テスト、コンテキスト駆動型テスト（多くの人がそれを知らずに行う）のようなより実用的なアプローチに移行しています。
- より多くのテストコミュニティを形成し、志を同じくする人々が大規模に集まる必要があります。共有、学習、適応、革新することがたくさんあります。
私の経験と発見が、あなたがより良いテスターになるのに役立つか、テストをよりよく理解するのに役立つことを願っています。
さらに読む=> 初心者からプロへ：テスト専門家の成功した旅への完全なガイド
著者について： この記事は、STHチームメンバーのMahesh Cによって書かれました。彼は現在、複数の複雑な製品およびコンポーネントのテストの最前線をリードした経験を持つ上級品質保証マネージャーとして働いています。
返信をお待ちしております。ここにコメントするか、私たちに連絡してください。読んでくれてありがとう。
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- いくつかの興味深いソフトウェアテストのインタビューの質問
- ソフトウェアテストコースのフィードバックとレビュー
- 完璧なソフトウェアテスト履歴書ガイド（ソフトウェアテスター履歴書サンプル付き）