بازگشت به مدرسه: نحوه آموزش تست‌کنندگان دستی برای مقابله با تست‌های خودکار

از هر پنج متقاضی QA، چهار نفر می خواهند نحوه کار با تست های خودکار را بیاموزند. همه شرکت ها نمی توانند چنین خواسته های تسترهای دستی را در ساعات کاری برآورده کنند. Wrike یک مدرسه اتوماسیون برای کارمندان برگزار کرد و این آرزو را برای بسیاری محقق کرد. من دقیقاً به عنوان دانش آموز QA در این مدرسه شرکت کردم.

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

تجربه Wrike در سازماندهی یک مدرسه

هنگامی که نیاز به یک مدرسه اتوماسیون آشکار شد، سازمان آن به دست Stas Davydov، رهبر فنی اتوماسیون افتاد. چه کسی جز او می تواند توضیح دهد که چرا آنها به این ابتکار عمل کردند، آیا به نتایجی دست یافتند و آیا از زمان صرف شده پشیمان هستند؟ بیایید به او صحبت کنیم:

— در سال 2016، چارچوب جدیدی برای تست‌های خودکار نوشتیم و آن را طوری ساختیم که نوشتن تست‌ها آسان شد: مراحل عادی ظاهر شدند، ساختار بسیار قابل درک‌تر شد. ما به یک ایده رسیدیم: ما باید همه کسانی را که می‌خواهند تست‌های جدید بنویسند، درگیر کنیم و برای اینکه درک آن آسان‌تر شود، مجموعه‌ای از سخنرانی‌ها ایجاد کردیم. ما به طور جمعی طرحی از موضوعات ارائه کردیم، هر یک از اساتید آینده یکی را برای خود انتخاب کردند و گزارشی در مورد آن تهیه کردند.

- دانش آموزان چه مشکلاتی داشتند؟

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

- آیا مدرسه نتیجه داد؟

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

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

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

نکات سازماندهی

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

مرحله 0. یک فرهنگ لغت ایجاد کنید

البته این مرحله نه تنها برای QA لازم است. با این حال، می‌خواهم آن را صریح بیان کنم: پایگاه کد اتوماسیون باید به شکلی قابل خواندن نگهداری شود. زبان های برنامه نویسی - نه کم اهمیت языки، و از اینجا می توانید شیرجه خود را شروع کنید.

در اینجا یک اسکرین شات از یک taskview با نام عناصر است. بیایید تصور کنیم که شما در حال آزمایش taskview به عنوان یک جعبه سیاه هستید و هرگز در زندگی خود سلنیوم ندیده اید. این کد چه کاری انجام می دهد؟

(اسپویلر - کار از طریق rest از طرف ادمین حذف می شود و سپس می بینیم که یک رکورد از این در جریان وجود دارد.)

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

مرحله 1. عبارات را تکرار کنید

بیایید به موازی با زبان ادامه دهیم. وقتی در کودکی صحبت کردن را یاد می گیریم، از ریشه شناسی و معناشناسی شروع نمی کنیم. ما "مادر"، "اسباب بازی بخر" را تکرار می کنیم، اما بلافاصله وارد ریشه های پروتو-هند و اروپایی این کلمات نمی شویم. اینجا هم همین‌طور است: بدون تلاش برای نوشتن چیزی که کار می‌کند، غواصی در اعماق ویژگی‌های فنی تست‌های خودکار فایده‌ای ندارد.
کمی غیر منطقی به نظر می رسد، اما کار می کند.

در درس اول، ارزش این را دارد که مبنایی در مورد نحوه نوشتن مستقیم تست های خودکار ارائه شود. ما به راه‌اندازی محیط توسعه (در مورد من Intellij IDEA) کمک می‌کنیم، حداقل قوانین زبانی را که برای نوشتن روش دیگری در کلاس موجود با استفاده از مراحل موجود ضروری است، توضیح می‌دهیم. یکی دو تا تست باهاشون می نویسیم و بهشون تکلیف می دیم که اینجوری فرمت می کنم: یک شاخه از استاد منشعب شده ولی چند تست ازش حذف شده. فقط توضیحات آنها باقی مانده است. از آزمایش‌کنندگان می‌خواهیم این آزمایش‌ها را بازیابی کنند (البته نه از طریق نمایش تفاوت).

در نتیجه، کسی که گوش داد و همه کارها را انجام داد، قادر خواهد بود:

1. یاد بگیرید که با رابط محیط توسعه کار کنید: ایجاد شاخه ها، کلیدهای میانبر، commit ها و فشارها.
2. به اصول ساختار زبان و کلاس ها تسلط داشته باشید: کجا تزریق ها را وارد کنید و کجا وارد کنید، چرا حاشیه نویسی لازم است، و چه نوع نمادهایی در آنجا یافت می شود، علاوه بر مراحل.
3. تفاوت بین عمل را درک کنید، صبر کنید و بررسی کنید، کجا از چه چیزی استفاده کنید.
4. به تفاوت بین تست‌های خودکار و بررسی‌های دستی توجه کنید: در تست‌های خودکار می‌توانید به‌جای انجام اقدامات از طریق رابط، یک کنترلر را بکشید. به عنوان مثال، به جای باز کردن یک taskview، انتخاب ورودی، تایپ متن و کلیک کردن بر روی دکمه Send، یک نظر مستقیماً به باطن ارسال کنید.
5. سوالاتی را که در مرحله بعد به آنها پاسخ داده خواهد شد، فرموله کنید.

