تمتلك أقسام تكنولوجيا المعلومات اليوم مزيجًا من DevOps، وWaterfall، والذكاء الاصطناعي، وبرامج التشغيل/الإصدار الجديد، لذلك يجب أن يكون ضمان الجودة قادرًا على الاختبار والتحقق من “جودة” كل هذه الأنظمة المتنوعة. ومع ذلك، فإن أولئك منا الذين قادوا أقسام تكنولوجيا المعلومات يعلمون أن وظيفة ضمان الجودة لا تحظى بالتقدير الكافي عادة.
من خلال إدراك أن ضمان الجودة يجب أن يوسع نطاقه لاختبار مثل هذا النطاق الواسع من الأنظمة المختلفة، قام البائعون بطرح أدوات ضمان الجودة مثل التنفيذ الآلي لنصوص الاختبار التي تصممها ضمان الجودة.
وقد أدى هذا إلى إنشاء سوق ثابت في برامج اختبار ضمان الجودة، والتي تم تحديد رؤى السوق العالمية بقيمة 51.8 مليار دولار في عام 2023، مع معدل نمو سنوي مركب متوقع يبلغ 7٪ بين عامي 2024 و2032.
ما يجب على أقسام تكنولوجيا المعلومات فعله الآن هو وضع استراتيجية لكيفية استخدام هذه الأدوات على أفضل وجه لعدد محدود من موظفي ضمان الجودة، مع تطوير قاعدة المعرفة والوصول إليها مما يسمح لهم بتغطية مجموعة واسعة من التطبيقات والأنظمة الجديدة التي يُطلب من ضمان الجودة اختبارها.
أداء ضمان الجودة بدون “لوح زجاجي واحد”
إذا كنت تعمل في برمجة النظام أو دعم الشبكة، فأنت تعلم أن هناك حلول برمجية شاملة تتميز برؤية “جزء واحد من الزجاج”. توفر هذه الأنظمة بنية شاملة تمكنك من توحيد رؤية جميع الأدوات والوظائف المختلفة الموجودة لديك على شاشة واحدة. لا تستثمر جميع أقسام تكنولوجيا المعلومات في هذه البنى البرمجية الباهظة الثمن، لكنها موجودة على الأقل.
هذا ليس هو الحال بالنسبة لضمان الجودة.
في ضمان الجودة، يعد “مقعد الاختبار” عبارة عن خليط من الأدوات والتقنيات المختلفة المنتشرة على طاولة الأدوات العامة. عندما يقوم أحد الموظفين بإجراء ضمان الجودة، فإنه يختار الأدوات التي يختار استخدامها من مجموعة الأدوات هذه بناءً على نوع التطبيق الذي يتم استدعاؤه للاختبار.
إذا كانت منطقة التطبيق المراد اختبارها هي DevOps، ضمان الجودة عبارة عن وظيفة تكرارية “لم يتم تنفيذها مطلقًا” وقد تستخدم بعض أتمتة الاختبار لتنفيذ سير العمل، ولكن هذا يتطلب أيضًا قدرًا كبيرًا من التعاون بين ضمان الجودة والتطوير والمستخدمين النهائيين حتى يصل الجميع إلى إجماع على أن التطبيق جاهز للإنتاج.
في بيئة الذكاء الاصطناعي، يكون الاختبار أيضًا متكررًا ولا ينتهي أبدًا. أنت تعمل مع خبراء في مجال التطوير ومنطقة المستخدم لتحقيق المعيار الذهبي المتمثل في الدقة بنسبة 95٪ فيما يستنتجه خبراء الموضوع. ومن ثم يجب عليك إعادة تأكيد الدقة بشكل دوري لأن ظروف العمل تتغير باستمرار، وقد تنخفض مستويات الدقة.
إذا كان التطبيق شلالًا، فإنه يمر عبر المسار التقليدي للتطوير، واختبار الوحدة، واختبار التكامل، واختبار الانحدار، والنشر.
إذا كان النظام عبارة عن قاعدة بيانات جديدة أو إصدار لنظام التشغيل أو البنية التحتية من أحد البائعين، فستتم محاكاة الإصدار الجديد أولاً في بيئة اختبار، حيث يتم اختباره وتصحيح أخطائه. يتم تثبيت الإصدار الجديد في مرحلة الإنتاج عندما يتم حل كافة مشكلات الاختبار في البيئة التي تمت محاكاتها.
يتطلب كل من سيناريوهات الاختبار هذه نهجًا عقليًا مختلفًا لضمان الجودة ومجموعة مختلفة من الأدوات.
جعل ضمان الجودة وظيفة استراتيجية ورفع مكانتها؟
مزود أداة الاختبار وقد صرح هاتيكا“في الماضي، كان مهندسو ضمان الجودة يركزون بشكل أساسي على الاختبار – اكتشاف الأخطاء والتأكد من أن المنتج يعمل على النحو المنشود قبل إصداره للمستخدمين. ومع ذلك، فإن هذا النهج التفاعلي تجاه الجودة لم يعد كافيًا في بيئة اليوم. وسرعان ما سيتحول مهندسو ضمان الجودة من كونهم مختبرين في نهاية العملية إلى استراتيجيين للجودة يشاركون منذ البداية.
في تطوير Agile وDevOps، يوجد بالفعل اتجاه ناشئ لضمان الجودة يؤكد ذلك. تشارك ضمان الجودة على الفور في فرق عمل Agile وDevOps، ويقدم فريق ضمان الجودة قدرًا كبيرًا من المدخلات في عملية DevOps/Agile الشاملة مثل التطوير والمستخدمين النهائيين. مع قيام أقسام تكنولوجيا المعلومات بنقل المزيد من العمل إلى Agile وDevOps، سوف يتوسع دور ضمان الجودة كخبير استراتيجي للواجهة الأمامية.
ومع ذلك، في عمليات نشر إصدار الشلال والبنية التحتية الجديدة، يكون دور ضمان الجودة أكثر تقليدية وخلفية. يقوم بإجراء عمليات فحص “نهاية السطر” وغالبًا لا يشارك في المراحل الأولية من التطوير. يمثل الذكاء الاصطناعي أيضًا تحديًا لضمان الجودة، نظرًا لأن مجموعة منفصلة من خبراء علم البيانات أو الموضوع قد تقوم بمعظم تطوير النظام والتحقق منه، لذلك يتم تقليل دور ضمان الجودة إلى الحد الأدنى.
أفضل نهج لضمان الجودة
بفضل حركة Agile/DevOps، ترى ضمان الجودة الآن دورًا أكثر تقدمًا واستراتيجيًا. ومع ذلك، في الوقت نفسه، تعمل التطبيقات في مجالات الذكاء الاصطناعي والشلال والبنية التحتية على إشراك ضمان الجودة كوظيفة خلفية.
كما أن ضمان الجودة متعثر أيضًا بسبب عدم وجود بنية واحدة لأدواته، وبسبب الحقيقة القاسية المتمثلة في أن معظم الموظفين في أقسام ضمان الجودة هم موظفون جدد أو موظفون مبتدئون. وسرعان ما يتقدم هؤلاء الأفراد بطلبات للانتقال إلى تطوير التطبيقات أو قواعد البيانات أو الأنظمة، لأنهم يرون أنها الخيارات الوحيدة القابلة للتطبيق لتطوير حياتهم المهنية في مجال تكنولوجيا المعلومات.
ومن خلال فهم هذه الحقائق، يمكن لمديري تكنولوجيا المعلومات القيام بثلاثة أشياء:
1. نقل ضمان الجودة إلى موقع أكثر استراتيجية في جميع أشكال تطوير التطبيقات. مثل مكتب مساعدة تكنولوجيا المعلومات، تتمتع ضمان الجودة بذاكرة مؤسسية طويلة للعيوب الشائعة في تطبيقات تكنولوجيا المعلومات. إذا انخرطت ضمان الجودة في وقت مبكر في عمليات تطوير التطبيقات، فيمكنها زيادة الوعي بهذه العيوب الشائعة حتى يمكن معالجتها مقدمًا في التصميم.
اقبل أيضًا أن معظم موظفي ضمان الجودة سيرغبون في الانتقال ليصبحوا مطورين أو متخصصين تقنيين في تكنولوجيا المعلومات ويستخدمون ضمان الجودة كأرضية للاستمالة. ولتحقيق هذه الغاية، كلما زادت مشاركة ضمان الجودة في وقت مبكر في تخطيط التطبيقات وتطويرها، زادت المعرفة ببرامج تكنولوجيا المعلومات التي سيكتسبها موظفو ضمان الجودة. وهذا يمكن أن يعدهم للتطوير أو وظائف الأنظمة، إذا اختاروا اتباع هذه المسارات لاحقًا.
2. التأكد من تدريب موظفي ضمان الجودة بشكل صحيح على أدوات ضمان الجودة. لا توجد “بنية uber” متاحة لمجموعة واسعة من الأدوات التي يستخدمها ضمان الجودة، لذا فإن التدريب الشخصي هو المفتاح.
3. تعزيز التعاون. في بيئة Agile/DevOps، يوجد تعاون نشط بين ضمان الجودة والتطوير والمستخدمين النهائيين. في تطوير الذكاء الاصطناعي، يمكن لمديري تكنولوجيا المعلومات تعزيز تعاون أكبر في مجال ضمان الجودة من خلال تشكيل فريق ضمان الجودة مع محللي أعمال تكنولوجيا المعلومات، الذين غالبًا ما يعملون جنبًا إلى جنب مع خبراء في مجال المستخدم وعلماء البيانات. في اختبار إصدار البنية التحتية الجديدة وفي اختبار الشلال، يجب تعزيز التعاون الأكثر نشاطًا مع مبرمجي الأنظمة والتطبيقات.
كلما قمت ببناء المزيد من الجسور التعاونية، كلما زادت فعالية أداء وظيفة ضمان الجودة لديك.
