العلاقة بين المطورين وفرق ضمان الجودة

نحن لا نفعل ذلك حقًا ، ولكننا سنصل إلى ذلك بعد قليل. بصفتي عضوًا في فريق ضمان الجودة في Vardot ، أجد نفسي أقرأ كثيرًا عن المشكلات التقنية عبر الإنترنت من أجل إنقاذ المطورين من الإذلال الشديد من خلال التقاط ومنع الشفرة التي تنتشر فيها الأخطاء التي أرسلوها للتو من رؤية النور. في أحد تلك الأيام ، عثرت على مدونة بعنوان "QA Hates You" التي أجبرتني على كتابة منشور المدونة هذا.

لنكون صادقين ، نحن لا نكره المطورين حقًا ، نحن فقط نكره حقيقة أن علاقتنا بأكملها معهم تقوم على محاولتنا العثور على أخطاءهم ، ناهيك عن عادتهم في القيام بأشياء مثل إصلاح الأخطاء وعدم الإبلاغ مرة أخرى أنه قد تم إصلاحه ، أو على افتراض أننا جاهلون بشأن كيفية عمل متصفحات الإنترنت المختلفة. لذا ، للمساعدة في تصفية الهواء بين مطوري الويب وفرق ضمان الجودة ، قررت تجميع قائمة بالأشياء التي أخبرني بها المطورون في الماضي وأشر إلى سبب إحباطهم الشديد. بهذه الطريقة ، نأمل في المرة القادمة التي تتعامل فيها مع ضابط ضمان الجودة الخاص بك أن تعرف ما لا تقوله.

 

"امسح ذاكرة التخزين المؤقت في المتصفح"

مجرد لمعلومات سريعة ، ربما جربنا ذلك بالفعل قبل أن تطرق على باب مكتبك ، لذلك لم تعطنا حلاً عندما تشرح لنا معجزة مسح ذاكرة التخزين المؤقت. أيضًا ، لا تلوم المستعرض على الخطأ الخاص بك ، فنحن ندرك أن بعض المتصفحات التي تختبرها قديمة ، ولكن خمن ماذا ، لا يزال المستخدمون يستخدمونها (نحن نتحدث معك IE).

                                                                                       

 

"كل شيء على ما يرام على جهازي"

من الممكن أن تأتي جهازي من جيل مختلف عن جيلك! ولكن ليس من الممكن حقًا أن يكون جهازك هو الجهاز الوحيد الذي يعمل فيه ، لذا تأكد فقط من أنك دفعت كل تحديثاتك قبل تعيين المهمة إلى ضمان الجودة.

                                                                                       

"هل تريدني حقًا توثيق ذلك؟"

 

 

"لا تجرّب على Internet Explorer ، فهو يحتوي على الكثير من الأخطاء ولا يستخدمه أحد"

هل تعتقد حقًا أنني لا أعرف أن IE مليء بالأخطاء؟ (طابورى يضحك بشكل هستيري). إذا كانت شفرتك تعمل بشكل صحيح على IE دون اكتشاف أي أخطاء ، فأنت ROCK ، ولكن بجدية ، سيقوم فريق ضمان الجودة في أي شركة تطوير ويب ذات سمعة جيدة باختبار شفرتك على أكثر من IE فقط. لذا ، إذا جئنا إليك للإبلاغ عن الأخطاء ، فهناك فرصة جيدة لفحص الكود الخاص بك على متصفحات متعددة لأن هذا يحدث كجزء من عملنا. ثانيًا ، ضع في اعتبارك أن IE لا يزال يستخدم من قبل ملايين المستخدمين حول العالم.

 

 

"Aaaaand ، لقد انتهى"

قطع الزوايا عند محاولة إصلاح الخلل ليس الجواب أبدًا. إذا لم يكن لديك الوقت للقيام بذلك بشكل صحيح ، فأنت بحاجة إلى الوقت للقيام بذلك. سنجعلك تفعل ذلك مرة أخرى. ومره اخرى. ومرة أخرى حتى تلبي متطلبات العميل. حسنا؟ الوقت ليس مشكلة كبيرة بالنسبة لنا. الطريقة الوحيدة التي يمكنك بها الابتعاد عن عدم إصلاح الخلل هي ما إذا كان مدير المشروع الخاص بك يخلصك من خلال إخبارنا بتجاوز المشكلة في الوقت الحالي! بخلاف ذلك ، كن مستعدًا للقيام بعملك مرارًا وتكرارًا حتى يكون صحيحًا. أوه ، ولا تعطيني الخط القديم "إنها ميزة ، وليس خطأ" ، إنها أقدم خدعة في الكتاب.                                                                                                                                                                                                                                                                                                                                        

 

"لم أجد الخطأ الذي أبلغت عنه"

"لم أر لقطة الشاشة". ماذا يمكنني أن أفعل؟ كم يمكن أن يكون أكثر وضوحا؟ عندما نجد خطأ ، نكتب سيناريو يحدد الخطأ بدقة ، ويأخذ لقطات شاشة تحدد الخطأ ، ويفتح العنصر المحدد الذي يتعلق بالخلل ويفحصه للتأكد من أنه خطأ بالفعل. أكثر ما يمكن أن تحتاجه ربما؟! فقط اخبرني رجاء. أخبرني وسوف أتأكد من أنني أفعل ذلك لأنني متأكد تمامًا من أنني مكتئب سريريًا الآن بفضل المطورين البطيئين.

 

 

"إنها على الأرجح مجرد مشكلة في المحتوى"

