درس‌های مهم از تست‌های شکست‌خورده نرم‌افزار

افراد عاشق پیدا کردن پاسخ سوال‌هایی هستند که هنوز نمی‌دانند یا دوست دارند کسی آن‌ها را برایشان پیدا کند.
اما گاهی یادگیری واقعی از پیدا کردن پاسخ‌ها نمی‌آید؛ بلکه از شکست، از دیدن چیزی که باید کار می‌کرد… و نکرد، حاصل می‌شود.

وقتی شروع به جمع‌آوری داستان‌ها و درس‌ها از بیش از ده سال کار در زمینه تست و معماری کردم، متوجه یک عدم تعادل عجیب در ادبیات نرم‌افزار شدیم.

کتاب‌ها، مقالات و ویدئوهای بسیار زیادی درباره اینکه چطور تست را درست انجام دهیم وجود دارد؛ درباره فریم‌ورک‌ها، استراتژی‌ها، اتوماسیون، CI/CD، پوشش و مهارت حرفه‌ای. اما بسیار کم هستند کسانی که درباره اینکه چرا تست‌ها شکست می‌خورند و چه چیزی باعث آن می‌شود صحبت می‌کنند.

با این حال، نه فقط در طراحی نرم‌افزار یا تست اتوماتیک، بلکه همیشه شکست جایی است که درک واقعی شروع می‌شود. تجربه من نشان داده که کیفیت نرم‌افزار صرفاً با افزایش تعداد تست‌های اتوماتیک بالا نمی‌رود؛ بلکه وقتی واقعاً یاد می‌گیریم که شروع به پرسیدن می‌کنیم: «چرا این تست، چه دستی و چه اتوماتیک، مفید نبود؟ چرا مثال‌ها نتوانستند ابهامات یک فیچر یا باگی که رفع شده بود را روشن کنند؟»

تست‌ها می‌توانند ابزاری برای کشف و فهم واقعی سیستم باشند، نه صرفاً ابزاری برای تایید اینکه کد درست کار می‌کند. برای مثال، یک تست اتوماتیک ممکن است همیشه سبز باشد، اما وقتی فیچر جدیدی اضافه می‌کنیم، همان تست دیگر مشکلات را نشان نمی‌دهد. یا یک تست دستی که انتظار داشتیم باگ را پیدا کند، عملاً هیچ کمکی نکرده است. این‌جاست که تحلیل شکست‌ها و پرسیدن چرا باعث می‌شود واقعاً بفهمیم سیستم چگونه کار می‌کند و کجا نیاز به اصلاح دارد.

شکست جایی است که درک واقعی ما آغاز می‌شود.

قبل اینکه جلوتر بریم، باید بگم این پست، قبلا اینجا منتشر شده بود.

https://masoudbahrami.com/article/why-we-learn-more-from-broken-tests-than-from-perfect-ones/

شکست آنچه موفقیت پنهان می‌کند را آموزش می‌دهد

وقتی تیم‌ها درباره شکست تست‌های اتوماتیک صحبت می‌کنند، بحث معمولاً از سطح کد شروع می‌شود:

• توسعه‌دهنده تست‌های تمیز ننوشته است.

• فریم‌ورک به درستی انتخاب نشده است.

• تیم QA مهارت کافی نداشته است.

نمیخوام بگم که این کار اشتباه هست، نه نیست، ولی این یک ریزنینگ ناقص است.

مثل این است که عملکرد یک خودرو را فقط با نگاه کردن به تایرها بررسی کنیم، چون تایرها حرکت ایجاد می‌کنند؛ یا فقط موتور را بررسی کنیم و فرض کنیم قدرت از همانجا می‌آید.
یک خودرو سیستم پیچیده‌ای از روابط است و کوچک‌ترین نقص در هر قسمت می‌تواند کل عملکرد را مختل کند.

شکست‌های تست نیز به همین شکل سیستمی هستند. یک تست خراب فقط مشکل کدنویسی نیست؛ بلکه بازتابی از نحوه تفکر، طراحی و ارتباط تیم است.
به همین دلایلی که مختصر در بالا شرح دادم، من کتاب How to Fail Your Test Automation (Easily!) را نوشتم، مجموعه‌ای از بیش از ۶۰ درس که از پروژه‌های شکست خورده تست اتوماتیک نرم‌افزار که طی این‌ سال‌ها به عنوان برنامه‌نویس و مشاور نرم‌افزار آموخته‌ام.

