Комментарии 15
Смотрим, как должно быть по ТЗ. Сравниваем с тем, как модуль сделан в реальности. Но главное — учимся смотреть на продукт и изменения с точки зрения здравого смысла и обычного пользователя.
Удобен ли рабочий сценарий? Всё сделано «по-человечески»? Параллельно проводим ещё и usability-тестирование.
Разве это не задача Feature Owner/Product Owner/Analytic описывать сценарии по человечески, до того как они попадут к разработчикам? Не он ли должен описывать совместно с QA что и как тестировать?
Почему у вас QA определяют то как выглядит продукт?
Разработчик утверждает, что ошибка исправлена — мы проверяем. Если ошибка не исправлена, возвращаем тикет в работу.
Если разработчик несколько раз не может исправить одну и ту же ошибку, то убираем эту часть из обновления…
По-моему, что-то не так…
Разработчики, собирают пачку кода в отдельную версию. И пишут описание: « Новый интернет-магазин в облаке. Изменения такие-то. Добавили кучу новых страниц». И обязательно прикладывают огромный changelog с несколькими сотнями коммитов.
Всё это поступает к тестировщикам. Этот процесс я называю «экстремальным Agile» — мы работаем по чётким итерациям.
Выглядит скорее как "экстремальный Waterfall". Возможно, я неправильно понял, но сначала разрабы собирают релиз, а только потом QA тестируют? Даже если вы работаете итерациями, это все равно выглядит как waterfall
А вот чего в нашем процессе тестирования нет, так это постоянной интеграции. Она нам не подходит, потому что есть накопленное «историческое наследие».
И на протяжении трех месяцев каждую ночь автоматически собирается и выкладывается новая сборка.… Если всё в порядке, запускаются все автотесты.
Ночные сборки с запуском тестов это и есть CI, на сколько могу судить.
Сейчас наш полный цикл ночных автотестов наконец-то стал укладываться в ночное время. Раньше он занимал около 32 часов.
Смок тест 32 часа? Да даже есть 8 (ночь) все равно как-то не тянет. Или какие тесты вы запускаете ночью? На картинке с видами тестирования у вас регресс в колонке с ручным. Наверное, только полный регресс может столько времени занимать
Ночные сборки с запуском тестов это и есть CI, на сколько могу судить.
И да, и нет. «Красивый» классический CI он же как: разработчик коммитит код или банч исправлений, сразу же стартует сборщик. А там и автотесты стартуют, а потом, в случае ошибки, разработчик уведомляется об этом. А потом итерация повторяется.
У нас, в силу некоторых особенностей, есть элементы CI, представленные как раз в ночных сборках.
Смок тест 32 часа? Да даже есть 8 (ночь) все равно как-то не тянет. Или какие тесты вы запускаете ночью? На картинке с видами тестирования у вас регресс в колонке с ручным. Наверное, только полный регресс может столько времени занимать
Нет-нет, смок тесты по крупным модулям, например CRM, идут максимум 1,5-2 часа. Это, пожалуй, самый большой модуль с множеством важных бизнес-кейсов. Средний смок тест идет 15 минут.
Ночью стартуют большие прецедентные тесты, вообще все что есть, по всем модулям. Днем — смотрим по ситуации. И можем обойтись только смок тестом или пускаем параллельно с ручной проверкой большой сценарный тест.
Как проходит среднестатистический автотест?
- Подготавливаем тестовую установку для проверки сценария, через API, минуя интерфейс
Можно ли поподробнее об этом API?
Пока автоматизация тестирования сильно упирается в то, что тестовый стенд автоматом развернуть весьма затруднительно.
Конечно. Мы реализовали так.
Есть php-файл с набором методов для работы с сущностями продукта: создание задач с предустановленными параметрами, создание лида, удаление поста в ЖЛ и т.д. На каждый тестируемый модуль. Необходимые параметры создания сущности мы передаем через гет-параметры (что делаем, с какой сущностью, какие параметры у сущности или действия). Далее процесс автотестирования прецедента, например, удаления задачи выглядит так:
1. Робот дергает через урл наш php-файл, передав туда метод очистки старых демо-данных. Имена сущностей у нас предопределены, поэтому всегда знаем, что относится к тестовым данным, которые необходимо очистить
2. Робот дергает через урл наш php-файл, передав через гет необходимый набор параметров: создаем задачу, с крайним сроком, с id ответственного номер такой-то, и т.д.
3. Робот через UI идет по сценарию: переходит в список задач. У созданной выше задачи кликает на пункт меню «Удалить». Проверяет, что задачи в списке нет
Есть php-файл с набором методов для работы с сущностями продукта: создание задач с предустановленными параметрами, создание лида, удаление поста в ЖЛ и т.д. На каждый тестируемый модуль. Необходимые параметры создания сущности мы передаем через гет-параметры (что делаем, с какой сущностью, какие параметры у сущности или действия). Далее процесс автотестирования прецедента, например, удаления задачи выглядит так:
1. Робот дергает через урл наш php-файл, передав туда метод очистки старых демо-данных. Имена сущностей у нас предопределены, поэтому всегда знаем, что относится к тестовым данным, которые необходимо очистить
2. Робот дергает через урл наш php-файл, передав через гет необходимый набор параметров: создаем задачу, с крайним сроком, с id ответственного номер такой-то, и т.д.
3. Робот через UI идет по сценарию: переходит в список задач. У созданной выше задачи кликает на пункт меню «Удалить». Проверяет, что задачи в списке нет
Еще до перечисленных действий должна быть как-то подготовлена сама установка Б24 или БУС. Это автоматизировано?
Кроме Мастера установки других способов развертывания продукта не предлагается. Для своих задач писали обертку над установщиком: без участия пользователя скачивает и распаковывает дистрибутив, проходит все шаги мастера с заранее заданными настройками (без интерфейса, selenium, phantomjs или других зависимостей).
Кроме Мастера установки других способов развертывания продукта не предлагается. Для своих задач писали обертку над установщиком: без участия пользователя скачивает и распаковывает дистрибутив, проходит все шаги мастера с заранее заданными настройками (без интерфейса, selenium, phantomjs или других зависимостей).
Конечно, готовим дистрибутив или облачный портал, как тестовую среду, в зависимости от ситуации. В ночной прогон, например, робот полностью все готовит сам, собирает дистр, ставит его. В процессе производства текущих обновлений днем, смок-тест, например, не ставит свой дистр, а может ходить вообще по любому облачному порталу, подготавливая лишь необходимые данные для UI-теста.
Почему вы решили, что применяете гибкие методологии разработки?
У вас:
Разработчик сам не способен, ему нужен секретарь?
У вас:
- есть четкое деление на этапы тестирования, разработки.
- разработчики не тестируют. Классический водопад.
- разработчики всеми автоматизированными тестами не пользуются, только юнитами.
- автоматизация вообще удел отдельных людей, а не команды.
Утром тестировщик проверяет логи и смотрит, где и что упало, где разработчик допустил ошибку, где нужно поправить автотест.
Разработчик сам не способен, ему нужен секретарь?
Почему вы решили, что применяете гибкие методологии разработки?
Этапы, конечно, есть. Не разработав начальную версию продукта (или отдельно верстки, дизайна, логики), мы не сможем провести первую итерацию тестирования или первичного контроля реализованной части.
Разработчики тестируют определенный набор кейсов. Набор кейсов для проверки, конечно, на много меньше чем тот, что имеют тестировщики.
Разработчики пользуются любыми тестами, которыми захотят. Всю UI-автоматизацию и тестирование осуществляет отдел автоматизированного тестирования.
4-й ваш пункт я не понял. Автоматизацией занимается у нас отдел автоматизированного тестирования. Они же делают чек логов прогона тестов.
Разработчик сам не способен, ему нужен секретарь?
Согласен с вами, хочу со временем передать эту часть разработчикам =). Пока, как историческое наследие, это делают ребята из отдела автоматизации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автотесты, ночные сборки, экстремальный Agile. Как мы тестируем наши продукты