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

こんにちは、Habr！



新しい重要なトピック-IT製品の高品質の開発があります。 HighLoad ++で、ロードされたサービスを高速にする方法と、遅くならないクールなユーザーインターフェイスであるFrontend Confについてよく話します。 テストに関するトピックと、テストを含むさまざまなプロセスの組み合わせに関するDevOpsConfが定期的にあります。 しかし、全体として品質と呼ぶことができるもの、およびそれを包括的に扱う方法については、いいえ。



QualityConfで修正しましょう -開発の各段階でユーザーの最終製品の品質について考える文化を発展させます。 責任範囲にとらわれず、テスターだけでなく品質を関連付ける習慣。



カットの下で、ロシア語を話すQAコミュニティAnastasia Aseeva-Nguyenの作成者であるTinkoff Businessのテスト責任者であるプログラム委員会の長と、QA業界の現状と新しい会議の使命についてお話します。







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



アナスタシア ：私は銀行のテストを率いており、非常に大きなチームの責任者です。私たちは90人以上います。 私たちには重要なビジネスラインがあり、法人のエコシステムを担当しています。



私はmehmatで学び、最初はプログラマーになりたいと思っていました。 しかし、興味深いオファーがあったとき、私はテスターとして自分自身を試してみることにしました。 奇妙なことに、これは私の呼び出しであることが判明しました。 今、私はこの業界での私の仕事すべてを見ています。

私は品質保証の規律を熱心に支持しています。 どのような製品が作られるか、それらが会社、チーム、そして原則として開発プロセスで品質にどのように関係するかは気にしません。

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



-品質保証とテストという言葉を使用します。 平均的な人間の目には、これらの2つの用語は非常に頻繁に交差しています。 深く掘り下げると、どのように違いますか？



アナスタシア：むしろ、彼らは違いはありません。 テストは品質保証の規律の一部であり、直接的な活動です。まさに私が何かをテストしているという事実です。 実際、テストには多くの種類があり、さまざまな人がさまざまな種類のテストを担当しています。 しかし、ロシアでは、テスターを会社に供給するアウトソーシング業者の波があったとき、テストは単一のビューに縮小されました。



ほとんどの場合、機能テストのみに制限されています。開発者がコンパイルしたものが仕様を満たしていることを検証し、それだけです。



-品質保証には他にどんな分野がありますか？ テストの他に何が含まれていますか？



アナスタシア ：品質保証は、まず第一に、高品質の製品を作成することです。 つまり、私たちは私たちの製品が持つべき品質の属性を疑問に思っています。 したがって、これを理解すれば、これらの品質属性に影響を与える人を比較できます。 開発者、プロジェクトマネージャー、またはプロダクトマネージャーは、 製品の開発、バックログ、戦略に影響を与える人です。



テスターは自分の役割をよりよく認識しています。 彼は、自分の仕事が要件の順守をテストするだけでなく、要件をテストし、製品技術者の言葉に疑問を投げかけ、クライアントの暗黙の要件と期待をすべて明らかにすることを理解しています。 顧客に新しい機能を提供するとき、彼の期待に真に応え、痛みを解決しなければなりません。 品質のすべての属性について考えると、クライアントは満足し、自分の製品を使用している会社が本当に自分の興味を気にし、「機能をリリースするだけ」の原則に基づいていないことを理解します。



-今説明したのは、製品の専門家の仕事のようです。 これは原則として、テストではなく、品質に関するものではありません。一般的に製品管理に関するものですよね？



アナスタシア ：含む。 品質保証は、特定の1人が責任を負う分野ではありません。 現在、テストには一般的な傾向があり、 アジャイルテストと呼ばれるアプローチがあります。 彼の定義では、これはテストに対するチームアプローチであり、特定のプラクティスセットが含まれていることは簡単に聞こえます。 チーム全体がこのアプローチを実装する責任があり、テスターがチームにいる必要さえありません。 チーム全体がクライアントに価値を提供することに注力しているため、この価値はクライアントの期待に応えます。



-品質は周囲のほとんどすべての分野と交差し、周囲のすべてに枠組みを課していることがわかりますか？



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



この種のテストは、 UAT （ユーザー受け入れテスト）のようにポップアップします。 残念ながら、ロシアではめったに実践されていませんが、SCRUMチームにエンドカスタマー向けのデモとして存在することもあります。 外国企業では、これはかなり一般的な種類のテストです。 すべてのお客様に機能を公開する前に、まずUATを作成します。つまり、テストを実施してすぐにフィードバックを行うエンドユーザーを招待します。製品は本当に期待に応え、痛みを解決します。 これが後になって初めて、他のすべてのクライアントへのスケーリングが行われます。



