Clever Geek Handbook

テスタヌ間の問題の同䞀性





品質保蚌郚QAは、゜フトりェアのバグを怜玢したす。 方法は䌚瀟によっお異なりたすが、通垞は゜フトりェアに粟通しおいる人がこれを行いたす。 圌らはさたざたな方法でそれを䜿甚し、開発者が芋逃したバグを芋぀けようずしたす。



QAずいう甚語は、プロセス自䜓、組織、およびこの組織内の個々のテスタヌを指す堎合がありたす。 通垞、品質保蚌組織のテスタヌは「QA」ず呌ばれたす。 この蚘事では、䞀貫性を保぀ために、より正確な「品質保蚌テスタヌ」ではなく、䞀般的な略語QAを䜿甚したす。



補品の党䜓的な品質に関しお、䌚瀟ごずに異なるQAの責任がありたす。 バグを探しおその数を数えるだけの堎合、「品質保蚌」ずいう甚語がこの郚門に完党に圓おはたらない堎合がありたす。



以䞋は、QA郚門の問題のある個人です。





消防ホヌス



非垞に倚くのバグレポヌトを非垞に迅速に報告し、開発チヌムが決しお終わらないテスタヌ。




問題



バグが芋぀かった堎合は、明確なレポヌトを䜜成し、すぐに適切な開発者に割り圓おるこずが重芁です。 ただし、䞀郚のテスタヌは、開発チヌムが修正するよりも早くバグを芋぀けるこずができたす。 このため、バグのリストは絶えず増え続けおおり、すべおを閉じるこずはできたせん。



䞀芋、補品の品質に問題があるように芋えるかもしれたせんが、これは垞にそうではありたせん。 非垞にバグの倚いプログラムで動䜜する通垞のテスタヌずは異なり、消防ホヌスは、1぀以䞊の特城的なプロパティを持぀雪厩のレポヌトを生成したす。





消防ホヌスのテスタヌは、倚くの堎合、盎接たたは間接的な䌚瀟のプレッシャヌにさらされたす 。 ゚ラヌが倚くなればなるほど、仕事がうたくいきたす 。 これにより、実際の゚ラヌの根本原因を泚意深く監芖し、明確か぀簡朔に報告するQAテスタヌは、単䜍時間あたり最倧数のレポヌトを発行する消防ホヌスよりも生産性が䜎いず考えられたす。



このようなテスタヌの掻動はプロゞェクトのパニックを匕き起こす可胜性がありたす。補品の品質が䜎く、プロゞェクトが予定より遅れおいるためです。 圌らの士気ぞの圱響は即座に劇的なものになる可胜性がありたす。開発チヌムはバグ報告の流れを䞭断するように祈っおいたす。



解決策



消火ホヌスを修理する前に、それを正確に識別し、非垞にバグの倚いシステムに遭遇した効果的なQAず混同しないようにするこずが重芁です。 最も明確な蚌拠は、開発者の苊情から来おいたす。





状況を改善するには、倚数の゚ラヌを報告するむンセンティブがないこずを消火ホヌスに説明する必芁がありたす。目暙は、システムの品質を改善し、開発者を支揎するこずです。 その埌、補品の品質は同じたたはより良いペヌスで改善されたすが、パニックは発生したせん。



怜察官



QA。バグが芋぀かった埌、開発者はプログラムをテストしおいないず非難したす。




問題



理論的には、開発者は補品をQA郚門に転送する前にバグを芋぀けお修正できたす。 したがっお、䞀郚のテスタヌは、開発者が自分の䜜業を十分にテストしおいないずいう別の蚌拠ずしお芋぀かった各゚ラヌを認識したす。 この反論の䜙地のない議論により、怜察官は開発チヌムに関する吊定的な意芋をさらに倧声で衚珟するこずができたす。



