Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Служба поддержки. У них всегда полный рот хлопот. Иногда баг невозможно воспроизвести, иногда им не хватает информации о последнем релизе. Логи звонков и писем службы поддержки всегда были полезным подспорьем для меня. Я люблю искать закономерности в вопросах к поддержке - они направляют мои усилия по тестированию и придают значимости моим отчетам. Если уже пять человек не может разобраться в каком-то аспекте продукта - с шансами я найду баг в этой области.

· Документация. Я все реже к ней обращаюсь. По моим ощущениям, большинство компаний перешло на SaaS и решило, что пользователи разберутся сами. Если я работаю над большим десктопным приложением, документацию я тестирую так же тщательно, как софт. Работают ли новые функции так, как задумано? Верна ли инструкция по установке, рабочая ли она? В документации всегда найдется пара-тройка багов.

4. Думайте в долгосрочном ключе.

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

Если у вас, как я надеюсь, кросс-функциональная команда, следующий ваш шаг - сформировать культуру парного тестирования.

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

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

Я задавал ему кучу вопросов. Что будет, если я добавлю тут спецсимвол? Что будет, если я не заполню это поле? Затем мы сразу же пробовали проверить это на практике в среде разработчика.

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

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

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

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

Следующие несколько месяцев я создавал API-тесты, концентрируясь на областях, беспокоящих разработчиков. Я нашел приличное количество проблем, создавая свои тесты, и один за другим тесты добавлялись в стандартные проверки билда и голосили, если что-то шло не так. Раньше узнали о проблеме - раньше исправили ее.

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

Обсудить в форуме