「優先順位を付けることが重要です」:Sberbank Technologiesでのテストについて





ロシア企業のテストが特に筋金入りのタスクになる可能性について考えると、 Sberbank Technologiesはすぐに思い浮かびます。 第一に、巨大な規模があり、第二に、多くの責任があります(金融業務はジオロケーションと写真を共有しません)、第三に、可能な限り最速のリリースサイクルのためのコースを受講しました:つまり、多くの非常に高品質のテストを同時に行う必要がありますとても速い。



このような相互に排他的な態度での生活はどのようなものですか? 会社がスポンサーであるハイゼンバッグ会議に続いて、企業信用システムのテスト部門の副部長である品質部門からアントン・ロマノフにいくつかの質問をしました。



-Sberbank Technologiesの前は、Aplanaで働いていました。Aplanaでは、外部の請負業者からSberbankシステムのテストにも携わっていました。 しかし、会社と請負業者の間のテスト作業は、一般的にどのようにしてSbertechで共有されますか?



-歴史的に、請負業者は当初、主に回帰テストに関与していました。 そして、ほとんどの回帰テストが行​​に引き渡され、Sbertehが制御したとき、私はAplanで働いていました。 そして現在、作業量が増加するにつれて、請負業者も新しいプロジェクトをテストするために雇われています。



-Sberbank-Technologiesが大企業であることは誰にとっても明らかですが、テストの面でどれだけ大きいかについて、数字を使って考えてください。



-約1,500人が品質部門で働いており、これらは38の部門です。約5つの部門が機能コンピテンシーに分かれています:負荷テスト部門、自動バンキングシステムのテスト部門、フロントエンドシステムのテスト部門、および管理部門です。 また、各部門には約5つの部門があります。



-非常に多くの部門があるとき、それは興味深いものになります:このすべてがどれくらい統一されていますか? すべての人が従うことをテストするための厳格な統一基準がありますか、または部門に高度の自律性がありますか?



-妥協点があると思います。 たとえば、テスト組織部門はいくつかのガイドプラクティスを設定します。 それらについては、特定の条件下で満たされるまたは満たされない基準が定義されています(初期段階でのテスト、アナリストとのテストの調整など)。 つまり、チームは一般的なルールセットに従って動作しますが、システムの機能と開発プロセスに応じて、チームは独自に適用可能なプラクティスと実装方法を決定します。



当然、プロセスは透明でオープンです。作業プロセスの積極的なフィードバック、調整、理解が必要です。



-そして、チームはまだ主流になっていないいくつかの革新的なプラクティスを使用できますか、またはあなたの場合は常にタイムテストが必要ですか?



-もちろん、信頼性が必要ですが、これは新しいもので作業できないという意味ではありません。 たとえば、マインドマップ(メンタルマップ)は、最近まで革新的なプラクティスと見なされていました。 これらを使用しますが、追加のツールとして使用します。 もちろん、他のテスト文書と引き換えにマインドマップのみを使用することは許可されていません。 したがって、新しいものを使用して、リスクを計算して軽減し、多くの場合、パイロットモードで同様のテストを実施します。 そして、効率と結果を確認した場合にのみ、そのような決定が実践され、再現されます。



-金融取引の高い責任がテストへのアプローチに影響することを外部から正しく理解していますか?



-お金に関しては、大きな責任があります-そしてもちろん、これはテストへのアプローチに影響します。 このプロセスは非常に厳格で、いくつかの承認段階があります。開発からテストへの移行、システムテストから統合テストへ、統合テストから承認への移行です。 つまり、すべてが数回再チェックされ、そのような配布キットには厳格な転送基準があり、回帰テストの実装と新しい機能のテストの品質が監視されます。



-そして、おそらく、あなたの場合、負荷テストは特に重要ですか?



-はい、そうです。 たとえば、Sberbankには、相互に対話する約150の異なるシステムがあります。 私たちの部門には1つの大規模なシステムがあり、1営業日に1秒間に約500件の支払い書類を受け取ります。 したがって、領土銀行あたりの量は1日あたり約400万文書です。 これらは顧客への支払いであり、税金と公共料金の支払いはすべての塊です。



したがって、負荷テストは非常に重要な役割を果たします。これは、Sberbankにとって、これらのドキュメントの処理時間が非常に重要であるためです。 次の更新プログラムのロールアップ後のシステムの動作に細心の注意を払っています。サービスレベルが低下しないことが非常に重要です。 したがって、負荷テストでは、産業環境と最も一貫した環境を作成しようとします。



