AtlassianのQA

AtlassianでクラウドQAマネージャを務めるMark Hrynczak氏は同社の今年のサミットで高い価値のQAチームはどのように振舞うかについての氏のビジョンを語った。

氏は、QAチームの価値を、第一に企業の戦略的目的と完全に足並みを揃えること、と定義している。足並みを揃えることで、企業が特定のタイミングで直面するかもしれない重要な問題の解決に貢献するのだ。

InfoQ:“Quality Assistance”モデルの構成要素と“QA Champion”と呼ばれるモデルへどのように進化したのか、簡単に説明いただけますか。

Hrynczak: “Quality Assistance”モデルはソフトウエア開発チームは品質とスピードを両方とも最適化する必要があるという考えに基づいています。このふたつはトレードオフにあるとは考えません。テストステージやテストプロセス、テスターを追加することで品質を改善するのではなく、課発者が自分たちの機能をプロダクションの品質基準へ向けてテストするように支援し教育します。ソフトウエアの品質を高めるQAチームというよりは、開発チームの生み出すソフトウエアの品質向上を支援します。詳細はhttps://www.atlassian.com/inside-atlassian/qaに書きました。

InfoQ:ネットプロモータースコア(NPS)は企業が、正しい問題に向かい合っているかどうかを保証のに使えるおすすめのツールです。企業の顧客満足を評価するツールとしてのNPSをどのようにしてQAチームのメンバーの具体的な動きに結びつけるのでしょうか。

Hrynczak: 私たちのNPSの利用はプロダクトに基づいています。断続的に製品内でダイアログ表示して使っている製品の評価をしてもらい、データを収集しています。私たちの製品には非常にたくさんのユーザーがいます。データの収集と分析はユーザーの感情についてたくさんの洞察を与えてくれます。この洞察は未来の意思決定のガイドになります。ユーザーはどのような機能が使いたいのか、製品のどの部分が使いにくいのか、どのようなタイプのバグや振る舞いがユーザーにもっとも不満を与えるのか。私たちはNPSのスコアを特定のチームのメンバの活動と強く結びつけようとはしていません。チーム全体のメトリクスだからです。データから得られた洞察に基づいてアクションをする場合、その洞察に関連するデータで上昇傾向が見られるのを期待します。

InfoQ:あなたの講演のひとつの重要なアイディアは改善を、予防や緩和、撲滅といった先回りの方法で置き換えるということでした。これらの方法について詳しく教えてください。どのような利点があるのでしょうか。

Hrynczak: 今、上がった例について下に説明します。

• 予防: 共通の原因から生まれるバグにはパターンがあります。例えば、特定の文字列が望ましくない事象を生む場合、従来のアプローチでは、テスターはデフォルトのテストデータとして使う文字列を作り、テストをするときはいつでもその文字列を使ってテストをし、バグを検出します。このやり方で、良いテスターとして認識されるのです。一方、予防のアプローチでは、これらの文字列を開発の前に開発者に渡します。これらの文字列をサポートする必要があるということを事前に合意しておき、開発者がこれらの文字列を考慮したコードを書くようにします。

• 緩和: プロダクションにはたくさんのユーザーがいます。バグがデプロイされたら大きなインパクトを与えます。従来のテストの方法では、時間と労力を費やして潜在的なバグをしらみつぶしにしてそのインパクトからユーザーを守ります。緩和というアプローチでは、デプロイ戦略自体を変えます。段階的なロールアウトやブルー/グリーンデプロイ。エラーのモニタリング、自動ロールバックなどの方法です。バグはデプロイ前のチェックをすり抜けてしまうかもしれませんが、デプロイを停止したりロールバックしたりできるので影響は限定的になります。優れた戦略をもってすれば、内部のユーザーや重要でないユーザーにのみ影響を受け、実際の顧客には全く影響を与えないようにできます。

• 撲滅: 開発者が無自覚だったり、忘れていたり、防御的にコードを書いていないと、セキュリティ問題が発生します。たったひとつの脆弱性が製品を危険にしてしまうのです。すべての変更に対して広範囲にテストするのではなく、コードをデフォルトで安全にすることでこのような問題がおきる可能性を大幅に減らせます。テンプレートライブラリの自動エスケープ機能を使えばXSSを避けられます。動的に生成されるトークンを使ってCSRFを避けることができます。セキュリティ診断を完全になくすことはできないかもしれません。しかし、同じようなバグの発生を大幅に削減することはできるでしょう。

InfoQ: QAをボトルネックであると感じ、あなたの会社と同じような方向に向かいたいと思っている企業に具体的なアドバイスをお願いします。

Hrynczak: 従来の考え方から品質支援の考え方に変えるのは組織文化の変更が必須です。QAだけではなく、開発者、リーダー、他の利害関係者も変わる必要があります。全員を納得させる必要はないかもしれませんが、この新しいモデルが効果的であり品質も目的を達成していることがわかれば、多くの人が評価してくれるでしょう。それにはいくつかの前提があります。

• リーダーが支援をし、このモデルに開かれていること。リーダーはチーム全体が良い成果にも悪い成果にも責任を持つようにしなければなりません。開発者がひとつのストーリーのコーディングとテストに時間をかけることは、テストを短縮して完了を早めるという点で良いことだという認識を持つ必要があります。また、リーダーは大きな影響を与えたバグが出荷されてしまったのをQAチームが補足できなかったからだと考えるのには抵抗を示さなければなりません。

• 開発者はエンドユーザーのことを考え、品質の良いソフトウエアを作るように動機づけられている必要があります。高品質でバグのないコードを書いて出荷できる開発者は優れているという一般認識がなければなりません。テストチームはミスを補足するためにあると考える従業員は基準に達していないかもしれません。

• QAチームのメンバは“テストをする”ということ以上の価値を自らに見出す必要があります。高速開発のワークフローを理解し、自分たちは信用ならない開発者と価値を生み出すエンドユーザーの間の門番であるという考えを捨てる必要があります。この役割で成功するのに必要なスキルは従来のものとは異なり、心地よいものではないかもしれません。これについてはhttps://www.atlassian.com/inside-atlassian/software-QA-skillsで詳しく書きました。