怜察官はチヌムの士気を食い尜くしたす。 補品の品質を向䞊させるのではなく、開発チヌムが仕事をしおいないこずを蚌明しようずしたす。 各゚ラヌは、開発者がバグを特定するのではなく、QAに過床に䟝存しおいるずいう蚌拠の山に远加されたす。



残念ながら、怜察官は兞型的でかなり予枬可胜なプロセスの結果ずしお䜜成されたす。



  1. 本番環境で重倧な゚ラヌが怜出されたした。
  2. テスタヌはこのバグを芋逃しおいるず非難されおいたす。


これはあたりにも頻繁に発生するため、QAは反論の䜙地のない議論を䜿甚しお自然に防埡したす。



解決策



告発者を修正する前に、組織は最初に生産䞊のバグのQAを非難する必芁がありたす。 これを行う人は、゜フトりェア品質を改善するためのより生産的な方法で蚓緎される必芁がありたす。



組織が生産バグ​​のQAを非難するのをやめたずき、圌の心ず態床を倉えるように圌を招埅するこずによっお、告発者テスタヌを修正するこずができたす。



開発者は単なる人間であり、すべおの人々が間違いを犯しがちであるこずを圌に䌝えおおく必芁がありたす。 QA郚門は、顧客に圱響を䞎える゚ラヌに察する保護ずしお機胜するこずにより、開発者のこの自然な人的財産を補う必芁がありたす。 さらに、退屈で退屈なコヌディングプロセスのため、開発者は朚の背埌にある森を芋ないようにするのは非垞に簡単です。



態床の倉化私たちは党員がチヌムで働いおいるこずを芚えおおく必芁がありたす。仲間はミスを互いに責めるべきではありたせんが、チヌムの利益のために修正するのに圹立぀はずです。 プロゞェクトのためにQAが開発チヌムずパヌトナヌシップを確立するこずは特に重芁です。バグを怜出し、報告し、バグを修正するラむフサむクルの途切れないプロセスは、補品の品質にずっお重芁です。



譊報係



QA。補品党䜓の品質は蚱容できないレベルであるず述べおいたすが、その意芋は衚面的な印象にのみ基づいおいたす。




問題



基本的に、アプリケヌションの機胜によっお品質が異なりたす。 比范的単玔なものもあれば、高床なスキルを持぀開発者によっお開発されたものもあるため、゚ラヌはほずんど、たたはたったくありたせん。 他のものは比范的掗緎されおいるか、経隓の浅い開発者によっお開発されおいるため、バグでいっぱいです。 譊報係は、すぐに質の悪い地域に出くわす幞運ではありたせんでした。 さらに調査するこずなく、圌は補品党䜓が䞍適切であるず発衚したした 。



QAが開発者を疲れさせ、時間を浪費する方法に぀いお倚くのこずを話すこずができたす 誀解を招くタむプのテスタヌを参照が、これは2぀の状況です。 実際、開発者はQAの十分にテストされおいない゜フトりェアを意識的に䞎えお、行われた䜜業に察する報酬を埗るか、期限に間に合ったこずを宣蚀したす。 QAがこのようなシステムのテストを開始するず、開発者が目にするはずの倚くの゚ラヌがすぐに発生したす。 したがっお、圌が芋たものを補品党䜓に倖挿し、非垞に䜎い品質を䞻匵しおいるこずは明らかです。



通垞、譊戒員はQA郚門で䜕らかの暩限を持ち、圌の意芋は尊重されたす。 圌の暩限のレベルが高いほど、プロゞェクトぞの圱響は砎壊的です。 兞型的なシナリオは次のずおりです。





これは、子䟛を氎で投げる叀兞的なケヌスです。 特に開発チヌムが未怜蚌の゜フトりェアをQAに転送するずいう評刀がある堎合、QAが正しい遞択をするこずがありたす。 しかし、1人の開発者が匱いためにアラヌムが発生するこずがありたす。



解決策



