メニュー

クライアントはソフトウェアテスターに​​本当に何を期待していますか？

what do clients really expect from software testers

問題を排除するために楽器を試してください

今日の記事では、クライアントの場所で日々の対面のやり取りを行った私の直接の経験に基づいて、クライアントが私たちに本当に期待していると私が信じていることについていくつかの考えを共有します。 オフショアでのコラボレーション メールや電話で。

ITサービスはソフトウェア業界の重要かつ不可欠な部分であり、成功するには顧客満足度が重要です。各クライアント/組織は、プロセスが異なる場合があり、異なるプロトコルに従う場合があり、異なるタイプのビジネスを扱う場合があります。

しかし、以下の要因は一般的であり、一般的に誰にとっても重要です。

ソフトウェアテストクライアント

(画像 src )

学習内容：

クライアントがソフトウェアテスターに​​期待する5つのこと：

クライアントの期待1

＃1）費用便益

あなたが何かを売ったり買ったりすることを考えるとき、コストは主要な役割を果たし、それはしばしば重要な決定要因の1つです。ブラックフライデー、フリップカートビリオンデイセール、またはアマゾンの素晴らしいショッピングフェスティバルを私たちは皆熱心に待っていませんか？私たちはセール期間中に狂ったバイヤーになります。私たちのお金に見合うだけの価値があると期待するのは、単純な人間の行動です。

企業と顧客に違いはありません。費用便益は顧客とサービスの関係を後押しし、サービス会社が競合他社の見積もりが少ないために入札を失うことは珍しくありません。

費用便益

今の大きな問題は、どうすれば顧客に費用便益を示すことができるかということです。

これらのポイントは役立ちます：

  • 彼らに彼らのお金の価値を示す 。あなたの正当化と裏付けとなる証拠を提供する 見積り 。
  • 支出を節約するための創造的な方法を考えてください。
  • 見積もりを調整します。 Xの金額がかかる標準的なプロセスに固執する代わりに、より安価な代替手段を提供します。 例えば ：完全なシステムテストではなく、クリティカルパステストを提案します。
  • あなたの競争を知る 。価格設定モデル市場の関連性を維持するためには、他のサービス会社がどのようなコストでクライアントに提供しているかを簡単に確認できます。

＃2）仕事の質

仕事の質と量は2つの非常に異なるものです。

作成されたテストケースの数や報告された欠陥が生産性や品質の指標に使用されていた時代は終わりました。もう違います。

状況は以下の画像のようになります。

仕事の質

仕事の質2

A）「いいえ」と言うタイミングを知る

私たちは皆、残業したり、週末に電話をかけたり、深夜や早朝の電話に出たりする場所にいました。しかし、事態が悪化し続ければ、NOと言えるのです。 いいえと言う 仕事の質と正気を維持できる唯一の方法です。

その際、事前に懸念を表明し、品質を主張してください。

これが私がいた状況であり、これは私が話していることのより良い考えをあなたに与えるかもしれません：

私の会社は新しいロゴを獲得し、古い会社から私の会社への移行の一環として、知識移転セッションが計画されました。私たち6人のメンバーのチームがクライアントサイトに移動しました。 紹介初日、KTプランを共有しました。私の名前は複数のモジュールに対してタグ付けされていることがわかりました。私はそのテクノロジーにさえ気づいていなかったので、それらのモジュールの1つは完全に私の範囲外であったはずです。それは私のスキルとはまったく一致しませんでした。

私はナレッジトランジションリードに行き、状況を彼に話しました–

  • 割り当てられた作業項目が多すぎるため、セッションで品質と100％をキャプチャする能力が妨げられます。
  • 予定されていたアイテムには、自分のスキルが合わない部分があり、体に合わなかったため、移行中に100％理解できない可能性があります。

先頭 問題を理解し、KT計画を修正しました。

リーダーブックになる方法

