タスクの正当化パターンとアンチパターン

内容

• 1.アンチパターン：不十分な理論的根拠
  
  • 1.1。 明らかに
  • 1.2。 私はママに誓います！
  • 1.3。 バニーは気分を害する
• 2.適切な正当化パターン
  
  • 2.1。 Pruflink
    
    • 要件へのリンク
    • 要件自体
    • インターネットリンク
    • 顧客の手紙
    • ROI
    • 統計
  • 2.2。 均一性
  • 2.3。 問題、または＃人生の痛み
• 3.根拠が必要でない場合
• 4.まとめ

タスクを開始するとき、正当化する必要があります。 開発者に次のことを説得する必要があります。

• これは本当にバグです。
• 修正する必要があります。
• 先ほど述べたとおりに修正する必要があります。

そして時々、あなたはバグ（特に初心者のバグ）を読んで、自問してください：

-なぜこれがバグなのですか??

たとえば、「レポートをダウンロードすると、57.6が得られます。 そして、-57.9 "になります。



理論的根拠を書くことは問題を解決します：

• 同僚は、「なぜこれがバグなのか？」という質問に気を取られ、それを文脈から切り離します。
• 1か月後、あなた自身は忘れていましたが、実際には、なぜそれがバグだったのか...

こちらもご覧ください：
バグで正当化が必要な理由-なぜ、一般的に正当化されるのかについての詳細。

何百人もの初心者テスター（生徒）が私を通り抜けました。 「なぜこれがバグなのか？」という質問をし始めたのは、まさに彼らの仕事でした...あなたはみんなに尋ねると、見返りに「はい、それは明らかです！」 まあ、どういうわけか非常に=））

一連のタスクと質問「なぜ？」を通して、回答のパターンが現れ始めました。 良いパターンと悪いパターンを強調しました。 それらについて話したいです。

この記事の対象者：

• 初心者テスター -視点を正しく説明する方法を学びます。
• テストマネージャー -パダワンへのリンクを提供し、それ以上の説明なしにアンチパターンを参照します。

1.アンチパターン：不十分な理論的根拠

1.1。 明らかに

テスターがバグの理論的根拠をまったく書かないのはなぜですか？ はい、それは彼らにとって明白だからです。 そして、彼らは皆に自分の考えを投影します。 私には明らかです=何かを書く理由は誰にでも明らかですか？

しかし実際には、これはそうではありません。それぞれの人が何らかのコンテキストにいるからです。 そして、あなたに明らかなことは、他の誰かに明らかな事実ではありません。

簡単な例を見てみましょう。 以下に書く言葉を読んでください-あなたがそれを読んだとき、あなたはどう思いましたか？ どのアソシエーションが思い浮かびましたか？

ロック

ドアロックまたは巨大な石の要塞？

結婚

結婚式ですか、壊れたiPhoneですか？
...

はい、これらは同音異義語です。 しかし、彼らは問題を「明らかに」示しています。 お城はお城であること、そして私にとってはお城であることは明らかです。

そして、あなたがバグを書く場合：

結果
57.6

期待される結果
明らかに、57.9

それは私の質問「なぜ？」に答えません。「自明」とはどういう意味ですか？ 私に説明してください。 それは私には明らかではない、そうでなければ私は再び尋ねません。 しかし、著者は明らかであり、彼は誰もがそう思う。



初心者の経験について話すと、私の生徒の1人がこのアイデアを最もよく定式化した：

「他の学生のバグを読むまで、バグを正当化する理由をまったく理解していませんでした」

非常に長い間、異なることは誰にとっても「自明」であり、私はあなたの文脈にはないことなどを伝えることができます...しかし、タスクの作成者は、彼らが単に彼に過失を見つけたと考え、残りの人は理解していませんが、彼はうまくやっています！

そして、他の人のバグを読むだけで、「うーん、なぜ彼はそう思うの？ 私は異なって考えました。」 そのとき、あなたの「自明」は誰にも明らかではないという理解が生まれます。

バグトラッカーに入って、学生からそのようなバグを見たとき、「シャリパットという名前を入力します。それは男性的と定義されています。 そして、それは女性のようであるべきです！」 なぜ女性のようにすべきなのでしょうか？ 私はこの名前を見る-まあ、シャリパットとシャリパット、それは男のように見えます。 私は尋ねます：

「なぜそれを決めたのですか？」 なぜ女性なの？
-はい、私の名前がそうだからです！

そして、これは少なくとも彼がタスクを始めた理由をすでに説明しています。 アプリケーションをテストするとき、最初に単純なデータ、つまりわかっていることを試します。 私たちの名前、妻、兄弟、姉妹の名前を試してみてください...