-同時に、すでに大量のコードが記述されているため、回帰テストが複雑になりますが、同時に、リリースを可能な限り高速化することが目標です。 このような課題に対処するのに何が役立ちますか?



「古き良き慣習が役立つ—リスクベースのテスト。」



私たちがテストしているシステムは、継承によって私たちに引き継がれました。それはもともとサードパーティ企業によって開発されました。 ドキュメントは7年前のレベルのどこかに残り、新しい変更はさまざまな場所に散らばってドキュメント化されました。 つまり、最初のタスクは、それが何を、どこで、どのように機能するかを理解することです。



そして次の瞬間-ボリューム。 このシステムでは、約15,000のオペレーションがあり、すべての支払いがそこに流れ込みます-会計レポート、投稿、および一般的にすべて。 弊社のリリースには厳しい締め切りがあり(すべてについて2週間のオーダー)、1回目と2回目のターンで何をチェックし、どの程度までチェックすることが重要です。 優先順位を決定し、開発、サポート、Sberbankの同僚を引き付けます-利害関係者との包括的な対話を行います。



プロセスを自動化して時間を節約することは非常に重要です。 ただし、手動でしか実行できないチェックもあります。ここでは、リードタイムメトリック(回帰の開始から終了までの時間)-回帰テストの実行にかかる時間を使用します。 ツールに保存されているテスト実行時間のデータを使用し、これに基づいて回帰を実行するのに必要な時間を推定し、この時間を日付、終了日(終了日(2つの計算方法-実際の完了日と開始日、およびテストの量と平均実行時間を通じて、これまでのところ、「事実」は計算値を超えています)。 これまでのところ、私たちには違いがあり、個々のテストの実行にかかる時間を短縮する方法について考えています。



-Sbertechの規模の会社について、その中には多くのツールが開発されているように思われます-あなたの仕事でそのようなものに遭遇しますか?



-何を話すかによって異なります。独自のJIRAはありませんが、個々のテストニーズに合わせて多くのユーティリティが開発されています。 たとえば、特定の形式の特別なメッセージの作成、テストデータジェネレータ、SQLスクリプトは非常に一般的です。



-以前、Sbertehは、DevOpsが品質部門で実装されていることを報告しましたが、これは実際に部門にとってどのような意味がありますか?



-devopの出現により、継続的インテグレーションや継続的展開などのプラクティスが登場します。 私の勤務する部署では、システムはレガシークラスに属しているため、まだ存在していません。レガシープラットフォームは新しいプラットフォームに置き換えられます(Webアプリケーションとして開発されています)。 ただし、他の部門の同僚はすでにDevOpsで作業しているため、時間を大幅に節約し、プロセス全体を高速化できます。 すべてが自動的に収集されるため、夜間にロールして開始され、午前中に結果を確認するだけで済みます。



-Sbertehについては、開発者を積極的に採用していることが知られています-また、テストでは常に新しい人を引き付けますか?



-現在、Sberbankの新しいITプラットフォームが積極的に開発されており、現在個別に存在する多数のシステムを組み合わせます。 これは、個々の機能を実行する多数のモジュールで構成される単一のプラットフォームになります。 しかし、並行して、既存のシステムのアプリケーションを処理します。 したがって、もちろん、この本当に大規模なタスクを実行する人々が必要です。



あなたはISTQBフルアドバンスレベルまでの認定テスターです-知識の獲得と証明書の取得の事実はSbertechにどの程度影響しますか?



-私の仕事では、この知識は非常に役立ちます。 多くの場合、「何らかのビジネスプロセスが設計されています。作業を大まかに計画し、リグレッションの所要量を大まかに理解するには、何らかの方法でテスト数を評価する必要があります」という一連のタスクがあります。 ここでは、ISTQBで説明されているテスト設計方法が必要です。 非常に詳細な文書さえ持っておらず、既存のリスクと品質基準に関する仮定に基づいて、可能性のある量を決定するのに役立ちます-おそらくテストではなくチェックの観点から。



また、リスクベースの戦略は回帰モデルに非常に適用可能です。 リスクをどのように評価するか、どのように優先順位を付けるか、誰にこれをもたらすか-これはすべて非常に有用であり、私の仕事で何度も助けてくれました。 まあ、一般的には、私にはそう思われるように、認証の準備で得られた知識は、仕事へのさらなるアプローチを決定します。 すべてをテストすることはできないという頭の中に、心は徐々に収まります。リスクから先に進み、利用可能なリソースで最高の品質を確保する必要があります。 問題を解決するこのアプローチでは、まったく異なる結果が得られます。



All Articles