QAの誰かが極端なプログラミングプロジェクトで効果的に作業するには、どのようなプログラミングスキルが必要ですか？
まあ、タイトルは本当にすべてを語っていますが、少し詳しく説明すると、ランダムで通常は効果的なQA部門を担当して、XP環境での学習を習得させることができます（学習曲線を使用してXPワークフロー）を選択するか、効果的なプログラミングスキルがさらに必要ですか？必要な場合、何を知る必要がありますか？
XPへのQAチームの変換？
あなたが尋ねるこの質問は、多くの伝統的なテスターがキャリアの存続のために依存しているものです。
短い答えは多分です。ワークフローを問題として特定するのは正しいことですが、プログラミングと開発のトレーニングに比べてワークフローは単純です。テスターをプログラマーにすることは、あまりにも遠い橋かもしれません。テスターの現在のスキルセットにより近い他の多くのスキルがあります。
ソフトウェアテストエンジニアの役割はあると思いますが、2つの新しいクリーチャーが登場しました。テスト駆動開発者とテストのソフトウェア開発エンジニアが、STEに所属していた多くの芝生を引き継ぎます。
XPワークフロー
XPワークフローの下では、ユニットテストは開発者の責任です。通常、ワークフローには、ストーリーカードの作成、ユースケース図といくつかのユースケースの作成、それらのテストケースへの変換が含まれます。 。テストケースは、テスト駆動開発（TDD）と呼ばれる方法で開発を推進します。プログラムが存在する場合、毎分最初に実装されるテストケースがあり、その後、最初に失敗するコードが続き、その後、追加の作業の後にパスします。そのテスト。ストーリーカードから識別されたすべてのテストに合格すると、製品が実行されます。または、少なくとも最新の増分が実行されます。ユニットテストは、言語に依存する方法で作成され、コードの一部です。多くの参照がありますが、簡単なイントロについては、ウィキペディアをチェックしてから、スコット・アンブラーによる次のWebページを参照してください。
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と自動テストが実行されない手動テストにマップする方法を学びます。
- システムエンジニアがシステムを理解できるようにしますが、文書化されていない曖昧なものを決定するのではなく、明確にするのに役立ちます。
- 開発者と一緒に毎日のサイクルに参加します。これは、テスト対象の機器とテストツールの頻繁で迅速な再構成を意味します。
- 環境によっては、開発者がテスターよりもはるかに幅広いツールセットを使用している場合があります。ラボで使用しているものがある場合、それはお世辞であり、開発者による臨時のトレーニングと臨時のトレーニングのためのより親切な環境です。例としては、仮想マシンマネージャーとVMの使用、SSHまたはリモートデスクトップを使用したネットワーク経由のリモートデバッグまたは診断、画面キャプチャまたはカメラやスマートフォンで写真を撮ることによるデバイスの状態またはUIの外観を保存する機能、およびネットワークディレクトリまたはサムドライブ。
- ログデータを使用した予備分析は、スプレッドシートに移動され、プロットに変換されました。ビッグデータについては多くのものが書かれており、ラボやベータテストサイトからのテスト出力がビッグデータになる場合があります。
- ベータテスト中の顧客インターフェースを促進する方法を学びます。これには、電話で顧客を文書化して指導することによるログファイルの取得が含まれる場合や、クラッシュダンプを開発者（またはトリアージするスキルがある場合はあなたに）に直接配信する自動システムにフックされる場合があります。
- ソフトウェアレベルおよびシステムレベルの製品の定量分析のサポートを支援します（以前と同じですが、それ以上）。
- プロジェクトの終わりだけでなく、毎週または毎日、開発者が自由に使用できるさまざまなテスト方法とツールの数、および作業の品質を保証するように要求するために適切に機能するものをより多く知る方法を探します。
- テスターがどのように支援できるかについて、組織の開発者にどのようなビジョンがあるか尋ねてください。これまでにお互いの背中を見ていたら、うまくいくはずです。あなたは一緒に素晴らしいアイデアを得るべきです。
XP=）への移行と、同じことを行うためのチームの準備に頑張ってください。