QAの誰かが極端なプログラミングプロジェクトで効果的に作業するには、どのようなプログラミングスキルが必要ですか？

まあ、タイトルは本当にすべてを語っていますが、少し詳しく説明すると、ランダムで通常は効果的なQA部門を担当し、XP環境での作業を学ぶことができます（もちろん、XPワークフローを習得するための学習曲線があります）。彼らは効果的になるためにより多くのプログラミングスキルを必要とするでしょうか？もしそうなら、彼らは何を知る必要がありますか？

XPへのQAチームの変換？

あなたが尋ねるこの質問は、多くの伝統的なテスターがキャリアの存続に依存しているものです。

短い答えは多分です。ワークフローを問題として特定するのは正しいことですが、プログラミングと開発のトレーニングに比べてワークフローは単純です。テスターをプログラマーにすることは、あまりにも遠い橋かもしれません。テスターの現在のスキルセットにより近い他の多くのスキルがあります。

ソフトウェアテストエンジニアの役割はあると思いますが、2つの新しいクリーチャーが登場しました。テスト駆動開発者とテストのソフトウェア開発エンジニアが、STEに所属していた多くの芝生を引き継ぎます。

XPワークフロー

XPワークフローでは、単体テストは開発者の責任です。通常、ワークフローには、ストーリーカードの作成、ユースケース図といくつかのユースケースの作成、それらのテストケースへの変換が含まれます。テストケースは、テスト駆動開発（TDD）と呼ばれる方法で開発を推進します。プログラムが存在するたびに、最初に実装するテストケースがあり、その後、最初は失敗するコードが続き、その後、追加の作業の後にそのテストに合格します。ストーリーカードから識別されたすべてのテストに合格すると、製品が完成します。または、少なくとも最新の増分が行われます。単体テストは言語に依存する方法で作成され、コードの一部です。多くの参考文献がありますが、簡単なイントロのためにウィキペディアをチェックしてから、スコット・アンブラーによる次のウェブページをご覧ください。

http://www.agiledata.org/essays/tdd.html#WhatIsTDD

また、テストケースはストーリーカードとユースケースに基づいているため、システムの受け入れテストとはかなり重複しています。ATDD（Acceptance TDD）は区別しますが、それは一種の恣意的なものかもしれません。

誰もが同じ真剣さでテストを受けるわけではありません。マネージャーは開発者にテストしないように要求できます。彼らは、テスターに​​もテストしないように要求することができます。私のチームの開発者が予算に費やされていた1年はかなり大変でしたが、プロジェクト計画では最終的に2週間しか機能しなかったにもかかわらず、プロジェクトのテスターは週に数時間バグ修正と新機能をテストしました。それは正しいことのように思われ、プロジェクトは依然として収益性があり、それにより顧客はより良い製品を手に入れました。

開発者はテストする必要があります。テスターは実行、レポート、繰り返しを行う必要があるため、そうしないと非常に無駄になります。ソフトウェアの品質は、テスターよりも開発者の責任です。この共有により、テスターの生活に不満を感じることは少なくなりますが、すべての人に多くの知識とスキルを求める要求も高まります。

開発者がテストを真剣に受け取れない場合、ビルドを毎日取得するため、テスターへの要求が高まる可能性があります。しばらくの間、「なぜ私たちは一歩前進し、二歩後退しているように見えるのか」と言われることがあります。答えは、今やチームがこれまでになかったような可視性を備えたシステムを使用しているためです。これは、それらの人々が差し迫った災害について知っていたのは90％のマークでした。

テストの開発者への移行

私の経験では、開発を加速するために、テスターが行ったジョブを開発に移すことができます。これは、タッチスクリーンクリアのUIテストから、Windows Hardware Quality Labのテスト（WiFi用のWindowsドライバーなど）の非常に複雑なアイテムまで、すべてに当てはまります。

エンジニアがメモや技術情報を秘書に入力、複製、配布するように指示したPCより前の日を考えてみてください。メール、イントラネットWiki、バグ追跡のコメント、ソース管理またはコードレビューツール、インスタントメッセージングなどを使用している開発者と比較してください。テストが必要な変更が多すぎて、周囲のコミュニケーションと知識の伝達はそうです私たちのテストの多くは、テストを委任することなく、開発者が直接実装できるように自動化されています。

テスター向けの付加価値

私は、システムエンジニアになる可能性のあるテスターや、クレイジーな優れたコミュニケーションスキル（ほとんどマインドリーディング/テレパシー）を持つテスターと協力してきました。彼らとの私の最も効果的な仕事は、システムで見られた予期しない動作を説明するときに、通常はバグトラッカーに書いて、良い説明をしたときでしたが、デモは非常に役に立ちました。

もう1つの重要な基準は、コードの受け渡しの労力が可能な限り少ないことです。しばらくの間、テスターが独自のビルドを生成できると、開発者はある程度の安心を感じました。現在、私たちは常時統合サーバーを使用しているため、開発者はソースをコミットするだけで済み、TDDを正しく使用した場合、自身で実行してレポートするテストがたくさんあります。