彼は妻の名前を入力しようとし、バグを発見しました。 そして、「性別は女性、これは女性の名前です-私の名前はそれです」という予想結果で書いたとしても、少なくとも「なぜこのタスクを始めたのですか？」という質問は消えました。

もちろん、そのような正当化は十分ではありません。 Googleの「異常な名前」。息子のベッドサイドテーブルに名前を付けることさえ禁じられていないからです。しかし、この言葉を正しい男性の名前と考える価値はありますか？

だからここで、問題をローカライズするために、一般的に名前は何ですかグーグルする必要があります-ロシアの名前の問題？ カザフ？ ウクライナ人？ しかし、システムはそれらを処理できるはずですか？ などなど。 たぶんバグではありません...
それでも、「私の妻の名前はそうです」と少なくとも著者は私たちに彼のコンテキストを紹介し、彼がタスクを開始することにした理由を説明することができます。

そして、覚えておいて、証拠は文脈によって決定することができます。 システムの大規模なモジュールを注意深く学習し、すべてを完全に理解しました。 したがって、「このチップはここで動作するはずです」ということは完全に明白です。 しかし、1〜2か月でタスクに戻ると、すでに別のモジュールで作業していることになり、なぜそうなるのかを思い出すことはより困難になります。

最も愚かな鉛筆でさえ、最もシャープなインターネットメモリよりもシャープです。

バグを開始し、予想される結果が明らかな場合は、停止して「なぜそう思うのか」と考えてください。 そして、この質問に対する答えを書き留めてください。

1.2。 私はママに誓います！

「自明だから」何も書いても失敗しないことを生徒が理解すると、怒り、否定、バグの正当化の次の段階に進みます。これは「ママに誓う」と呼ばれます。理由を説明せずに。



つまり、根拠は次のようになります。

結果
57.6

期待される結果
57.9とても正しいから

しかし、そのような理論的根拠は、「しかし、なぜ？」という私の質問には答えません。 なぜそうだと決めたのですか？ 私はまだ王でもテレパスでもないので、なぜこれが正しいと思うのか分かりません。

実際、これは「明白なため、まったく何も書かなかった」という状況と大差ありません。 したがって、私はこれを第2段階と呼びます。このシナリオでは、通常、イベントは通常「最初に」明らかになり、次に「はい、そうです」ということになります。 学生の生活の例を見てみましょう。

ピーターとインディアン

私たちのシステムは、ケースごとに名前を活用できます。 学生が名前Peterを確認します。 それがどのように傾いているのか知っていますか？ 主格の場合、それは文字Eで書かれ、残りはすべてEで書かれます。「ピーター、しかしピーター」。

それで、バグトラッカーに入り、そのようなバグを読みます。「ピーターは手紙eでケースを調べますが、eで確認する必要があります。」

私は尋ねます：

「なぜあなたはそう思いますか？」
-まあ、それはEを介してそれが必要であることは明らかです（第一段階）
「なぜこれが明らかだと思いますか？」
-しかし、これはロシア語の規則によるとそうです！
-どんなルールで？
-さて、私はロシア語のルールを実行し、グーグルで検索するべきですか？ （第二段階-そう、信じて）
-はい！ はい、それはまさにあなたがすべきことです。 これがバグの理由になるからです。 多分あなたの開発者はインド人であり、あなたもインド人だからです。 そして、あなたはロシア語の規則を知らない！ だから彼らにリンクを与えると、すべての質問はすぐに消えます。

もちろん、入力ミスやコンマの間違いにバグを付けたときに、極端に進んで辞書にリンクを張る必要はありません。 それにもかかわらず、ピーターは重要な例であり、これは規則の例外です。 常にこのように機能しますが、ピーターにとっては異なります。

したがって、ここでリンクが役立ちます。 特に、開発者が「本当にそれが正しいのか？」 あなたは彼を愚かさと非識字で非難し、関係を台無しにすることができます。 そして、あなたの視点を穏やかに確認して、リンクを与えることができます。

しかし、さて、別の例を見てみましょう。ロシア語のルールについてではなく、「とても明白」です。

Email.rf

私の学生はこのタスクを開始するのが大好きです（ほぼすべてのストリームがそれを作成します）。

-email.ruで登録しようとしていますが、できません。 これはバグです！
-なんで？
-それはどうしてですか？ 私たちはロシアに住んでいます、誰もがそのようなメールを持っています！