開発チヌムから繰り返し倱望させられた堎合、テスタヌは譊戒心を持ちたす。 圌女が垞に高品質の゜フトりェアを提䟛した堎合、䞍信の理由はありたせん。 しかし、テスタヌが譊戒心を抱くようになった堎合、開発チヌムが自信を持っお取り戻すこずは困難になりたす。特に、チヌムの開発者が䞭囜の店で無胜な 象を実際に持っおいる堎合はなおさらです。



通垞、倧芏暡な開発チヌムでは、チヌム党䜓ではなく、個々の開発者から䜎品質のコヌドが生成されたす。 そのため、胜力の䜎い開発者の䜜業を最埌にテストするか、譊告に陥らないこずが䞍可欠です。 ただし、これにより、プロゞェクトに悪圱響を䞎える開発者がチヌムにいるずいう本圓の問題が隠されたす。



科孊者



新しいバグを芋぀けるのではなく、バグの蚘録にほずんどの時間を費やすテスタヌ。




問題



システム内の問題を芋぀けるこずは、宝探しず同じくらい刺激的です。 そしお、あなたがこの宝を芋぀けたずき、パズルを解くこずはそれほど面癜くない。 この方法で゚ラヌを芋぀けるプロセスを怜蚎するテスタヌが理想的であるず䞻匵できたす。 しかし、圌が魅力的な旅を泚意深く蚘録しようずするず、問題が発生したす。 開発者は、䞻な問題に焊点を圓おる代わりに、倚くの圹に立たない詳现を含む長いストヌリヌを読んで、関連情報を遞択しようずしたす。



科孊者は、「バグを慎重に文曞化する」ずいう芁件を文字通り認識しおいたす。 圌はそれらをテキスト履歎の圢で説明し、再珟のための明確な䞀連の手順を含む簡単な説明ではありたせん。 このようなレポヌトの読み取りには非垞に長い時間がかかり、最終的には正確に問題が䜕であるかがただ䞍明です。 通垞、このような説明にはいく぀かのバグが含たれおおり、これは特定の問題ではなく、システムの広範囲を指したす。



科孊者から゚ラヌメッセヌゞを受信する際の開発者からの䞻な䞍満は、信号察雑音比が䜎すぎるこずです。 圌らは意識の流れをふるい分け、特定の詳现を探すこずに時間を費やしたす。 これは、開発者ずテスタヌの䞡方にずっお時間の無駄です。



解決策



QAの科孊者は、正しいレポヌトの曞き方を教えるこずで簡単に修正できたす。 倚くの堎合、蚂正は、圌に必芁なこずを説明するずすぐに行われたす。 適切なスタむルを教えるための最も効果的な方法は、1぀以䞊のレポヌトを正しい圢匏で曞き盎すこずです。これは、将来のモデルずしお圹立ちたす。 その結果、熱狂的なテスタヌは、より理想的にするこずができない゚ラヌの明確で簡朔なレポヌトを䜜成したす。



誀解を招く



゚ラヌをしばしば䞍正確に報告するQAは、開発者が問題を再珟しお修正しようずするず、間違った方法で導きたす。




問題



゚ラヌレポヌトには次のものが含たれおいる必芁がありたす。



  1. 実際に間違いがあるこずを刀断する胜力
  2. バグを再生する手順を定矩する機胜
  3. ゚ラヌの完党な説明。倚くの堎合、根本原因が含たれたす
  4. バグを再珟する明確な手順


これらの段階のいずれにおいおも、レポヌトは開発者を誀解させる可胜性があり、その結果、時間を無駄にしたす。





簡単なテスタヌ゚ラヌのために、開発者が混乱する堎合がありたす。 しかし、誀解を招くテスタヌがそのようなレポヌトを生成するこずが倚く、開発者の間でかなりの䞍満が生じたす。 状況が続くず、テスタヌは最終的に開発者の信頌を倱い、実際のバグでさえも修正されなくなり、そのような゚ラヌ報告は拒吊されたす。



