What is Nightwatch?
Nightwatch.js is an automated testing framework for web applications and websites, written in Node.js and using the W3C WebDriver API (formerly Selenium WebDriver).
Почему прощай Selenium, ведь NightwatchJS — это одна из его оберток. То есть там, где будут проблемы у Selenium с WebDriver ровно там будут проблемы и у NighwatchJS. Ну плюс еще и свои собственные.
> Учитывая, что по времени написание таких тестов будет примерно аналогично собственно разработке функционала.
Если считать это верным (к счастью, это не всегда верно) — то можно сразу поставить крест или на скраме. или на автоматизации с TestComplete — просто не будете успевать в одной итерации решить эти две задачи.
Хочу напомнить, что «юнит-тесты и интеграционные» и должны составлять львиную долю автотестов (см. «пирамида автотестирования», так что даже противоречия тут никакого нет.
Считаю, что высокоуровневые автотесты не могут ускорить тестирование — только замедлить могут.
Ускорить можно прогоны регрессии. Успевать с автоматизацией высокоуровневой регрессией в скраме — чрезвычайно сложно, хотя наверное возможно, если иметь хороших специалистов. В данном случае важно убедить всех членов команды, что спринт не может считаться успешным, если не закончены задачи автоматизации регрессии. На практике — очень непростое дело.
Заголовок — «Автоматизация тестирования по методологии Scrum» — явно ошибочен. Scrum никак не описывает автоматизацию тестирования (а описывает управление проектом), и даже, строго говоря, не является методологией. Впрочем статья в целом никак не соотносится с SEO-ориентированным заголовком.
По теме статьи, считаю, что ветвь — выделения в команду QA-автоматизатора, чтобы «свести ручную работу к минимуму» — тупиковая, ну и особенно, если других тестировщиков в команде нет. Так называемая «ручная» работа, а на самом деле «мозговая» — является краеугольным камнем тестирования, она приносит наибольшую пользу всему проекту, поэтому нет никакого смысла сводить её к минимуму. Что вероятно имел в виду автор — свести к минимум регрессионное тестирование (небольшую часть работы тестировщика), что разумно — но работает это гораздо лучше, когда сами программисты занимаются этой частью автоматизации. Роль типичного «автоматизатора» должна по моему мнению заключаться в обучении программистов и помощи им в технических вопросов. Или другими словами — автоматизатор, это такой же девелопер, с бОльшими познаниями в технологии написания автотестов.
Еще система так устроена, что для пациентов с гос. страховками у врача есть глобальные договоренности со страховками, (для примера цифры выдуманные, но отражают идею) например «домашний врач» — получает оплаченным 10 минут на пациента, неважно сидел он 5 минут или 25. Конечно врач пытается в соответствии с Гиппократом уделять каждому, столько времени, сколько нужно, но сами понимаете — когда кто-то час времени требует, а тебе только за 10 минут заплатят — это не в кайф. А с частными проще — сколько нужно, столько и оплачивают.
Будет и разница в уровене обслуживания. Например гос. пациентам врач имеет право выписывать не все те лекарства, которые он считает нужными, а частным — все.
Плюс разница в сроках приёма — были реальные такие случаю, звоню:
— Мне нужен «термин» у вашего врача
— Ближайший свободный через полтора месяца
— У меня частная страховка
— Сегодня сможете?
Некоторые советы в «выводах» — очень вредны для подавляющего большинства проектов. Как например:
сохраняйте тип населенного пункта и улицы.
Разделяйте номер дома и литеру.
Зачем проекту это надо? Запутать себя, клиентов и тестировщиков? Чтобы потом менеджер мог отчетик по всем клиентам, у которым дом с литерой Г составить?
Мой вывод:
«Сохраняйте весь адрес, кроме индекса и города-страны в нескольких строках без валидации»
Если считать это верным (к счастью, это не всегда верно) — то можно сразу поставить крест или на скраме. или на автоматизации с TestComplete — просто не будете успевать в одной итерации решить эти две задачи.
Считаю, что высокоуровневые автотесты не могут ускорить тестирование — только замедлить могут.
Ускорить можно прогоны регрессии. Успевать с автоматизацией высокоуровневой регрессией в скраме — чрезвычайно сложно, хотя наверное возможно, если иметь хороших специалистов. В данном случае важно убедить всех членов команды, что спринт не может считаться успешным, если не закончены задачи автоматизации регрессии. На практике — очень непростое дело.
По теме статьи, считаю, что ветвь — выделения в команду QA-автоматизатора, чтобы «свести ручную работу к минимуму» — тупиковая, ну и особенно, если других тестировщиков в команде нет. Так называемая «ручная» работа, а на самом деле «мозговая» — является краеугольным камнем тестирования, она приносит наибольшую пользу всему проекту, поэтому нет никакого смысла сводить её к минимуму. Что вероятно имел в виду автор — свести к минимум регрессионное тестирование (небольшую часть работы тестировщика), что разумно — но работает это гораздо лучше, когда сами программисты занимаются этой частью автоматизации. Роль типичного «автоматизатора» должна по моему мнению заключаться в обучении программистов и помощи им в технических вопросов. Или другими словами — автоматизатор, это такой же девелопер, с бОльшими познаниями в технологии написания автотестов.
Radio QA
Плюс разница в сроках приёма — были реальные такие случаю, звоню:
— Мне нужен «термин» у вашего врача
— Ближайший свободный через полтора месяца
— У меня частная страховка
— Сегодня сможете?
Зачем проекту это надо? Запутать себя, клиентов и тестировщиков? Чтобы потом менеджер мог отчетик по всем клиентам, у которым дом с литерой Г составить?
Мой вывод:
«Сохраняйте весь адрес, кроме индекса и города-страны в нескольких строках без валидации»
А примерчики, да — хорошие!