معرفی
بعد از ظهر بخیر ساکنان خابروفسک. همین الان داشتم یک تکلیف آزمایشی برای جای خالی QA Lead برای یک شرکت فین تک حل می کردم. اولین کار، ایجاد یک برنامه آزمایشی با یک چک لیست کامل و نمونه هایی از موارد آزمایشی برای آزمایش کتری برقی، می تواند به صورت پیش پا افتاده حل شود:
فکر کردن به یک برنامه آزمایشی بهتر با یک چک لیست کامل دشوار است.
اما بخش دوم یک سوال بود: "آیا مشکلات مشترکی برای همه تسترها وجود دارد که مانع از کارایی بیشتر آنها شود؟"
اولین چیزی که به ذهنم رسید این بود که تمام مشکلات کم و بیش قابل توجهی را که در طول آزمایش با آنها مواجه شدم فهرست کنم، چیزهای کوچک را حذف کنم و بقیه را خلاصه کنم. اما به سرعت متوجه شدم که روش استقرایی به سؤالی پاسخ می‌دهد که برای «همه» صدق نمی‌کند، بلکه در بهترین حالت فقط برای «اکثریت» آزمایش‌کنندگان کاربرد دارد. بنابراین تصمیم گرفتم که از طرف دیگر به صورت قیاسی به آن نزدیک شوم و این اتفاق افتاد.
تعاریف
اولین کاری که معمولاً هنگام حل یک مشکل جدید انجام می‌دهم این است که سعی کنم بفهمم موضوع چیست، و برای انجام این کار باید معنای کلماتی که آن را مطرح می‌کنند، درک کنم. کلمات کلیدی برای درک موارد زیر است:
- یک مشکل
- آزمایشکننده
- کار تستر
- کارایی تستر
بیایید به ویکی پدیا و عقل سلیم بپردازیم:
(مشکل یونان باستان) به معنای گسترده - یک موضوع پیچیده نظری یا عملی که نیاز به مطالعه و حل دارد. در علم - وضعیت متناقضی که به صورت مواضع متضاد در تبیین هر پدیده، اشیاء، فرآیند ظاهر می شود و برای حل آن نیاز به نظریه کافی دارد. در زندگی، مشکل به شکلی فرموله می شود که برای مردم قابل درک باشد: "من می دانم چه چیزی، نمی دانم چگونه"، یعنی معلوم است چه چیزی باید به دست آید، اما نحوه انجام آن معلوم نیست. . از دیروقت میاد لات مشکل از یونانی مشکل "پرتاب به جلو، قرار دادن در جلو"؛ from προβάλλω “through forward, put in front of you; سرزنش».
در واقع "مشکل" = "هر چیزی که باید با آن برخورد شود" چندان منطقی نیست.
- یک متخصص (ما به انواع تقسیم نمی کنیم، زیرا ما به همه آزمایش کنندگان علاقه مند هستیم) که در آزمایش یک جزء یا سیستم شرکت می کند که نتیجه آن این است:
- مجموعه ای از فعالیت های مربوط به آزمایش.
(lat. effectivus) - رابطه بین نتیجه به دست آمده و منابع استفاده شده (: 2015)
- نتیجه یک زنجیره (مجموعه) اقدامات (نتیجه) یا رویدادها که به صورت کیفی یا کمی بیان می شود. نتایج احتمالی شامل مزیت، ضرر، سود، ضرر، ارزش و پیروزی است.
مانند «مشکل»، معنای کمی وجود دارد: چیزی که در نتیجه کار ظاهر شده است.
- امکان اندازه گیری کمی برای انجام هر فعالیت یک شخص یا افراد؛ شرایطی که امکان استفاده از تبدیل های خاص را برای به دست آوردن نتیجه مطلوب فراهم می کند. آزمایش کننده یک شخص است و طبق نظریه منابع حیاتی، هر فرد دارای چهار دارایی اقتصادی است:
پول نقد (درآمد) یک منبع تجدید پذیر است.
انرژی (نیروی حیات) یک منبع تا حدی تجدید پذیر است.
زمان یک منبع ثابت و اساسا غیر قابل تجدید است.
دانش (اطلاعات) یک منبع تجدیدپذیر است، بخشی از سرمایه انسانی است که می تواند رشد کند و از بین برود..
من می خواهم توجه داشته باشم که تعریف کارایی در مورد ما کاملاً صحیح نیست، زیرا هر چه دانش بیشتری استفاده کنیم، کارایی کمتری دارد. بنابراین، من کارایی را به عنوان «نسبت بین نتایج به‌دست‌آمده و منابع مصرف‌شده» دوباره تعریف می‌کنم. سپس همه چیز درست است: دانش در طول کار هدر نمی رود، اما هزینه های تنها منبع اساسا غیر قابل تجدید آزمایشگر - زمان او را کاهش می دهد.
تصمیم
بنابراین، ما به دنبال مشکلات جهانی آزمایش کنندگان هستیم که کارایی کار آنها را مختل می کند.
مهم‌ترین منبعی که صرف کار یک آزمایشکننده می‌شود، زمان اوست (بقیه را می‌توان به هر طریقی به آن تقلیل داد)، و برای اینکه بتوانیم در مورد محاسبه صحیح بازده صحبت کنیم، باید نتیجه را نیز به زمان تقلیل داد. .
برای انجام این کار، سیستمی را در نظر بگیرید که آزمایشگر از طریق کار خود از دوام آن اطمینان حاصل می کند. چنین سیستمی پروژه ای است که تیم آن شامل یک آزمایش کننده است. چرخه عمر پروژه را می توان تقریباً با الگوریتم زیر نشان داد:
- کار با نیازمندی ها
- تشکیل مشخصات فنی
- توسعه
- آزمایش
- عرضه به تولید
- پشتیبانی (بروید مورد 1)
در این مورد، کل پروژه را می توان به صورت بازگشتی به پروژه های فرعی (ویژگی ها) با چرخه عمر یکسان تقسیم کرد.
از نظر پروژه، هر چه زمان کمتری برای آن صرف شود، اجرای آن موثرتر است.
بنابراین، ما به تعریف حداکثر بازده ممکن یک تستر از نقطه نظر پروژه می رسیم - این وضعیت پروژه زمانی است که زمان آزمایش صفر است. یک مشکل رایج برای همه آزمایش کننده ها عدم توانایی در رسیدن به این زمان است.
باید باهاش چکار کنم؟
نتیجه گیری کاملا واضح است و برای مدت طولانی توسط بسیاری استفاده می شود:
- توسعه و آزمایش باید تقریباً به طور همزمان شروع و پایان یابد (این معمولاً توسط بخش انجام می شود ). گزینه ایده‌آل زمانی است که تمام قابلیت‌هایی که در حال توسعه هستند، تا زمان آماده شدن، توسط تست‌های خودکار پوشش داده شده باشند، و با استفاده از نوعی آزمایش به صورت رگرسیون (و در صورت امکان، قبل از انجام آزمایش) سازماندهی شوند. .
- هرچه یک پروژه دارای ویژگی های بیشتری باشد (هرچه پیچیده تر باشد)، زمان بیشتری باید صرف بررسی اینکه عملکرد جدید عملکرد قبلی را خراب نمی کند. بنابراین، هرچه پروژه پیچیده تر باشد، نیاز به اتوماسیون بیشتری دارد .
- هر بار که اشکالی را در تولید از دست می‌دهیم و کاربر آن را پیدا می‌کند، باید زمان بیشتری را برای گذراندن چرخه عمر پروژه از نقطه 1 (کار با الزامات، در این مورد، کاربران) صرف کنیم. از آنجایی که دلایل از دست دادن یک باگ به طور کلی ناشناخته است، تنها یک مسیر بهینه‌سازی برای ما باقی می‌ماند - هر اشکالی که توسط کاربران پیدا می‌شود باید در تست رگرسیون گنجانده شود تا مطمئن شویم که دوباره ظاهر نمی‌شود.
منبع: www.habr.com