Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Возможна ли автоматизация с нуля без ручного тестирования?

management
Теги: #<Tag:0x00007f7b653f8a58>

(Александр Таранков) #1

Рассмотрим пример из жизни. Возможно кому-то сложно такое представить, но, увы, такое есть.

Вот представим: есть проект, достаточно крупный (по сложности и количеству кода, а не по пользователям). Примером может служить типичный продукт для внутреннего использования в компании, какого-нть бэкофиса и т.п., не суть важно.

Разработка продукта ведется без тестирования. Ну, то есть, новый функционал как-то проверяется на соответствие поставленным требованиям, а на остальное не хватает времени. Систематического тестирования нет. Тестовой документации нет.

Вопрос: можно ли организовать тестирование такого продукта только посредством автоматизации тестирования? Может ли это быть эффективно?

Вопрос, понятно, подразумевает не односложный ответ. Хочется услышать вашу аргументацию, размышления, рассуждения, личный опыт и т.д.


(rmerkushin) #2

Думаю, что вполне возможно. Все зависит от опыта команды разработки, есть проекты где люди обходятся полностью без тестирования как такового вообще (присутствуют только юнит тесты). И проект прекрасно живет :smile: Но в тех случаях зачастую роль тестировщика зачастую выполняет сам заказчик или пользователи. А есть проекты где тетсирование используется по полной, но от этого они лучше не становятся, думаю примеры тут не нужны :smiley:


(sidelnikovmike) #3

Кажется, что может. Вопрос в том, насколько востребована автоматизация тут? Если один раз сделали и забыли - то может и не надо вообще мучаться. Если же это большой проект с развитием - то тут она может быть очень полезна, чтоб не привлекать ручников.
Хотя на внутренних проектах думается основной упор можно сделать на юнит тесты, а интеграцию делать а-ля смоук чек работоспособности системы.


(vmaximv) #4

На крупном “долгострое” без тестовой документации да с нуля поднять автоматизацию?
Я бы в это болото не полез :wink:
Можно конечно “понадрывать” спину - но в итоге проделанная работа будет просто никому не нужна.


(Roy Obenon) #5

Без документации конечно туго! Один считает так, другой так - короче каша. (сам в таком участвовал, получалось тупое клацанье). В принципе на быструю руку можно тестировать, но опять таки (чисто моё мнение) 30-50% багов не будут выявлены (начиная от логических, заканчивая GUI и юзабилити). Просто потом начинается от заказчиков, то неправильно, там кнопка не работает, там год можно вводить до 7654. По таким вот критериям и идет впечатление о компании и дальше поверьте и самому не хочется там работать.


(Urtow) #6

Полностью согласен с @vmaximv

Отвечаю как человек делающий подобное.

Итак - имеем весьма крупный проект.
Не имеем:

  • Тестирования вообще. От слова никак. Даже ручного.
  • Какой либо документации. (И желания её делать со стороны всех, кроме непосредственно спеца по тестированию)

Результат:

Автоматическое тестирование сделать можно, но (цензура) сложно.

К сожалению, у меня в проекте из-за особенностей самого проекта сделать 100% автоматизацию нереально вообще.

Личное мнение и эмоции:

Чтоб я еще раз сел за баранку этого пылесоса (с)

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

Резюмируя:

Сразу нафиг. Либо какие нереальные бонусы, которые могут реально заинтересовать.
Потому что Ваша работа будет никому не нужна и все будут только жаловаться.


(Roy Obenon) #7

Получается, если предлагают работу всё с 0 поднимать, то что отказываться не задумываясь?


(vmaximv) #8

Думать надо всегда, и лучше на пару ходов вперед :wink:

Если вам подробно озвучили скоуп, цели, дали хотя бы что-то слегка похожее на чек-листы - то почему бы и нет.


(Urtow) #9

Есть один нюанс (с)

Если с нуля в проекте, который сам фактически с нуля - это одно. Практически идеальный вариант, если есть конечно опыт или голова на плечах :smile:

Если с нуля в проекте, которому уже n лет и тестирования там нет - начинаются интересности. Почему не было тестирования? Почему решили сделать сейчас? Что ждут от тестирования?

Очень многое зависит от ответов на эти вопросы. От Вас могут ждать волшебной палочки - то есть пришел махнул палочкой и все проблемы решились. При этом нет никакой готовности к смене процессов, выделению ресурсов, написанию хоть какой-то документации и другим вещам без которых (как я представляю) сделать качественное тестирование невозможно.

