اسمي ساشا زبرشوك. جئت إلى Solid منذ ثلاث سنوات بصفتي Junior Manual QA. منذ ذلك الوقت ، أصبحت مهندسًا للأتمتة ، وتخرجت من أول مدرسة لضمان الجودة عملنا معها ، وانتقلت إلى منصب مدير المنتج.
في هذا المقال ، سأتحدث عن ميزات اختبار أنظمة الدفع وأشارك تجربة فريقنا: ما الذي نختبره وكيف وما هي التحديات التي نواجهها وكيف نستجيب لها. ستكون هذه التجربة مفيدة لأولئك الذين يبنون عملية الاختبار في المشروع - مهندسو ضمان الجودة ومديرو المنتج / المشروع.
لن أتعمق في التقنية والأدوات المحددة ، لكنني سأتحدث عن الفكرة الرئيسية: كيفية جعل عملية اختبار الخدمات المعقدة تقنيًا شفافة وهادئة قدر الإمكان.
مكوناتها وكيفية عملها
Solid هي بوابة تسمح للشركات في جميع أنحاء العالم بقبول مدفوعات العملاء عبر الإنترنت بعدة طرق ، من البطاقات المصرفية والمحافظ الإلكترونية إلى PayPal و Alipay.
هناك أربعة لاعبين رئيسيين في هذه القصة بأكملها:
- مستخدم (هو أيضًا مشتر) ؛
- تاجر - أي شركة تبيع سلعها / خدماتها على الإنترنت وتريد قبول الأموال مقابلها ؛
- بوابة الدفع - صلبة ؛
- بنك (مشتري) - مؤسسة مالية تجري معاملات بأموال حقيقية.
بعبارات بسيطة ، يبدو الأمر كما يلي: ببساطة ، نساعد التجار على تحقيق الدخل وكسب المال.
قد يكون لديك سؤال: لماذا يختار التجار Solid ، إذا كان بإمكانهم العمل مباشرة مع البنوك؟ الأمر بسيط: 1) هناك العديد من البنوك ، ولكل منها خصائصه الخاصة - من خلال الجمع بين البنوك المختلفة من مختلف البلدان في بنية تحتية واحدة ، نحقق أقصى قدر من التحويلات والإيرادات ؛ 2) لدينا خبرة واسعة في منطق الدفع ومكافحة الاحتيال ؛ 3) بالإضافة إلى المدفوعات المصرفية ، نقبل جميع طرق الدفع البديلة الشائعة في منطقة معينة ، و 4) نحن أرخص.
لنبدأ بالنقطة الأولى - ما هي ميزات إجراء المدفوعات في البلدان المختلفة؟ على سبيل المثال ، في الولايات المتحدة ، من الغريب أنك لن تكون قادرًا على إجراء دفعة بسهولة كما هو الحال في أوكرانيا - باستخدام بيانات البطاقة فقط. هناك ، يتعين على البنوك التحقق من تفاصيل دافع إضافية مثل عنوان الفواتير والرمز البريدي.
هناك العديد من الفروق الدقيقة المماثلة. وكذلك بدائل مدفوعات البطاقات. في هولندا وألمانيا ، على سبيل المثال ، يحب الناس استخدام محافظ الإنترنت المحلية. أكثر طرق الدفع شيوعًا في الصين هي Alipay و WeChat Pay و UnionPay. وفي نيجيريا ، لدفع ثمن البضائع على الإنترنت ، يذهب المستخدمون إلى البنك نقدًا!
نقبل جميع المدفوعات الشائعة ، دون استثناء - من البطاقات المصرفية إلى PayPal أو المحافظ الإلكترونية أو Google Pay أو Apple Pay أو الرسائل القصيرة. بمساعدة Solid ، يحصل التاجر على إمكانية العمل مع جميع أنواع الدفع في تكامل واحد. بالإضافة إلى ذلك ، تتمتع البوابة بحماية خاصة بها ضد الاحتيال ونظام توجيه الدفع وأداة لمنع عمليات رد المبالغ المدفوعة غير المعقولة وغير ذلك الكثير.
لماذا تختبر أنظمة الدفع ومخاطر عدم الاختبار
يرتبط العديد من التجار بشركة Solid. لذلك ، نحن مسؤولون ليس فقط عن أعمالنا ، ولكن أيضًا عن تحقيق الدخل لجميع العملاء المرتبطين بنا. إذا حدث خطأ ما من جانبنا ، فإننا نفشل الكثير من الشركات. والعكس صحيح - من خلال اختبار خدمة الدفع لدينا وتحسينها ، نقوم بتحسين منتجات الشركات الأخرى.
لسوء الحظ ، بالإضافة إلى الدفع الناجح ، يمكن أن تحدث أخطاء - سواء في النظام أو المستخدم. من المهم أن نفهم أن 100٪ من المدفوعات لن تمر بنجاح في أي مكان. ولكن من جانبنا ، نحن ملزمون ببذل قصارى جهدنا لجعل تحويل المدفوعات ممكنًا.
اختبار بوابة الدفع ليس مهمة روتينية ، لأنها آلية معقدة إلى حد ما لعشرات الخدمات الصغيرة والترابط. نختبر كل شيء على ثلاث مراحل. أولاً ، نتحقق من كل مهمة في بيئة معزولة ، ثم نجمعها ونفحصها في الإصدار المرشح في المرحلة ، ونرى كيف يعمل كل شيء في التكامل ، ثم نطلق كل شيء ونختبره مرة أخرى في الإنتاج.
دعنا نلقي نظرة فاحصة على ما علينا اختباره على وجه التحديد.
مميزات اختبار أنظمة الدفع
يتكون نظام الدفع من واجهات برمجة التطبيقات والويب. لا توجد فروق جوهرية بين API واختبار الويب لأنظمة الدفع ، على عكس أي منتجات أخرى. الميزة الرئيسية في اختبار مدفوعات محددة لمناطق مختلفة ، فضلا عن جميع الخدمات المساعدة.
يبدو أن اختبار الدفع ليس بالأمر الصعب: فأنت بحاجة إلى إجراء دفعة ، والتحقق من خصم الأموال من أحد الحسابات ، وقيدها في حساب آخر. لكن هناك فروق دقيقة. يحتاج المختبرين إلى معرفة تفاصيل المدفوعات في البلدان المختلفة ، وأحيانًا الفروق الدقيقة في القوانين المحلية واللوائح المصرفية.
النقطة الثانية هي أنواع مختلفة من المدفوعات: الاشتراكات ، الدفعة الأولى ، التفويض (تجميد الأموال في الحساب) ، الدفع من خلال المحفظة الإلكترونية. كل واحد منهم لديه تفاصيل الاختبار الخاصة به.
يجب إيلاء اهتمام خاص للعمل مع العملات: فليس لكل منهم جزء كسري. على سبيل المثال ، الهريفنيا لديها بنس واحد ، لكن البيزو التشيلي لا يمتلكها. إذا قمت بتحويل مبلغ الدفعة 100 في أوكرانيا ، فسيقوم البنك بشطب 1 غريفنا ، أي 100 كوبيل. وهذا يعني في تشيلي 100 بيزو. كما ترى ، لا ينبغي تفويت هذه اللحظات.
ما يجب اختباره في أنظمة الدفع
جميع عملائنا (الويب ، تطبيقات الهاتف المحمول ، وكذلك الخدمات الخلفية) يتواصلون معنا باستخدام Solid API . تقع البوابة نفسها على مجموعة منفصلة وتتصل بأنظمة مختلفة (مكافحة الاحتيال ، والرمز المميز ، والبنوك ، وما إلى ذلك).
يشارك المطورون المتميزون في حل عدة أنواع من المشكلات (وتنتهي كل هذه المهام تحت تصرف فريق ضمان الجودة):
- ( , , , , );
- (PayPal, Alipay Visa Mastercard);
- : API, ;
- ( , );
- , (, , -);
- .
بالإضافة إلى المهام التي تأتي مباشرة من المطورين ، نتلقى مهام أخرى: فحص جميع البيانات و UAT عند الاتصال بتجار جدد ، والتحقق من المهام من فريق DevOps ، ووضع قواعد لمكافحة الاحتيال.
للتلخيص ، يمكن تقسيم كل شيء نختبره إلى الفئات التالية:
خدمات الخلفية الصلبة:
- مكافحة الغش؛
- خدمة الاشتراك؛
- توجيه الدفع
- نظام المحاسبة والرقابة المالية ؛
- التكامل مع الخدمات الخارجية.
التكامل مع البنوك:
- التحقق من صحة العمل بالعملات ؛
- التحقق من أنواع المدفوعات المختلفة (الدفع الأول عن طريق بيانات البطاقة ، الدفع عن طريق الرمز المميز ، المبالغ المستردة ، تجميد الأموال ، إلخ) ؛
- معالجة الإخطارات.
طرق الدفع البديلة (بدون البطاقة):
- التحقق من الدفع
- التحقق من ميزات الموقع.
مشرف:
- لوحة الإدارة الداخلية (كل ما يساعد محللي Solid على إجراء اختبارات A / B لتحويل نموذج الدفع ، وإعداد قواعد لمكافحة الاحتيال) ؛
- لوحة الادارة للتجار.
واجهات المستخدم:
- ظهور نماذج وصفحات الدفع ؛
- ما إذا كان النموذج معروضًا بلغة منطقة معينة (نموذج الدفع الثابت متاح بجميع لغات العالم) ؛
- العرض الصحيح للمبلغ والعملات ؛
- تتبع إجراءات المستخدم على النماذج ؛
- حالة الصفحة.
آخر:
- UAT عند توصيل تاجر جديد بـ Solid ؛
- المهام من قسم المخاطر للتحقق من التكوينات الجديدة ؛
- دراسات الصحة الوظيفية (على سبيل المثال ، هل تعمل Apple Pay في WKWebView).
خطوات اختبار النجاح
التشغيل الآلي
عند العمل مع حلول تكنولوجيا المعلومات واسعة النطاق ، مثل مزودي الدفع ، فأنت بحاجة إلى اختبار باستمرار ليس فقط تشغيل العناصر الفردية للوظائف ، ولكن أيضًا تفاعلها. لن تعمل بدون أتمتة. إذا كانت بعض الخدمات لا تغطيها الاختبارات التلقائية ، فلا يمكن تجنب الفشل. قم بإجراء الاختبارات التلقائية كلما أمكن ذلك. سكب المهمة في البيئة - قم بإجراء الاختبارات. دمج العديد من المهام في إصدار مرشح - قم بإجراء الاختبارات.
في حالتنا ، يحدث شيء مثل هذا:
- يقوم المطورون بإجراء الاختبارات بشكل مستقل عند تنفيذ المهمة ؛
- يجري المختبرون اختبارات عند اختبار مهمة ما في بيئة معزولة ؛
- يتم تشغيل الاختبارات تلقائيًا عند إنشاء نسخة جديدة من البناء ؛
- تعمل الاختبارات التلقائية باستمرار على بيئة Prod.
يستغرق إجراء الاختبارات التلقائية بعض الوقت ، وبالتالي فإننا نسعى دائمًا لتحسين هذه العملية قدر الإمكان. يتم إجراء الاختبارات متعددة مؤشرات الترابط ، كما يتم تقسيمها إلى مهام حسب الأهمية.
لدينا مجموعة قليلة من الاختبارات التي تتحقق من صحة وظائف معالجة الدفع الأساسية في Solid - يتم تشغيلها في أقل من دقيقة. تستغرق جميع اختبارات Solid API والخدمات المصغرة الأخرى حوالي 3-4 دقائق. اختبارات واجهة المستخدم ، بالطبع ، أبطأ قليلاً. ولكن حتى هنا لا نتوقف عن العمل على التحسين والتحسين.
لماذا لا يكون الاختبار المعزول هو الخيار الأفضل عند اختبار المدفوعات؟ سأخبرك عن قضية مكافحة الاحتيال لدينا.
كل تاجر في Solid لديه حساب ضد الاحتيال مرتبط بوضع القواعد وكيفية عملها. على سبيل المثال ، إذا كان المستخدم قد سدد أكثر من ثلاث دفعات في اليوم مع تاجر ، فإننا نحظر الدفع الرابع. أو إذا قام أكثر من خمسة مستخدمين بإجراء مدفوعات بنفس البطاقة ، فإننا نحظرهم ونضيفهم إلى القائمة السوداء. قمنا بتغطيته بالاختبارات التلقائية ، لكن واجهنا مشكلة.
في البداية ، قمنا بتكرار جميع القواعد الخاصة بالحساب التجريبي ، ومحاكاة الإجراءات الاحتيالية ، ويبدو أن الاختبارات تعمل. لكن اتضح أن التاجر نفسه غالبًا ما يواجه مواقف يتم فيها دمج قواعد مكافحة الاحتيال ، على سبيل المثال ، ثلاثة منهم تعمل.
من خلال عزل كل دفعة لكل قاعدة محددة ، تخلصنا من إمكانية وجود مجموعة من القواعد وتأثير الخدمات الأخرى على عملية الدفع.
كيف سددنا كل دفعة: قمنا بمسح بيانات الاختبار ، وخلقنا جميع الشروط لكي تخضع الدفعة لقاعدة معينة ، ثم نجحت. لكنها ليست حقيقة أنه سيكون كذلك في بيئة العمل ، لأنه لن يكون هناك أبدًا وضع مثالي لكي تندرج المدفوعات تحت قاعدة واحدة.
قررنا ربط قواعد مكافحة الاحتيال الحقيقية لعملائنا بالتاجر التجريبي. ثم بدأوا في العمل بشكل أكثر وضوحًا. بمعنى أنه كان من الضروري إنشاء قواعد ليست معزولة ، ولكن اختبارها بشكل إجمالي كما هي لعميل معين.
الآن يمكن لعملاء Solid تخصيص قواعد مكافحة الاحتيال لأنفسهم. لأن المعاملات التي تبدو وكأنها احتيال لتاجر قد تكون هي القاعدة بالنسبة لآخر.
إذا أجرى شخص ما خمس عمليات شراء يوميًا في متجر عبر الإنترنت ، فهذه هي القاعدة: أولاً ، أحب حالة الهاتف المحمول ، ثم دفتر الملاحظات ، إلخ. لكن بالنسبة لتطبيقات اللياقة البدنية ، يعد هذا بالفعل أمرًا شاذًا. من غير المرجح أن يشتري الشخص خمسة برامج تدريب في اليوم.
تساعد الأتمتة حقًا في بناء توازن: يتم فحص الميزات الجديدة فقط وتلك السيناريوهات التي تتطلب اهتمامًا بشريًا ، ويتم تشغيل كل شيء آخر تلقائيًا. يمكن أن تساعد الأتمتة في تقليل تكاليف الاختبار والمخاطر البشرية.
الاختبار في مرحلة المواصفات الفنية
بالإضافة إلى التحقق المباشر من وظائف الوظيفة ، نخصص الكثير من الوقت للتأكد من أن المطورين والمديرين يدركون الوظائف المنفذة بنفس الطريقة. يبدو واضحًا ، لكن الكثيرين يتجاهلونه.
جميع خدمات التكوين معقدة للغاية ، ولديها مجموعة كبيرة من القدرات ، وحتى أصغر التفاصيل يمكن أن تؤدي إلى عدم عمل الخدمة كما هو متوقع.
تتميز تقنية "الاختبار المبكر" بالعديد من المزايا في وقت واحد:
- سيفهم فريق التطوير المهمة بشكل صحيح ، ولن نضيع الوقت في الإصلاحات ؛
- المواصفات الفنية المكتوبة جيدًا هي 70٪ من التوثيق الجيد ؛
- نظرًا لحقيقة أن فريق الاختبار قد تعرف على TOR مقدمًا ، فإن سيناريوهات الاختبار يتم التفكير فيها أيضًا مسبقًا ، وفي الوقت الذي تأتي فيه المهمة المنفذة للاختبار ، تسير العملية بشكل أسرع.
وثائق اختبار جيدة
التوثيق الداخلي الجيد والمنظم حقًا هو نصف المعركة عند الاختبار. على الرغم من حقيقة أن جميع الوظائف تقريبًا يجب أن تكون تلقائية ، إلا أن العمل اليدوي لن يتحقق أبدًا.
إن وصف عمليات الاختبار للوظائف المختلفة ، والمقالات التي تحتوي على حلول محتملة للمشكلات والأدلة المتنوعة ، تسرع عمل فريق الاختبار.
لقد أنشأنا في Solid قاعدة المعرفة الخاصة بنا. يصف كيف يعمل كل بنك وطريقة دفع بديلة في مواقع مختلفة ، وأنواع المدفوعات التي يدعمها البنك ، وكيف ، من حيث المبدأ ، يتم إجراء المدفوعات في منطقة معينة.
مثل هذه القاعدة مهمة رحبة ومعقدة أصبحت تحديًا لنا. كان من الضروري جمع كل الوثائق معًا ووصف العمليات بطريقة يسهل الوصول إليها. لكن الآن ، عندما يأتي موظف جديد إلينا ، فلا توجد مشاكل. من الصعب تذكر كيفية عمل شيء ما في المرة الأولى ، وإذا كان هناك وثائق اختبار ، فإن خيار ارتكاب الخطأ يكون ضئيلاً. تسمح الوثائق الواضحة للمختبِر بتحديد سبب عدم إجراء الدفع بالضبط: إنه خطأ أو أن هذا النوع من الدفع ببساطة لا ينبغي أن يعمل في هذا البنك.
اسمح لي أن أقدم لك مثالا آخر. بمجرد تغيير شعارات أنظمة الدفع الدولية في نماذج الدفع. لدينا أكثر من 200 تصميم مختلف لعملائنا ، ولكل تصميم يمكن أن يكون هناك عدة تكوينات للحقول على النموذج. على سبيل المثال ، بالنسبة للبرازيل ، تمت إضافة حقل CPF إضافي - نظير لكود التعريف الخاص بنا.
نظرًا للحجم الجديد للشعار ، فقد تتحرك بعض الحقول في النموذج أو تختفي أو تصبح غير قابلة للنقر. لا أحد في فريق اختبار Solid يعرف جسديًا كيف يجب أن تبدو جميع الأشكال الـ 200.
كان اختبار هذه المهمة محطمًا للأعصاب ، ولكن نتيجة لذلك ، أنشأنا قاعدة معرفية مع نماذج مرجعية لكل من تجارنا ، وقمنا بتغطيتها بالاختبارات التلقائية ، والآن لا نخشى أي تغييرات تتعلق بالتصاميم.
***
أخيرًا ، سأخبرك بحقيقة مثيرة للاهتمام قليلاً من عالم المعالجة: حصة انخفاض البطاقة المقيدة في أوكرانيا منخفضة جدًا - 1-2٪. إما أن البنوك الأوكرانية جيدة جدًا في منع الاحتيال ، أو لا أحد يريد سرقة بيانات بطاقة المستخدمين الأوكرانيين ...
ومع ذلك ، لا يوجد منتج بعمليات تطوير واختبار مثالية ، ولكن يمكننا تحسينها. بعد كل شيء ، فإن مهمة كل عمل هي إطلاق منتج عالي الجودة. من غيره ، إن لم يكن مهندسو ضمان الجودة ، سيساعد في هذا؟
سأكون سعيدًا إذا كنت تشارك مبادئك لعملية اختبار جيدة في التعليقات.