الهدف من عملي هو التأكد من أن كل سطر أخير من الكود نظيف وأن المنتج النهائي يتماشى مع طلبات العميل. عندما تكون هناك مشكلة في المحتوى ، فهذا يعني أننا لم نكمل عملنا بعد. لذا ، إذا كانت هناك مشكلة في المحتوى ، فقم بإصلاحها ثم ارجع إليّ - ثم سأقرر ما إذا كان هذا خطأ حقيقي أم مشكلة فعلية في المحتوى. قد يكون الأمر "مجرد مشكلة في المحتوى" ولكن لا يزال يتعين عليك التحقق ، ولا يستغرق الأمر وقتًا طويلاً - فهذه أمور سهلة مثل هذه التي تحل المشكلات!

 

 

---

نصائح لفريق ضمان الجودة:

لكن فريق البرمجة ليس المحرض الوحيد في هذه العلاقة الصخرية (معظم الوقت فقط). إليك بعض النصائح التي يجب على فريق ضمان الجودة مراعاتها ؛ سيجعل وظائفنا أسهل ويساعد على تخفيف التوترات مع المطورين عندما نتقدم من خلال الامتدادات النهائية لمشروع كبير.

رقم 1. استخدم عنصر الفحص ... استخدمه

لا أفهم لماذا لا يستخدم بعض مختبري ضمان الجودة عنصر الفحص ؛ إنها ميزة مذهلة تجعل مهمتنا أسهل. يسمح لنا برؤية العمل الحقيقي - الكود. ويتيح لنا عنصر الفحص أن نحدد بشكل قاطع ما إذا كان هناك خلل حقيقي أم لا وفي مكانه بالضبط. بصفتك أحد مختبري ضمان الجودة ، فإنك تكسب الاحترام عندما تكشف وتوثق الأخطاء وغيرها من المشكلات التي تمنع فريق التطوير من إطلاق الشفرة مع وجود عيوب قاتلة فيها لعملائنا. نظرًا لأن فريق ضمان الجودة هو أحد خطوط الدفاع الرسمية الأخيرة في عملية العناية الواجبة ، فنحن بحاجة إلى استخدام أفضل الأدوات المتاحة لدينا لضمان جودة منتجاتنا. لماذا تتجاهل أداة مثل عنصر الفحص تجعل هذه العملية أبسط وأسرع؟

 

# 2. بعض الأخطاء أسوأ من غيرها

تمامًا كما هو الحال في مملكة الحيوانات ، فإن بعض الحشرات أكثر خطورة من غيرها. المثال الأكثر وضوحًا هو وجود خلل أمني - يجب أن يظل دائمًا على رأس أولوياتك. أول شيء نريد أن نضمنه هو أن منتجنا آمن - فالأمان هو دائمًا طلبك الأول للأعمال ، ويجب إعطاء الأولوية لجميع الأخطاء التي قد تؤدي إلى حدوث خرق والتعامل معها على الفور ، خاصة في الحالات التي تتعلق ببيانات المستخدم. إن إطلاق الشفرة مع أي مشكلة هو شيء نريد دائمًا تجنبه ، ولكن يجب أن تكون أخطاء الأمان على رأس قائمة "الأسئلة الأكثر طلبًا" الخاصة بنا.

 

# 3. تعلم أن تقول "لا" للمطور

يرغب بعض المطورين في ادعاء أنه يمكنك تعديل بعض المشكلات من النهاية الخلفية ومحاولة تحديد المسؤولية عليك (بعض المطورين يفعلون ذلك ، وليس كلهم. إذا لم تكن واحدًا منهم لا تغضب ، حسنًا). يجب أن تكون قادرًا على إخبار المبرمج "لا" أن هذه ليست وظيفتك ، أو إذا حاولوا إقناعك بأنها ميزة ، فأنت بحاجة إلى الرجوع إلى المتطلبات والعثور على الأدلة التي تحتاجها لإثبات أن نعم ، في الواقع ، إنه خطأ. هذا أمر مهم لأنه إذا قمت بعملك بشكل صحيح وقمت بتحديد مشكلة داخل الكود ، فيجب إصلاحه - ومن خلال مطور لديه الخبرة للتعامل مع هذه المهمة ، وليس عضوًا في ضمان الجودة. لذلك من أجل إنجاز المهمة ، كعضو ضمان الجودة ، يجب أن تكون قادرًا على وضع قدمك مع المطورين عندما يحاولون التنصل من المسؤولية.

 

 

# 4. استخدم لقطات الشاشة

يجب أن تكون لقطات الشاشة (إلى جانب عنصر الفحص) أفضل صديق لاختبار ضمان الجودة. عندما يوثق اختبار ضمان الجودة خطأً ، يحتاجون إلى تعزيز أدلةهم من خلال لقطة شاشة لأن المطور يحتاج إلى دليل ملموس على أن المشكلة موجودة بالفعل - وبهذه الطريقة لا يمكنهم أن يقولوا "هذا خطأ ، لا يمكنني العثور على الخطأ!" قم بتغطية قواعدك والتقط أفضل لقطة شاشة ممكنة لإثبات أنها خطأ بشكل صحيح - وبهذه الطريقة إذا ادعى المطور أنه لا يمكنه العثور على خطأ ، فلن تضطر إلى البحث عنه مرة أخرى ، لأنك وثقت بالفعل المشكلة.

                                                                                                                                                                                                      

لسوء الحظ ، ربما لن تعمل هذه المدونة على إصلاح العلاقة المكسورة تمامًا بين فريق التطوير وفريق ضمان الجودة ، ولكن على الأقل قمت بمسح الهواء. بهذه الطريقة ، ربما في المرة القادمة يتساءل أحد مطوريك عن سبب قيام اختبار QA عبر غرفة الاستراحة بإصلاحك بقطعة ، سيكون لديك فكرة عن السبب.