品質の責任者は誰ですか?

おい、ハブル！

私たちには、IT 製品の高品質な開発という新たな重要なテーマがあります。 HighLoad++ では、忙しいサービスを高速化する方法についてよく話します。また、Frontend Conf では、速度が落ちないクールなユーザー インターフェイスについて話します。 テストに関するトピックや、テストを含むさまざまなプロセスの組み合わせに関する DevOpsConf についてのトピックが定期的にあります。 しかし、一般的に品質と呼べるものと、それに包括的に取り組む方法については、そうではありません。

これを修正しましょう 品質会議 — 開発のあらゆる段階で、ユーザーにとっての最終製品の品質について考える文化を育みます。 自分の責任分野に焦点を当てず、品質をテスターだけでなく関連付ける習慣。

このカットの下では、プログラム委員会の責任者、Tinkoff.Business のテスト責任者、ロシア語を話す QA コミュニティの創設者と話をします。 アナスタシア・アシーバ・グエン QA業界の現状と新しいカンファレンスの使命について。

- ナスティア、こんにちは。 あなた自身について教えてください。

アナスタシア: 私は銀行でテストを管理しており、90 名を超える非常に大規模なチームの責任者です。 私たちは重要な事業分野を持っており、法人のエコシステムに責任を負っています。

私は力学と数学を勉強し、最初はプログラマーになりたいと思っていました。 しかし、興味深いオファーをもらったので、テスターとして自分自身を試してみることにしました。 奇妙なことに、これが私の天職であることが分かりました。 今、私はこの業界での自分の仕事をすべて見ています。

私は品質保証規律の熱心な支持者です。 私は、どのような製品が作成されるか、会社内、チーム内、そして原則として開発プロセス内で品質がどのように扱われるかについて無関心ではありません。

それは私にとって明らかです この方向のコミュニティは十分に成熟していません、少なくともロシアでは。 私たちは、品質保証がアプリケーションの要件への準拠をテストすることだけではないことを常に理解しているわけではありません。 この状況を変えたいと思っています。

—品質保証とテストという言葉を使っていますね。 平均的な人の目には、これら XNUMX つの用語が重なることがよくあります。 深く掘り下げると、それらはどのように異なるのでしょうか？

アナスタシア: むしろ、それらは何ら変わりません。 テストは品質保証分野の一部であり、私が何かをテストしているという直接的な活動です。 実際にはテストにはたくさんの種類があり、さまざまな種類のテストをさまざまな人が担当しています。 しかし、ここロシアでは、企業にテスターを供給するアウトソーサーの波が現れ、テストは単一の種類に縮小されました。

ほとんどの場合、テストは機能テストのみに限定されます。開発者がコーディングしたものが仕様に準拠しているかどうかをチェックするだけです。

— 他にどのような品質保証分野があるのか​​教えてください。 ここにはテスト以外に何が含まれますか?

アナスタシア: 品質保証とは、まず第一に、高品質の製品を作成することです。 つまり、製品がどのような品質特性を持つべきかを自問します。 したがって、これを理解すれば、誰がこれらの品質特性に影響を与えるかを比較することができます。 関係ない、 開発者、プロジェクトマネージャー、または製品スペシャリスト 製品の開発、そのバックログ、およびその戦略に影響を与える人物です。

テスターは自分の役割をより意識するようになります。 彼は、自分の仕事が要件への準拠をテストするだけでなく、要件をテストし、製品スペシャリストからの処方に疑問を呈し、クライアントの暗黙の要件と期待をすべて明らかにすることであることを理解しています。 新しい機能を顧客に提供するときは、顧客の期待に真に応え、顧客の悩みを解決する必要があります。 品質のすべての属性を考慮すれば、クライアントは満足し、自分が使用する製品を提供する会社がクライアントの利益を本当に気にかけており、「機能をリリースするためだけに」という原則に基づいて仕事をしているわけではないことを理解するでしょう。

――今おっしゃったのはプロダクトスペシャリストの仕事ですね。 これは原則として、テストや品質に関するものではなく、一般に製品管理に関するものです。

アナスタシア： 含む。 品質保証は、特定の人物が責任を負う分野ではありません。 現在、テストには一般的な方向性があり、それは と呼ばれるアプローチです。 アジャイルテスト。 彼の定義では、これがテストに対するチーム アプローチであり、特定の一連の実践が含まれると明確に述べられています。 このアプローチの実装はチーム全体が責任を負いますが、チーム内にテスターがいる必要さえありません。 チーム全体が顧客に価値を提供し、その価値が顧客の期待に確実に応えることに重点を置いています。

