Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Четыре секрета управления тестированием
26.02.2016 11:06

Автор: Джастин Рорман (Justin Rohrman)

Оригинал статьи: http://blog.smartbear.com/automated-testing/managing-testing-workflow/

Перевод: Ольга Алифанова

Возьмем для примера типичный проект.

Новый код появляется по кусочкам - фронтэнд уже готов, но API, к которому он обращается, еще не установлен на тест-сервере. Попутно идет оптимизация производительности.

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

В тестировании программного обеспечения это норма жизни. Работа идет рывками, и зачастую непредсказуема.

Как управлять тестированием и поддерживать работоспособность ваших тестировщиков? Я расскажу о некоторых фишках, сработавших лично для меня.

 

1. Выйдите за пределы тест-кейсов.

Поначалу, когда разработка нового функционала только начиналась, тестировщики только и делали, что голосили на стэндапе - "даешь больше кейсов!"

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

Мы можем куда больше.

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

Тестировщики - это профи в области тест-дизайна, а уж если они занимаются этим больше года, и делают это с душой - они настоящие эксперты своего дела. Иногда это чистая интуиция - мы не можем объяснить, почему мы решили проверить именно эту комбинацию событий, просто наше чутье подсказало, что это было бы не лишним. Когда я общаюсь с разработчиком, я строчу вопросами как из пулемета. Откуда ты знаешь, каким будет значение на этом этапе? Что произойдет, если пользователь слишком быстро нажмет "Подтвердить"? Если этот код изменится, не сломает ли он что-то другое? Под конец я уношу с собой ряд идей для автотестов и надежду на улучшенную версию функции. Если сборка уже готова, я ныряю в нее с головой, но я никогда не сижу на руках.

Предвижу возражения - это слишком долго, мы успеем внедрить меньше функционала! Может быть, да. А может, и нет. Пусть вы успеете внедрить меньше функций, зато они будут лучше работать, если вы изначально тренируете разработчиков не забивать на качество продукта. Используя этот подход, я неоднократно завершал спринт с пятью отличными, готовыми к проду функциями, вместо обычного варианта "три готовы, четвертая сомнительна". Попробуйте хотя бы один раз, на одной функции, мучая одного человека, и посмотрите, как пойдет.

2. Устраняйте ненужные препятствия.

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

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

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

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

Но что же делать, если препятствия для тестирования - в головах?

3. Используйте "время простоя".

Слышать "мне нечего делать" так же приятно, как скрип железа по стеклу. Всегда есть область, где нужна помощь, где тестировщик может подключиться и нанести пользу. Тестировщики обычно копаются в ПО, но мы ведь можем гораздо больше! Вокруг нас столько людей, которым мы можем помочь, если нам "нечем заняться", так как нет нового кода:

· Менеджеры продукта. Они эксперты в переговорах с заказчиком, знают, как выяснять его потребности,