グローバル競争がサイクルタイムを押し上げており、システムの手直しがやり直されています。明日、テスターから今日追加した欠陥について聞いた場合、今日欠陥を作らなかった（または自分で見つけた）相手とどのように競争しますか？私たちはまだそこにはいませんが、カットアンドトライのプログラマーの時代は過ぎ去ったと思います。多くのリハーサルを行った可能性のあるGoogle開発者のデモを見ましたが、90分の講義中にプログラムを最初から最後まで入力でき、変更と実行のサイクルに問題がほとんどないかまったくないため、説明を行っているようです。テスターは、作業とやり直しの時間を短縮することで付加価値を付けるため、今日のビルドに関する今日の簡潔なレポートは、大きな利点です。

新しいテストロール

多くの組織が、SDET-Software Developer Engineer in Testの役割を切り分けています。これらの人はスクリプト、コード、コードレビューを行います。次のリンクは、MicrosoftのSDETに関するブログです。

http://aliabdin.wordpress.com/2007/03/31/what-does-an-sdet-do/

また、見つけたバグをSDETにフィードするソフトウェアテストエンジニア（STE）についても説明します。SDETの役割について私を驚かせたもう1つのことは、従来のソフトウェア開発者とは異なり、バグのあるシステムがある場合、ほとんどすべての部分が問題の原因である可能性があるため、システム全体のコードを知る必要があるため、広範なメンタルマップが役立つことです。それを追跡します。

移行の成功につながるビジョンの形成

その役割をスクラムに組み込む方法がわからないプロジェクトマネージャーの同様の問題に遭遇しました。スクラムマスターであることは彼女の移行先でした。それは明確に定義された役割であり、そのためのトレーニングがあります。探し続けると、テストに似たものが見つかることがあります。

アジャイルテストの詳細については、こちらをご覧ください。

http://www.ambysoft.com/essays/agileTesting.html#AgileTestingStrategies

ここの独立したテストチームについて：

http://www.ambysoft.com/essays/agileTesting.html#IndependentTestTeam

スコットアンブラーがアジャイルと従来のアプローチの開発者とテスターの比率について観察した結果は、1日ではありません（15：1対3：1）。スキルとツールの専門知識に基づいて、テストチームのビジョンを理解して作成することをお勧めします。

• バグトラッカーで完全に流暢に。
• コミット、ブランチ、タグなどの開発者レベルのソース管理の概念を理解します。
• ソース管理システムからのコードコミットとそのコメントに関するレポートを実行できる。
• 解読する開発者がコミットコメントを話し、UIと自動テストが実行されない手動テストにマップする方法を学びます。
• システムエンジニアがシステムを理解できるようにしますが、文書化されていない曖昧なものを決定するのではなく、明確にするのに役立ちます。
• 開発者と一緒に毎日のサイクルに参加します。これは、テスト対象の機器とテストツールの頻繁で迅速な再構成を意味します。
• 環境によっては、開発者がテスターよりもはるかに幅広いツールセットを使用している場合があります。ラボが彼らの使用するものを持っている場合、それはお世辞と開発者からの臨時のトレーニングと臨時のトレーニングのためのより親切な環境です。例としては、Virtual Machine ManagerとVMの使用、SSHまたはリモートデスクトップを使用したネットワーク経由のリモートデバッグまたは診断、画面キャプチャまたはカメラやスマートフォンで写真を撮ってデバイスの状態またはUIの外観を保存する機能、およびネットワークディレクトリまたはサムドライブ。
• ログデータを使用した予備分析は、スプレッドシートに移動され、プロットに変換されました。ビッグデータについては多くのものが書かれており、ラボやベータテストサイトからのテスト出力がビッグデータになる場合があります。
• ベータテスト中の顧客インターフェースを促進する方法を学びます。これには、電話で顧客を文書化して指導することによるログファイルの取得が含まれる場合や、クラッシュダンプを開発者（またはトリアージするスキルがある場合はあなたに）に直接配信する自動システムにフックされる場合があります。
• ソフトウェアおよびシステムレベルの製品の定量分析のサポートを支援します（以前と同じですが、それ以上）。
• プロジェクトの終わりだけでなく、毎週または毎日、開発者が自由に使用できるさまざまなテスト方法とツールの数、および作業の品質を保証するように要求するために適切に機能するものをより多く知る方法を探します。
• テスターがどのように支援できるかについて、組織の開発者にどのようなビジョンがあるか尋ねてください。これまでにお互いの背中を見ていたら、うまくいくはずです。あなたは一緒に素晴らしいアイデアを得るべきです。

XPへの移行、およびチームが同じことを実行するための準備に幸運を。

通常のテスト駆動開発では、QAがプログラミングを知っている必要はおそらくありません。

しかし、振る舞い駆動型の開発を行っている場合、QAがCucumberのような言語を知っていると有益です。特に、ビジネスアナリストが「必要なときに」のスタイルでストーリー要件を記述している場合は特にそうです。

しかし、それは本当にあなたの「人」とあなたが働いているツールに依存します。プログラミングの知識がまったくなくても効果がある可能性はあると思いますが、確かに害はなく、より効果的になる可能性があります。