— 品質は周囲のほぼすべての分野と交差し、周囲のあらゆるものにフレームワークを課すことが判明しましたか?

アナスタシア： 右。 高品質の製品をどのように作成したいかを考えるとき、品質のさまざまな属性について考え始めます。 たとえば、クライアントが必要とする機能を本当に作成したかどうかを確認する方法です。

このタイプのテストが登場するのは次のような場合です。 UAT （ユーザー受け入れテスト）。 残念ながら、ロシアではほとんど実践されていませんが、エンドクライアント向けのデモとして SCRUM チームに存在することがあります。 これは外資系企業でよく行われるタイプのテストです。 すべてのクライアントに機能を公開する前に、まず UAT を実行します。つまり、エンド ユーザーを招待してテストを行い、製品が本当に期待に応え、問題を解決できるかどうかをすぐにフィードバックします。 この後にのみ、他のすべてのクライアントへのスケーリングが行われます。

つまり、私たちはビジネスとエンドクライアントに焦点を当てていますが、同時に テクノロジーを忘れないでください。 製品の品質は技術にも大きく左右されます。 アーキテクチャが悪いと、機能を迅速にリリースして顧客の期待に応えることができなくなります。 スケーリングしようとすると多くのバグが発生したり、リファクタリングしようとすると何かが壊れたりする可能性があります。 これらすべてが顧客満足度に影響します。

この観点から、アーキテクチャは、すべてを壊すことを恐れずに、すぐに変更を加えることができるクリーンなコードを作成できるようなものである必要があります。 そのため、単に膨大な量のレガシーがあり、長いテスト段階を実行する必要があるという理由だけで、改訂の繰り返しが数か月に及ぶことはありません。

— 合計すると、開発者、アーキテクト、製品サイエンティスト、製品マネージャー、テスター自身がすでに関与しています。 他に誰が品質保証プロセスに関わっていますか?

アナスタシア: さて、機能がすでにクライアントに提供されていると想像してみましょう。 明らかに、製品がすでに生産されている場合でも、製品の品質を監視する必要があります。 この段階では、明らかではないシナリオ、いわゆるバグが発生する可能性があります。

最初の疑問は、製品をすでにリリースした後、これらのバグにどのように対処するかということです。 たとえば、私たちはストレスにどのように反応するのでしょうか? ページの読み込みに 30 秒以上かかる場合、クライアントはあまり満足しません。

ここで搾取、つまり今で言うところの搾取が登場します。 DevOps。 実際、これらの人々は、製品がすでに実稼働しているときにその製品の操作を担当します。 これには、さまざまな種類の監視が含まれます。 テストのサブタイプとして、本番環境でのテストというサブタイプもあります。これは、展開前に何かをテストせずに、本番環境ですぐにテストすることを許可します。 これは、インシデントに迅速に対応し、影響を与え、修正できるようにするインフラストラクチャの組織化の観点からの一連の対策です。

インフラも重要です。 テスト中に、クライアントに提供したいものがすべて揃っているかどうかを確認できない場合がよくあります。 私たちはそれを本番環境に展開し、明らかではない状況を捉え始めます。 それはすべて、テストのインフラストラクチャが運用環境のインフラストラクチャに対応していないためです。 これは新しいタイプのテストにつながります - インフラストラクチャのテスト。 これらは、さまざまな構成、設定、データベースの移行などです。

これにより、おそらくチームはインフラストラクチャをコードとして使用する必要があるという疑問が生じます。

インフラは製品の品​​質に直接影響すると考えています。

カンファレンスで実際の事例を交えた報告があることを期待しています。 コードとしてのインフラストラクチャが品質にどのような影響を与えるかについて、ご自身の経験から教えていただける場合は、私たちまでご連絡ください。 コードとしてのインフラストラクチャを使用すると、すべての設定を確認したり、他の方法では不可能なテストを簡単に行うことができます。 したがって、高品質な製品を開発するプロセスには運用も含まれます。

— 分析とドキュメントについてはどうですか?

