1. Составляя чек-листы тестировщик изучает задачу и записывает, какие проверки он будет делать. Если требования поменяются, чек-лист за ним так же меняется.
2. Статус REOPEN существует. Если мы повторно открываем задачу или баг, то он помещается в колонку IN PROGRESS и разработчик после завершения текущей задачи, возвращается к задаче / ошибке со статусом REOPEN.
3. Для нашей команды мы вывели оптимальное количество задач от 4-х, конечно их может быть и больше. По суммарному времени проверок это не регламентируется. Если нужно выкатить одну задачу срочно — мы выкатываем одну задачу.
Сергей, спасибо за вопросы.
Изменяется продукт и другие процессы в проекте и процесс тестирования так же пересматривается. Если он изначально не описан или, что еще хуже, не доведен до команды — нечего улучшать, процесс будет выстраиваться каждый раз как с нуля, без учета ранее решенных проблем или опробованных и не сработавших решений.
Баги появляются в процессе тестирования нового и ранее реализованного функционала.
Бага это ошибка, фича это новый функционал или доработка.
Добрый день, Денис. Спасибо за интересную статью. Возник вопрос, практикуется ли автоматизация тестирования силами разработчиков и если да, то насколько успешно? Всё-таки, написание юнит-тестов для разработчиков привычная практика.
Ещё можно использовать Selenium + Python без отчётов, паттернов и bdd. Тоже быстрее будет, но при частом изменении функционала поддержка займет много времени. Вариантов много выбор зависит от конкретных потребностей на проекте.
Думаю, что лучше разобраться почему «загрузка данных на странице в одних и тех же таблицах может занимать как 1 секунду так и 40 секунд». Если это нормальное поведение системы, то добавить ожидание в цикле и условие, которое проверит, что таблица полностью загрузилась и можно продолжить проверку.
2. Статус REOPEN существует. Если мы повторно открываем задачу или баг, то он помещается в колонку IN PROGRESS и разработчик после завершения текущей задачи, возвращается к задаче / ошибке со статусом REOPEN.
3. Для нашей команды мы вывели оптимальное количество задач от 4-х, конечно их может быть и больше. По суммарному времени проверок это не регламентируется. Если нужно выкатить одну задачу срочно — мы выкатываем одну задачу.
Изменяется продукт и другие процессы в проекте и процесс тестирования так же пересматривается. Если он изначально не описан или, что еще хуже, не доведен до команды — нечего улучшать, процесс будет выстраиваться каждый раз как с нуля, без учета ранее решенных проблем или опробованных и не сработавших решений.
Баги появляются в процессе тестирования нового и ранее реализованного функционала.
Бага это ошибка, фича это новый функционал или доработка.
Было интересно прочитать про историю развития стартапа)) спасибо за статью.
Понятно, спасибо :)
Да. Karate пока не использовала, посмотрю в его сторону. Спасибо:)
Спасибо, почитаю
Не совсем понятно зачем в автотестам использовать Threadlocal ?
Уже переходим на селенид:)
На момент написания статьи на нашем проекте их было 149, количество их меняется при увеличения/уменьшения основного функционала.
Ещё можно использовать Selenium + Python без отчётов, паттернов и bdd. Тоже быстрее будет, но при частом изменении функционала поддержка займет много времени. Вариантов много выбор зависит от конкретных потребностей на проекте.
Если нравится javaScript, то можно посмотреть в сторону Cypress. На поддержку может уходить много времени и поддерживает только chrome.