解決策



誀解を招くQAは倚くの堎合、バグを芋぀けるのに適しおいたすが、バグの蚘録は䞍十分です。 したがっお、圌を蚓緎するのに努力する䟡倀がありたす。



最も効果的な方法の1぀は、開発者を監芖するこずです。開発者は、圌のレポヌトに基づいお、問題を特定しようずしたす。 レポヌトの1぀を受け取った開発者の隣に座っお、開発者がどのようにそれを理解しようずしおいるのかを干枉するこずなく静かに芳察するだけで十分です。 通垞、これにより、バグを報告する最善の方法に぀いお健党な䌚話が行われ、開発者ずQAの䞡方に利益がもたらされたす。



抑圧された



QA。開発者によっお、゚ラヌを報告する可胜性が䜎く、いじめを恐れる皋床にbeatられおいたす。




問題



おそらく、QAに察する開発者の兞型的な態床ほど倧きな免責の兆候はありたせん。 さらに、攻撃的な開発者は、テスタヌがコヌドの自然な゚ラヌを報告したずしおも、公然ずテスタヌを脅迫しおいるこずがわかりたす。 これに察抗するには、積極的な開発者ず䜜業する際のQAの成功には、次の特性が必芁です。





残念ながら、倚くのテスタヌがそのような特性を持っおいるわけではないため、開発者はしばしばそれらに぀いお足を拭き、䞻にQAを新しいバグの怜出のせいにしたす。 これがいかに非論理的に芋えるずしおも、これは次の条件䞋での兞型的な状況です。





QAが時間をかけお培底的に打ち負かされた埌、通垞、ストレスを軜枛するために敵察的な開発者ずの察立を回避したす。 その結果、これらの特定の開発者からのバグが報告されるこずはほずんどありたせんが、バグは存圚する可胜性がありたす。 原則ずしお、本番環境で問題が発生した堎合にのみ状況が怜出され、テスト郚門がバグを怜出しなかった理由の調査が開始されたす。 意気消沈したテスタヌは、次のいずれかの説明を提䟛したす。





消極的なキャラクタヌは、抑圧されたQAを認識するのをしばしば困難にしたす。 重芁なのは、このQAが連携する開発者の分析-敵意の明らかな兆候の怜玢です。



解決策



倚くの堎合、開発者はテスタヌを盎接モックしたす。 したがっお、これらはフヌリガンず同様に扱う必芁がありたす。





特に深刻なケヌスでは、特に状況が悪化しお敵意を露呈した堎合、人事郚が介入する必芁がありたす。



この状況が䟋倖ではなく暙準であるこずは残念です。 唯䞀の違いは敵意の皋床です。



ランダムクリッカヌ



ランダムクリック方匏で゚ラヌを怜玢するQA。




問題



システム内のバグの怜玢は、䞻に2぀の方法で実行されたす。



  1. テスト蚈画に埓っお、テストケヌスのリストを系統的に凊理したす。
  2. ナヌザヌのアクションを゚ミュレヌトしようずしお、アプリケヌションをランダムにさたよう。


テスト蚈画の䜜成は時間のかかる䜜業であり、テストが開始されるたでに、芁件を倉曎した埌でも蚈画が匕き続き適切であるずいう保蚌はありたせん。 これは、テスタヌがテスト蚈画を完党に攟棄し、代わりにバグを芋぀けるこずを期埅しおアプリケヌションず察話するずいう事実に぀ながる可胜性がありたす。



実際、特に補品開発の初期段階では、アプリケヌションずの偶発的なやり取りにより゚ラヌが明らかになりたす。 ただし、補品が叀くなるに぀れお、この方法で゚ラヌを芋぀けるこずははるかに困難になりたす。残りのバグは境界線の堎合に隠されおいるためです。 これは、単に適切にテストされおいなかったずしおも、アプリケヌションに゚ラヌがなかったかのように、誀ったセキュリティ感芚に぀ながりたす。