А могут понимать, что тестирование (и контроль качества) - это не только тыкание в кнопочки. Тогда уже будет легче.

Идеального ответа нет, надо думать головой :smile:

Но я с бОльшей осторожностью отнесусь к предложению поднимать тестирование с нуля в уже долгоиграющем проекте, так как был крайне отрицательный опыт.

Отвечая непосредственно на вопрос топика:

Поднятие тестирования с нуля - это всегда весело. Ставить или нет кавычки - зависит от ответов на вопросы выше.
А автоматическое оно или ручное - особой роли не играет. Если можно 100% автоматизировать - то возможна.
Если нет - то нет.


(Sergey Korol) #10

На внутренние продукты обычно не выделяют ресурсов. Т.е. по всей видимости там будет 1-2 автомейшена максимум. Если проэстимейтить эффорт на развертку инфраструктуры, написание фрейма, изучение функционала, анализ / подготовку данных, непосредственное написание тестов, нон-стоп саппорт и репортинг, misc таски, - вы поймете, что это себя не окупит. Вся эта затея превратиться в автоматизацию ради автоматизации. Вы не сможете давать необходимый пифоменс / фидбек команде. Потом встанет вопрос профита и автомейшен прикроют.

Но опять-таки, все упирается в ресурсы. Если вам дадут 5 сеньоров в подчинение, то возможно через 3-6 месяцев у вас уже будет какой-то вменяемый смоук / регрешен. Но в любом случае о 100% coverege и речи быть не может. Скрипты то по сторонам не умеют смотреть. А чтобы даже чуть-чуть приблизить покрытие к тому порогу, когда можно обойтись без ручников, вам придется “пыхтеть” сутками. Основные баги все равно находят люди. Особенно в новой функциональности, которую вы чисто физически не заавтоматизируете до ее непосредственной стабилизации. А ручники бы давно нашли миллион багов при таком кейсе. Ну т.е. в плане новых фич без мануальщиков будет жесткий просест в фидбеке. Все будут ждать вас, любимых, пока вы покроете тестами новую функциональность. И тут наступает замкнутый круг. Пока вы их напишите, пока они найдут баги, пока девы их пофиксят, параллельно что-то меняя, пока вы пофиксите свои тесты из-за изменений, пока опять все не отладите… В общем, я бы тоже за такое не взялся. Особенно в одиночку.


(Александр Таранков) #11

Всем спасибо за комментарии!

У меня так складывается карьера, что я в каждом новом месте (их было не много, но все же) участвую в поднимании тестирования и автоматизации тестирования. И я убежден в том, что начинать надо с ручного тестирования, с выстраивания процессов разработки под него, а только потом начинать автоматизацию. Сроки и разрыв между этими событиями зависит от многих факторов, это не суть. Но последовательность должна быть именно такой: ручное, потом автоматическое.

Логика подсказывает, что иначе в принципе и невозможно, ведь что автоматизировать, если нет тестирования? Должна быть хотя бы тестовая документация. А если есть тестовая документация, то почему бы не тестировать вручную, ведь это быстрее на коротких интервалах времени.

И сейчас, на очередной ступеньке своей карьерной лестницы, столкнулся с “блестящей идеей” - делать сразу автоматические тесты! Без регулярного тестирования! На gherkin, чтоб аналитики сразу могли писать автоматические тесты! Идея на мой взгляд столь же плохая, сколь и не новая - так или иначе, в разной степени “веры”, руководство любит заблуждаться по этому поводу, ожидая от автоматизации эффекта “волшебной палочки” - написал и ВСЁ, нет проблемы :smile:.

Я стараюсь “снять шоры”, посмотреть шире, поэтому задал тут этот вопрос. Я думаю, что понял правильно, что большинство комментариев разделяет мою точку зрения.

Юнит-тесты - хорошая идея, они пишутся (со скрипом и не везде), но задача функционального тестирования все же стоит и её надо решать. К тому же не всё так безнадежно - роль тестеров выполняют аналитики. Это конечно отдельная песня (тестирование силами аналитиков), но лучше, чем совсем в одного.

Буду пробовать решать проблему разными способами: частично через автоматизацию, частично через пропаганду “правильного образа жизни”, когда быстрого эффекта можно достигнуть просто начав тестировать вручную правильно :smile: