Четыре из пяти соискателей-QA хотят научиться работать с автотестами. Не все компании могут осуществить такие желания ручных тестировщиков в рабочее время. Wrike провёл школу автоматизации для сотрудников и реализовал это желание для многих. Я в этой школе участвовал именно как ученик-QA.
Я научился работе с Selenium и сейчас самостоятельно поддерживаю определённое количество автотестов практически без помощи извне. И, по итогам нашего совместного опыта и моих личных выводов, я постараюсь вывести ту самую формулу как можно более идеальной школы автоматизации.
Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).
Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.
Я работаю в команде Integration, задача которой — интеграция нашего сервиса во внешние продукты и интеграция внешних продуктов в наш сервис. Например, мы интегрировали таск-трекер Jira. Jira Cards — визуальное отображение задач, с которыми можно удобно работать на доске, не заходя в Jira.
Я бэкенд-разработчик в серверной команде Badoo. На прошлогодней конференции HighLoad я выступал с докладом, текстовым вариантом которого и хочу поделиться с вами. Этот пост будет наиболее полезен тем, кто самостоятельно пишет тесты для бэкенда и испытывает проблемы с тестированием legacy-кода, а также тем, кто хочет тестировать сложную бизнес-логику.
О чём пойдёт речь? Сначала я коротко расскажу о нашем процессе разработки и о том, как он влияет на нашу потребность в тестах и желание эти тесты писать. Затем мы пройдёмся снизу вверх по пирамиде автоматизации тестирования, обсудим используемые нами виды тестов, поговорим об инструментах внутри каждого из них и о том, какие проблемы мы решаем с их помощью. В конце рассмотрим, как поддерживать и запускать всё это добро.
Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?
Несколько месяцев назад я сама сменила работу и попала в английский проект, в котором никогда раньше не было QA. Сам проект существует давно. Как часто бывает, компания, в которой много денег, купила компанию, в которой денег поменьше, но есть клиенты. В итоге, крупная компания получила новых клиентов и минус одного конкурента на рынке. Мой проект получил смену менеджмента и принципов управления.
В первые же дни знакомства с новой командой, я услышала честный недоумевающий вопрос одного из разработчиков Лондонского офиса «А что ты будешь здесь делать?»
Большинство руководителей в IT-сфере выросли из технарей. Нам комфортнее работать с программами, чем с людьми, а слово “сервер” нам ближе и понятнее, чем слово “мотивация”. Чтобы решить эту проблему, биг-боссы компаний приглашают сторонних коучей и экспертов по мотивации, а IT-менеджеры пытаются ломать себя и следовать правилам с тренингов: хвалить, давать обратную связь, мотивировать и стимулировать. Такие натянутые действия тоже не приводят ни к чему хорошему!
Оказывается, люди мотивированы всегда, и их не надо пинать! Вопрос не в том, мотивированы они или нет, а в том, что мешает раскрытию их максимального потенциала.
В своём докладе Виктория расскажет о том, как решили эту задачу в Лаборатории качества, внедрив новую парадигму Менеджеров Счастья. В числе тех инструментов, которые помогли им, и которыми автор поделится с вами:
* анализ проблем, хотелок и пожелалок наших любимых сотрудников; * обучение линейных руководителей менеджменту счастья; * совместная проработка общих целей; * решение не поверхностных, а корневых проблем.
Не нужно создавать созданное, нужно научиться применять имеющееся. Все проще, чем кажется.
Вы когда-нибудь задумывались о том, что команде, которая что-то разрабатывает, тестировщик или разработчик автотестов на самом деле не нужен? Этой команде необходим человек, который будет совмещать свою роль с ролью тестировщика.
Давайте рассмотрим традиционное положение вещей.
Если у вас не agile, то у вас скорее всего есть:
-отдел разработки;
-отдел аналитиков;
-отдел тестирования
И все они могут одновременно работают над разными продуктами.
А если вы еще решили делать автоматизацию тестирования, то появляется еще отдел автоматизации тестирования. И для управления всем этим добром, как правило, нужен руководитель проектов (РП). А теперь внимание, что делать РП, у которой тестировщика нет? Или он ушел в отпуск, или заболел?
-Забивать на качество продукта?
-Ждать когда он вернется?
-И нести финансовые потери от несвоевременного запуска продукта или же наоборот, от того что продукт выпустили в «забагованном» состоянии.
Если же у вас agile, то проблемы остаются те же. Только тут, как правило 1 тестировщик и 1 разработчик автотестов на команду, как минимум.
И тут помимо озвученных вопросов, возникает еще вопрос:
-Что делать, если этих двух людей на один проект? Проект не генерирует такую нагрузку для двоих?
-Что делать, если разработчик автотестов отказывается заниматься функциональным тестрованием, если вы оставляете его одного в команде?
-Или же, если тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно?
В своем докладе автор расскажет о том, что такое кроссфункциональная команда. Расскажет, как на своем примере «затащили» роль тестировщика в каждого члена команды, а также от безвыходности и необходимости автоматизации тестирования научили разработчиков писать и помогать поддерживать автотесты тестировщикам.
Автор: Алан Ричардсон (Alan Richardson)