Часики-то тикают! Как время диктует свои правила тестировщикам

Самая большая проблема, с которой сталкиваются 99% клиентов, — это время. Его постоянно не хватает, дедлайны горят, а когда сотрудники пытаются ускорить рабочие процессы, ситуация лишь обостряется до предела и появляются новые вопросы без ответов.

Чаще всего мы слышим от заказчиков:

    • задача появилась сегодня, а решить ее нужно было еще вчера,
    • прямо сейчас все специалисты заняты, а задача срочная,
    • только решишь одну задачу – появляется еще 10,
    • времени ни на что не хватает…

Поэтому наша команда сражается за каждую минуту клиента и предлагает комплексные долгосрочные решения, которые не просто «затыкают дыру» в данной конкретной ситуации, а решает вопрос раз и навсегда, экономя драгоценное время и деньги компании.

Проблема № 1. Хотели быстрее, а вышло как всегда


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

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

    • чётко обозначить разработчику дату релиза, чтобы он более продуктивно планировал своё рабочее время и мог дать обратную связь по задачам в срок;
    • дублировать информацию из личной переписки в задачу в формате коротких тезисов и главных договоренностей;
    • после завершения задачи указывать в комментариях, что она была протестирована, чтобы ее могли заливать на стенд конечного клиента.

Плюшки: кроме приятного отзыва от клиента, мы получаем в долгосрочной перспективе больший контроль над задачами, прозрачность работы в команде, стабильность и уверенность в качестве продукта перед конечным заказчиком.

Проблема № 2. Большие задачи для маленькой команды


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

Наше решение: мы инициировали внедрение автоматизации. С июня начались работы по написанию тест-кейсов в TestRail, а также их разработка на Java с использованием Selenide, Twin (от Google), Selenoid, TestNG, TestRail API, jdbc, cmd.

Уже в октябре мы получили первые 25 автоматизированных тестов, успешно запускающихся через CI Jenkins и включающихся в план быстрого теста, генерирующих Allure отчет по прохождению, а также устанавливающих автоматизировано статусы прохождения тестов в TestRail.


Наши тесты в данный момент умеют:

  • работать с личными сертификатами, выбирать любой установленный личный сертификат в IE;
  • выполнять SQL скрипты и получать из БД определенные данные;
  • работать с Twin (это позволяет нам работать с модальными системными окнами);
  • запускать наборы тестов в удобном порядке, который укажет тестировщик (по TestNG.xml);
  • работать с CMD;
  • работать с TestRail;
  • подготавливать все необходимые тестовые данные автоматизировано до запуска тестов;
  • работать с передаваемыми системными параметрами через Jenkins, через CMD или через сами тесты.

Кроме того, нами учтена возможность расширения тестов и изменения наборов, возможность будущей параллелизации и использования других браузеров.

Плюшки: уже сейчас существенно сократилось время на тестирование! А в будущем мы планируем полностью освободить команду от регулярного смоук-теста.

Заказчики очень довольны результатом и прогрессом! Но и мы сами довольны проделанной работой, ведь мы использовали TestRail API, реализовали нестандартный подход к автоматизации выбора сертификата и провели эксперименты со сборкой своего драйвера для браузеров на движке Chromium (для будущих тестов). Такой опыт и реализацию не найти в интернете.


Приятный бонус и большая ответственность! Один из наших сотрудников был выбран для проведения аудитов ЧТЗ после их подготовки аналитиками. Сейчас он занимается такими задачами, как составлением тестовых наборов, чек-листов; оценкой времени на тестирование; проверкой написанных требований и помощью в их улучшении.

Проблема № 3. Быстро или качественно? Вот в чем вопрос.


Ситуация: вы, наверняка, видели схему рабочего процесса, описанную в трех параметрах «Быстро», «Качественно» и «Дорого», где всегда необходимо сделать выбор в пользу двух составляющих и пожертвовать третьей. Опустим вопрос стоимости и поговорим о том, как сделать быстро и качественно? Как в ситуации с нашими клиентами, у которых была проблема с качеством заведения дефектов.

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

    • добавить дополнительные обязательные поля для заполнения;
    • добавить прямые ссылки на страницу с дефектом в системе;
    • использовать только хранилище БТС для скриншотов;
    • указывать версию системы при валидации.

Плюшки: сразу после внедрения дополнительных условий увеличилась скорость исправления дефектов. Мы смогли улучшить понятность заведённых дефектов для разработчиков и повысили удобство при валидации.

Чтобы оставаться на месте, нужно бежать как можно быстрее

Если вы тоже сталкиваетесь с похожими проблемами в своей работе, то ловите несколько инсайтов этого месяца, которые могут вам пригодиться в будущем:

1. Мыслите масштабно! Задайте себе вопросы: как часто я решаю подобные задачи? Срочность такой задачи действительно разовая или возникает периодически? Что я могу сделать, чтобы в следующий раз, на будущей неделе, через месяц или полгода не столкнуться снова с этой проблемой? Так вы сможете решать вопросы глобально и не зацикливаться на мелочах.
2. Будьте стратегами! Постарайтесь на основе прошлого опыта или обсуждения с коллегами, выяснить, сколько времени вам понадобится на решение определенной задачи. В первый раз заложите чуть больше времени на ее реализацию. Планируйте своё время и управляйте им, а не идите на поводу у дедлайнов. Это поможет вам избежать многих ошибок.
3. Работайте в команде! Сделайте процесс вашей работы понятным и прозрачным для коллег. Пусть они знают о статусах текущих задач, чтобы продуктивно отрабатывать их в своей зоне ответственности, а не дергать вас вопросами из разряда «А когда будет готово?», «Уже готово?», «А сейчас?». Благодаря этому вы не только наладите рабочий процесс, но и прокачаете свои отношения с коллективом.

На сегодня — все!
До встречи в блоге «Лаборатории качества».

Об авторе

Редакция сайта

Поиск
Облако меток
8 марта (1)api (5)Game of testers (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (1)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (1)Опрос (1)ПОИНТ (2)Приёмочное тестирование (1)РИТ (1)Юмор (2)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (2)баги (4)банковские приложения (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (2)ежемесячный отчет (13)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (20)лайф-хаки (3)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (10)обучение (7)оптимизация тестирования (13)оффлайн тренинги (1)поздравление (1)поздравления (6)пользовательские истории (1)пример (1)проблемы (2)проектные риски (1)проекты (4)процесс тестирования (25)развитие команды (5)разработчики (1)распределенная команда (3)решения (2)ритейл-приложения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (46)тестирование безопасности (3)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (4)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (3)
Получите совет