DUMPカンファレンスでこのケースを話しましたが、満席の客席がありました。 私はそのようなメールを持っている人の手を上げるように頼みました。 200人のうち、3人が手を挙げました。

私たちがロシアに住んでいるという事実は、誰もがそのような電子メールを持っているという意味ではありません。 まあ、はい、はい...そして飼いならされたクマと入れ子人形...

ここには因果関係はありません。あなたの考えをあきらめることは単純に困難です。 結局のところ、ここでバグを見つけました！ どうしてこれがバグにならないの？ かっこいい。 ロシア、明らかに！ いいえ、明らかではありませんか？ まあ、すべて同じです、ロシア、確かにたくさんあります。

このような理論的根拠は、「私はグーグルに行くのが面倒です。事実を探してください。 言葉を信じてください。」 事実と証拠がない場合、その正当性を覆い隠し、「おそらく、おそらく確かに...」と書きたいという願望があります。



しかし、これらはストップワードです！ あなたがそれらを書きたいという願望を持っているなら、あなたは本当の事実を持っていません。 考えてみてください。 そして、なぜテスターの想像力に基づいたタスクを行う必要があるのでしょうか？ あなたの理論を証明してください！

そして、事実がなければ？ その場合、タスクは開始する価値さえありません。 はい、「ネイティブ」バグを拒否するのは難しいです。 しかし、これもできるはずです。

Email.ru-事実

ここでの事実は何でしょうか？

まず、domain.rfに登録する必要がある政府の顧客向けにサイトを作成できます。 企業基準、彼らは方法がありません。

または、本当に多くのそのような顧客がいます。これは統計によって示されています。 たとえば、「このようなドメインを介して登録しようとしています」というログに多くのエラーがあります。 そして多分それはこの機能を作る価値があります。 潜在的な顧客を失わないため。

そのような事実に基づいて、PM（プロジェクトマネージャー）は、タスクを実行するかどうかを決定します。 そして、もしそうなら、いつ。 または、「まあ、エラーがあります。わかりました。登録全体の1％未満です。できません」

抽象的な「はい、そのような人々は間違いなく存在しています！」の代わりに、事実を伝えてください。

タスクを設定するときは、原則5を使用してください。 予想される結果を書き留めながら、「なぜこれを期待しているのですか」と自問してください。 最初の答えは「これは明らかです」ですが、再び「なぜ？」という質問をします。 そして、データがないことに気づいたら、あなたにはそう思われます-事実を探すか、同僚と状況を話し合ってください。

1.3。 バニーは気分を害する

事実はないが、バグを拒否したくない場合、学生は怒り、否定、バグの正当化の次の段階に進みます...感情への圧力：

クトゥルフという名前で登録しようとしましたが、システムは登録しません。 そうでなければ、与える必要があります...私は気分を害し、去った、そしてあなた！ 顧客を失った！

そして確かに誰もが私と同じであるので、あなたはすべてのクライアントを失いました、そして彼らはまたalso辱の訴訟を起こし、すべてのお金を取りました！

そして、他の車...

もちろん、私が個人的に何かが好きではないとき、私の問題を無視することは非常に怒っています。 「普通の人はその名前で登録しない」とはどういう意味ですか？ 私が望むように、それは呼ばれています、どうすれば私に何かを禁止できますか？！

そして、投影がオンになります-私がそれを気に入らない場合、他のユーザーはそれを気に入らないでしょう！ すべてではない場合、少なくとも多く。 したがって、これは間違いなくバグであり、修正する必要があります。 まあ、または少なくとも学生のことを話しているなら、トレーニングの一部として出発します。

ただし、気分を害するユーザーは、これまでにない最悪の正当化です。 ナンセンスを正当化できるからです：

• メインの猫はいませんか？ それだけです！ 私は気分を害し、去りました！ そしてあなた！ 顧客を失った!!
• 登録しましたが、支払いはありませんでした?? 私は気分を害して去った...そしてあなた！ さて、あなたはそれを得る！

何でも起こり、私を怒らせます。 ボタンは緑ですが、赤いものが欲しかったので、システムは私にピザをプレゼントとして提供しませんでした...ユーザーとして、私は何でも怒ることができます。 しかし、誰が気にしますか？ それでも、あなたは喜ばないでしょう、willみは避けられません。 そして、脅迫は一般的に最後のことです。

すべては、この秘密のフレーズを言った生徒の一人から始まりました。
-ああ、あなたはロシア連邦のドメインを介して登録したくないですか？ そして、私が登録しようとしたユーザーとして、私はこのひどい状況を見て、消えました！ そしてあなた！ 顧客を失った！

