Комментарии 17
А может, не стоит выделять "Автоматизатора" в принципе? В нашей компании мы нанимаем инженеров по тестированию. И инженер по тестированию отвечает за качество продукта, а руками он тестит или пишет фреймворки для автотестов — уже его дело. Любой тестировщик должен и руками уметь потестить, и прикидывать, как автоматизировать тот или иной кейс и вообще я стоит ли автоматизировать (ROI).
Не говоря уж про то, что разработчикам тоже неплохо бы про тесты знать, в итоге получаем, что собеседование на разработчика вообще не сильно отличается от собеседования тестировщика. Ну там отклонения туда-сюда, но в целом все перечисленное разработчик тоже должен как минимум представлять
Ага, особенно когда покрываешь все бранчи, ретурны и вообще все. А потом гоняешь lcov/glov. Тесты на software as product та еще адовщина. И SDET стоит на равне в SDE.
Инструменты тестирования становятся более dev-friendly. Релизы чаще, поэтому на пайплайны "написал код — ждёшь тестов — ждёшь автоматизации" банально не хватает времени. Да и качество архитектуры/кода автоматизатора всегда ниже, чем у девелопера, что загоняет солюшн по автоматизации в неработоспособное состояние каждые несколько лет. Оптимальным выглядит вариант, когда QA инженеров мало, но они скиловые в трёх направлениях: технологии, качество, продуктивность. Это позволяет им выбирать оптимальные стратегии тестирования/автоматизации, подбирать инструменты, обучать команду, но сами тесты пишут разработчики. Похожая концепция описана в книге "Как тестируют в Google".
Оптимальным выглядит вариант, когда QA инженеров мало, но они скиловые в трёх направлениях: технологии, качество, продуктивность. Это позволяет им выбирать оптимальные стратегии тестирования/автоматизации, подбирать инструменты, обучать команду, но сами тесты пишут разработчики.
Я тот самый скиловый в трех направлениях QA инженер. Не вижу причин отдавать тесты разработчикам при их наличии. Как раз когда разработчики пишут тесты, солюшен по автоматизации скатывается в неработоспособное состояние, точнее в неподдерживаемое кем-то уровня ниже сеньора. Из опыта, далеко не каждый разработчик понимает, как писать тестовые фреймворки правильно. Качество кода и архитектуры не всегда ниже, чем у девелопера, вам просто с автоматизаторами не везло. Опять же, кто мешает Quality Gate настроить на том же SonarQube?
Да и качество архитектуры/кода автоматизатора всегда ниже, чем у девелопера
Ох как высокомерно-то
Извиняюсь, не хотел никого обидеть. Я сам QA, временами автоматизирую, и действительно искренне уверен, что при прочих равных, человек, тратящий 100% времени на работу с кодом, напишет код лучше, чем человек, тратящий на код 40-60% времени. Это же вопрос специализации. Конечно есть исключения, есть гугловские SDET-ы, но, в среднем, мой опыт такой, как я написал.
Ок, неправильно выразился. При прочих равных, человек, тратящий 100% времени на разработку (в т.ч. анализ, дизайн, документация), напишет код лучше, чем человек, тратящий на разработку 40-60% времени. Я подразумеваю, что чаще QA-инженер занимается не только автоматизацией, но и другими QA-активностями.
Я специально разделил разработку и написание кода.
Разработчик тратит 100% времени на разработку.
QA тратит <100% времени на разработку, так как есть другие QA активности.
P.S. Вы сейчас действительно сливаете мне карму? Да что не так с этим сайтом, мы же просто обсуждаем особенности разных подходов к автоматизации.
Там только процесс написания кода тот же. И то с учетом особенностей архитектуры и использованных тулзовин.
Я согласен с мыслью выше, что «если нужно открыть консервы — вы используете консервный нож, если нужно открыть вино — штопор».
Касательно кармы — я минус поставил на Ваш комментарий выше, это правда. Потому что мне показалось, что тема уже обсуждалась и комментарий выше не несет ничего нового. ¯\_(ツ)_/¯
Касательно кармы — не знаю, не трогал. Видимо не только мне что-то показалось не так. Я вообще за то, чтобы нельзя было поставить необоснованный минус — было бы круто, если бы требовали какой-то комментарий. Это я как автор статей говорю. :)
Так, вижу, что дискуссия свернула куда-то не туда, поэтому постараюсь чуть более развернуто и точно изложить свои мысли.
Буквально 10-15 лет назад, сфера тестирования и автоматизации сильно отличалась от той, что есть сейчас. Гибкие методологии только начинали приживаться, поэтому процессы скорее напоминали водопад, а релизные циклы были по несколько месяцев. Сильные стороны водопадов это хорошая проработка требований и точное планирование, что позволяло начинать написание и автоматизацию тестов даже до начала разработки.
Времени на прогон тестов тоже было много. Помню, как мы закладывали две недели между dev freeze и релизом — как раз на стабилизацию и прогоны огромных тест паков + фиксы найденных проблем.
Другой особенностью были инструменты автоматизации. Монструозный Selenium с тестами на Java для фронта, BDD-фрэймворки с тысячами степов для бэка. Онборд в такой проект был долгим и сложным, поэтому разработчики зачастую даже смотреть туда не хотели.
В результате, получались достаточно длинные цепочки по автотестированию:
- аналитик пишет требования
- ручной тестировщик пишет тест кейсы
- автоматизатор (или отдел автоматизации, сразу на несколько команд) эти кейсы автоматизирует
- разработчик пишет код
- ручной тестировщик прогоняет тесты, расследует падения
- если виноват тест — пишет в отдел автоматизации и ждет фиксов
- если виноват продукт — сообщает об ошибке разработчику
У таких цепочек были очевидные минусы:
- Очень долгое время фидбека между внесением ошибки в код и получением уведомления об этом. В момент получения результатов тестов, разработчик может работать над совсем другой задачей.
- Автоматизатор хуже владеет контекстом фичи. Пишет тесты по кейсам, но улучшить/дополнить при таком сетапе — ему сложно.
- Высокая цена изменения фичи. Нужно заново запускать цикл кейсы — автоматизация — прогон. А ведь у автоматизатора работа тоже распланирована — придется ждать.
- В целом, накладные расходы в таком пайплайне сильно замедляют скорость деливери. Но для водопада ок.
Очевидная оптимизация — заменить ручного тестировщика и автоматизатора одним человеком. Но и тут ряд проблем:
- Поди найди такого, который и в тест дизайн умеет, и код хорошо пишет, и CI настроить может, и процессы SDLC готов улучшать, и руками потестировать не против. Да не одного, а несколько. И софт скилы ещё ведь. Месяцами искать можно, если не годами.
- Скорость деливери все равно страдает — фича заблокирована написанием тестов или исправлением упавших.
- Остается проблема позднего фидбека.
- Вопрос компетентности. Вижу, что он весьма больной, но все же — учитывая число навыков, которыми должен обладать QA, можно ли ожидать, что он будет настолько же хорош в каждом, насколько в нем хорош узкий специалист? Я допускаю, что такое бывает, но, блин, скиньте мне CV такого человека, нам такой очень нужен в команду :)
И вот, на дворе 2021-й год. Рынок меняется каждую неделю (сколько хайповал clubhouse?), фичи прилетают с пометкой ASAP, на проработанные требования все подзабили, зато начали менять их на лету, обозвали это скрамом и фигачат weekly релизы. И это еще хорошо, у многих релизы daily или вообще CD. При таком раскладе, цепочка выше начинает жутко боттлнечить в районе тестировщика-автоматизатора и нужно что-то делать.
В это же время, инструменты для автотестов сильно прокачались. Если раньше это были чуть ли не standalone решения, то сейчас их стараются создавать максимально близко к workflow разработчика. Например, если раньше в web-е царил упомянутый выше Selenium, то затем появились JS биндинги (понятные web-девелоперам), а сейчас фокус сместился еще ближе к коду — на компонентные и интеграционные фрэймворки типа enzyme/rtl/cypress-component.
Эти два фактора подводят нас к ситуации, в которой можно задуматься: если хорошего QA-инженера широкого профиля так сложно найти (а если найти, то цепочка "разработчик пишет код — QA пишет тесты — разработчик получает фидбек и начинает фиксить" все равно несет накладные расходы), а тесты пишутся немногим сложнее юнитов (которые разработчики писать умеют), то не передать ли ответственность за написание тестов разработчикам?
Это несет целый мешок плюсов:
- разработчик получает фидбек о дефектах сразу после написания тестов
- разработчик лучше всех знает код, покроет все условные ветки
- разработчик может проверить tricky кейсы с помощью тестов
- разработчик сразу чинит упавшие регрессионные тесты, не нужно ждать QA
Если прибавить к этому еще пару QA практик, то на входе QA-инженер будет получать фичу покрытую тестами, с зеленым прогоном регрессии, с пройденными ручными смоукчеками (да, тоже силами разработчика). То есть, практически, в prod-ready состоянии. Останется немного поправить написанные тесты (если есть замечания по тест дизайну), проверить руками необходимые сценарии и можно релизить. Получается быстро и качественно.
Конечно, нужно сразу оговориться, что для достижения такого процесса, QA-инженеру нужно проделать огромную работу — выбрать удобные для разработчика тест фрэймворки (и дописать/интегрировать их), настройка CI, написание документации, примеров, проведение сессий обучения тест дизайну, воркшопы по автоматизации. Для смоукчеков понадобятся чеклисты с проверкой самых критичных/проблемных зон. Но результат будет очень крутым. Повторюсь, что-то похожее описано в книге "Как тестируют в Google", которая мне местами очень нравится.
Надеюсь, никого не обидел. После предыдущих комментариев — карма у меня отрицательная, поэтому отвечать буду не всем и не сразу. Но тема очень интересная и актуальная, мой опыт показывает, что процессы влияют на качество ничуть не меньше инструментов, а пишут, в основном про инструменты, поэтому особенно приятно обсудить процессы :)
Этот ответ для всех участников дискуссии: 3vi1_0n3, asocial, nizkopal
«разработчик может проверить tricky кейсы с помощью тестов» — не могу сказать, что очень жизнеспособная концепция. Объясню почему. При имплементации фичи не очень вероятно, что разработчик понимает те сценарии, которые будут проходить пользователи при использовании этой фичи. И говорить разработчикам, что использовать для написания юнит-тестов я лично не стал бы, ровно как и слушать что они хотели бы, чтобы использовал я.
Я очень даже за обсуждение процессов, а не инструментов, однако замечания на тему «компонентные тесты лучше селениума» не поддерживаю, потому что есть область тестирования, которая никогда компонентными тестами не покроется. Скажем, вы мокаете бэкенд, чтобы протестировать компонент того же React'а, но он в жизни не будет работать сам по себе, в отрыве от других компонентов. А с тем же селениумом увидите, что реальные данные могут приходить дольше, поэтому возникает, например, неожиданный эффект типа краша приложения, если две кнопки нажали слишком быстро и т.д.
Опять же, возвращаясь к тому, с чего я начал. Количество тестов и их размер будут разными на разных уровнях тестирования. Как вы себе представляете разработчика, который не писал фичу и видит тест-кейсы в первый раз, которому дают писать тесты на UI? Один тест на UI будет явно масштабнее, чем несколько юнит-тестов.
Я не уверен, что правильно понимаю вас, но мне кажется, что вы разделяете «ручных» тестировщиков и «автоматизаторов», но при этом соединяете Quality Assurance и тестирование, тогда как это вовсе не одно и то же. Одно входит в другое, но они не равны. Поправьте, если не прав. Вообще и в статье, и в этом комментарии есть вещи, с которыми я согласен, и с которыми готов поспорить, но в основном больше в плане отделения мух от котлет и целесообразности разделения обязанностей (а не их наличия).
Надеюсь еще пообщаемся на эти темы, нечасто про QA и тестирование удается тут поговорить.
Конечно, нужно сразу оговориться, что для достижения такого процесса, QA-инженеру нужно проделать огромную работу — выбрать удобные для разработчика тест фрэймворки (и дописать/интегрировать их), настройка CI, написание документации, примеров, проведение сессий обучения тест дизайну, воркшопы по автоматизации.
Не все из этого процесса придется делать QA. В быстрой и качественной проверке заинтересованы не только QA, но и Dev Team Lead, Solution Architect, Project Owner, CTO, в некоторых командах заинтересованы DEV, поэтому все, что может быть делегировано, должно быть делегировано компетентных лицам. Из личного опыта «выбрать удобные для разработчика тест фрэймворки (и дописать/интегрировать их)», «проведение сессий обучения тест дизайну» и «воркшопы по автоматизации» делать не пришлось. Архитектуру приложения для E2E сделать похожей на архитектуру основного приложения — желательно -это добавит еще плюс в мешок, сможете новеньких людей в проект вводить через расширение проекта с e2e. Это еще и решает проблему с кадрами, автоматизаторов найти крайне затруднительно, да и в этом процессе они становятся не нужными.
Какие вопросы ожидать на позицию автоматизатора и причем тут сортировка?