نکته آخر بسیار مهم است. این پاسخ‌ها را می‌توان به راحتی زودتر از موعد ارائه کرد، اما این یک اصل آموزشی مهم است که پاسخ‌های بدون سؤالات فرمول‌بندی‌شده به خاطر سپرده نمی‌شوند و در صورت لزوم استفاده نمی‌شوند.

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

چه چیزی را نباید داد:

1. دانش عمیق تر از عملکرد محیط توسعه و خود زبان برنامه نویسی، که فقط در هنگام کار با شاخه ها به طور مستقل مورد نیاز خواهد بود. به خاطر نمی‌آید، باید دو یا سه بار توضیح دهید، اما ما برای زمان مهندسان اتوماسیون ارزش قائل هستیم، درست است؟ مثال‌ها: حل تضادها، افزودن فایل‌ها به git، ایجاد کلاس‌ها از ابتدا، کار با وابستگی‌ها.
2. همه چیز مربوط به xpath به طور جدی. شما باید در مورد آن جداگانه صحبت کنید، یک بار و بسیار متمرکز.

مرحله 2. نگاهی دقیق تر به دستور زبان

بیایید اسکرین شات taskview از مرحله #0 را به خاطر بسپاریم. ما یک مرحله به نام checkCommentWithTextExists داریم. تستر ما قبلاً متوجه شده است که این مرحله چه کاری انجام می دهد و می توانیم به داخل استپ نگاه کنیم و کمی آن را تجزیه کنیم.

و در داخل ما موارد زیر را داریم:

onCommentBlock(userName).comment(expectedText).should(displayed());

جایی که onCommentBlock است

onCommonStreamPanel().commentBlock(userName);

اکنون یاد می گیریم که بگوییم "اسباب بازی بخر"، بلکه "اسباب بازی را از فروشگاه دتسکی میر بخر، که در کابینت آبی رنگ در قفسه سوم از بالا قرار دارد." لازم به توضیح است که از عناصر بزرگتر به صورت متوالی به یک عنصر اشاره می کنیم (stream -> بلوک با نظرات یک شخص خاص -> آن قسمت از این بلوک که متن مشخص شده در آن قرار دارد).

نه، هنوز زمان صحبت در مورد xpath نیست. فقط به اختصار ذکر کنید که همه این دستورالعمل ها توسط آنها شرح داده شده است و ارث از طریق آنها انجام می شود. اما ما باید در مورد همه این تطبیق دهندگان و پیشخدمت ها صحبت کنیم؛ آنها به طور خاص به این مرحله مربوط می شوند و برای درک آنچه اتفاق می افتد ضروری هستند. اما زیاده روی نکنید: دانش آموز شما می تواند بعداً ادعاهای پیچیده تر را به تنهایی مطالعه کند. به احتمال زیاد باید، waitUntil، displayed();، exist();، not(); کافی باشد.

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

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

مرحله 3. غوطه وری کامل

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

ابتدا اجازه دهید روشن کنیم که همه این onCommentBlock و نظرات توسط آنها توضیح داده شده است.

مجموع:

"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"

ترتیب داستان بسیار مهم است. ابتدا هر xpath موجود را می گیریم و نشان می دهیم که چگونه تب عناصر حاوی یک و تنها یک عنصر است. در مرحله بعد، ما در مورد ساختار صحبت خواهیم کرد: زمانی که باید از WebElement استفاده کنید، و زمانی که باید یک فایل جداگانه برای یک عنصر جدید ایجاد کنید. این به شما امکان می دهد تا ارث را بهتر درک کنید.

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

در این مرحله، مخاطب باید کاملاً درک کرده باشد که چگونه به ارث می رسد و چه چیزی را می توان بعد از نقطه در onCommentBlock وارد کرد. در این مرحله، تمام عملگرها را توضیح می دهیم: /، //، .، [] و غیره. ما دانش در مورد استفاده را به بار اضافه می کنیم @class و سایر موارد ضروری

دانش آموزان باید بدانند که چگونه xpath را به این روش ترجمه کنند. برای تحکیم - درست است، تکلیف. ما توضیحات عناصر را حذف می کنیم، اجازه می دهیم کار تست ها را بازیابی کنند.

چرا این مسیر خاص؟

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

با این حال، برخی از شما احتمالاً می‌توانید تجربه خود را در مورد چگونگی بهینه‌سازی بیشتر فرآیند به اشتراک بگذارید. من خوشحال خواهم شد که پیشنهادات مشابه را در نظرات بخوانم!

منبع: www.habr.com