それから私の友人は、そのようなスピーチは「バニーが気分を害した」と非常に似ていると言った。 彼女がこの類推をどこから得たのかわかりませんが、誰もがそれを気に入りました。

生徒は自分が興奮していることに気付きました。 私は感情のない理論的根拠を探しに行きました。 そして、アンチパターンという名前を得ました。

単純なルールを1つ覚えておいてください- バグに感情があってはなりません！

感情は過ぎ去る現象です。 今、あなたは正しい怒りで燃え上がっており、「馬鹿だけがこのようなコードを書くことができる」などの悪意のあるコメントでそれを表現したいと思っています。 しかし、隣の子供が気まぐれで、買われていないおもちゃやアイスクリームのためにママのかんしゃくを手配したときの状況を覚えておいてください。 外部のオブザーバーとして、このシーンを見て楽しんでいますか？ しかし、バグトラッカーのヒステリーはまったく同じに見えます！

したがって、本当にしたい場合は、すべてを言葉で表現してください。 開発者と喫煙室でのタスクについて話し合い、激しくあなたの立場を守ってください。 しかし、コンピューターに到達するとすぐに、感情を取り除き、事実のみを記述します。 「if yes if」と「and YOU！」なしで 顧客を失った！」

1、2、3年後にタスクに戻ることを忘れないでください。 そして、あなたでさえ、あなた自身のかんしゃくを見ることにうんざりするでしょう。 結局のところ、過去の感情はこれ以上ありません。これはばかげているように見えます。 言葉で最大限の感情-喫煙室で！ そして何とか彼らなしでバグで。



そして、正当化の理由で、私たちは大げさなバニーについては書きません。 タスクのそのような防御はばかげていることがあります：

学生はユーザーの申し出にタイプミスを見つけました。 最優先でバグを入れてください。 優先順位を明確にするよう求められたとき、彼は非常にinしていました。

-システムは私を欺いた、私はそれを信頼することはできません!!!

彼はおそらく、質問が「これはまったくバグではない」に変わるのではないかと心配していたので、彼は自分のバグを弁護し始めました。 しかし、これがバグであることを気にする人はいません。 しかし、なぜそれが重要なのでしょうか？ 誰が申し出を読むのですか？

-私は読んでいます！ したがって、システムに問題があることがわかりました。そこにタイプミスがあった場合、何ができますか？ そして、今それをどう信じるのか？！

しかし、「読んだ」≠「全員が読んだ」。 そして、学生自身は、プログラムをインストールするときに私たちに滑り込まれているすべてのライセンス契約を注意深く読んでいないことを認めました。 そのため、同じストーリーを提供します。 これまでのところ、彼らはそれを読みません。 気に入らないものがある場合は、すでにルールに対応してください。

しかし、ほとんどの人が読んでいないテキストの10ページ目に1つのタイプミスがあるため、「システムは私を欺いたので、私はそれを信じることができません」...まあ...バグでこれを書いてはいけません。

そのため、バグから感情を取り除きます。 そして、私たちはそこに何を残すことができますか？ もちろん、事実！

「うさぎはきっと気分を害し、去ってしまい、顧客を失うことになる」という感情を書く代わりに：

-統計を収集します。
-人件費の見積もり。
-ROIをカウントします。
-ユーザーへのインタビュー;
-製品を競合他社と比較します。

そして、ヒステリックなリスの代わりに、あなたは思慮深いバグを作るクールなテスターに​​なります！

2.適切な正当化パターン

バグを正しく正当化する方法は？ 書いたとおりにバグが修正されるように、期待される結果に何を書く必要がありますか？ そして、彼らは「なぜそんなに正しいのか」と10回尋ねませんでしたか？

上記では3つのアンチパターンについて説明しましたが、バグを正当化するための3つの良いパターンについて説明しましょう。

2.1。 Pruflink

可能性があります：

• 要件へのリンク
• 要件自体（Wordファイル、プレゼンテーション...）
• インターネットリンク
• 推定ROI
• 顧客の手紙
• 統計

要件へのリンク

最も単純なバグは、TKがあり、そこに記載されているとおりにシステムが動作しない場合です。

そのため、期待される結果を記述します。「57.9、作業指示書にそうなっているからです。」 うーん、うーん...ちょっと待ってください。 「私はお母さんに誓う」ように聞こえます...

はい、その文言ではそのように聞こえます。 したがって、リンクを使用して言葉を確認してください。 それ以外の場合、開発者はバグを読み取り、必要とします：

