6 أخطاء سؤال وجواب وكيفية تجنبها

Elkling تمرير حكمته

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

1. ننسى الصورة الأكبر

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

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

2. أضف قضايا بناءً على مشاعرك

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

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

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

3. نسيان وجود المصمم الخاص بك

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

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

4. تغضب ديف الخاص بك

Ahhhh ، يمكن أن تكون devs مخيفة ، يمكن أن تكون devs مزعجة ، يمكن أن تكون devs متغطرسة وغاضبة. لكن المطورين هم دائمًا أفضل صديق لك ، دائمًا! لذا تبذل قصارى جهدك وتؤسس علاقة ثقة. تذهب وتطحن حتى يتحملونك ، أجرؤ على القول حتى مثلك. لأن devs سعيد = QAs سعيد. حتى إذا كان عليك أن تسمع 1000 مرة "إنها ليست حشرة ، إنها ميزة" ، فأنت تعض لسانك وتثابر. إذا كنت لا تصدق شيئًا يخبرك به مطورك ، يمكنك الذهاب إلى أحد كبار المسؤولين وطلب رأي ثانٍ. ولكن من الناحية المثالية ، من الأفضل أن تحافظ على شراكة ثقة. أنت بحاجة إلى الثقة بخبرتهم ومن ثم يثقون بكفاءتك. إنه تكافل جميل ولكنه هش.

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

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

5. افترض أنك جيد جدًا في التوثيق

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

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

6. عدم القيام بالأساس

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

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