アナスタシア: これはエンタープライズ システムにさらに当てはまります。 エンタープライズについて話すとき、アナリストやシステム アナリストなどの人々がすぐに思い浮かびます。 彼らはテクニカル ライターと呼ばれることもあります。 彼らは仕様書を作成し、たとえば XNUMX か月間かけて完成させるタスクを受け取ります。

テストプロセス中にバグが特定され、返品が開始されるため、このようなドキュメントを作成すると、非常に長い開発反復と長い改良反復につながることが繰り返し証明されています。 その結果、ループが多くなり、開発コストが増加します。 さらに、これにより脆弱性が発生する可能性があります。 私たちはリファレンス コードを書いたようですが、その後、完璧に考え抜かれたアーキテクチャを壊す変更を加えてしまいました。

最終結果は、完全に高品質な製品とは言えません。パッチがすでにアーキテクチャに適用されており、一部のコードがテストで十分にカバーされておらず、締め切りが迫っているため、すべてのバグを迅速に解決する必要があるためです。 それはすべて、元の仕様では実装する必要があるすべての点が考慮されていなかったためです。

開発者は害虫ではないので、意図的にエラーのあるコードを書くことはありません。

最初に必要な点をすべて網羅した仕様を検討していれば、すべてが必要に応じて正確に実装されていたでしょう。 しかし、これはユートピアです。

100 ページにわたる完璧な仕様書を書くことはおそらく不可能です。 それが理由です ドキュメントの別の書き方を考える必要がある、仕様、タスクの設定により、開発者が必要なことを正確に実行できるようになります。

ここでアジャイルからのアプローチ、つまり受け入れ基準を備えたユーザーストーリーが思い浮かびます。 これは、小規模な反復で開発するチームにさらに当てはまります。

— ユーザビリティテスト、製品の使いやすさ、デザインについてはどうですか？

アナスタシア：チームにはデザイナーもいるから、これは非常に重要なポイントですね。 ほとんどの場合、デザイナーは、デザイン部門または外部委託されたデザイナーによってサービスとして使用されます。 デザイナーが製品スペシャリストの意見に耳を傾け、理解したとおりに実行したように見える状況がよくあります。 しかし、反復を開始すると、実際に行われたことは期待されたものではないことがわかります。デザイナーは何かを忘れていて、動作を十分に検討していませんでした。なぜなら、彼はチームのメンバーではなく、コンテキストやフロントにもいないためです。 -end 開発者はレイアウトを完全に理解していませんでした。 フロントエンド開発者の設計理解に問題があるため、数回の反復が必要になる場合があります。

さらに、もう一つ問題があります。 デザインシステムは現在人気が高まっています。 これらは誇大宣伝になっていますが、そこから得られるメリットは完全には明らかではありません。

デザインシステムは開発を簡素化する一方で、インターフェースに多くの制限を課すという意見に遭遇します。

その結果、私たちはクライアントが望む機能を作るのではなく、それを作ることができる特定のキューブをすでに持っているので、私たちにとって都合の良い機能を作ります。

これは検討してみる価値のあるトピックだと思います。デザインを容易にするという試みが実際にクライアントの問題点を解決しているかどうかを考えてみましょう。

— 品質保証に関する話題は意外と多いですね。 ロシアにそれらすべてについて議論できる会議はありますか?

アナスタシア：SQA Days 品質保証カンファレンスと呼ばれる、今年で 25 回目を迎える最も古いテストカンファレンスがあります。 ここでは主に、機能テスター向けのツールと特定のテスト手法について説明します。 原則として、SQA Days のレポートでは、テスター自身の責任の範囲内の特定の領域について詳しく調査しますが、複雑なアクティビティについては調査しません。

これは、さまざまなツールやアプローチ、データベースや API などをテストする方法を理解するのに非常に役立ちます。 しかし同時に、より良い製品を作るためにテスト以上のことを行う動機にはなりません。 一方で、テスターは、製品とそのビジネス コンポーネントのグローバルな目標を考えるプロセスにはあまり関与しません。

私は大規模な部門を運営しており、業界全体の現状についての洞察を得るために多くのインタビューを行っています。 原則として、当社のスタッフは企業で働いており、明確な責任領域を持っています。 外国のプロジェクトで働く同僚は、さまざまな種類のテストを使用します。チームが製品の品質を確保するのに非常に役立つため、彼ら自身が負荷テスト、パフォーマンス テスト、さらにはセキュリティ テストを行うこともあります。