つまり、私たちはビジネス、最終顧客に焦点を当てていますが、同時にテクノロジーについても忘れないでください 。 製品の品質もテクノロジーに大きく依存しています。 アーキテクチャに問題がある場合、機能を迅速にリリースできず、顧客の期待に応えることができません。 スケーリングしようとしたり、リファクタリングしようとすると、多くのバグが発生する可能性があります。 これはすべて顧客満足度に影響します。



この観点から、アーキテクチャは、すべてを壊すことを恐れることなく、迅速に変更を加えることができるクリーンなコードを書くことができるようなものでなければなりません。 そのため、多くのレガシーがあり、テストの長い段階を実行する必要があるという理由だけで、洗練の反復が数か月間延長されません。



-合計で、開発者、アーキテクト、製品の専門家、製品マネージャー、テスター自身がすでに関与しています。 品質保証プロセスに関与しているのは誰ですか？



アナスタシア ：今、クライアントに機能を既に提供していることを想像してください。 明らかに、製品の品質と、それがすでに生産されているときを監視する必要があります。 この段階では、非自明なシナリオ（いわゆるバグ）が発生する可能性があります。



最初の質問は、製品をすでにリリースした後、これらのバグをどのように処理するかです。 たとえば、負荷にどのように対応しますか？ ページが30秒以上読み込まれると、クライアントはあまり満足しません。



これが、エクスプロイト、または現在、 DevOpsと呼ばれているところです。 実際、これらは、すでに販売されている製品の操作を担当する人々です。 これには、さまざまな種類の監視が含まれます。 テストのサブタイプもあります。ロールアウトする前に何かをテストせず、製品上ですぐにテストすることを許可する場合、製品上でテストします。 これは、インフラストラクチャの編成という観点からの一連の手段であり、インシデントに迅速に対応し、インシデントに影響を与え、修正することができます。



インフラも重要です。 多くの場合、テスト中に、クライアントに提供したいすべてのものが本当にあるかどうかを確認することが不可能な場合があります。 製品にロールアウトします-そして、自明でない状況をキャッチし始めます。 すべては、テストのインフラストラクチャが製品のインフラストラクチャと一致しないためです。 これにより、新しいタイプのテスト、つまりインフラストラクチャテストが行​​われます 。 これらは、さまざまな構成、設定、データベースの移行などです。



これは疑問を投げかけます-おそらく、チームはインフラストラクチャをコードとして使用する必要があります。

インフラストラクチャは製品の品​​質に直接影響を与えると考えています。

カンファレンスで実際の事例を報告することを願っています。 コードとしてのインフラストラクチャが品質にどのように影響するかをお知らせください。 コードとしてのインフラストラクチャにより、すべての設定を簡単に確認し、他の方法では不可能なことを簡単にテストできます。 したがって、搾取は高品質の製品の開発にも関係しています。



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



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



テストプロセス中にバグが検出されると返品が開始されるため、このようなドキュメントを作成すると、開発の非常に長い反復と洗練の長い反復が発生することが繰り返し証明されています。 その結果、開発コストを増加させるループが多数あります。 さらに、これにより脆弱性が発生する可能性があります。 参照コードを作成したようですが、完全に考え抜かれたアーキテクチャを壊すような変更を加えました。



パッチは既にアーキテクチャに登場しているため、一部の場所のコードはテストで十分にカバーされていないため、結果はそれほど高品質の製品ではありません。 元の仕様では、実装する必要があるすべてのポイントが考慮されていなかったためです。

開発者は害虫ではなく、特にエラーのあるコードを作成しません。

すべての必要なポイントがカバーされる仕様を最初に考えた場合、すべてが必要なとおりに実装されます。 しかし、これはユートピアです。



100ページの完全な仕様を記述することはおそらく不可能です。 したがって、 ドキュメントを記述し 、指定し、開発者が必要なことを正確に行えるようにするタスクを設定する別の方法を検討する必要があります。



アジャイルアプローチが思い浮かびます-受け入れ基準を持つユーザーストーリー。 これは、小さな反復で開発するチームにより適しています。



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



アナスタシア ：これは非常に重要なポイントです。チームにはデザイナーがいるからです。 ほとんどの場合、設計者はそれをサービスとして使用します-設計部門またはアウトソーシングされた設計者。 多くの場合、設計者が製品技術者の話を聞いて、彼が理解したことをしたように見える状況があります。 しかし、イテレーションを開始すると、期待されていたことが実際に行われたわけではないことがわかりました。デザイナーは何かを忘れ、チームやコンテキストにいないために振る舞いを考えなかった、またはフロントエンド開発者がそれを完全に理解していなかったレイアウト。 フロントエンド開発者による設計の理解に問題があるため、何度か繰り返す必要があります。