これが次のことを確認するのに役立つことを願っています：何かが私たちの皿にある場合、それは私たちがそれをすべて食べなければならないという意味ではありません。特にそれが品質の妥協を意味する場合はそうではありません。

B）テストケースの完全性

あなたの何人が私に同意します テストケースの書き方を改善する 、それはより良い品質につながりますか？

以下は、ほとんどのテストケースで一般的ないくつかの一般的な間違いです。

テストケースコンポーネント現在の問題解決
目的 目的はテストケースの最も重要な部分であり、これがすべてのテストケースの違いです。 Objectiveのよくある間違いは、明確さが欠けています。

1つの機能に対して作成されたすべてのテストケースと同様に、各テストケースの違いを示すことなく、1つの目的があります。		 各テストケースの目的/目的は、そのテストケースの一部としてテストされる機能とテスト条件を説明するために明確にする必要があります。

同じ機能でテストケースがポジティブとネガティブになる可能性があるため、目的は違いを示すのに十分明確である必要があります。目的を定義するには、テストシナリオを参照することをお勧めします。
前提条件 多くのテスターは、前提条件について言及することを完全に見逃しているか、単にコピーして貼り付けるだけです。各テストケースは別のテストケースとは完全に異なる可能性があるため、コピー貼り付けはエラーにつながります。コピー＆ペーストエラーを避け、細部に注意を払ってください。
テストデータ これはおそらく最も見落とされているフィールドであり、ほとんどのテストケースでは空であるか、正確な定義が不足しています。入力する適切なデータに言及します。場合によっては、正確である必要はありません。

例：ユーザー登録でユーザーAnnaまたはJohnを登録できますが、それは問題ではありません。ただし、すべての文字を含み、長さが4〜10である有効な名前を定義すると、多くのことを明確にするのに役立ちます。
テストケースID 簡略化された命名規則または番号付け規則。たとえば、ログインボタンをテストしているとします。多くの場合、IDは次のとおりです。
TC_1_Login
TC_2_Login		それらをより説明的にします：
TC_1_Login_Invalid_User
TC_2_Login_Valid_User
参照文書 一貫性のないコピー-誤ったものを使用して、参照ドキュメントから貼り付けます。正しいバージョン番号で正しいリファレンスドキュメントに言及することを常にお勧めします。たとえば、一部のテストケースでは、FRSと技術仕様の両方が参照されているため、リファレンスセクションのテストケースでは両方に言及する必要があります。
テストケースの手順 欠落しているステップ。主に、アプリケーションをよく知っているテスターに​​よるものです。彼らは物事を想定し、手順について言及することをスキップすることができます。これは、ビジネス、レビュー担当者、および新しいテスターに​​問題を引き起こします。適切な手順と順序を使用する必要があります。

要約すると、設計段階で細部を考慮に入れると、テスト出力の品質ははるかに優れたものになります。

＃3）ビジネスの理解

これは、顧客がテスターに​​求める最も重要な要素の1つです。しかし、一部のテスターが自分の仕事はFRSに基づいてテストケースを作成することであり、ビジネスを理解する努力をしないと信じているのは悲しいことです。

最初にビジネスを理解してから、機能を調べてください。あなたはできる クライアントのニーズを想像する さらに、それに応じてテストします。

これが例です– FRSは、「XYZレポートは、日付、名前、ステータスの3つの列で生成する必要がある」と述べています。以下は、この要件を額面どおりに受け取ったときに最終的に得られるテストケースです。

  • レポートXYZが生成されたことを検証します
  • 検証レポートには、日付、名前、ステータスの3つの列があります
  • 3列のデータを検証します。

ただし、このレポートのビジネスへの適用性を念頭に置いておくと、次のことをテストする必要がある場合があります。

  • このレポートのビジネス目的は何ですか？
  • このレポートは毎日生成されますか？
  • このレポートを見ているビジネスユーザーは誰ですか？
  • このレポートのデータのソースは何ですか？
  • 利用可能なデータがない場合、レポートを生成する必要がありますか？