• どんな種類のTKであるかを理解します。
• TK自体を見つけます。
• 問題の特定の場所を見つけます。
• 把握するために...

最後のアイテムだけを残す方が簡単ではありませんか？ 結局、開発者は10の異なるプロジェクトに取り組むことができ、そのドキュメントは10の異なる場所で配布されます。 TKを検索するのに5〜10分かかります。リンクを追加するのはほんの一瞬です。 現在、TKに従ってテストしています。つまり、TKは開いていて、目の前にあります。 リンクをコピーして貼り付けてください！

同僚の時間を尊重し、彼らはあなたに感謝します。

要件自体

要件がConfluenceやその他のクラウドシステムではなく、通常のWordに保存されている場合は、テストするドキュメントを添付します。



古い要件をテストしている可能性があります。 また、チェック対象の直接Wordファイルを添付すると、アナリストはそれを見て、「ああ、待って、すでに10回すべてを変更しました。アップロードするのを忘れました。 ちょっと待って！」

そうでない場合は、「私は別のものを持っています！」と言う開発者とのショーダウンに3時間費やします。 あなたは走り、彼の要求を見て、それからあなたの要求を見て、誰が正しいかを明確にするためにアナリストを探します...

そのため、すぐに要件を入力すると、開発者は「何かが何らかのゴミである」と言って分析をリダイレクトしました。 アナリストはそれらを書き、彼があなたの言葉を開くと、彼はすぐに彼が時代遅れであるかどうかを理解します。 それは時間を節約します！

インターネットリンク

覚えているように、要件はいつもとはほど遠いものです。 そして、それらの代わりにあるかもしれません...インターネットへのリンク！ はい、なぜですか？

「ピーター、ピーター」の例を思い出せば、システムに要件があったとしても、「システムはロシア語の規則に従って機能する」とは言えず、ロシア語のすべての規則がリストされます。 もちろん、そのように書いている人はいません。 それでも、ロシア語のルールを参照したい場合は、それらをグーグルで検索する必要があります。

または、Sharipatの例を使用する場合。 繰り返しますが、これは普通の女性の名前であるという考えをどこで得ましたか？ あらゆる種類のカザフ語やその他の名前をグーグルで検索し、Sharipatを見つけ、他の同様の名前を見つけ、このページへのリンクを提供します。

そして、ここで、開発者があなたに同意しない場合でも、彼は来て言うことができます-「見てください、あなたはサイトへのリンクを与えましたが、これはある種の黄色のプレスです、彼らは常にゴミを書きます」 ただし、リンクを提供しなかった場合、開発者は自分でグーグルで検索し、あらゆる種類のサイトを検索する必要があります。そうすることで、偽の情報を攻撃した可能性があることを理解できます。 時間を節約して、すぐにインターネットへのリンクを提供してください。



はい、ここではすべてのリンクが有用で正当化されるわけではないことを理解する必要がありますが、少なくともこれが本当にバグだと思う理由を示します。 それはあなたへの私の「母の誓い」ではなく、正当化です！

顧客の手紙

理由は、顧客への手紙を送ることかもしれません。 個別のフィールドであるBusiness Justificationもあり、この機能を要求した顧客を書き留めます。 そして、バグを読むと、すぐに次のことがわかります。

-はい、ビジネスケースは空です。 これは、私たち自身がこの問題を発見し、修正する必要があると考えていることを意味します。

または：

-はい、そのような顧客は2015年8月1日に問題について不満を言いました

そして、この顧客に正確に彼に合わないものを明確にする必要がある場合、すべての情報（誰、いつ、何と呼ばれるか）があるため、この手紙を簡単に見つけることができます。 この情報を知っているので、Outlookで5秒以内に手紙を見つけます。 この情報がない場合は、Outlookにアクセスして、10人の異なる父親の間で検索する必要があります-どの顧客がどの手紙でそれを要求しましたか？

さらに、この機能が複数の異なる顧客から要求されていることがわかった場合、すぐに優先順位が上がります。 私たちが理解しているから：

-ええ、ここでは顧客1が不平を言っていましたが、数週間/数ヶ月で別の顧客が不平を言いました。 うーん、でも確かに苦しんでいるが静かな他の顧客の束があります。 泣き、刺しますが、サボテンを食べ続けます。 結局のところ、誰もが私たちに書いて問題を報告するわけではありません...



したがって、苦情が多いほど、優先度は高くなります。 これは実際のユーザーの不満であると理解しているため、彼らは本当にそのような問題を抱えています。 また、添付の手紙または少なくともそのリンクのおかげで、6か月後または1年後にバグに戻ったとしても、タスクの履歴をいつでも上げることができます。