蚈画に文曞化されおいない状況を明らかにする可胜性があるため、アプリケヌションずのランダムな盞互䜜甚は受け入れられる方法論であるこずに留意するこずが重芁です。 しかし、これはテスト蚈画ぞの単なる远加であり、代替ではありたせん。



解決策



ランダムクリッカヌは、次の2぀の堎合のいずれかで衚瀺されたす。



  1. 圌は、アプリケヌションを正しくテストする方法を教えられたせんでした。
  2. 圌は積極的にテスト蚈画を曞くこずを避けおいたす。


問題がトレヌニング䞍足である堎合、それを提䟛する必芁がありたす。 ただし、この堎合、テスタヌは2番目のカテゎリヌに分類される可胜性があり、テスト蚈画を立おる必芁はないず知っおいおも、テスト蚈画を立おるこずは望みたせん。



適切なテスト蚈画を䜜成するには、たれなレベルの組織、勀勉、および集䞭力が必芁です。 その結果、特定の皮類の人々はそのような仕事を楜しんでいたすが、ほずんどの人はそうではありたせん。 運がよければ、ランダムクリッカヌが適切なテスト蚈画を䜜成するために必芁な特性を芋぀けたすが、その可胜性はわずかです。



倧胆に



開発者がレポヌトを倱瀌ず解釈するほど受動的で攻撃的なレポヌトを持぀テスタヌ。




問題



正しい゚ラヌ報告は、時間がかかり、認知的に困難なプロセスであり、QAの䞭には十分な劎力をかけたくないものもありたす。 原則ずしお、これらはいく぀かの暩利を持぀テスタヌです。圌らは蚀葉遣いを詊しお遞択する必芁はないず考えおいたす。 たた、開発者を軜芖するこずも倚く、ある皮の゚ラヌ分析に時間を費やす䟡倀がないずは考えおいたせん。



䞍泚意なテスタヌからの兞型的なバグレポヌトには、次のフレヌズが含たれおいたす。





明らかに、開発者は、゚ラヌを再珟するための手順の代わりに同様のフレヌズを䜿甚するレポヌトにあたり満足しおいたせん。 これはプロのQAアナリストによっお報告されるこずはめったにありたせんが、バグを探すように䟝頌された䌚瀟の別の埓業員が゚ラヌを報告した堎合によく起こりたす。 これは通垞、リリヌスたでの時間がほずんどなく、十分なテスタヌがいないずきに発生したす。 このような「ヘルプ」の結果ずしお、開発者がレポヌトを拒吊するため、通垞は混乱が生じ、チヌム内でさらに論争を匕き起こし、whichをさらに深めたす。



解決策



䞀般的に、プロのテスタヌはバグを芋぀ける責任がありたす。 残念ながら、業界では誰でもバグを怜玢できるずいう意芋がありたすが、そうではありたせん。 ゚ラヌは誰でも怜出できるず蚀う方が正確ですが、原則ずしお、プロのQAスペシャリストのみが境界線の状況に隠された重芁な゚ラヌを識別し、開発者がこのバグをすぐに理解、再珟、したがっお修正できるように報告するこずができたす。



䞍泚意に行動するテスタヌは、そのような軜薄なレポヌトに察するすべおの暩利があるず考えおいたす。 圌がQA郚門に入れば、圌の非生産的な行動を修正するように譊告されるべきです。 バグの怜玢が圌の盎接の責任ではない堎合、専門的に行うこずを習埗するたで゚ラヌの報告を犁止する必芁がありたす。



倚くの堎合、䞍泚意に倪字のテスタヌを単玔に削陀する方が、修正するよりもはるかに効率的です。 圌の行動によっお、圌はテストに埓事したくないこずを明確に明確にしおいるので、それを取り陀くこずは共通の利益です。



こちらもご芧ください



More articles:


All Articles