これはほんの一例ですが、ビジネスの認識と専門知識を身に付けることで、より良いテストを実現できることに私たちは皆同意していると思います。

＃4）可用性

あなたが顧客をサポートする単一の個人であろうとチームであろうと、あなたの可用性は常にチェックされるべきです（ 改善の範囲）。

可用性とは、24時間年中無休のサポートを意味するものではありません。それは、休暇、代替計画、到達可能であり、MIAに行かないことについての明確で事前のコミュニケーションを意味します。

以下は、サービス業界が従うモデルの一部です。

  • スタッフ増強モデル– スタッフ増強モデルで作業していて、会社の唯一の代表者である場合は、必要な手配ができるように、顧客に作業のタイミングと予定されている欠席を通知することをお勧めします。
  • 管理プロジェクトモデル– 大規模なプロジェクトチームが形成され、デリバリー/プロジェクトマネージャーが率いるマネージドプロジェクトモデルでは、バックアップリソースプランを持つことはもはや顧客の責任ではありません。 PMの管理の必要性 計画的および計画外の両方の休暇。このモデルでは、PMが事前にチームから計画された欠勤データを収集し、それに応じて管理することをお勧めします。お客様から週末のサポートや長時間勤務をご希望の場合がございます。このような場合も、リソースをローテーションして計画する必要があります。チームは、必要に応じて相互にバックアップできるメンバーで構成する必要があります。計画された詳細は、お客様と共有する必要があります。

＃5）改善の範囲

これは、ソフトウェア業界だけでなく、あらゆる場所で望ましいことです。改善をもたらすことは一日の仕事ではありません。改善の範囲は継続的に取り組む必要があり、次のように分けることができます。 3つのステップ–

また読む=> テストスキルを向上させ、競争に打ち勝つ方法

ステップ1：特定する

徹底的な調査を行い、改善すべき領域/範囲を特定します。たとえば、同じプロセスを使用して同じ機能を複数回テストするように求められた場合、プロジェクトから移動するか、テスト方法を変更したいと思うときが来るでしょう。これが、既存の方法に飽きたときに改善がもたらされる方法です。 私たちは変化と改善を考えています 。

ステップ2： 改善をもたらす

手動で行う場合は、 いくつかのことを自動化してみてください 。私が自動化と言うとき、それは必ずしも自動化されたツールを購入することを意味するわけではありません。

私は状況を引用します：

私はデータベーステストチームの一員でした。私たちの日常業務では、同じSQLスクリプトを、異なるパラメーターのセットを使用して1日に複数回実行する必要がありました。プロジェクトを開始したとき、これらの手順は問題ありませんでしたが、最終的にはシステムをよりよく理解し、誰かが手動でパラメーターを更新して実行する代わりに、同じSQLスクリプトをストアドプロシージャの一部として実行できると考えました。

ステップ3： 改善を評価する

3年の経験のためのセレンウェブドライバーインタビューの質問と回答

新しいプロセスが実装されるときはいつでも、それが期待どおりに機能し、副作用がないことを確認する必要があります。前の例であるストアドプロシージャの紹介を拡張して、新しく作成された自動化された方法からの出力と手動による方法からの出力が同じであるかどうかを確認します。

もう1つの部分は、一定期間にわたってメリットを監視して、確実に結果をクライアントに提示することです。私たちのプロジェクトでは、クライアントにテスト実行時間が30％短縮され、それによってコストが削減されることを示しました。

結論

結論として、私たち一人一人には生来の才能があり、私たち全員が独自の働き方を持っていることを述べたいと思います。これらは、クライアントにより良いサービス体験を提供できると私が信じるいくつかのヒントにすぎません。

著者について： この素晴らしい記事は、STHチームメンバーのPriya Rによって書かれています。私たちのために書いて、経験を共有したい場合は、 こちらからお知らせください 。

あなたがこの記事を読んで楽しんで、それが有益であるとわかったことを願っています！共有する別の経験がある場合はお知らせください。

推奨読書

^