الفريق الصغير بلا مختبِرين يحتاج نظاماً خفيفاً لا قسماً للجودة: شخص واحد مسمّى يملك قرار «جاهز للإطلاق»، وتعريف مكتوب لكلمة «منجز» يتضمن أن يجرب الميزة شخص غير من بناها، وقائمة قصيرة بالرحلات التي يكسب منها العمل تُعاد بعد كل تعديل، ونسخة تجريبية يُختبر عليها قبل النشر، وسجل واحد للأخطاء. ثم ينقل الفريق الإعادة المتكررة إلى وكيل جودة بالذكاء الاصطناعي، ويحتفظ البشر بما يحتاج حكماً.
- ضمان الجودة للفرق الصغيرة
- كيف نختبر التطبيق بدون مختبرين
- اختبار البرمجيات لشركة ناشئة
- هل تحتاج الشركة الناشئة مهندس جودة
- كيف اسوي نظام جودة لفريق صغير
- من يختبر التطبيق في فريق صغير
من يملك الجودة حين لا يوجد مختبِر؟
في فريق من خمسة أشخاص يسير الأمر هكذا: المطور ينهي الميزة ويقول «جربتها وتعمل». صاحب المنتج يفتحها مرة ويقول «ممتاز». تُنشر الخميس. والأحد يتصل عميل. لا أحد قصّر، لكن لا أحد كان مسؤولاً عن السؤال: هل هذا جاهز فعلاً؟ الجودة في الفرق الصغيرة لا تنهار بسبب نقص المهارة، بل بسبب نقص المالك.
رسم توضيحيالحل ليس توظيف مختبِر غداً. الحل أن تسمّوا شخصاً واحداً يملك قرار الإطلاق. ليس هو من يختبر كل شيء، بل هو من يسأل: هل اختُبر؟ ومن؟ وما النتيجة؟ في أغلب الفرق يكون صاحب المنتج أو المؤسس، ويمكن أن يدور الدور كل شهر.
ما يملكه الجميع لا يملكه أحد. سمّوا اسماً واحداً بجانب كلمة «جاهز».
ما أصغر نظام جودة يعمل فعلاً؟
خمس قطع فقط. أي فريق يستطيع تركيبها في أسبوع، وكل واحدة تعالج سبباً شائعاً لوصول الأخطاء إلى العملاء:
- مالك
- اسم واحد يقرر «جاهز» أو «غير جاهز»
- تعريف «منجز»
- قائمة قصيرة لا تُعتبر الميزة منتهية بدونها
- قائمة الرحلات
- ثلاث إلى خمس رحلات تُعاد بعد كل تعديل
- نسخة تجريبية
- مكان يُختبر فيه قبل أن يراه العميل
- سجل أخطاء واحد
- مكان واحد، لا محادثات متفرقة
لاحظ ما ليس في القائمة: لا قسم جودة، لا وثيقة خطة اختبار من عشرين صفحة، لا أداة معقدة. هذه تأتي لاحقاً إن كبر الفريق. والنسخة التجريبية أهم القطع وأكثرها إهمالاً، وشرحها في النسخة التجريبية والنسخة الحية.
ماذا يجب أن تعني كلمة «منجز»؟
أغلب الخلاف في الفرق الصغيرة حول هذه الكلمة. المطور يقصد «كتبت الكود»، وصاحب المنتج يفهم «العميل يستطيع استخدامها». اكتبوا التعريف مرة واحدة وعلّقوه:
البند الأول يفترض أن هناك وصفاً مكتوباً أصلاً. سطران لكل ميزة يكفيان: ماذا يجب أن تفعل، وماذا يجب أن ترفض. هذه هي معايير القبول، ومن دونها لا يوجد ما يُختبر مقابله. وإن أردتم كتابتها بشكل منظم فاقرؤوا كيف تكتب وثيقة المتطلبات، أو دعوا مديرة المنتج نورة في فنّان تسأل الأسئلة وتكتبها معكم.
ماذا تختبرون حين لا تستطيعون اختبار كل شيء؟
لن تختبروا كل شيء، ولا الفرق الكبيرة تفعل. الحيلة أن تختاروا عن قصد لا بالصدفة. اسألوا عن كل جزء سؤالين: ماذا نخسر إن تعطّل؟ وكم مرة يتغير؟
| الفئة | أمثلة | كم تختبرونها |
|---|---|---|
| يمس المال مباشرة | الدفع، السلة، الحجز، الأسعار، الخصومات | بعد كل تعديل، وكل يوم آلياً إن أمكن |
| يمس الثقة | الدخول، الصلاحيات، بيانات العميل، الرسائل المرسلة | بعد كل تعديل يقترب منها، وأسبوعياً |
| يتغير كثيراً | الصفحة الرئيسية، العروض، ما تعملون عليه هذا الشهر | عند كل تغيير |
| مستقر وقليل الأثر | صفحة «من نحن»، الأسئلة الشائعة، التذييل | قبل الإطلاقات الكبيرة فقط |
| لوحة الإدارة الداخلية | التقارير، إعدادات الموظفين | حين تتغير، والموظفون سيبلّغون بسرعة |
واكتبوا صراحة ما قررتم عدم اختباره. قرار واعٍ مكتوب يختلف تماماً عن نسيان، ويمنع المفاجأة لاحقاً.
ما الإيقاع الأسبوعي الذي يُبقي النظام حياً؟
النظام الذي يعتمد على الحماس يموت في الشهر الثاني. اربطوه بأيام ثابتة. هذا مثال لأسبوع عمل من الأحد إلى الخميس، ومجموعه ساعة إلى ساعتين من وقت الفريق:
- الأحدماذا سنطلق هذا الأسبوع؟
عشر دقائق: الميزات المخططة، ولكل واحدة سطران يحددان ما تفعله وما ترفضه.
- الإثنين–الثلاثاءعين ثانية على كل ميزة
كل ميزة تنتهي يجربها زميل آخر على النسخة التجريبية قبل أن تُعتبر منجزة.
- الأربعاءصيد أخطاء جماعي
عشرون دقيقة، كل واحد على جهاز مختلف، ثم إعادة الرحلات الأساسية كاملة.
- الخميس صباحاًقرار الإطلاق
المالك يراجع السجل: لا حرج ولا عالٍ مفتوح؟ ننشر. وإلا يُؤجَّل ما لم يجهز فقط.
- الخميس بعد النشرفحص دخان على الحية
خمس دقائق: طلب حقيقي من الجوال للتأكد أن ما عمل في التجريبية يعمل هنا.
ولا تنشروا آخر ساعة قبل نهاية الأسبوع. إن ظهر خلل فلن يكون أحد موجوداً ليصلحه، وعملاء المتاجر والمطاعم أنشط ما يكونون في العطلة.
كيف تزيدون طاقة الاختبار دون توظيف؟
حين يكبر المنتج تصبح ساعة الأسبوع غير كافية. قبل إعلان وظيفة، هناك أربع طرق أرخص:
اختر ما يشبه حالتك لترى النصيحة.
هذا عمل وكيل الجودة بالذكاء الاصطناعي. يحفظ الحالات ويعيدها في متصفح حقيقي بعد كل تعديل أو على جدول، ويوثّق ما تعطّل. أنتم تراجعون الخطة والتقرير فقط.
مختبِر مستقل لبضع ساعات عند كل إصدار كبير. أعطوه هدفاً ووصف الميزة ودعوه يستكشف بحرية. لا يحتاج عقداً دائماً.
خمسة عملاء حقيقيين يجربون أمامكم، أو مجموعة تجريبية صغيرة تحصل على الميزة أسبوعاً قبل الجميع. لا أداة تعوض هذا.
دوّروا الدور: كل أسبوع شخص مختلف هو «مختبِر الأسبوع» ساعتين. يتعلم الجميع المنتج كاملاً، وتتغير العين التي تنظر.
المقارنة بين الوكيل والإنسان مهمة بمهمة في وكيل جودة أم مختبِر بشري. والقاعدة: لا تدفعوا لإنسان كي يكرر، ولا تنتظروا من برنامج أن يحكم على الذوق.
كيف يدخل وكيل الجودة في فريق صغير؟
يدخل كزميل يحمل أثقل قطعة في النظام: قائمة الرحلات التي تُعاد. مهندس الجودة في فنّان يأخذ عنوان موقعكم أو تطبيق الويب، سواء بُني في فنّان أو خارجه، ويستكشفه ويقترح حالات اختبار. لا يبدأ قبل أن يوافق أحدكم على الخطة. ثم ينفذ في متصفح حقيقي ويرفع تقريراً بلقطات الشاشة ودرجة الخطورة، وفيه متتبع أخطاء له حالات واضحة، ويعيد الاختبار بعد الإصلاح. وهو ضمن الخطط المدفوعة.
| قطعة النظام | قبل الوكيل | مع الوكيل |
|---|---|---|
| قائمة الرحلات | تُعاد يدوياً، وتُختصر عند الانشغال | حالات محفوظة تُعاد كاملة كل مرة |
| سجل الأخطاء | جدول يُحدَّث عند التذكر | كل خلل له لقطة وخطوات وحالة |
| قرار «جاهز» | انطباع | حكم مع قائمة بما لم يُغطَّ |
| إغلاق الخلل | كلمة «تم» من المطور | إعادة اختبار ناجحة |
| المالك | ما زال مطلوباً | ما زال مطلوباً |
نحن فريق من أربعة أشخاص وليس عندنا مختبِر. هذا تطبيق حجز ملاعب. اختبر أهم ثلاث رحلات بمقاس الجوال: حجز ملعب ودفع العربون حتى صفحة الدفع دون إتمام دفع حقيقي، إلغاء حجز قبل موعده، ودخول صاحب الملعب لرؤية حجوزات اليوم. تأكد أن الملعب نفسه لا يُحجز مرتين في الساعة نفسها، وأن اللاعب لا يرى حجوزات غيره، وأن صاحب ملعب لا يرى ملاعب غيره. أنت على النسخة التجريبية ويمكنك إنشاء حجوزات تجريبية. احفظ الحالات لنعيدها كل أسبوع.
جرّبه في فنّانما الأخطاء التي تقع فيها الفرق الصغيرة؟
- «سنختبر عندما نكبر»: الأخطاء لا تنتظر. والعادات التي لا تُبنى بخمسة أشخاص لن تُبنى بعشرين.
- المطور يختبر عمله وحده: يعرف الطريق الصحيح فلا يخرج عنه. عين ثانية ولو عشر دقائق.
- الاختبار على الحية مباشرة: أسرع اليوم، وأغلى غداً.
- حملة اختبار ضخمة قبل كل إطلاق كبير: مرهقة، ثم تُهمل. الإيقاع الأسبوعي الصغير يغلبها.
- إصلاح بلا إعادة اختبار: الإصلاح نفسه قد يكسر شيئاً مجاوراً.
- شراء أداة بلا مالك: الأداة تنتج تقارير، وتقرير بلا قارئ لا يغيّر شيئاً.
- قياس الجودة بعدد الاختبارات: قيسوها بما وصل للعملاء من أخطاء وكم بقي قبل أن يُكتشف.
ومتى توظفون مختبِراً بدوام كامل؟ حين يصبح العمل البشري الثابت كافياً لملء وقته: ميزات جديدة كل أسبوع، أو أجهزة ونقاط بيع، أو منتج معقد. قبل ذلك، هذا النظام مع وكيل ومستقل عند الحاجة يكفي. ولصورة أوسع عن فريق منتج يعمل بالذكاء الاصطناعي، اقرؤوا فريق منتج في مكان واحد: خطط وابنِ واختبر.
الخلاصة
- «الجودة مسؤولية الجميع» تعني عملياً أنها مسؤولية لا أحد؛ سمّوا مالكاً واحداً للقرار.
- من بنى الميزة لا يكون آخر من يختبرها؛ عين ثانية ولو لعشر دقائق.
- لا تختبروا كل شيء؛ اختبروا ما يخسّركم مالاً أو ثقة إن تعطّل، وبالترتيب.
- إيقاع أسبوعي ثابت من ساعة أو ساعتين يغلب حملة اختبار كبيرة كل ثلاثة أشهر.
- وكيل الجودة يضيف طاقة اختبار دون راتب، لكنه لا يعفي الفريق من تسمية مالك وقراءة التقرير.
أسئلة شائعة
هل تحتاج الشركة الناشئة مهندس جودة من البداية؟
من يختبر التطبيق في فريق بلا مختبِرين؟
كم من الوقت يحتاج الاختبار في فريق صغير؟
هل يكتب المطورون اختبارات آلية بأنفسهم؟
ما الفرق بين ضمان الجودة والاختبار؟
هل يصلح هذا النظام لمؤسس يعمل وحده؟
اسأل مساعدك الذكي عن هذا الموضوع
انسخ هذا الطلب والصقه في مساعد الذكاء الاصطناعي الذي تستخدمه، ثم أضف تفاصيل حالتك.
أقرأ هذا الدليل: «الجودة للفرق الصغيرة: كيف تختبرون وليس عندكم مختبِر» https://fanann.com/ar/blog/qa-for-small-teams-without-testers/ سؤالي: ضمان الجودة للفرق الصغيرة اعتمد على هذه الصفحة كمصدر واشرح لي الإجابة خطوة بخطوة بما يناسب حالتي، واذكر ما يجب أن أتحقق منه قبل أن أبدأ، واذكر رابط الصفحة كمرجع.