ROI

ROI-回収率の計算を試みることができます。 本当にこの機能を作成するか、このバグを修正する必要がありますか？ これは適切な効果をもたらしますか？

30分間の開発のために小さな編集を行うことは1つのことであり、これは何百人ものユーザーに役立ちます。 それは完全に異なります-1人のユーザーのヒステリーのために、システムの作業を2週間やり直すため、他のすべての人に適しています。

ROIを計算し、ゲームがろうそくに値することがわかった場合、計算をタスクに入れます。 しかし、計算後、タスクを実行する必要がないことが判明する場合があります。 これは正常です！ そのため、不必要な機能について議論する時間を節約しました。

そのため、私たちは理論的根拠を考えます-時には「ああ、なんてバグ、なんてバグだ！」と思われるかもしれません。そして、あなたは理論的根拠について考え始めます...そして、あなたはバグではなくこのゴミは起動する価値がないことを理解しています...

たとえば、モバイルアプリケーションで作業するようになり、テスター向けのデバッグパネルが次のように表示されます。



すごいすごい 青が少し、赤が少し、テキストが完全に見えない、フォントが散らばっている...明らかなバグ！ 私の前でこれに気づかなかったのはどうしてですか 緊急クリアランス、リファクタリングが必要です！

正当化する方法は？ 「ユーザーがこれを見つけた場合、あなたはどういう意味ですか、そして、彼はすぐに気分を害し、去ります。」停止。 脳をオンにします。 これはデバッグパネルです。 これは、テスターと開発者、テストのアシスタントです[2]。 ユーザーには表示されません。 そして、彼が見れば、これはすでにバグであり、重大です！

そして、美容指導...しかし、それを必要とするのは、この美しさですか？ そこに新しい機能が緊急かつ迅速に追加されます。 テスターが来て、問題について文句を言い、開発者はひざまずいてコードを書きます。 動作しますか？ 触らないでください！

テスターの美意識には何も起こりません。他の場所でそのようなバグを探してみましょう。 このパネルのリファクタリングには1週間の開発期間がかかる可能性があるためです。 そして、それは非常に高価です。 そして何のために？ 美のために？ まあ、彼女をnafig、それはクライアントが支払う機能を作る方が良いです。

だから、人件費を計算し、私たちは元気に生活していることに気付きました。

統計

統計を収集し、タスクに投資します。

-ログ内のエラーの数。
-テクニカルサポートの苦情の数。
-ボタンのクリック数。
-注文の段階で去った（タブを閉じた）ユーザーの数。
-...

つまり、オンラインストアで注文する標準的な形式が「不良」であり、改善する必要があると思われる場合は、それを正当化します。 何が悪いのですか？ 住所を入力するには、インデックスを知り、10の必須フィールドに入力する必要がありますか？ それは本当に悪いですか、それともあなたを悩ますだけですか？

開発者はソフトウェアに「明らかな」ものを見ないかもしれないことに注意してください。 結局、彼らはそれを開発し、テストしました...彼らは1日に100回絶えずそれを見ます、彼らはすでにインターフェースに慣れています。 たとえそれが本当に古くなっていても、事実が必要です。

また、事実は簡単に収集されます。ユーザーがページを離れたときの統計を作成してください。 そして、彼がピザをバスケットに追加し、それから畑を埋め始め、5-7の吐き出しと放置の後、これはあまりクールではありません。 そして、3分の1がそうするなら、間違いなく何かを改善する価値があります！

email.rfを思い出すと、ログを見ることができます-「そのような電子メールの登録を拒否しました」などのエラーはありますか？ まったく存在しないかもしれませんが、私たちはすでに多くの気分を害するユーザーを見つけています。そのため、サイトは文字通り数百万人を失いました。

統計が感情よりも優れているのはなぜですか？ 私たち、ITプロフェッショナル、および一般ユーザーは、2つの異なる世界だからです。 私たちにとって便利なのは、彼らにとって不便です。 そしてその逆。



会計ソフトウェアを実行するとします。 「フー、誰もマウスで動作しないので、コマンドラインからすべてが動作することを確認する必要があるので、マウスに触れる必要はありません！」 この機能には多くの時間を費やしていますが、実際のユーザーはまったく使用していません。 彼らは大きなボタンを突くためにマウスを突く必要があるので...しかし、プログラマにとって便利なのは、彼らにとって完全に異なるので、一般的に電球を気にします。

また、ユーザーに必要なものを全員に伝えたい場合は、まずユーザビリティテストを勉強し、次にバニーが気分を害するかどうかを伝えます。

