من در حال ساخت آینده آزمایش خودکار هستم

ویرایش: با تشکر از همه پشتیبانی اولیه ، من محصول خود را ساخته و راه اندازی کردم! می توانید آن را در TestingBee.io پیدا کنید!

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

به عنوان مثال ، یک تست خودکار که فرم “ویرایش پروفایل” را تأیید می کند ممکن است به این شکل باشد:

import { test, expect } from '@playwright/test';

test('allows user to edit profile and save changes', async ({ page }) => {
  await page.goto('https://yourapp.com/profile/edit');

  await page.fill('input[name="name"]', 'John Doe');
  await page.fill('input[name="email"]', 'john.doe@example.com');

  await page.click('button:has-text("Save Changes")');

  const successMessage = await page.locator('text=Profile updated successfully');
  await expect(successMessage).toBeVisible();
}

برنامه ها می توانند صدها یا حتی هزاران نفر از این تست ها را داشته باشند و همه آنها قبل از استقرار هر به روزرسانی جدید اجرا می شوند. عالی!

اما صبر کنید … آیا با آزمون فوق چیزی را مشاهده می کنید؟ اگر برنامه خود را به روز کنیم و دکمه “Save Changes” را تغییر نام دهیم ، چه می شود؟ یا ورودی 3 را به فرم ویرایش پروفایل اضافه کنید؟ یا صفحه ویرایش پروفایل را به جای دیگر منتقل کنید؟

این مشکل اصلی آزمایش خودکار است. آنها عملکرد شما را آزمایش می کنند ، اما از نظر تغییرات بسیار شکننده هستند. این امر داشتن پوشش کامل تست را دشوار می کند و در عین حال ویژگی های جدید را نیز به همان سرعت که یک استارتاپ نیاز دارد ، فشار می آورد.

مشکل دیگر آزمایش خودکار این است که آنها برای نوشتن وقت گیر هستند. این یک مثال ساده است ، اما معمولاً آزمایشات شما بسیار پیچیده تر است. و دوباره ، 100 بار این کار را ضرب کنید.

در اصل ، کد تست خودکار از نمودار کارآیی مانند چنین است:

همانطور که مشاهده می کنید ، اضافه کردن تست های بیشتر باعث افزایش اعتماد به نفس شما در مورد کار برنامه شما می شود ، اما همچنین مانع سرعت توسعه شما در همان زمان می شود.

مشکل

برای اکثر شرکت ها – این واقعیت که آنها باید تست های خودکار را بنویسند و حفظ کنند ، مشکلی نیست. ارزش آزمایش در خارج از هزینه به سمت بهره وری. به این دلیل است که به طور معمول یک ویژگی جدید هرگز به اندازه ویژگی های موجود شما ارزشمند نیست.

اما ، برای استارتاپ ها به طور معمول درست نیست.

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

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

اگر هدف از آزمایش اطمینان از ادامه محصول شما برای حل مشکل است ، آیا اولویت اول تأیید این است که محصول شما در وهله اول مشکل را حل می کند؟

آیا نباید اطمینان حاصل کنید که این یک تجارت مناسب قبل از تمرکز بر قابلیت اطمینان فنی آن با آزمایش است؟

اکثر بنیانگذاران استارتاپ با من موافق هستند ، بنابراین ، شما این عبارت مشترک را در مورد دنیای استارتاپ می شنوید:

“سریع حرکت کنید و چیزها را بشکنید” – مارک زاکربرگ
اما ، من معتقدم که می توانیم حتی بهتر از این مانترا عمل کنیم.

سریع حرکت کنید و چیزها را بشکنید

و این ما را به راه حلی می رساند که برای یک ماه گذشته ساخته ام. من ابزاری را ساختم که اگر محصول شما کاملاً کاربردی باشد ، به طور خودکار آزمایش می کند و این کار را بدون سرپرستی تست های خودکار سنتی انجام می دهد.

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

شما این کار را از طریق کد انجام نمی دهید ، بلکه از طریق توضیحات ساده در مورد تجربیات کاربر نهایی. بنابراین مجموعه تست شما چیزی شبیه به این خواهد بود:

از طریق این اهداف گسترده – هوش مصنوعی از طریق سایت شما قدم می زند و تست های خاصی را که به طور خودکار مورد نیاز خود قرار می دهید تولید می کند. اساساً نوشتن کل مجموعه تست خودکار خود را برای شما.

سپس ، در هر تغییر کد ، ما آن تست ها را در برابر محصول شما اجرا خواهیم کرد تا اطمینان حاصل شود که کد شما هنوز دقیقاً مانند گذشته کار می کند.

اما ، اگر یک آزمایش از بین برود ، چه می شود؟

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

به عنوان مثال ، اگر هدف “کاربر باید بتواند نمایه خود را ویرایش کند” ، با استفاده از تغییر کد که دکمه “ذخیره تغییرات” را برای “ذخیره” تغییر نام می دهد ، باعث می شود یک آزمایش خاص شکست بخورد. با این حال ، از دیدگاه کاربر ، این محصول هنوز هم کاملاً کار می کند.

و واقعاً ، این آزمایش نباید شکست بخورد. شما می خواهید تست های خود اطمینان حاصل کنند که محصول شما عملکردی دارد. اما ، در آزمایشات دنیای واقعی تقریباً همیشه از تغییر محصول که تجربه کاربر را نمی شکند ، شکست می خورد.

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

بنابراین ، برای مثال بالا ، ما دستورالعمل های خاص را برای بررسی دکمه “ذخیره” به جای دکمه “ذخیره تغییر” ، دوباره آزمایش ، دوباره به روز خواهیم کرد ، سپس آن را ذخیره کنید تا به روز شود تا به جلو حرکت کند.

برای به روزرسانی کد تست خود ، کد فشار بیشتری تغییر نمی کند.

مزیت دیگر این امر این است که ما هشدارهای دروغین را حذف می کنیم که در غیر این صورت مرتباً دریافت می کنید. از آنجا که ما می توانیم تشخیص دهیم که یک آزمایش یک شکستگی محصول است و نه فقط یک تغییر محصول ، این هشدارهای با اولویت بالا به معنای چیزی است!

من به زودی راه اندازی می شوم ، هنوز هم عملکردی برای اضافه کردن وجود دارد اما من اصلی کار می کنم و از به اشتراک گذاشتن آن هیجان زده ام!

به هر حال این همه ، متشکرم!