На якому етапі Agile (SCRUM) ми повинні почати створювати тести автоматизації?

9

Трохи переді мною - я тестер, який майже 2 роки використовую ручне тестування в Agile середовищі, використовуючи SCRUM (спринти 1-2 тижнів). Тому я хочу впровадити тестування автоматизації у своїй роботі за допомогою Selenium WebDriver (з Java).

Моє запитання полягає в тому, коли слід тестувати функціональність вручну і коли я повинен конвертувати їх для тестування автоматизації?

Я читав і отримую інший підхід, наприклад:

Коли починається новий спринт, конвертуйте історії користувачів в автоматизовані сценарії з попереднього спринту, АБО;
Конвертувати історії користувачів в одному спринті.

Будь-які поради будуть дуже вдячні. Спасибі заздалегідь.

— Джей
джерело

4

Будь ласка, не переписуйте те саме питання на двох різних сайтах обміну стеками. Видаліть одну з них.

— R Sahu

2

Хрест відправив на sqa.stackexchange.com/questions/27017 / ... .

— R Sahu

13

Автоматизація тестів (і всі інші тестування) повинні бути частиною визначення зробленого . Це для того, щоб зробити продукт, який потенційно може бути відвантажений. Чи можете ви відправляти, якщо його не перевіряли?

Тестування також повинно бути підходом цілої команди, тому автоматизація тестування не є відповідальністю тестерів. Почніть думати про тестування якомога швидше в процесі.

Автоматизація тестів настільки важлива в Agile, оскільки:

Організаційна спритність обмежена технічною спритністю

Іншими словами, коли ви повільно вносите зміни у свій продукт, то не має значення, як ви структуруєте свої команди, свою організацію чи які рамки ви приймаєте, ви будете повільно реагувати на зміни.

https://less.works/less/technical-excellence/index.html

Якщо ви відкладете тестування до іншої ітерації, ви завжди будете відставати. Полегшаючи зміну напрямку виробу, оскільки складніше переробляти та безпечно захищати зовнішню поведінку виробу. Будь-яке повторне ручне тестування є ключовим фактором для уповільнення, автоматизації роботи!

Дуже багато тестувальників скажуть вам, що не слід починати тестування в кінці, поки інтерфейс продукту не стабілізується. Не чекайте, замість цього добре використовуйте PageObjects і переконайтесь, що ваші тести є ремонтопридатними, і покладіть на них відповідальність розробника за їх створення та виправлення.

— Нільс ван Реймерсдал
джерело

Я не згоден з першим "повинен". Визначення зробленого - це те, що команді Scrum потрібно розробити для себе. Якщо команда вважає автоматизоване тестування важливим, то вони включатимуть її як частину свого визначення. Однак сам процес не говорить про те, що вони повинні чи навіть повинні. Це щось, що повністю залежить від команди, і немає правильної, неправильної чи бажаної відповіді.

— aroth

@aroth Я згоден з вами, але майже у всіх випадках ви створюєте більший програмний продукт, який ви хочете додати тестування до DoD. Тому я думаю, що добре сказати людям, що слід, принаймні серйозно подумати над цим. Як тестер, я вважаю, що тестування наприкінці окремою командою - це перші кроки до Вагіле. Але так, є ситуації та / або випадки, коли тестування може навіть не знадобитися.

— Нільс ван Реймерсдал

2

Ключовим є те, що ви не позначаєте історію закінченою, якщо не написали автоматизовані тести для цієї історії.

Тому 1, здається, не вийшов, коли ви пишете тести на завдання, виконане в попередньому спринті. що робити, якщо тести не вдаються?

— Еван
джерело

Отже, якщо на першому тижні нового спринту жодна історія користувача про цей спринт не перебуває в стані, він може бути перевірений регресією, ви пропонуєте, що ОП має їхати додому і нічого не робити? Для мене це не дуже ефективно ;-)

— Док Браун

Тестер повинен використати цей перший тиждень, щоб поставити під сумнів специфікацію "хммм як користувач, я б очікував фонову музику на своїй веб-сторінці .." знайти помилки в неповних історіях і взагалі скласти проблеми. Девам дозволено сказати, що вони не можуть почати, поки не будуть написані плани випробувань