このシステムでは、匿名の統計情報を収集します。どの機能が使用され、どの機能は使用されません。Webフォームには、維持するのが難しい非常に多くのフィルターがあります。彼らは必要ですか？単に取り出して削除することはできません。確認する価値があります。

したがって、統計は通常非常に驚くべきものです。このフィルターはまったく使用されていないと考えましたが、実際には1時間ごとに機能しました。そして他方では、彼らは高い希望を持っていましたが、誰も彼を必要としません...

問題の存在を正直に伝えるのは統計だけです。統計がなければ、それはただの味になります。そして、誰もが異なる好みを持っています。テスターは赤いボタン、開発者は緑色のボタン、デザイナーは青色のボタンが必要です。事実を探して、pruflinkを渡してください！

2.2。 均一性

pruflinkがない場合、システムの均一性を参照できます。システムが常にこのように動作し、その後突然異なる動作をする場合-これがバグの理論的理由かもしれません。

たとえば、システムがpuntoswitcherのように機能する場合（これはロシア語で印刷するときに、レイアウトを切り替えるのを忘れて、システムが自分で切り替える場合です）。「Olga」と入力するか、「Jkmuf」と入力すると、2番目のオプションが最初のオプションに変わります。

これは、あらゆる種類の政府アプリケーションで発生します。彼らは時々同じ原理で動作します。パスポートのように明確に登録する必要があります。私たちはロシアに住んでいるので、登録はロシア語なので、英語の文字を修正します。明らかに、レイアウトを変更するのを忘れていたのです！

Jkmuf→オルガ

わかりましたが、「Julia」という名前を入力しようとした場合はどうなりますか？文字Uで始まり、この文字はロシア語のアルファベットの文字ではなく、特殊文字に対応します。

>→ゆう

そして、これは完全に異なる等価クラスです！

つまり、システムがpuntoswitcherのように機能することを理解している場合、少なくとも2つの同等クラスがあります。ラテン文字に対応するロシア文字と、特殊文字に対応するロシア文字があります。

これらは完全に異なるクラスです。チェックする必要があります！そして、おそらく特殊文字を印刷するとき、システムはそれを認識しません。そして、バグを開始します->記号を入力します。システムがそれを文字Uに変換することを期待していますが、何も起こりません。なぜこれを期待していますか？システムはすでにそのように動作しているため、Jkmufを入力すると、システムはOlgaであると認識します。

システムがすでにこのように機能していることを示しています。これは正当な理由です。「母に誓って、彼女はそのように働いている」とは言わず、オルガで証明します。

2.3。 問題、または＃人生の痛み

実際のユーザーの問題について教えてください。

私たちはテスターだからです。私たちのタスクは、つぶして壊し、短いフィールドに「戦争と平和」と入力し、2つのブラウザタブで1つのエントリを編集し、他のタブで他のエントリを編集することです。そして、何かがうまくいかなくても、ユーザーが同じことをするという意味ではありません。

また、「誰もそれをしない」という理由だけでバグが修正されない場合があります。これは正常です。決して起こらない問題にエネルギーと資源を浪費するのはなぜですか？

これは、特にユーザビリティの問題に当てはまります。覚えているように、ITスペシャリストにとって便利なことは、単純なユーザーにとっては不便です。そしてその逆！そして、「まあ、これは不便です...」と書くと、これは不十分な正当化であり、何が不快なのか決してわかりません。すべてが残りに合っています。しかし、ユーザーからフィードバックを収集し、苦情を申し立てる手紙を添付すると、そのような問題が実際に存在することがすぐに示唆されます。そして、これはすでに優先度を上げています。

実際の顧客の問題は、テスターからのある種の否定的なテストよりも常に優れています。



これは、テスターが問題を修正しないことを意味するものではありません。問題がある場合は、文句を言ってください！開発者がたった5分であなたを助けてくれるかもしれませんが、彼は状況を知らないだけです。

新しい機能をテストするときは、自動テストでそれをカバーします。テストフレームワークは長い間存在しており、私たちはそれに慣れています。テストは互いに似ているので、コピーして貼り付けます-通常、1つのパラメーターを変更し、残りは変更しないためです。これは「1テスト= 1テスト」の原則であるため、テストの低下はすぐに原因を示します。

そして今、自動テストから自動テストにパラメーターをコピーする必要があります。そして、私はそれらを最初のテストから2、3、4、5、10に掘り下げなければなりません...そしてこのコピーペーストでは、1行で1つの値だけを変更する必要があり、そうしないと、すべてがひどく崩壊します間違い。