ロシアの人たちにも、この業界は機能テストで終わるわけではないということを考え始めてほしいと思います。

— この目的のために、私たちは統合的な分野としての品質に特化した新しいカンファレンス、QualityConf を組織しています。 このアイデアについて詳しく教えてください。カンファレンスの主な目的は何ですか?

アナスタシア: 私たちは、高品質の製品を作ることに興味がある人々のコミュニティを作りたいと考えています。 彼らが参加し、レポートを聞き、品質を向上させるために何を変更する必要があるかを具体的に理解して会議後に帰ることができるプラットフォームを提供します。

最近はコンサルティングで「テストや品質に問題があった場合はどうすればいいですか？」という相談をよく聞きます。 チームとのコミュニケーションを開始すると、問題はテスター自体にあるのではなく、プロセスの構造にあることがわかります。 たとえば、開発者が自分にはコードを書くことだけが責任であると信じている場合、そのタスクをテストに引き渡した瞬間にその責任は終了します。

貧弱なアーキテクチャで書かれた低品質のコードがプロジェクトに大きな問題をもたらす恐れがあるという事実を誰もが考えているわけではありません。 彼らはエラーのコストについて考えず、本番環境にバグが発生すると会社とチームに多大なコストが発生する可能性があることを考えていません。 それについて考える文化がありません。 カンファレンスで配布を開始したいと思います。

これがイノベーションではないことは理解していますが、品質に関する 14 の原則の著者であるエドワード・デミングは、前世紀にエラーの代償について書いています。 学問としての品質保証はこの本に基づいていますが、残念なことに、現代の開発はそれを忘れています。

— テストやツールに関する話題に直接触れる予定はありますか？

アナスタシア：ツールに関する報告があることは認めます。 企業やチームが製品に影響を与えることができる、非常に普遍的なツールがあります。

すべてのレポートは、XNUMX つの共通の使命によって世界的に統合されます。それは、このアプローチ、ツール、方法、プロセス、テストの種類の助けを借りて、当社が製品の品質に影響を与え、クライアントの生活を改善したことを聴衆に伝えることです。

ツールのためのツールに関するレポートは絶対にありません。 プログラムに含まれるすべてのレポートは、共通の目標によって統合されます。

— カンファレンスのゲストとして誰があなたの話に興味を持ちますか?

アナスタシア: プロジェクト、製品、システムの運命を気にかけている開発者向けのレポートを用意しています。 同様に、テスターに​​とっても、特にマネージャーにとっても興味深いものとなるでしょう。 マネージャーとは、意思決定を行い、製品、システム、チームの運命や開発に影響を与えることができる人々を意味します。

これらは、製品やシステムの品質を向上させる方法を考えている人々です。 私たちのカンファレンスでは、彼らはさまざまな対策について学び、現状の何が問題で、何を変える必要があるのか​​を理解できるようになります。

主な基準は、品質に問題があることを理解し、それに影響を与えたいと思うかどうかだと思います。 初回だけで大丈夫だという人にはおそらく届かないでしょう。

— 業界全体がテストだけでなく、品質の文化について話す機は熟していると思いますか?

アナスタシア：成長したと思います。 現在、多くの企業が従来のウォーターフォール アプローチからアジャイルに移行しつつあります。 顧客を重視しており、チームの人々は高品質の製品を作成する方法を真剣に考え始めています。 大企業でも品質の向上に再び注力し始めています。

コミュニティで生じているリクエストの数から判断すると、その時期が来たと思います。 もちろん、これが大規模な革命になるかどうかはわかりませんが、この意識革命が起こってほしいと思っています。

- 同意しました！ 文化を浸透させ、意識を変えていきます。

高品質なIT製品開発に関するカンファレンス 品質会議 起こる 7月XNUMX日にモスクワで。 高品質の製品がどの段階で構成されているかはご存知でしょう。当社には本番環境でバグとの闘いに成功した事例があり、一般的な方法を実践でテストしました。私たちはあなたの経験を必要としています。 送信 彼らの 1月XNUMX日までのお申込み、プログラム委員会は、カンファレンスの全体的な整合性のためにテーマを集中させるのに役立ちます。

に接続します チャット、品質問題とカンファレンスについて話し合います。 テレグラムチャネル番組ニュースの最新情報を入手できます。

出所： habr.com