https://virgool.io/feed/@m_58384324 fa 2026-06-17 02:43:27 https://files.virgool.io/upload/users/3067741/avatar/BJexFl.png?height=120&width=120 https://virgool.io/@m_58384324 https://virgool.io/@m_58384324/%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%87%D9%88%D8%B4%D9%85%D9%86%D8%AF%D8%A7%D9%86%D9%87-%D8%B4%DA%A9%D8%B3%D8%AA-%D8%A7%D8%B2-%D8%AC%D9%86%DA%AF-2006-%D8%AA%D8%A7-%D8%B9%D9%85%D9%84%DB%8C%D8%A7%D8%AA-%D8%A8%D8%B1%D9%82-%D8%A2%D8%B3%D8%A7%DB%8C-2025-qnm4xitcva4v در سال 2006، رژیم اسرائیل در جنگی 33 روزه علیه حزب الله لبنان به اهدافش نرسید و به سختی درگیری با یک گروه چریکی را پایان داد. اما امروز، پس از دو دهه، نه تنها جنگی مخرب بر حزب الله تحمیل کرد، بلکه علیه کشوری در 2000 کیلومتری با 80 برابر وسعت و 10 برابر جمعیت عملیاتی برق آسا و ویرانگر را آغاز کرد؛ هر چند خود آسیب فراوانی دید.تحولی که رخ دادچه اتفاقاتی رقم خورد که چنین کشور کوچکی در مقیاس جمعیت و مساحت و تمدن، پس از شکستی خفت بار از یک گروه کوچکتر، توانست خود را چنان بازیابی کند که آتشی بزرگ در منطقه به پا کرده و کشوری به مراتب گسترده‌تر با تمدنی کهن و ملتی منسجم را به جنگ بکشاند؟ چه شد تا مردمی که توانایی تحمل یک ماه جنگ را نداشتند، به سطحی از تاب‌آوری رسیدند که بیش از 2 سال را در جنگ و تنش سپری کنند؟پاسخ در مدیریت هوشمندانه شکست نهفته است.پس از ناکامی رژیم اسرائیل در جنگ 2006، درحالی که طرف مقابل در حال جشن گرفتن بود، اسرائیلیها کمیسیونی مستقل به رهبری «ایلیاهو وینوگراد» (قاضی بازنشسته) تشکیل دادند که مأموریتش "بررسی ریشه‌ای شکست بدون محدودیت و با اختیارات تام" تعیین شد. تشکیل «کمیسیون وینوگراد» نقطه عطف تحول اسرائیل بود.روش آنها ارزیابی عملکرد تمامی سطوح تصمیم‌گیری (سیاسی/ نظامی) و آسیب‌شناسی سیاست‌های امنیتی بود (دقت کنید: در تماااامی سطوح). این کمیسیون هیچ محدودیتی برای انجام تحقیقات و احضار تمامی مقامات بلندپایه نداشت و تبعیت مقامات ارشد سیاسی و نظامی از آنها الزامی بود و همین نکته، موفقیت و شفافیت گزارش این کمیسیون را ضمانت کرد.خروجی این کمیسیون تحول‌آفرین و شگرف بود؛ گزارش که منتقدانه، شفاف و بدون مصلحت‌اندیشی تدوین شده بود.این گزارش، سه مقام ارشد شامل: نخست‌وزیر، وزیر جنگ و رئیس وقت ستاد مشترک ارتش اسرائیل را مسئول ناکامی معرفی کرد و باعث استعفای وزیر جنگ شد و لرزه‌های سیاسی شدیدی در آنجا ایجاد کرد.اما مقامات فقط به این گزارش اکتفا نکردند و تلاش کردند تا نقاط ضعف خودشان به شکل اصولی و همه جانبه اصلاح کنند و استراتژیهای خود را بازبینی و بازنویسی کنند. نهایتا تغییرات زیادی در دکترین نظامی و ساختار فرماندهی صورت گرفت و اصلاح سیستم‌های اطلاعاتی و لجستیکی شروع شد و از همان روزها تحول در آموزش و آمادگی رزمی کلید خورد.تضاد دو رویکرد: درس‌هایی از دو مسیر مختلفدو طرف نبرد برخورد متفاوتی با نتیجه جنگ داشتند که آینده آنها را به شکل کاملا متفاوتی رقم زد.رژیم اسرائیل این مسیر را در پیش گرفت:. پذیرش شکست بدون توجیه و انکار. شفافیت بی‌رحمانه در آسیب‌شناسی عملکرد. سرمایه‌گذاری جسورانه بر اصلاحات ساختاریحزب الله / ایران اینگونه ادامه دادند:. انکار واقعیت با توجیه‌های ایدئولوژیک. تمرکز انحصاری بر تبلیغ پیروزی‌ها. تکرار الگوهای شکست‌خورده بدون بازنگریاین تفاوتِ رویکرد، سرنوشتِ دو سیستم را رقم زد: رژیم اسرائیل با مواجهه شجاعانه با اشتباهات، شکست را به موتور تحول تبدیل کرد ولی حزب الله و متحدانش با پنهان‌سازی ضعف‌ها در پشت شعارهای پرشکوه، در دام تکرار چرخه‌های شکست گرفتار ماندند.نتیجه؟ فاصله‌ای که در 20 سال از "ناکامی در جنگ 33 روزه" تا "برتری راهبردی در نبردهای فرامرزی" ایجاد شد!برای مدیریت هوشمندانه شکست، این نکات کلیدی هستندشکست، موتور نوآوری است: اصلاحات بنیادین تنها با پذیرش ناکامی‌ها ممکن می‌شود. اگر نظام یا سازمانی خود را همیشه پیروز بداند و شکستها را به عنوان پل پیروزی نبیند، نه تنها نقاط ضعف را مستند نمیکند بلکه همان نقاط ضعف را به شکل توانمندی جا میزند و تلاشی برای رفع آنها نمیکند. سازمانی که ذهنیت برنده (winning mindset) دارد، هر شکست را دانشگاهی می‌بیند برای بهتر بودن نه ابزاری برای تفاخر یا تمسخر.پنهانکاری مساوی فاجعه است: انحراف از واقعیت، اشتباهات را به بحران‌های مکرر تبدیل می‌کند. پذیرش شکست، سازمان پیشرو را به سمت بررسی دقیق و ریشه‌ای مشکل هدایت میکند تا هم از تکرار آن جلوگیری کند و هم مسیر را برای پیروزی و موفقیتهای بزرگتر هموار سازد. مخفی‌کاری تنها هزینه‌ها را به صورت نجومی بالا میبرد و در کوتاه مدت مرهمی برای فراموشکاری است نه یک راه حل درست و نهایی.شفافیت کلید اصلی است: گزارش‌های بی‌پروای حاوی اخبار بد پیشران تحول هستند. کالبدشکافی شکست، هر چند دردآور و سنگین است اما این حرکت کوتاه‌مدت، موفقیت سازمان را در بلندمدت تضمین میکند. سازمانی که شجاعانه خود را در معرض نقدها و موشکافی متخصصان بیرونی قرار میدهد، شانس خود را برای شناسایی، بررسی، اصلاح و پیشرفت چندین برابر میکند و هزینه‌های زیادی را صرفه‌جویی میکند.نتیجهتحول 20 ساله رژیم اسرائیل مثالی بزرگ از این گزاره است: «پذیرش شکست، گران‌ترین اما ضروری‌ترین سرمایه‌گذاری است». آنها اشتباهات را به پلکان ترقی تبدیل کردند و ما در باتلاق تکرارِ الگوهای شکست‌خورده ماندیم.تمایز بین سازمان‌های پیشرو (با ذهنیت برنده) و وامانده (با ادعای برندگی همیشگی) در نحوه مواجهه با شکست است: پیشروها آن را آینه‌ای برای دیدن زشتی‌های خود می‌دانند و وامانده‌ها آن را پنجره‌ای برای تخریب دیگران!نمونه دیگری که برای مدیریت هوشمندانه شکست میتوان بررسید، مسابقه فضایی ابرقدرتهای غرب و شرق است. کتاب "مسابقه فضایی" نوشته ناتان آسنگ، مدیریت شکست را در آن مسابقه را مرور میکند و دلیل برتری طرف پیروز بیش از پیش قابل درک خواهد بود.#مدیریت_شکست #تحول_سازمانی #رهبری_تحول‌آفرین #شفافیت_سازمانی #مدیریت_تغییر #برنامه‌ریزی_استراتژیک #رهبری_اجرایی#آسیب‌شناسی #نوآوری_در_مدیریت #مدیریت_هوشمندانه_شکست #ذهنیت_برنده سید محسن سید محسن Sat, 09 May 2026 13:57:33 +0330 https://experience.basalam.com/از-خاکستر-بحران-تا-نقشه-ی-آینده-قدرت-تحلیل-داده-در-مدیریت-بحران-dcu05phhx04j در آتش‌های جنگ، یکی از ارزشمندترین دارایی‌ها، داده‌های دقیق و تحلیل‌شده است. تجربه نشان می‌دهد که جمع‌آوری نظام‌مند اطلاعات و سپس تحلیل هوشمندانه‌ی آن، دست برتر استراتژیک را در اختیار تصمیم‌گیران قرار می‌دهد.این داده‌ها، سنگ بنای برنامه‌ریزی‌های حیاتی است:برنامه‌ریزی دفاعی و امنیتی: شناسایی نقاط آسیب‌پذیر، تخصیص بهینه منابع، پیش‌بینی مسیر تهدیدات.برنامه‌ریزی اقتصادی و اجتماعی: مدیریت بحران‌های معیشتی، توزیع کمک‌های انسان‌دوستانه، حفظ چرخه‌های اقتصادی حیاتی.مدیریت منابع: بهینه‌سازی توزیع آب، غذا، دارو و انرژی در شرایط بحرانی.اما قدرت این آموزه‌ها تنها به دوران جنگ محدود نمی‌شود. شرکت‌ها و استارتاپ‌ها - از خرده‌فروشی آنلاین و پلتفرم‌های حمل‌ونقل گرفته تا سرویس‌های رزرو اقامتگاه - می‌توانند با به‌کارگیری اصول مشابه تحلیل داده در شرایط بحران، برای سناریوهای اختلال پیش‌بینی نشده (شکست زنجیره تأمین، بلایای طبیعی، ناآرامی‌ها) برنامه‌ریزی کنند و تاب‌آوری خود را افزایش دهند.مناطق بمباران شدهاکنون، با گذر از آن دوران دشوار، ثروتی از داده‌های تجربی در اختیار داریم. تحلیل تطبیقی این اطلاعات - مانند داده‌های مربوط به مناطق آسیب‌دیده - چراغی قدرتمند برای آینده است. این تحلیل‌ها به ما امکان می‌دهند:مدل‌های پیش‌بینی دقیق‌تری برای انواع بحران‌ها بسازیم.سناریوهای پاسخ‌گویی را با واقع‌بینی بیشتری طراحی کنیم.زیرساخت‌ها و سیستم‌های خود را برای تاب‌آوری حداکثری بهینه‌سازی نماییم.🔗 دسترسی به داده‌ها:برای بررسی دقیق‌تر، مجموعه داده‌های مناطق بمباران شده مبتنی بر منابع آزاد اینترنت (غیرمحرمانه) را گردآوری کرده‌ام که شامل ستون‌های زیر است:https://docs.google.com/spreadsheets/d/1SXCg09SH2OAR2C485fr8gaM6a9rCQ5Td8w-6CRcTcuw/مختصات جغرافیایی (طول و عرض)تاریخاستانشهر📌 توجه به محدودیت‌ها:۱. این داده‌ها شامل حملات ریزپرنده‌ها (پهپادی) نمی‌شوند.۲. فعالیت‌های پدافندی در این مجموعه‌داده لحاظ نشده‌اند.۳. امکان ناقص بودن: به‌ویژه در ساعات پایانی، برخی حملات ممکن است در این نسخه ثبت نشده باشند.اگر داده‌های تاییدشده‌ی دیگری دارید که به تکمیل یا اصلاح این مجموعه کمک می‌کند، خوشحال می‌شوم از دانش شما بهره ببرم. هدف من ایجاد مرجعی دقیق‌تر برای تحلیل‌های آینده است.درس بزرگ: سرمایه‌گذاری بر سامانه‌های جمع‌آوری و تحلیل داده، حتی در صلح، آمادگی ما را برای هر طوفان غیرمنتظره‌ای افزایش می‌دهد و تصمیم‌گیری‌ها را از واکنشی به کنشی تبدیل می‌کند.و در پایان، آرزویی فراتر از تحلیل داده: امیدوارم روزی برسد که هیچ‌کجای این کره‌ی خاکی، شعله‌ی جنگ افروخته نشود و صلح، تنها بستری باشد که در آن، داده‌ها برای پیشرفت و رفاه همگان به کار گرفته شوند.#تحلیل_داده #مدیریت_بحران #تاب_آوری #برنامه_ریزی_استراتژیک #هوشمندسازی #داده_محوری #داده_باز #تحلیل_فضایی #جغرافیایی #ایران #صلح #یادگیری_از_تجربه #استارتاپ #کسب_و_کار #زنجیره_تامین #logistics #ecommerce #PredictiveAnalytics #DataTransparency سید محسن سید محسن Fri, 27 Jun 2025 18:39:38 +0330 https://experience.basalam.com/تجربه-ایجاد-تیم-تست-باسلام-چطور-تیم-تست-دار-شد-d12xqwkcipn3 میانه‌های سال ۱۴۰۰، اوضاع محصول باسلام در نسخه‌های موبایلی و کامپیوتری، به حد بسیار آزاردهنده‌ای رسیده بود. هم برای تیم باسلام هم برای کاربران محصول باسلام (شامل غرفه‌داران و مشتریان). درصد قابل توجهی از تماسهای ورودی به عملیات پشتیبانی، ریشه در باگهای نرم‌افزاری داشتند. طبق آماری که کافه بازار در گفتگویی ارائه دادند، میزان انتشار (release) نسخه موبایلی باسلام، ۳ برابر اپلیکیشن‌های مشابه بوده است. تیم‌های توسعه بیشترین فشار را بابت اصلاح خطاها و باگ‌ها تحمل می‌کردند و همه سازمان در تب و تاب اصلاح ناهماهنگی‌ها و عجله‌ها بود. با وجود اینکه هر کسی خروجی کار خود را تست می‌کرد، اما اغلب انتشارها بسیار کم کیفیت و حتی خراب بودند. بازخوردهای منفی از هر طرف به سمت تیم باسلام می‌آمد.دلیل این مسأله یک چیز بود: هیچگاه تست جامعی بر روی محصول نمی‌شد و رویکرد تست‌های انجام شده، فقط اثبات کار کردن همان قسمت از محصول به شیوه دلخواه خودمان بود نه چیز دیگر! آن هم محصولی که میلیون‌ها کاربر ثبت نام شده دارد!تماس تلفنی با پشتیبانی به دلیل گزارش باگ در دوره 1400 - 1401ریشه دیدگاه مذکور اما ذهنیت مدیران توسعه‌دهنده محصول باسلام بود: دقت نکردن به نیاز واقعی مشتری و تمرکز صرف بر نوآوری و رشد سریع و توجه نداشتن به اعتماد کاربر (trust). ( تجربیات داود با موضوع بلیتز اسکیلینگ جالب هستند - BlitzScaling -) به بیان دیگر، به بهانه این که "ما در حال رشد سریع هستیم نمی‌توانیم وقت را تلف کنیم! هر وقت کاربری به مشکل خورد آن را برطرف می‌کنیم" هر چند رویکرد درستی بود اما خروجی‌های بی‌کیفیت و پر اشکالی منتشر می‌شد که باعث کم شدن اعتماد کاربران به محصول شد. اولویت شدید کمیت بر کیفیت! (درباره کیفیتِ کمیت خواهم نوشت…)اما سرانجام اتفاق خوبی افتاد: آن اتفاق خوب، اتفاقِ بدِ کند شدن رشد باسلام بود! این مساله باعث پررنگ شدن کیفیت نرم‌افزار و توجه به اعتماد بیشتر کاربر به محصول شد و جرقه ایجاد فرآیند تست در شرکت زده شد.این نوشته برای چه کسانی خوب است؟مجموعه‌هایی که به نتیجه رسیده‌اند نیاز به تست پیش از انتشار دارند، اما نمی‌دانند از کجا شروع کنند؛ یا اینکه تیمی برای این کار دارند اما خروجی آن مطلوب نیست و در بر همان پاشنه سابق می‌چرخد.گزارشهای کاربران به نتیجه نمی‌رسد و مجبورید تیم پشتیبانی و توسعه محصولتان را بزرگتر کنید و دستانتان بسته است.قیف هست، قیر نیست! قیر هست، مامور رفته به مرخصی!! و کلا همه چیز هست اما انگار نیست…این نوشته، خلاصه تجربیات باسلام در تشکیل این فرآیند است.تصمیم سخت رهبران و مدیرانتغییر شیوه تفکر به فرآیند توسعه محصول، جام زهری بود که رهبران باید سر می‌کشیدند! نظم نداشتن، هماهنگی کم، ارائه سریع نسخه‌ها (fast releases)، تحلیل کم عمق و در یک کلام «چارچوب درست نداشتن»، رفتارهایی بودند که همه ما به آن عادت کرده بودیم و تغییر چنین عادت‌هایی بسیار سخت و انرژی‌بر است. هم‌راستا کردن افرادی که متفاوت فکر می‌کردند و ناهماهنگ عمل، کاری بس سخت بود.حرکت درست، شروع شد: مدیرعامل تغییر را از خودش آغاز کرد. این موثرترین کاری بود که می‌توانست اصلاح فرآیند را به پیش ببرد.تغییر از بالا به پایین کم هزینه‌تر و سریعتر رخ می‌دهد ضمن اینکه ماندگاری و مقبولیت بیشتری توسط افراد دارد و موثرتر است. اگر این مسیر از پایین به بالا باشد، علاوه بر بسیار زمانبر و پرهزینه بودن، ممکن است تغییرات واقعی رخ ندهد  و صرفا پوسته کارها تغییر کند؛ خصوصا اگر بالاییها در برابر تغییر مقاومت کنند.در نتیجه این کار مدیرعامل، عملی بسیار ارزنده و شایسته بود که آن را با هماهنگی سایر رهبران انجام داد.مرحله دوم، اقناع مدیران و سایر افراد مجموعه برای پذیرش مسیر جدید و قاعده‌مندتر شدن بود. مدیران و سرتیم‌هایی که به همان رفتارهای پیش‌گفته عادت کرده بودند و افراد تیم را به آن ترغیب می‌کردند، حالا باید ۱۸۰ درجه تغییر مسیر بدهند. بسیار پیش آمده افرادی که در بخشی مشغول کار هستند، توجهی به تصویر کلی ندارند و بعضا تاثیرات مثبت و منفی عملکرد خود را در مقیاس بزرگ، نادرست ارزیابی می‌کنند. ترکیب این نگرش با خطاهای ذهنی مانند انواع سوگیری‌ها، باعث ایجاد اینرسی حرکتی بالایی برای ادامه مسیر قبلی می‌شود که تغییر آن انرژی زیادی می‌طلبد. (چقدر فیزیک!!!) این عوامل سبب می‌شود که عوض کردن تفکرات افراد به ذهنیت جدید، فوق‌العاده سخت باشد.بر همین اساس، لاجرم افرادی که در برابر ذهنیت و فرآیند جدید مقاومت می‌کردند، از سیستم خارج می‌شدند که این هم چالش انسانی زیادی ایجاد کرد.بالاخره پس از جلسات سخت و گفتگوهای بسیار، فرآیند جدید تصویب شد؛ و چه خوب که شد!ساختن تیم تضمین کیفیت (Quality Assurance - QA)پس از قطعی شدن فرآیند تست در توسعه محصول و تعیین وظایف تیم تست، گام دوم ما طراحی جزئیات فرآیند تست و جمع کردن تیمی قوی بود.این تیم علاوه بر اینکه وظایفی مشخص شده دارد، باید قدرت اجرایی بالایی هم در سازمان داشته باشد تا به خروجی مد نظر برسد.چرا QA بله و QC نه؟ تفاوتشان در چیست؟این دو تیم جدای از اختلافهایی که دارند، شباهتهای زیادی با هم دارند و همین باعث می‌شود که به اشتباه مثل هم تصور بشوند.این شکل جداسازی خوبی انجام داده:QA vs QCاما در باسلام ملغمه‌ای را پیاده کردیم! درست است که وظایف QC را انجام می‌دهیم اما به اسم QA هستیم به یک دلیل: میخواهیم Proactive باشیم.این مساله ارتباط نزدیکی با فرهنگ جدید باسلام داشت و آن هم عمیق‌تر شدن تحلیلها قبل از ورود به پیاده‌سازی محصول بود. به گفته دیگر، قرار گذاشتیم که بیشتر فکر کنیم و کمتر حرف بزنیم و هوشمندانه‌تر از قبل کار کنیم.بهرحال کاری که انجام می‌دهید مهمتر از عنوان است؛ اما عنوان تیم، نشان‌دهنده نوع تفکر شما و اولویتهای تیم است.تعریف وظایف و شاخص عملکردوظیفه اصلی تیم تست یا به عبارت درست‌تر تضمین کیفیت، اطمینان از خروجی بی‌اشکال محصول بود؛ اما وظایف دیگر که کمک کننده این هدف بود بشرح زیر تعریف شدند:تست جامع محصول و تهیه گزارش پیش از هر انتشارجمع‌آوری و پالایش گزارشهای باگ از همه کانالهاپردازش و ارسال گزارشها به تیم مربوطه در کانال درستارائه گزارشهای دوره‌ای از وضعیت عملکردی تیمها و باگهای آنهابر این اساس شاخصی برای تیم تضمین کیفیت تعریف شد: ۱۰۰% باگها از مسیر این تیم گزارش بشود؛ تا این تیم به دنبال اصلاح فرآیند گزارش باگها باشد و آن را از مسیر بهینه پیش ببرد. از دلایل تعیین شاخص فوق، ارتباط زیاد اشخاص مختلف در داخل و خارج تیم با افراد توسعه دهنده محصول (شامل مدیران و همکاران) بود که باعث عدم تمرکز آدم‌ها و بهم خوردن اولویت‌ها در مسیر توسعه بود و بارها از مسیرهای مختلف یک باگ تکراری گزارش می‌شد؛ بعلاوه اینکه باگها به افراد غیر مرتبط گزارش می‌شد که بعضا این گزارشها در گفتگوها محکوم به فراموشی بودند.در کنار این شاخص برای تیم QA، برای همه تیمهای محصول یک KR مهم تعریف شد: " Bug free بودن حوزه مسئولیت" تا به این ترتیب تیمها به همکاری با تیم جدید نیازمند و متعهد باشند و در نتیجه هم‌افزایی بیشتری برای بهبود کیفیت محصول انجام دهند.چون سه اصل سختگیرانه برای تیم‌ها تعریف شد:هیچ چیز تست نشده‌ای نداشته باشیم.پیش از هر انتشاری (Release)، حتما تایید QA برای UAT را بگیرد.مسئول باگهای هر تیم، همان تیم است؛ حتی اگر تایید QA را گرفته باشد.مورد سوم البته ابهامی ایجاد کرد: عدم تناسب مسئولیت و اختیار. جواب:دو اصل مهم در تست نرم‌افزار وجود دارد:. Testing shows the presence of defects, not their absence. Absence-of-errors is a fallacyفرآیند تست هیچ‌گاه نمی‌تواند بگوید که ۱۰۰% همه چیز درست و بدون اشکال است، اما با اطمینان بالا می‌تواند اعلام کند که محصول درست کار می‌کند.تیم تست هر چقدر هم کارآزموده و بزرگ باشد، نمی‌تواند و حتی محال است که تمام حالت‌ها را امتحان کند.( اصول هفتگانه تست نرم افزار در ISTQB را بدانید)خوشبختانه همه به این اصول متعهد شدند.در فرآیند جدید، تستهای performance و security قبلا توسط خود تیمها انجام می‌گیرد و البته سامانه‌ها پیوسته توسط تیمهای زیرساخت پایش می‌شوند و بطور دوره‌ای هم بررسیهای امنیتی انجام می‌پذیرد.تشکیل تیم: چه افرادی برای تیم تضمین کیفیت مناسب هستند؟اولین انتخاب خیلی از مجموعه‌ها برای تشکیل تیم تست، جذب افراد با سابقه و تجربه در این زمینه است. ولی پیدا کردن چنین گوهرهای نابی چه سخت و دشوار است! البته علاوه بر یافتن فرد مورد نظر، چالش بعدی اختصاص زمان زیاد برای شناختن و درک کل محصول از جانب همکار جدید خواهد بود که به اندازه جذب آن فرد زمان و انرژی می‌خواهد.همزمان با جستجوی بسیار و در میان امید و ناامیدی، ایجاد تیم از همکاران خودمان را هم در پیش گرفتیم و پروسه انتخاب شروع شد.شاید در نگاه اول برنامه‌نویسان مناسب‌ترین نفرات برای تست باشند و ممکن است مالک محصول (Product Owner) یا طراحان را برای این مساله دقیقتر بدانید. اما انتخاب ما باید کسانی می‌بودند که هم ریزبینی بالایی داشته باشد و هم وسواس مشتری!خصوصیات اعضای تیم را اینطور تعریف کردیم:با حوصله و دقیق است.کسب و کار باسلام را می‌داند.به گوشه و کنار محصول اشراف دارد.دردهای کاربران محصول را عمیقا می‌فهمد و برایش اولویت است.فرآیندها و journeyهای محصول را به خوبی درک می‌کند.به کاربران نزدیک بوده و آن ها را خوبِ خوب می‌شناسد.دانش فنی دارد و می‌تواند مرجع خطا را تشخیص دهد.دید مهندسی و تحلیلی‌اش قابل قبول است.یادگیرندگی بالایی دارد.خوب می‌نویسد.برای یافتن جمع آدمهایی با چنین ویژگی‌هایی از تجربه آدمها (یا PX یا همان منابع انسانی سابق، بزودی نوشته‌اش را می‌خوانید) یک راست رفتیم پیش همکاران عزیز عملیات پشتیبانی!دوستانی که در این قسمتِ سخت فعالیت می‌کنند، مهمترین مهارتهای نرم (Soft skills) مدنظر را داشتند ولی قسمت دیگر را چه می‌کردیم؟به سراغ افرادی در عملیات رفتیم که تحصیلات و یا تجربه این رشته ها را داشتند: مهندسی نرم افزار یا سخت افزار، مهندسی صنایع، مهندسی مکانیک. به این ترتیب آدمهایی را پیدا کردیم که مهارتهای اولیه یک تستر خوب را داشتند اما نیاز بود که مهارتهای تست را به آنها بدهیم.در نهایت ۴ نفر برای ایجاد تیم انتخاب شدند و مسیر همکاری و آموزش شروع شد.چرا تست دستی؟ تست نویسی و تست خودکار چه می‌شود؟قبل از اینکه ادامه دهیم، سوالی مطرح می‌شود: چرا automated test را اجرا نکردید؟دلیلش این بود که کلا فرآیند تست جامع نداشتیم و برای تست خودکار هم زمان و نیرو و تجربه نداشتیم. قصد داشتیم از مسیر تست دستی به تست خودکار برسیم. البته که تست خودکار هیچگاه نمی‌تواند جای تست دستی و انسانی را بگیرد. تست خودکار را بهینه‌ساز و مکمل تست انسانی می‌بینیم نه جایگزین آن.تست‌نویسی نیز از سمت تیمهای فنی اجرا می‌شد و هر commit جدید بدون unit test رد می‌شد. قواعدی تعیین شد که بسته به حساسیت هر بخش و محصول، درصد test coverage آن مشخص و تست نویسی برای آن انجام شود. مثلا بخشهای مالی و پس از سفارش، پوشش تست بالاتری نسبت به جستجو داشتند.چیزهایی که آموزش داده شددر مرحله آموزش، اصول پایه‌ای تست را با تیم جدید مرور کردیم و کمتر وارد جزئیات تست شدیم. چون جا افتادن این اصول، مسیر ما را روشن‌تر و شفاف‌تر و نتایج را قابل اعتمادتر می‌کند.روانشناسی تست (Psychology of Testing)اصول و پایه‌ای‌ترین مهارتی که هر تستر برای شروع و ادامه مسیر نیاز دارد، همان ابتدای راه به همکاران ارائه شد. تست محصول، قبل از اینکه یک عملیات فنی باشد، یک مهارت انسانی و روانی است. کسب آمادگی ذهنی برای ورود به چنین مسیر سختی، نیازمند یادگیری مهارتهای ارتباط موثر و فهم چارچوب تست و توسعه نرم‌افزار است که بدون درک این مقدمات، افراد تیم و فرآیند تست، دچار چالشهای عمیق و فرسایش زیاد می‌شوند.مفصل بخوانید: روانشناسی تست نرم‌افزارفازهای انتشار (Release states)ضروری بود تا همکاران در مورد فازهای انتشار و خصوصیات محصول در هر مرحله آشنایی بیشتری داشته باشند. دلیل این، بودجه‌بندی تمرکز تیم تست و تنظیم حساسیت آنها نسبت به نسخه پیش‌رویشان است و در نهایت اولویت‌بندی بهتری در انجام تستها داشته باشند. پس تستر باید بداند که کدام نسخه را برای تست در اختیار دارد تا مسیر و بستر مناسب تست را انتخاب کند و گزارش خود را بهتر تنظیم کند.در میانه تشکیل تیم، گذری هم به توزیع شدگی و کمک گرفتن از اجتماع کاربران (community) زدیم. این پیشنهاد جالب یکی از همکاران عملیات پشتیبانی سابق و تیم تست فعلی بود و ریشه آن هم به نوع رابطه ایشان با اجتماع کاربران برمی‌گشت و البته تمرکز زیادی روی آن نداشتیم؛ اما تجربه خوبی برای تعامل با اجتماع به ما داد که چه خوب می‌شود آن را دوباره تکرار کنیم.در این تعامل، باید دقت شود که چه نسخه‌ای و کدام مرحله در اختیار تستر و کدامیک در دسترس جامعه است چون ممکن است بعضی ملاحظات کسب و کار مانع از انتشار بعضی امکانات جدید باشد و حتی پلنهای بعدی در تست توزیع شده، افشا شود.بقچه سناریوها (Senario pool)بخش زیادی از فرآیند تست صرف بررسی journeyهای مهم و البته تکراری می‌شود و در یک محصول بزرگ که ایجاد Granularity بالا بین سرویسها رعایت می‌شود، این تستها پررنگ‌تر هستند. برای فراموش نشدن این تستهای تکراری و البته مهم، در گوگل شیت یا جیرا، جایی را درست کردیم که تمام journeyهای تست در آن قرار داده شد و با توسعه محصول این تعداد بیشتر شد. بخشی از این سناریوها توسط تیم توسعه‌دهنده محصول تهیه می‌شد و برخی دیگر ابتکار تیم تست بود.پس از آن هر ماموریت تست، یک چک‌لیست داشت که بر اساس نیاز آن ماموریت و سناریوها، تستها انجام می‌شدند.هر آیتم در این لیست برچسبهای مشخصی داشت که در ماموریتهای مختلف، استفاده می‌شد. مثلا بعضی سناریوها فقط در گوشی موبایل تست می‌شوند. بعضی دیگر مختص زمان کمپین هستند و تعدادی در همه حال باید تست شوند و از نان شب هم واجبترند! پس تگ‌گذاری سناریوها به ما کمک کرد تا هر ماموریت تست بهینه‌تر باشد.گزارش‌دهی (Reporting)گزارش باگها جزو قسمتهایی است که اگر به درستی انجام نشود، فرآیند تست فقط زمان و هزینه توسعه محصول را بالا برده و تاثیر چندانی ندارد. اینجا همان جاییست که احتمال تنشها بالا می‌رود و ابهامات رخ می‌دهد و باید توجه بالایی به این قسمت از فرآیند داشت.شرح دقیق و شفاف بودن باگ بسیار مهم است و چون ممکن است باعث سوءتفاهم شود و حتی به اشتباه برداشتی دیگر بشود.گزارشها دو دسته هستند:گزارش تست: مجموعه تستهای مربوط به یک انتشار که معمولا یک فرآیند در محصول هستند.گزارش باگ: ایرادها و اشکالهایی که در زمانهای مختلفی در محصول کشف یا گزارش می‌شوند و نیاز به اصلاح دارند.اما مواردی که در هر گزارش باید ذکر شود اینهاست:بستر و آدرس دقیق جایی که خطا رخ داده: مثلا در اپلیکیشن اندروید "غرفه من"نسخه‌ای که با آن کار شده: 3.55.34 RCنوع دستگاه، سیستم عامل و مشخصات صفحه نمایش در صورت لزوم: گوشی nova 5t, Android 10, 6.26", 1080x2340نحوه بازتولید خطا (چطور می‌توان آن را دوباره دید): برنامه غرفه من > سفارشات > انتخاب سفارش > گزینه پرینت لیبل مرسوله > گزینه پرینت > دریافت pdfزمان انجام تست یا مشاهده باگ: چون ممکن است در آن زمان خاص، اشکال زیرساختی وجود داشته باشد.شرح کامل خطای رخ داده و پیامهای سیستم. فیلم ضبط شده از صفحه و تصویری از آن بسیار کمک کننده است. نحوه اتصال به اینترنت نیز بعضی جاها مهم است.اولویت: بر اساس حساسیت، تعداد گزارش، نسبت کاربران آن بستر به همه و …شیوه مطلع شدن از خطا و تعداد: بیان این که چطور متوجه شدیم و در تست بودیم.تیم مسئولیکی از باگهای گزارش شده در Jiraاين موارد توسط تیم تست مشخص می‌شوند و بعد از گزارش توپ در زمین تیم مسئول است و آنجا وضعیت برطرف کردن باگ مشخص می‌شود.بستر گزارش باگ هر جایی می‌تواند باشد، اما باید این خصوصیات را دارا باشد:در دسترس همه افراد تیم باشد.وضعیت در آن مشخص شود.قابلیت گزارش‌گیری داشته باشد.چیزی از آن پاک نشود.اينها اصلی‌ترین مواردی بود که به تیم آموزش داده شد و جزئیات بیشتر، در فرآیند تست بدست آمد.فرآیند تست: چطور تیم تست سر جای خود نشست؟تیم تست باید مستقل باشد؛ مهمترین پارامتری که باید می‌داشت. به یک دلیل: هر چه فاصله تیم تست از ذینفعان نتیجه‌ی تست بیشتر باشد، احتمال تاثیرگذاری منفی روی آن کمتر است.البته جای درست تیم تست در قسمت محصول است اما چون این تیم و فرآیند نوپا بود، لازم بود تا این فرهنگ قدم به قدم جا بیفتد. پس این فاصله در ابتدا ایجاد شد و تیم تست، به عملیات نزدیکتر بود تا محصول.در نهایت، مقید بودن همه تیمها به نتیجه تست، تعیین کننده کیفیت نهایی محصول بود. در چک‌لیست هر انتشار، تایید تیم تست هم گنجانده شد یعنی پس از تایید فنی، محصول، زیرساخت، امنیت، تست هم پارامتر اصلی شد و در فرآیند انتشار نشست.پس از استقرار تیم و فرآیندهای آن، نوبت به پایش (monitoring) آن رسید.این تیم موظف شد در انتهای هر اسپرینت یا در هر OKR خوانی، نتایج خود را ارائه دهد و وضعیت رسیدگی تیمها به باگها را گزارش کند. اینجا هم یکی از نقاط پر چالش فرآیند است. چون تیمها با کیفیت عملکردشان مواجه می‌شدند پس مدیران تیمها می‌بایست آمادگی پذیرش مسئولیت خود را داشته باشند و حواسشان به وضعیت افراد تیمشان نیز باشد تا به رستگاری برسند.چون ممکن است این حس منتقل شود که تیمها به خاطر عملکردشان سرزنش می‌شوند یا در معرض اتهام کم‌کاری قرار می‌گیرند و مدیران باید شرایط را در عین مسئولیت‌پذیری و صراحت و شفافیت، مدیریت کنند.جمع‌بندیانجام کارهای ریشه‌ای و زیرساختی، انرژی و حوصله زیادی می‌طلبد و فرآیندهایی که یک مجموعه یا سازمان به آن عادت کرده‌اند نیازمند تغییرات ذهنی و فرهنگی عمیقی در همه سطوح سازمان است که باید از بالا به پایین صورت بگیرد تا نتیجه‌بخش باشد.ایجاد یک تیم یا فرآیند تست در مجموعه‌ای که به آن عادت نکرده، نیازمند تغییرات بنیادینی است که تعهد همه افراد به این فرآیند موفقیت آن را تضمین می‌کند وگرنه کاریست بیهوده. برنامه و اهداف شفاف، اقناع، آموزش، تطبیق فرآیند و پایش گامهای اساسی تشکیل تیم یا فرآیندهای این چنینی‌ست.در انجام کار درست محکم باشید و بر آن اصرار کنید و از همه افراد مطالبه کنید؛ اما خودتان قبل از همه به آن پایبند باشید. رطب خورده منع رطب کی کند!روانشناسی تست را فراموش نکنید که با نادیده گرفتن آن، آسیبهای جدی به کسب و کارتان وارد می‌شود و جبران آن بسیار سخت خواهد بود.تشکرمتشکریم از دوستانی که در این مسیر سخت همراه بودند و با صبوری تست را پیش بردند: خانم فهیمه خاکی و خانم فاطمه بختیاری سید محسن سید محسن Sat, 24 Aug 2024 15:50:30 +0330 https://experience.basalam.com/روانشناسی-تست-نرم-افزار-چرا-فرآیند-تست-در-سازمان-ها-به-درستی-پیش-نمی-رود-ns94j5qjeeml تعامل کجای فرایند تست نرم‌افزار است؟مرحله تست خروجی محصول نرم‌افزاری، همیشه از مراحل پرچالش و حساس توسعه محصول بوده که علاوه بر زمانبر بودن، هزینه‌های مختلفی را بر شرکت‌ها و تیم‌ها تحمیل می‌کند. یکی از دلایل زمانبر بودن، انسانی بودن بخش مهمی از فرایند تست نرم‌افزار است که براحتی قابل تغییر نیست چون کاربر نهایی انسان است!همین انسانی و دستی بودن فرایند، با وجود مسائل مالی و خطاهای انسانی، باعث ایجاد چالش‌هایی می‌شود که باز ماهیت آن‌ها انسانی است. مشخصا ارتباطات و تعامل افراد مهم‌ترین پارامتر این عملیات است. هر کجا صحبت از تعاملات انسانی باشد، پیچیدگی‌های آن هم وجود دارد که در صورت مدیریت نادرست، شکست اجتناب ناپذیر است.این چالش‌ها باعث می‌شود که بعضی شرکت‌ها از مرحله تست فراری باشند و این فرار بعضا تا شکست کامل محصول پیش می‌رود! چرا با وجود هزینه‌های گزاف مادی و روانی، این سیکل معیوب ادامه می‌یابد؟ پاسخ در عین سادگی، بسیار پیچیده است.شرکت‌ها برای حل این مسائل، تلاش کرده اند که با راه حل‌های دیگری، کم‌تر آدم‌ها را درگیر چنین فرایند کنند مانند تست ماشینی (Automated Test) و یا جمع‌سپاری تست (Community Test) و یا برون‌سپاری تست (Outsourcing)، با این وجود نمی‌توان تست انسانی (Manual Test) را در فرایند توسعه بکلی نادیده گرفت و آن را جایگزین کرد (البته که هوش مصنوعی می‌تواند جایگزین خوبی برایش باشد!) چون در نهایت شرکت‌ها مغلوب تعاملات موثر انسانی شده‌اند.بدترین راه حلی که برخی شرکت‌ها سراغ آن رفته‌اند، حذف فرایند تست بعنوان یکی از مراحل توسعه محصول است! بله درست خواندید! تیم‌هایی وجود دارند که به بهانه‌های مختلفی بجز مسائل مالی، تست محصول را نادیده می‌گیرند و این بدترین بلایی است که می‌تواند بر سر محصول و کاربر نهایی آن بیاید. (تجربه باسلام را اینجا بخوانید)تلاش علوم روانشناختی در راستای نزدیک شدن و هم‌ذهن شدن هرچه بیشتر آدم‌ها و نهایتا هم مسیر شدن افراد است که در نهایت منجر به افزایش سرعت رشد و کاهش استهلاک رشد روابط بین افراد است.اگر یک تیم محصول قوی دارید، اما خروجی پر از باگ است، ادامه این نوشته را از دست ندهید.اگر در مجموعه‌تان همه روال‌ها درست هستند و آدم‌های قوی را دور هم جمع کرده‌اید، اما در تست محصول و بازگشت و اصلاح پیش از انتشار گیر می‌کنید و کلی زمان از دست می‌دهید و آن پروژه برای شما ضرر است و ضرر!سختگیری در مورد کیفیت زیاد است، ولی محصول نهایی‌تان پر از باگ است و بی‌کیفیت! مدیر محصول و مدیر عامل همیشه از خروجی ناراضی است.تیم‌های تولید محصول از تست فراری هستند و می‌خواهند فقط سریع محصول را منتشر کنند! بین تیم تست و باقی تیم‌ها تنش‌های زیادی وجود دارد و تیم تست خیلی تحت فشار است. گزارش‌های موثری تولید نمی‌شود و یا به گزارش‌ها توجه لازم نمی‌شود.اهمیت این نوشتار برای تیم‌هاییست که فرایند تست را هنوز اجرا نکرده‌اند و یا در تعاملات بین‌تیمی سختی‌هایی را تجربه می‌کنند.این نوشتار به شما کمک می‌کند تا بر چالشهای چنین تعاملی آگاه شوید و حتی راه حل آن را بیابید.نویسنده تخصص روانشناسی ندارد و صرفا تجربیات و دانش خود در این زمینه را به رشته تحریر درآورده است.بهتر است چه کسانی تست را انجام دهند؟احتمالا این تجربه را داشته اید که افراد درون تیم‌های توسعه‌دهنده (شامل مدیران محصول، تحلیلگران، طراحان، برنامه نویسان و …) خودشان کل فرایند تست را بر عهده می‌گیرند و اعلام می‌کنند که نیازی به تیم تست ندارند. خیلی هم خوب! ولی این کار وظیفه همان تیم است و در واقع کار ویژه و متفاوتی انجام نداده‌اند؛ چون تست خروجی جزو فرایند توسعه محصول است و اگر قرار باشد که تیم تست کار خود را شروع کند، قبل از آن تیم توسعه‌دهنده می‌بایست خروجی خود را تست کرده باشد و از نتایج آن مطمئن باشد. به بیان دیگر، تیم توسعه‌دهنده محصول، نباید محصولی معیوب و مشکل‌دار را به کاربر نهایی و یا تیم تست تحویل دهد بلکه ابتدا خودشان از کیفیت محصول‌شان مطمئن هستند و برای اطمینان از این کیفیت، به سراغ تیم تست می‌روند. تحویل نسخه‌های پر اشکال متعدد به کاربران و یا تیم تست، اعتماد به آن تیم را خدشه‌دار می‌کند و ممکن است آن تیم دستخوش تغییرات زیادی شود.اما…چرا تست محصول توسط خود تیم توسعه‌دهنده، ایده کاملی نیست؟چون توسعه‌دهندگان نسبت به محصول یا خروجی خود، حس مالکیت دارند و برای تست آن، به نقاط مثبت توجه دارند. معمولا کل محصول را بصورت یکپارچه تست نمیکنند و فقط قسمتی را که اخیرا توسعه‌داده‌اند بررسی می‌کنند. نسبت به برخی اشکال‌ها، حساسیت ندارند و بعضا آن‌ها را کم اهمیت می‌بینند. کمتر از دید کاربر به خروجی خود می‌نگرند و نگاه والدانه آن‌ها غالب است. همچنین تیم تست با توجه به تجربیاتی که در تعامل با تیم‌ها و محصولات یا زیر محصولات مختلف بدست آورده، نگاه جامع‌تر و موشکافانه‌تری به نحوه اجرای تست دارد که تیم توسعه‌دهنده معمولا این نگاه را ندارد.از دیگر سو، میزان وابستگی و گره‌خوردگی تیم تست به توسعه‌دهندگان می‌تواند باعث انحراف نتایج تست شود.بر این اساس سطوح مختلفی از استقلال در تست بوجود می‌آید:تست توسط فرد توسعه‌دهنده: مانند کسی که طراحی کرده، کد زده و یا تحلیلی انجام دادهتست توسط یک هم تیمی: مثلا برنامه نویسی از همان تیمتست بوسیله تیمی دیگر در همان سازمان: مثل تست درگاه پرداخت توسط تیم لجستیک و یا توسط تیم تستبرون‌سپاری تست به یک تیم خارج از مجموعهچنانچه محصول را افرادی تست کنند که در این زمینه متخصص باشند و تجربه کافی داشته باشند، می‌توان انتظار بهترین نتایج را از تست داشت. از طرفی هر چه فاصله سازمانی تیم توسعه‌دهنده با تسترها بیشتر باشد، تاثیر تیم توسعه‌دهنده بر تسترها کمتر می‌شود که نهایتا نتایج دقیق‌تر و کاراتر خواهد بود و شاهد کیفیت به مراتب بالاتری هستیم. به همین دلیل است که شرکت‌ها پس از تست درون تیمی (به عنوان جزئی از فرایند توسعه) و سپس تیم تست درون سازمانی، مراحل آلفا و بتا را اجرا می‌کنند تا با هزینه مالی و زمانی کمتر و نیز حداقل تاثیرپذیری، بهترین و بیشترین بازخوردها را بگیرند.ذهنیت توسعه‌دهنده و تستردر فرایند توسعه محصول، توسعه‌دهندگان شامل برنامه نویسان، طراحان، تحلیلگران، مدیران محصول و … است که در یک طرف قرار می‌گیرند و تست کنندگان که در طرف دیگر قرار دارند.از زاویه دیگر بنگریم: گروه توسعه‌دهندگان خصوصیاتی را نمایش می‌دهد که در آن مشکل کاربر نهایی را حل کرده و دردی از جامعه هدف خود را با کیفیت بالا درمان کرده است در عوض گروه تست وظیفه دارد که این گزاره را به چالش بکشد و به هواخواهی از مشتری بر کیفیت محصول نظارت کند تا در نهایت قابل قبول‌ترین محصول از سمت کل تیم بدست مشتریان برسد. به عبارت دیگر اگر صاحب یا مدیر محصول نماینده کاربران باشد، تستر وکیل مدافع مشتریان است.بر اساس سوگیری تاییدی (Confirmation Bias) توسعه‌دهندگان دوست دارند که بیشترین تمجید از دسترنج‌شان را دریافت کنند اما تیم تست دقیقا برعکس این برخورد را بر اساس وظیفه‌شان انجام می‌دهند؛ اینجاست که یک مولفه مهم درگیر می‌شود: ارتباط موثر و سازنده.توسعه‌دهندگان به سختی می‌پذیرند که کدشان، طراحیشان و یا تحلیلشان خطا دارد و نمی‌توانند پیوسته اخبار منفی را درباره محصولشان بشنوند؛ لذا اغلب عملکرد تیم تست را مخرب قلمداد می‌کنند حتی اگر نتیجه نهایی کیفیت بالای محصول و رضایت مشتری باشد. پیدا کردن خطا برای تستر یک عملکرد مثبت محسوب می‌شود و برای توسعه‌دهنده یک امتیاز منفی.تعارضات در هر مرحله‌ای رخ می‌دهد؛ چه در مرحله‌ای که کدی اجرا نمیشود و تیم روی پروتوتایپ‌ها یا کاربردپذیری (Usability) کار می‌کند (Static Test)، چه در مرحله‌ای که محصول در فضای واقعی‌تری با اجرای کدها تست می‌شود (Dynamic Test).پیشنهاد می‌کنم همانطور که تیم تست به تیم‌های توسعه‌دهنده برای بهبود محصول گزارش می‌دهد، نسبت به عملکرد و شیوه گزارش‌دهی و تعامل خود بازخورد بگیرد و جریان گفتگو فقط یکطرفه نباشد. با این رویکرد، تحمل تیم‌ها در گرفتن گزارش‌های منفی بالا می‌رود و از طرف دیگر، شیوه عمل تیم تست روز به روز بهتر می‌شود.ارتباط موثر و سازنده: خروج تیم تست از لاک دفاعیبا مواردی که ذکر آن رفت، بار روانی بیشتری بر روی تیم تست وجود دارد. علاوه بر مدیران همه تیم‌ها، تیم تست و تسترها وظیفه سنگین‌تری در ایجاد و حفظ ارتباط سازنده و موثر بین تیم تست و سایر تیم‌ها دارند و داشتن مهارت‌های بالای ارتباطی، از پارامترهای ضروری افراد حاضر در تیم تست است.چه نوع افرادی برای تست نرم‌افزار مناسب هستند؟ (جای دیگری به این می‌پردازیم)مخابره ایرادها، خطاها و باگ‌های محصول به شکل محترمانه و مودبانه، کمک شایانی در ایجاد رابطه مثبت تیمی می‌کند و هم‌افزایی تیم‌ها را برای رسیدن به خروجی با کیفیت چند برابر می‌کند. البته که گزارش، نباید حس ناامیدی و شکست را به توسعه‌ دهندگان القا کند.تستر و گزارش دهنده خطا به این نکته توجه دارد که تمرکز او بر خود خطا و نحوه رخ دادن آن است، نه بر کسی که آن قسمت از محصول را طراحی یا تولید کرده است. تیم تست صرفا خطا را گزارش می‌دهد، حالت صحیح را یادآوری می‌کند (بر اساس مستندات محصول و یا خروجی‌های مورد انتظار تیم طراحی تست – Test designers -) و پیشنهاد خود را هم می‌تواند ارائه دهد، اما تیم یا فرد مسئول را بازخواست نمی‌کند و یا به او برچسب نمی‌زند یا در صورت تکرار، تمسخر نمی‌کند و همدیگر را رنگاوارنگ نمیکنند.صراحت در این فرایند بسیار مهم و ضروری است اما بدون توهین! افراد باید فرق بین صراحت و بی ادبی را متوجه باشند. نتیجه صراحت این است که تیم توسعه‌دهنده، به وضوح و شفافیت نقطه خطا را درک کند.در شرایطی که تیم توسعه‌دهنده تحت فشار رسیدن به ضرب‌الاجل‌های تحویل است و تیم تست باگ‌های متعددی را کشف کرده است (شرایط گل بود و به سبزه نیز آراسته شد!)، تیم تست در اولویت بندی اصلاح باگ‌ها بسیار کمک کننده است. برخی باگ‌ها تاثیر روانی منفی بیشتری بر مشتری و کاربر نهایی می‌گذارند و برطرف کردن نکردن آن‌ها، بازخوردهای بدتری را ایجاد می‌کند. تیم تست با توجه تجربیات خودش، منبع خوبی برای تعیین این اولویت است. البته تسترها در این شرایط خودآگاه باشند و حواسشان به سوگیری شخصی خودشان باشد.اما… عشق یکطرفه فرجام خوشی ندارد! (مانند مرحوم شهریار) توسعه‌دهندگان نیز یک طرف این رابطه هستند. آن‌ها نیز باید بار مسئولیت خود را به دوش بکشند و وظیفه‌ای را که به تیم تست محول شده، به درستی و با تمام جوانب آن بپذیرند. توسعه‌دهندگان بپذیرند که گزارش‌های تیم تست در راستای اهداف کلی محصول و بهتر شدن کیفیت آن است، گزارش‌های آن‌ها از جنس زیرآب زنی و یا تحقیر عملکرد و دانش تیم‌ها و افراد نیست، افراد آن دنبال دشمن تراشی نیستند و قصد تشویش اذهان عمومی و خصوصی را ندارند و نمی‌خواهند آب به آسیاب رقیب بریزند. تیم تست همانند آینه‌ایست که می‌خواهد ایرادهای محصولمان را قبل از اینکه دیگران به ما بگویند، به ما بگوید تا محصول را اصلاح کنیم. و در نهایت همه متعهد باشند به هم‌افزایی و مشارکت تلاش‌ها برای رسیدن به هدف مشترک (collaboration).جمع بندیفرایند تست، فرایندی است بشدت انسانی، روانی و فرهنگی! به عبارت بهتر تعاملی، ذهنی و وابسته فرهنگ سازمانی.مهارت ارتباطی توسعه‌دهندگان و تست کنندگان، مهمترین مولفه در به ثمر رسیدن این فرایند است که وظیفه مجموعه دوم سنگین‌تر از اولیست. همگی بدانند که تیم‌ها هم هدف و هم مسیر هستند و قرار بر رقابت و تخریب نیست؛ بلکه رضایت مشتری و کاربر نهایی ستاره قطبی همه اعضای تیم و سازمان است.توجه به ریزه‌کاری‌های ارتباطی و روانی در فرایند تست، علاوه بر بالا بردن کارایی همه آدمای درگیر، هزینه‌های ناشی از عدم ارائه محصول خوب و با کیفیت را به حداقل می‌رساند و موفقیت کسب و کار را تقویت می‌کند.البته حواستان باشد فرآیند را طوری طراحی و اجرا کنید که رشد را کند نکند و مانع نوآوری تیم نشود.در نوشته ای دیگر، تجربیات تشکیل یک تیم تست را می‌نویسم.منابع مورد استفادهhttps://medium.com/@madhavikau/psychology-of-testing-in-software-testing-a59bdeb90ae0https://toolsqa.com/software-testing/istqb/psychology-of-testing/منابع اصلی تصاویرhttps://miro.medium.com/v2/resize:fit:1100/format:webp/1*1tujnZjANnhcMC6dehIm6Q@2x.jpeghttps://www.testbirds.com/wp-content/uploads/21-illustration-why-testbirds.svghttps://www.scnsoft.com/software-development-services/custom-software-development/custom-lms/custom-lms-cover-pic.svghttps://www.testim.io/wp-content/uploads/2020/05/Testim-HItsubscribe-Who-Performs-Software-Testing-in-2020_572_450.jpghttps://www.testrail.com/wp-content/uploads/2023/02/TR-Three-Things-to-Learn-from-the-Bugs-You-Found.pngلینک اصلی نوشتهhttps://experience.basalam.com/sofware-testing-psychology-why-test-process-is-so-tough/ سید محسن سید محسن Fri, 19 Jan 2024 01:39:50 +0330