, , - … 30 , , NPE. , «, ».

, , … , . :

— , , . !

:
— , .

, ?!!!

恐れないでください！たぶんあなたは苦しんでいて、開発者はそれについてさえ知りません。そして今、彼はあなたの問題をすぐに解決できるかもしれません。そして、おそらくそれを修正しませんが、回避策を提案します。

もちろん、問題が1回限りの問題である場合、または修正に時間がかかりすぎる場合、最適化タスクは次のリリース以降に進みます。しかし、少なくとも「これをどのように改善できるか」を議論し、タスクを設定することは価値があります。結局のところ、タスクがない場合、誰も何もしません。

問題にはさまざまなケースがあり

ます。-顧客の問題。
-実際のユーザーの問題。
-テスターの問題。
-チーム内の問題。

優先度の高いものとそうでないものがあります。それでも、実際のケースと実際の問題を説明すると、そのようなタスクは「明らかに、だれもが良くなる」よりも修正の機会が多くなります。

はい、実際のユーザーにとってどれほど悪いかを説明しても、バグを修正する保証はないことを理解する必要がありますが、これは人生です。いずれにせよ、少なくとも問題を説明すれば、少なくともこのタスクを設定した理由は明らかです。1、2、3か月で彼に戻ったとしても。私たちは、ユーザーがそれを使用するのが悪く、不快であると思った理由を常に確認します。

3.根拠が必要でない場合

突然ね =）

それにもかかわらず、アンチパターンには「明らかに」例外があります。システムが以下の場合、理論的根拠を書く必要はありません。

• 電話を切った。
• 未処理のエラーで落ちました。

特に本番環境でこれが発生した場合。私たちのサイトが正当な理由がない場合、ゴングを打ち負かして開発者に「緊急に修正してください！」まったくバグなしで可能です。そして、簡単な「メインのエラー500」でこれで十分です。

「常に必要である」ため、指から理論的根拠を吸い出さないでください。「システムが落ちてはいけない」と書くことは、テキストのためのテキストです。

しかし！期待される結果を書く必要があります。自明であると思われる場合でも、書き留めてください。削除されることはありません。

手順 example.comを
開きます

結果
エラー500の

予期される結果の
メインページが開きます

ここではすべてがシンプルなようです-メインは開きませんが、開きます。しかし、もっと複雑な例があります。

たとえば、開発者がTKから式を作成し、どこかでゼロによる除算が発生したとします。 「エラーがあってはならない、レポートがロードされる」と書くだけでも、開発者は「それではどうやって開くべきですか？」ゼロによる除算があります！」

考え直して、「式に従ってそのような値でレポートが開くことを期待します」と書く必要があります-そこに何があるべきかを考える限り、TORでジョイントを見つけることができます。そして、アナリストに正しい方法を確認してください。



したがって、正当な理由がなくても、少なくとも期待される結果はあります。これはルールの例外であることを忘れないでください。システムが落下してフリーズすることはありません。ただし、このようなバグはまれであり、他の場合には正当化が必要です。

4.まとめ

3つのアンチパターンについて説明しました。怒り、否定、バグの正当化の3段階：

1. 明らかに -正当化しないことは明らかです。そして、私たちは「ああ、私はなぜ私が望んでいたのか忘れていました」...を取得します。半年後、あなた自身がその理由を忘れます。どんなに愚かで、どんな証拠があるのか​​を説明してください。
2. 私は母に誓います、そうです！-なぜ誓うのですか？何らかの理由で、あなたはそれがとても正しいと思うので、その理由を教えてください。たとえば、要件へのリンクを提供します。
3. バニーは気分を害しました -「ああ、メインに猫を追加しなかったのですか？さて、それだけです！私は気分を害しました...そして消えました！そしてあなた！顧客を失った!!」しかし、あなたにとって不便なことは、他の人にとっては便利かもしれません。感情を取り除き、事実を伝えてください。

代わりに、正しい理論的根拠を使用する必要があります。

1. — , , , ...
2. — , -, !
3. — , , ( ). , .

これが本当にバグだと判断した理由と、ここで書いたとおりに修正したい理由を必ず書いてください。「5 Why」シリーズから質問をします

-なぜこれが明らかだと思いますか？
-なぜそうだと思うのですか？
-ユーザーが動揺すると思うのはなぜですか？

インターネット上の要件へのリンクを提供し、統一性を示し、ユーザーの実際の問題について話します。

そして、1年後にあなたが有能に実行されたタスクを再読するとき、あなたはまだ「ありがとう！」と私に言うでしょう