هفت لایه شکست (و یادگیری)

وقتی داشتم این اشتباهات رو لیست می‌کردم به یک نکته‌ی جالبی برخوردم. توی جمع‌آوری این درس‌ها، متوجه شدم که می‌تونم آنها را به هفت دسته متمایز اما مرتبط تقسیم می‌شوند:

1. استراتژی و ذهنیت – بسیاری از شکست‌ها قبل از نوشتن کد آغاز می‌شوند؛ وقتی تیم‌ها بدون هدف مشخص تست می‌کنند، فقط حرکت را اندازه می‌گیرند، نه پیشرفت واقعی را.

2. طراحی و نیت تست – تست‌ها اغلب شکست می‌خورند چون رفتارها را بدون درک مدل دامنه می‌سنجند.

3. اشتباهات فنی و اجرایی – از selectors شکننده تا محیط‌های ناپایدار، سطح قابل مشاهده شکست است.

4. ابزار و زیرساخت – ابزارها مشکل نامشخص را حل نمی‌کنند، بلکه می‌توانند وضوح یا سردرگمی را تقویت کنند.

5. تیم و همکاری – تست یک عمل اجتماعی است؛ تست شکست خورده غالباً بازتاب یک گفتگوی شکست خورده است.

6. هزینه و ارزش – هر تست هزینه دارد، اما همه ارزش برابر ندارند؛ دانستن اینکه چه زمانی تست نکنیم به اندازه دانستن چه چیزی را تست کنیم مهم است.

7. یادگیری و بازتاب – تیم‌ها چگونه از تجربه تست خود می‌آموزند؛ بازخورد، شناسایی الگو و آگاهی معرفتی، شکست را به سوخت رشد تبدیل می‌کنند.

این هفت دسته مستقل اما به هم پیوسته هستند؛ شبیه زیرسیستم‌های یک ماشین پیچیده.

سیستمی که قابل تست نیست، قابل درک نیست

به حرف من اعتماد کنید. شاید بدون دلیل و صحبت کردن، خیلی آسون نباشه که این رو بگم، ولی وقتی می‌شنوم که تیمی یا شخصی عنوان می‌کند که: سیستم ما قابل تست نیست تست‌ها ناپایدارند، این جملات در واقعیت روی زمین یک حقیقت عمیق‌تر را نشون میدن: سیستمی که قابل تست نیست، سیستمی است که طراحی و مدل‌سازی آن واضح نیست.

سیستمی که قابل تست نیست، سیستمی است که طراحی و مدل‌سازی آن واضح نیست.

تست در ذات خود درباره صحت نیست؛ درباره درک واقعی سیستم است. شکست‌های تست ارزشمندند چون شکاف بین آنچه فکر می‌کنیم می‌دانیم و آنچه در کد واقعی وجود دارد را آشکار می‌کنند.

تست در ذات خود درباره صحت نیست؛ درباره درک واقعی سیستم است.

اگر علاقمند بودید بیشتر در این مورد بدونید می‌تونید این پست‌های من رو هم دنبال کنید:

https://masoudbahrami.com/article/epistemic-testing-chapter-01-what-makes-a-test-a-test/

و روی مدیوم هم می‌تونید بخونید و من رو دنبال کنید:
https://medium.com/@masoudbahrami/what-makes-a-test-a-test-27c7e64531c1

کتاب

کتاب کوتاه، صادقانه و کاربردی است. هر بخش شامل درس‌ها، بازتاب‌ها و هورستیک‌های عملی است، نه قواعد خشک. این کتاب درباره درک سیستم است، نه فقط فریم‌ورک‌ها یا متریک‌ها. اگه تا به حال با تست اتوماتیک دست و پنجه نرم کرده باشید، اگر کنجکاو هستید چرا گاها(خیلی وقت‌ها) پوشش تست بالا اما اعتماد پایین است، یا صرفاً می‌خواهید درباره تاثیر تست‌ها بر درک سیستم فکر کنید، این کتاب برای شماست.

دانلود رایگان در Leanpub:

https://leanpub.com/testautomationmistakes/