مختبر البرمجيات والصمود أمام فريق التطوير

مختبر البرمجيات والصمود أمام فريق التطوير

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

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

الجوانب المادية: نسبة المختبرين إلى المطوّرين واختلال التوازن بين الجنسين

يحتوي هذا القسم على المشكلات المرتبطة بصناعة تطوير البرمجيات نفسها. حتى إذا لم تكن لديك أي خبرة كعضو في شركة اختبار برمجيات، يمكنك توقّع بعض المشكلات من خلال تحليل البيانات الإحصائية المتاحة. على سبيل المثال، دعنا نلقي نظرة على نسبة المختبرين إلى المطوّرين والتي تعتمد على جوانب عديدة. لا تتبع جميع الشركات القاعدة الذهبية لمايكروسوفت وهي: حافظ على نسبة المطوّرين إلى المختبرين تساوي 1:1. النسبة الأكثر شيوعًا هي مختبِر واحد مقابل ثلاثة مطوّرين. يمكن أن يكون حتى مختبِر واحد لـ 10 مطوّرين في بعض الحالات. النقطة المهمّة هي أنه في السيناريو الأكثر تفاؤلاً، سيتعيّن على المختبِر التعامل مع الكود الذي كتبه ثلاثة مطوّرين مختلفين. إذا لم يتم التخطيط لسير العمل بشكل مناسب، فقد تجد نفسك غارقًا في المهام بسرعة كبيرة ويمكن أن يؤدي ذلك إلى انخفاض في الإنتاجية والتوتّر والإحباط. تتضمّن بعض منهجيات تطوير البرمجيات مثل Scrum على سبيل المثال اجتماعات منتظمة يمكن أن تساعد في مناقشة ما تم إنجازه وما يجب القيام به وما هي المشكلات التي يواجهها الفريق. يُعد سياق ال Agile هذا فرصة جيدة لمختبِر البرمجيات لجذب الانتباه إلى العديد من المهام الكبيرة لديه. ولكن في حالة نموذج V-Model أو المشاريع القائمة على ال Waterfall والتي لا تتضمّن اجتماعات منتظمة، يجب أن تكون هناك آلية للتواصل بين الفرق. يتعيّن على مدير المشروع التأكّد من عدم وجود آراء غير مُعلنة وأن أعضاء فريق الاختبار أحرار في مناقشة المشكلات التي يواجهونها بالإضافة إلى الأفكار لحلّها.

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

الجوانب النفسية: (إنه يعمل على جهاز الكمبيوتر الخاص بي) وأهمية بناء الفريق

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

على الرغم من حقيقة أن خصائص مهنتي الاختبار والتطوير هي مرتبطة بحل المشكلات التقنية، قد يكون من الصعب جدًا التغلّب على المشكلات غير التقنية. نظرًا لأنك تعمل مع أشخاص آخرين، يجب أن تتذكّر دائمًا أنه لا يمكن الاستهانة بتأثير العوامل البشرية مثل الحُكْم الذاتي. على سبيل المثال، ما الذي يجب عليك فعله عندما يكون مدير المشروع يريد إنهاء المشروع في أقرب وقت ممكن ولذلك يُصِر على أن الخطأ المُكتشَف ليس خطأ على الإطلاق ولا توجد أسباب لقضاء المزيد من الوقت والجهود في حلّها؟ المواصفات والمعرفة بمنتجات الشركات الكبيرة ذات الوظائف المماثلة هي حبوب سحرية يمكن أن تمنع احتمال وجود تناقضات. في الواقع، إذا حدّدت شركتك بوضوح ما هو الخطأ وما هي الميزة (feature)، فلن تضطر حتى إلى إقناع أي شخص بضمير حي لديك ويمكن أن تتأكّد من أن العمل لم يتم سُدى. عندما تعرف بالضبط ما يجب أن يقدّمه منافسوك المحتملون لعملائهم وأن هناك خلل يمكن أن يكسِر وظائف منتجك ويحرمك من ميزة تنافسية، فإن تجاهلها يمكن أن يبطِل كل الجهود. أي مدير في مثل هذه الحالة سيتعامل مع رأي فريق الاختبار بالاهتمام الواجب.

عادة ما يقع عبء المسؤولية عن جودة المنتج على فريق الاختبار. لسوء الحظ وفي معظم الحالات، يتم تجاهل أفكار تحسين سير العمل المقترحة من قِبَل المختبرين. يمكنك أن تتخيّل الضغط النفسي الذي يمكن أن يسبّبه الموقف الموصوف. يجب عليك إطلاق المنتج في وقت محدود وليس لديك أي تأثير على كيفية إنجاز كل شيء وفي نفس الوقت تُعتَبر مسؤولاً عن جودته. إنه وضع غير سار بالفعل. عادة ما تأتي القدرة على مقاومة مثل هذه التحدّيات مع الخبرة. إذا لم تتمكّن من تغيير الموقف، فعليك التكيّف معه. حتى لو كان عليك العمل ضمن موعد نهائي ضيّق فلا تتعجّل. اقض الكثير من الوقت الذي تحتاجه لتحديد أولويات اختبار الكود وعُمْق تغطية الكود (code coverage) بشكل صحيح وستكون قادرًا على تجنّب العواقب غير المرغوب فيها.

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

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

بالتوفيق للجميع…

* المصدر: https://www.softwaretestingmagazine.com/knowledge/how-to-survive-as-a-qa-in-a-software-development-team

** الصورة من موقع: https://wallencore.com/relationship-between-developers-and-testers

2 تعليقات

Rma

about 2 years ago

جميل جدا وواقعي استمتعت بالقراءة

Reply

أنور بوسبول

about 2 years ago

شكرًا لك

Reply

شاركني رأيك