さらに、別の問題があります。 設計システムの人気が高まっています。 それらは誇大宣伝されていますが、それらの利点は完全には明らかではありません。

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

結果として、クライアントが受け取りたいような機能を作成するのではなく、私たちにとって便利な機能を作成します。これは、特定のキューブを作成できるためです。



このトピックに注意を払い、設計の作業を簡素化するためにクライアントの痛みを本当に解決するかどうかを考える必要があるように思えます。



-驚くべきことに、品質保証に関連する多くのトピックが判明しました。 ロシアでそれらすべてを議論できる会議はありますか？



アナスタシア ：最古のテスト会議があり、今年で25回開催され、SQA Days Quality Assurance Conferenceと呼ばれます。 主に、機能テスター向けのツールと特定のテスト手法について説明します。 原則として、SQAデーのレポートでは、テスター自身の責任範囲内の特定の領域を深く考慮していますが、複雑なイベントは考慮していません。



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



私は大規模な部門を率い、多くのインタビューを実施しています。実際、業界全体の状況を示すことができます。 原則として、私たちの社員は企業で働いており、明確な責任範囲を持っています。 外国のプロジェクトで働く同僚は、さまざまな種類のテストを使用します。チームが製品に品質を提供するのに本当に役立つため、ストレステスト、パフォーマンステスト、および場合によってはセキュリティテストを行うことができます。



ロシアの私たちも、業界が機能テストで終わるわけではないと考え始めたいと思います。



-このために、全体的な規律として品質に専念する新しい会議QualityConfを開催しています。 このアイデアの詳細を教えてください。会議の主な目標は何ですか？



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



多くの場合、テストに問題があり、品質に問題がある場合の対処方法についての相談からのリクエストを聞きます。 チームと話し始めると、問題はテスター自身ではなく、プロセスの構築方法にあることがわかります。 たとえば、開発者がコードの作成のみに責任があると信じている場合、その責任はタスクをテストに移した時点で終了します。



誰もが、貧弱なアーキテクチャで質の悪い低品質のコードがプロジェクトに大きな問題をもたらすとは考えていません。 彼らは、エラーのコストについては考えていません。本番環境に入ったバグは、会社とチームに大きなコストをもたらす可能性があると考えています。 それについて考える文化はありません。 会議で配布を開始してほしい。



私はこれが革新ではないことを理解しており、14の品質仮説の著者であるEdward Demingが前世紀のエラーのコストについて書いています。 この本は規律としての品質保証に基づいていますが、残念ながら、現代の開発はそれを忘れています。



-テストとツールに関するトピックに直接触れる予定はありますか？



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

すべてのレポートは、このアプローチ、ツール、方法、プロセス、テストの種類によって、製品の品質に影響を与え、クライアントの寿命を改善したことを聴衆に伝えるという1つの共通の使命によってグローバルに統合されます。

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



-あなたが話していること、会議のゲストとして見ていることに興味を持っているのは誰ですか？



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



これらは、製品、システムの品質を改善する方法を知りたいと思っている人々です。 私たちの会議では、彼らはさまざまなイベントの複合体について学び、何が正しくないのか、何を変える必要があるのか​​を理解することができます。



主な基準は、品質に問題があることを理解し、それに影響を与えたいと思うことです。 おそらく、それが機能すると信じる人々に手を差し伸べるのは初めてですが、私たちは成功しません。



-テストだけでなく、品質の文化について話すために、業界全体が成熟したと思いますか？



アナスタシア ：私は成熟したと思う。 現在、多くの企業が、従来のウォーターフォールアプローチからアジャイルへの移行を進めています。 クライアントに焦点が当てられており、チームの人々は高品質の製品を作成する方法について本当に考え始めています。 企業であっても、品質の改善への方向転換があります。



コミュニティで発生するクエリの数から判断すると、今がその時だと思います。 もちろん、これが大規模な革命になるかどうかはわかりませんが、意識におけるこの革命が起こることを望みます。



-同意した！ 文化を植え付け、心を向けます。

QualityConf IT製品の品質開発に関する会議が6月7日にモスクワで開催されます。 高品質の製品がどの段階で構成されているかご存知です。在庫のバグとの闘いに成功した場合があります。私たちは実際に人気のある方法をテストしました-あなたの経験が必要です。 5月1日までに申請書を 送信してください。プログラム委員会が会議の全体的な整合性に関するトピックに焦点を当てます。



品質の問題や会議について話し合うチャットに接続し、 Telegramチャンネルに登録して、プログラムのニュースに遅れないようにしてください。