— Еван

@DocBrown: у перший тиждень нового спринту тестеру належить виконати неймовірний обсяг роботи. Вони повинні розуміти, що будують розробники, працюючи з власником продукту та розробниками. Їм потрібно співпрацювати з розробником, щоб переконатися, що вони роблять код перевіряючим. Вони можуть почати працювати над автоматизованим планом тестування. Вони навіть можуть почати писати якісь тести. Якщо у вас є належна тестова основа, де ваші тести написані на високому рівні абстракції, ви можете написати їх до того, як код буде готовий.

— Брайан Оуклі

1

В ідеалі ви повинні писати автоматизовані тести в тому ж спринті, в якому написаний код. Код не слід вважати "зробленим" до тих пір, поки автоматичні тести не будуть написані, і ви повинні довести код до стану "зроблено" до кінця спринту.

Ви повинні розпочати процес у перший день спринту, співпрацюючи з розробником, щоб зрозуміти код і допомогти їм зрозуміти ваші потреби як тестера. Наприклад, якщо ви створюєте веб-сторінки, ви можете допомогти їм зрозуміти необхідність додавання унікальних ідентифікаторів для кожного елемента сторінки, з яким потрібно взаємодіяти.

Пам'ятайте, що в scrum, ваша робота не в тому, щоб писати тести. Ваше завдання - працювати з командою, щоб виконати цілі спринту. Це означає спілкування та співпрацю, що має відбутися дуже рано у спринті. Ви можете розпочати роботу над тестовими розробками та тестовими планами задовго до того, як код буде готовий до тестування.

— Брайан Оуклі
джерело

0

Якщо ви збираєтеся тестувати автоматично, ви також можете створити тести заздалегідь. Це допоможе вам визначити, яку поведінку ви очікуєте, і стимулює вас мислити як клієнта, але це повинно зробити ваше програмне забезпечення більш зручним у підсумку. І ви отримаєте вигоду з тесту негайно, коли реалізуєте функціонал.

— Мартін Маат
джерело

1

Це не працює з інструментами тестування інтерфейсу користувача, як Selenium. Для створення тестів потрібен працездатний та стабільний інтерфейс користувача.

— Док Браун

@DocBrown: Я не думаю, що це обов'язково правда. Якщо ви дасте мені специфікацію для нової веб-сторінки, я можу почати (а можливо закінчити!) Писати автоматизовані тести до того, як сторінка буде написана. Вам просто потрібно співпрацювати з розробником, щоб ви обоє домовилися про те, що таке структура сторінки, які ідентифікатори елементів тощо.

— Брайан Оуклі

0

Ви можете робити будь-яке, але зазвичай ви хочете націлити регресійне тестування за допомогою тестів автоматизації. Це означало б, що я б робив посібник до тих пір, поки не переконаєтесь, що це досить міцно, щоб пройти регресійний тест. Це може бути посеред спринту для деякої функціональності, а може бути у майбутньому спринті для іншої функціональності.

— баранина
джерело

0

Як було сказано в іншій відповіді , коли тестування має бути частиною визначення зробленого . Однак я не згоден з деякою відповіддю, тому хотів розширити досвід, з яким я стикався.

У по-справжньому спритному середовищі кожен здатний зробити все. Не було б когось на 100%, присвяченого тестуванню, ви також розвивали б навички, щоб допомогти з базовою роботою інтерфейсу чи чимось іншим. Однак ми рідко коли-небудь живемо в ідеальному світі.

Що я б порекомендував, було б зробити трохи гібридний підхід. Для вашого визначення Done, я б сказав, що ручне тестування повинно бути частиною спринту, в якому закодовано роботу. один. Зосередившись на ручному тестуванні, ви ознайомитесь із тим, що повинен робити код. На початку наступного спринту, коли у вас може не так багато робити, ви можете налаштувати свої автоматизовані тести, які можуть запускатися як частина процесу збирання, щоб запобігти помилкам регресії.

— крильгар
джерело

Я ніколи не бачив спринт, де не було вже багато чого зробити для поточних цілей спринту в перший день. Для написання автоматизованих тестів потрібна співпраця та планування, і це повинно розпочатися в першій годині першого дня спринту.

— Брайан Оуклі