Комментарии 30
Наконец-то объяснено, зачем и в каком виде нужно тестирование в быстро развивающихся проектах.
Должны ли тестировщики уметь программировать? Ваши умеют? Проводите ли вы какие-нибудь курсы для них?
Я думаю, что вопрос однозначного ответа не имеет. Все зависит от.
С одной стороны я рассматриваю опыт и умение программировать как большой плюс. Лично мне, к примеру (а я в прошлом — программист), очень сильно помогает чтение изменений в коде перед тестированием. Таким образом мне легче определить уязвимые места и варианты проверок.
С другой стороны, у меня есть ребята, которые программировать не хотят/не умеют и при этом отлично справляются с поиском багов. Во многих случаях даже лучше меня (что скрывать, я не самый идеальный тестировщик).
По поводу курсов — мы даем возможность нашим сотрудникам посещать любые курсы в пределах определенного бюджета, с определенной периодичностью. Какие именно это курсы должен определить сам сотрудник, а его менеджер должен подтвердить необходимость. И да, некоторые сотрудники из QA посещали курсы по программированию в том числе.
С одной стороны я рассматриваю опыт и умение программировать как большой плюс. Лично мне, к примеру (а я в прошлом — программист), очень сильно помогает чтение изменений в коде перед тестированием. Таким образом мне легче определить уязвимые места и варианты проверок.
С другой стороны, у меня есть ребята, которые программировать не хотят/не умеют и при этом отлично справляются с поиском багов. Во многих случаях даже лучше меня (что скрывать, я не самый идеальный тестировщик).
По поводу курсов — мы даем возможность нашим сотрудникам посещать любые курсы в пределах определенного бюджета, с определенной периодичностью. Какие именно это курсы должен определить сам сотрудник, а его менеджер должен подтвердить необходимость. И да, некоторые сотрудники из QA посещали курсы по программированию в том числе.
Спасибо за хорошую, складную и легко читаемую статью!
Подписался. С нетерпением жду следующие публикации.
Подписался. С нетерпением жду следующие публикации.
Жесть-жестянская, извините. Это я не сдержался про ваш процесс разработки фич.
В прошлы статьях вы описывали у себя такую команду Альфа — крутых парней, которые пишут на Си и Go ваш HighLoad. Скажите, пожалуйста, эти программисты тоже удостоились — вот этого https://hsto.org/web/443/46a/db2/44346adb245d4d3992a99cd9105da895.png?
Или там всё, как у номральных — постановка, программирование, код ревью, релиз? Без всяких общенйи с продактами, без вот этой всей бюрократии и разговоров, можно просто взять и начать работать, борясь за RPS и производительность системы?
В прошлы статьях вы описывали у себя такую команду Альфа — крутых парней, которые пишут на Си и Go ваш HighLoad. Скажите, пожалуйста, эти программисты тоже удостоились — вот этого https://hsto.org/web/443/46a/db2/44346adb245d4d3992a99cd9105da895.png?
Или там всё, как у номральных — постановка, программирование, код ревью, релиз? Без всяких общенйи с продактами, без вот этой всей бюрократии и разговоров, можно просто взять и начать работать, борясь за RPS и производительность системы?
Привет, Денис, спасибо за ваше мнение.
Прежде всего, справедливости ради, я бы хотел отметить что крутые ребята у нас работают не только в A-team (платформа). Badoo — это команда очень хороших профессионалов в разных сферах, с высокой инженерной культурой.
А отвечая на ваш вопрос, я бы рекомендовал заглянуть вот в эту нашу статью. В ней Константин Карпов рассказывает как раз про процесс разработки и тестирования в платформе при производстве демонов.
Еще много различной информации про работу наших замечательных ребят из A-team можно найти вот в этой статье.
Удачи!
Прежде всего, справедливости ради, я бы хотел отметить что крутые ребята у нас работают не только в A-team (платформа). Badoo — это команда очень хороших профессионалов в разных сферах, с высокой инженерной культурой.
А отвечая на ваш вопрос, я бы рекомендовал заглянуть вот в эту нашу статью. В ней Константин Карпов рассказывает как раз про процесс разработки и тестирования в платформе при производстве демонов.
Еще много различной информации про работу наших замечательных ребят из A-team можно найти вот в этой статье.
Удачи!
Я представитель команды что пишет на Go и на Си.
PRD до нас доходит редко. Нам чаще всего ставят задачи уже эти вот самые проджект менеджеры, описанные в статье uyga. Это связано с тем, что наш результат не является тем, что видит пользователь. Наш результат используется другими программистами, чтобы сделать то, что видит пользователь.
Но с продактами общаться нам тоже приходится. В основном когда изменение связано с какими-то внутренними вещами, алгоритмами, поведением, которое не требует изменения со стороны «клиента».
Не вижу в этом ничего плохого. Мы же делаем продукт все вместе, а не сидим и слепо пишем код по разжеванному описанию.
PRD до нас доходит редко. Нам чаще всего ставят задачи уже эти вот самые проджект менеджеры, описанные в статье uyga. Это связано с тем, что наш результат не является тем, что видит пользователь. Наш результат используется другими программистами, чтобы сделать то, что видит пользователь.
Но с продактами общаться нам тоже приходится. В основном когда изменение связано с какими-то внутренними вещами, алгоритмами, поведением, которое не требует изменения со стороны «клиента».
Не вижу в этом ничего плохого. Мы же делаем продукт все вместе, а не сидим и слепо пишем код по разжеванному описанию.
Спасибо за отличную статью! Используем похожую схему цикла разработки, но аналог Product Visual QA проводим только для действительно крупных и важных фич, причем смотрит вся команда(тестеры+ разработка+аналитик. благо нас мало и это не так дорого, как могло показаться) — помимо просмотра позитивных сценариев такие мероприятия выполняют роль обмена знаниями о фичах внутри команды. Ну и принцип «1 голова хорошо, а несколько лучше» тоже часто срабатывает в плане полезных идей и замечаний от участников просмотра.
Спасибо, увлекательно
Интересуют следующие вопросы:
1. Есть ли какая-то договоренность к какому моменту у вас должны быть написаны чек-листы по новой фиче?
2. На основе чего и как строится процесс адаптации нового человека в команду тестирования?
Интересуют следующие вопросы:
1. Есть ли какая-то договоренность к какому моменту у вас должны быть написаны чек-листы по новой фиче?
2. На основе чего и как строится процесс адаптации нового человека в команду тестирования?
Спасибо за отзыв.
Отвечаю на вопросы по пунктам:
1) Договоренности и формального срока нет. Очень многое зависит от функционала конкретных фич. В каких-то случаях он интуитивно понятен и без напоминалок, в каких-то случаях, чувствуя необходимость, люди начинают создавать чек-листы. Кроме того, учитывая огромное количество экспериментов, в некоторых ситуациях легче подождать «стабилизации» фичи. Для автоматизации — уж точно.
В этом и прелесть Exploratory testing — полный фристайл, минимум формализма.
2) Тут все очевидно — сначала нового человека необходимо познакомить с заведенными правилами команд, с системой, которую ему придется тестировать, с технологиями, инструментами и т.д. Для этого у нас во многих командах есть специальные странички в wiki, в которых описано как у нас происходит тот или иной процесс, из чего состоят те или иные компоненты системы. Информации очень много и мы не ожидаем того что человек сразу все это запомнит. Основная цель тут — показать где искать в случае чего. Обычно первый день нового сотрудника занят чтением этой информации и подготовкой рабочей среды.
Кроме того обычно либо сам менеджер, либо кто-то из команды, берет такого новичка «на поруки». Он выступает первой точкой контакта в случае возникновения вопросов, объясняет и показывает, ставит задачи. Это очень важный процесс, призванный установить доверительные отношения с новым сотрудником. На этом базируется все дальнейшее сотрудничество и карьерный путь новичка в компании.
Задачи для новичка сначала ставятся простые, для знакомства с системой, затем все сложнее и сложнее.
В то же время мы ожидаем максимальной самостоятельности от присоединившегося к нам человека. Долго нянчится и «водить за ручку» его никто не будет — своей работы полно. И в большинстве случаев готовность человека самостоятельно выполнять задачи является важным критерием прохождения испытательного срока.
Отвечаю на вопросы по пунктам:
1) Договоренности и формального срока нет. Очень многое зависит от функционала конкретных фич. В каких-то случаях он интуитивно понятен и без напоминалок, в каких-то случаях, чувствуя необходимость, люди начинают создавать чек-листы. Кроме того, учитывая огромное количество экспериментов, в некоторых ситуациях легче подождать «стабилизации» фичи. Для автоматизации — уж точно.
В этом и прелесть Exploratory testing — полный фристайл, минимум формализма.
2) Тут все очевидно — сначала нового человека необходимо познакомить с заведенными правилами команд, с системой, которую ему придется тестировать, с технологиями, инструментами и т.д. Для этого у нас во многих командах есть специальные странички в wiki, в которых описано как у нас происходит тот или иной процесс, из чего состоят те или иные компоненты системы. Информации очень много и мы не ожидаем того что человек сразу все это запомнит. Основная цель тут — показать где искать в случае чего. Обычно первый день нового сотрудника занят чтением этой информации и подготовкой рабочей среды.
Кроме того обычно либо сам менеджер, либо кто-то из команды, берет такого новичка «на поруки». Он выступает первой точкой контакта в случае возникновения вопросов, объясняет и показывает, ставит задачи. Это очень важный процесс, призванный установить доверительные отношения с новым сотрудником. На этом базируется все дальнейшее сотрудничество и карьерный путь новичка в компании.
Задачи для новичка сначала ставятся простые, для знакомства с системой, затем все сложнее и сложнее.
В то же время мы ожидаем максимальной самостоятельности от присоединившегося к нам человека. Долго нянчится и «водить за ручку» его никто не будет — своей работы полно. И в большинстве случаев готовность человека самостоятельно выполнять задачи является важным критерием прохождения испытательного срока.
Смотрел как-то доклад, где как раз рассказывали про разработку без тестирования и бюджет, но забыл что за компания :) Подскажите?
Очень интересно и познавательно! Спасибо
Должны ли тестировщики уметь программировать?
Моё мнение, что какими-то базовыми знаниями качественный тестировщик должен обладать. Иногда разработчик может не заметить банальной ошибки(например, сравнение строк через "==" или неправильное наименование поля "adress" вместо "address"). И чтобы не переоткрывать задачу, можно самостоятельно пофиксить.
В нашей компании компании, к сожалению, придерживаются политики, что только разработчик должен тестить своё творение
На сколько в реальности формализован процесс работы над задачей? Описан он довольно формально, но на сколько формально ему следуют. Например, для Visual QA можно просто рукой позвать ответственного или нужно менять состояние задачи и переводить её на другого человека?
Это зависит от стадии. Если для разработки и QA в нашей джире есть отдельные статусы и надо менять состояние задачи, то для Visual QA такого статуса нет.
Я бы сказал так: мы руководствуемся здравым смыслом и пытаемся избежать лишней бюрократии по-максимуму. Если мы видим, что какой-то шаг в процессе требует более пристального внимания/напоминания, то в этом случае мы можем применить более формальный подход. Так появился чек-лист для разработчика перед резолвом задачи, например. И сейчас это прям отдельный экран в трекере, куда надо руками проставить чекбоксы, чтобы кнопка «Готово» стала доступной.
Я бы сказал так: мы руководствуемся здравым смыслом и пытаемся избежать лишней бюрократии по-максимуму. Если мы видим, что какой-то шаг в процессе требует более пристального внимания/напоминания, то в этом случае мы можем применить более формальный подход. Так появился чек-лист для разработчика перед резолвом задачи, например. И сейчас это прям отдельный экран в трекере, куда надо руками проставить чекбоксы, чтобы кнопка «Готово» стала доступной.
Интересуют пара моментов в описанном процессе разработки.
Предположим перед командой ставится задача реализовать фичу, для обычного пользователя приложения на андроид. После всех декомпозиций, стало понятно, что вся фича разбивается на десять отдельных задач и оценивается в человеко-месяц, из которых две первые недели будут потрачены на рефакторинг существующего кода, еще неделя на разнообразные бэеграундные активности и последняя неделя непосредственный дизайн и взаимодействия.
Вопрос: как в таком случае строится разработка всего этого, если заказчика интересует непосредственная реализация фичи, т.е. там где он может ее пощупать и проверить, а первые три недели работы, фактически, не предполагают такого фидбека, поскольку с точки зрения пользователя ровным счетом ничего не меняется?
Если заказчик ждет до конца четвертой недели, то неужели, все эти задачи висят в статусе ожидания ревью и их никто не смотрит и не тестирует? И это при том, что фичу могут разрабатывать несколько людей одновременно и им, например, было бы неплохо договориться о ревью на начальном этапе, чтобы не пришлось переписывать в конце из-за того, что один человек решил назвать переменные так, а другой эдак (ну я сейчас очень утрирую, конечно).
— Второй вопрос: как происходит процесс, если в результате разработки или тестирования неожиданно вскрываются какие-то зависимости на внешние вещи, о которых не подумали до этого?
Предположим перед командой ставится задача реализовать фичу, для обычного пользователя приложения на андроид. После всех декомпозиций, стало понятно, что вся фича разбивается на десять отдельных задач и оценивается в человеко-месяц, из которых две первые недели будут потрачены на рефакторинг существующего кода, еще неделя на разнообразные бэеграундные активности и последняя неделя непосредственный дизайн и взаимодействия.
Вопрос: как в таком случае строится разработка всего этого, если заказчика интересует непосредственная реализация фичи, т.е. там где он может ее пощупать и проверить, а первые три недели работы, фактически, не предполагают такого фидбека, поскольку с точки зрения пользователя ровным счетом ничего не меняется?
Если заказчик ждет до конца четвертой недели, то неужели, все эти задачи висят в статусе ожидания ревью и их никто не смотрит и не тестирует? И это при том, что фичу могут разрабатывать несколько людей одновременно и им, например, было бы неплохо договориться о ревью на начальном этапе, чтобы не пришлось переписывать в конце из-за того, что один человек решил назвать переменные так, а другой эдак (ну я сейчас очень утрирую, конечно).
— Второй вопрос: как происходит процесс, если в результате разработки или тестирования неожиданно вскрываются какие-то зависимости на внешние вещи, о которых не подумали до этого?
Спасибо за вопросы.
1) Вы правы, обычно рефакторинг заказчика не интересует. Это нормально, он мыслит только бизнес-категориями, проблемы технического долга в его мире не существуют и не должны существовать. Как быть в каждом конкретном случае — это задача непосредственного технического лида разработки в команде.
В каких-то случаях стоит делать по-максимуму быстро, с костылями и велосипедами, в ущерб «красоте» кода и архитектуры, имея в виду что в будущем возникающий технический долг придется исправлять. В других случаях следует сначала избавиться от тех долга, лишь затем приступить непосредственно к написанию нового функционала. Еще ряд случаев может предполагать параллельную работу над рефакторингом и новыми фичами несколькими разработчиками сразу. Все индивидуально и сильно зависит от конкретных условий. Главный принцип тут — прагматизм. Как сделать максимально выгодно и пользователям и с точки зрения технологий.
Я бы сказал, что помимо людей и их проблем, эта задача — одна из основных для лида разработки.
Как именно разделять задачи правильно — это нетривиальная проблема, с которой справляется не каждый. Я сейчас готовлю отдельную статью про это.
2) Опять же, прежде всего — прагматизм. Гладко бывает только на бумаге и в сказках, в жизни регулярно возникающие неожиданности — это норма. Не подумали, не учли, не заметили, пропустили: так случается. Как быть в этом случае зависит от того, что именно явилось проблемой. Иногда чтобы их решить, приходится жертвовать личным временем; искать компромисс с заказчиком и выпускать задачу как есть, если она позволяет «прощупать» концепт итак; иногда бывает так что приходится начинать все сначала.
Главное помнить принцип — столкнулись с проблемой, значит надо решить как такую проблему (а идеально — и тип подобных проблем) избежать в будущем. Не искать виноватого, а конструктивно, надежно попытаться закрыть вопрос раз и навсегда. Тогда (не сразу) мы будем улучшать и улучшать инженерную культуру и будем воспитывать себя и своих коллег, обеспечивая развитие свое и своей компании.
1) Вы правы, обычно рефакторинг заказчика не интересует. Это нормально, он мыслит только бизнес-категориями, проблемы технического долга в его мире не существуют и не должны существовать. Как быть в каждом конкретном случае — это задача непосредственного технического лида разработки в команде.
В каких-то случаях стоит делать по-максимуму быстро, с костылями и велосипедами, в ущерб «красоте» кода и архитектуры, имея в виду что в будущем возникающий технический долг придется исправлять. В других случаях следует сначала избавиться от тех долга, лишь затем приступить непосредственно к написанию нового функционала. Еще ряд случаев может предполагать параллельную работу над рефакторингом и новыми фичами несколькими разработчиками сразу. Все индивидуально и сильно зависит от конкретных условий. Главный принцип тут — прагматизм. Как сделать максимально выгодно и пользователям и с точки зрения технологий.
Я бы сказал, что помимо людей и их проблем, эта задача — одна из основных для лида разработки.
Как именно разделять задачи правильно — это нетривиальная проблема, с которой справляется не каждый. Я сейчас готовлю отдельную статью про это.
2) Опять же, прежде всего — прагматизм. Гладко бывает только на бумаге и в сказках, в жизни регулярно возникающие неожиданности — это норма. Не подумали, не учли, не заметили, пропустили: так случается. Как быть в этом случае зависит от того, что именно явилось проблемой. Иногда чтобы их решить, приходится жертвовать личным временем; искать компромисс с заказчиком и выпускать задачу как есть, если она позволяет «прощупать» концепт итак; иногда бывает так что приходится начинать все сначала.
Главное помнить принцип — столкнулись с проблемой, значит надо решить как такую проблему (а идеально — и тип подобных проблем) избежать в будущем. Не искать виноватого, а конструктивно, надежно попытаться закрыть вопрос раз и навсегда. Тогда (не сразу) мы будем улучшать и улучшать инженерную культуру и будем воспитывать себя и своих коллег, обеспечивая развитие свое и своей компании.
1) Мне кажется, вы не поняли вопрос. Я спрашиваю, что если разбиение такое, как я описал, то задачи висят не отревьювленые и не оттестированные до тех пор пока не будет сделана задача, результат которой удовлетворяет заказчика?
2) Из вашего ответа, я так понимаю, никакого процесса, хотя бы общего, для таких случаев не предусмотрено? Т.е. все подобные случаи разбираются индивидуально?
3) Еще вопрос: какой у вас процесс работы с багами? Имеется ввиду, не баги в новых разрабатываемых фичах, а в тех фичах, которые уже вышли. Которые пропустили или они вскрылись только с изменением окружения, например, на новых версиях оси. Одним словом, не привязанные к задачам заказчика. Кто в таком случае заказчик и как схема, описанная вами, работает в этом случае?
2) Из вашего ответа, я так понимаю, никакого процесса, хотя бы общего, для таких случаев не предусмотрено? Т.е. все подобные случаи разбираются индивидуально?
3) Еще вопрос: какой у вас процесс работы с багами? Имеется ввиду, не баги в новых разрабатываемых фичах, а в тех фичах, которые уже вышли. Которые пропустили или они вскрылись только с изменением окружения, например, на новых версиях оси. Одним словом, не привязанные к задачам заказчика. Кто в таком случае заказчик и как схема, описанная вами, работает в этом случае?
1) Нет, задачи висеть в промежуточных статусах не будут. Задачи должны быть декомпозированы так, чтобы иметь возможность пройти по всем стадиям независимо. В том числе, быть выложенными на продакшен.
2) Не предусмотрено и не может быть предусмотрено, потому что задачи разные. Разные размеры и функционал новых фич стимулируют индивидуальный подход. Общая канва исходит из самого принципа разделения задач на кусочки — кусочки должны быть логически законченными и уметь выкладываться независимо. И вот эти кусочки уже идут по конвейеру дальше, подчиняясь общим правилам, не зависящим от типа изменений.
3) Работа с багами и другими задачами (например тех-долг), не отличается от новых фич в той части, когда они идут по конвейеру. Заказчик в этом случае для них внутренний — либо сами девелоперы, либо тестировщики, либо технический руководитель. В остальном принцип такой же — либо разбили на кусочки, если задача большая, либо одна задача — самостоятельный кусочек, который идет все по тому же флоу. Разумеется, Visual QA в этом случае может не быть, но так же очевидно что если бага касается изменения функционала или предполагает неочевидное, неучтенное ранее поведение фичи, то может потребоваться разговор с продакт-менеджером, который владеет фичей.
2) Не предусмотрено и не может быть предусмотрено, потому что задачи разные. Разные размеры и функционал новых фич стимулируют индивидуальный подход. Общая канва исходит из самого принципа разделения задач на кусочки — кусочки должны быть логически законченными и уметь выкладываться независимо. И вот эти кусочки уже идут по конвейеру дальше, подчиняясь общим правилам, не зависящим от типа изменений.
3) Работа с багами и другими задачами (например тех-долг), не отличается от новых фич в той части, когда они идут по конвейеру. Заказчик в этом случае для них внутренний — либо сами девелоперы, либо тестировщики, либо технический руководитель. В остальном принцип такой же — либо разбили на кусочки, если задача большая, либо одна задача — самостоятельный кусочек, который идет все по тому же флоу. Разумеется, Visual QA в этом случае может не быть, но так же очевидно что если бага касается изменения функционала или предполагает неочевидное, неучтенное ранее поведение фичи, то может потребоваться разговор с продакт-менеджером, который владеет фичей.
Спасибо за ваши ответы.
Касательно второго пункта, на мой взгляд, утверждать, что все проблемы индивидуальные и невозможно придумать к ним никакого общего подхода — это достаточно спорно и означает не заниматься риск-менеджментом. Но, тут, конечно, стоит исходить из необходимости, если и так все работает, а стоимость возможных проблем не такая большая, по сравнению с разработкой и внедрения плана действий, то, вероятно, тратить на это время не стоит.
Касательно второго пункта, на мой взгляд, утверждать, что все проблемы индивидуальные и невозможно придумать к ним никакого общего подхода — это достаточно спорно и означает не заниматься риск-менеджментом. Но, тут, конечно, стоит исходить из необходимости, если и так все работает, а стоимость возможных проблем не такая большая, по сравнению с разработкой и внедрения плана действий, то, вероятно, тратить на это время не стоит.
А какие проблемы тут возможны, где риск? Как вы решаете это в своей компании?
У вас, как я понимаю, все упирается в людей, в их опыт и настойчивость. Т.е. пока люди хороши в своем деле — все отлично. Процессы в данном случае, служат страховкой от каких-либо проблем, которые связаны с людскими взаимодействиями: ссоры, забывчивость, забивательство на обязательства и т.д. и т.п.
У нас это никак не решается, поэтому мне было интересно узнать как это сделано у вас.
У нас это никак не решается, поэтому мне было интересно узнать как это сделано у вас.
Спасибо за статью.
Интересно услышать ответы на несколько вопросов по процессам:
1. Есть ли у вас правило, что тестировщик закреплен за задачей на всем жизненном цикле или после повторных переоткрытий взять в тестирование задачу может любой другой тестировщик?
2. В описанном процессе тестировщик занимается только ручным тестированием, написание, например, функциональных тестов в рамках проверки задачи не предусматривается?
3. У вас есть отдельная команда, которая занимается только написанием интеграционных тестов и другой автоматизацией?
4. Как у вас обстоят дела с нагрузочным тестированием, есть ли у вас такой тип тестирования и если да, то на каком этапе и кем оно выполняется?
5. Ресурс тестировщиков у вас общий или конкретные тестировщики закреплены за профильными командами?
Интересно услышать ответы на несколько вопросов по процессам:
1. Есть ли у вас правило, что тестировщик закреплен за задачей на всем жизненном цикле или после повторных переоткрытий взять в тестирование задачу может любой другой тестировщик?
2. В описанном процессе тестировщик занимается только ручным тестированием, написание, например, функциональных тестов в рамках проверки задачи не предусматривается?
3. У вас есть отдельная команда, которая занимается только написанием интеграционных тестов и другой автоматизацией?
4. Как у вас обстоят дела с нагрузочным тестированием, есть ли у вас такой тип тестирования и если да, то на каком этапе и кем оно выполняется?
5. Ресурс тестировщиков у вас общий или конкретные тестировщики закреплены за профильными командами?
Спасибо за отзыв. Отвечаю по пунктам:
1) Правила нет. Более того, мы пропагандируем полный шаринг знаний и взаимозаменяемость. Это позволяет избежать бас-фактора. В то же время, часто для оптимальной работы зачастую на повторных этапах назначается тот же самый человек, что был вначале. Так попросту быстрее. Мы оставляем этот вопрос за каждым лидом конкретной команды тестирования и прямо запрещаем разработчикам назначать задачу на того же тестировщика после доработки.
2) Это зависит от команды. В desktop web, где мы в этом плане продвинулись максимально далеко (ибо начали раньше остальных), тестировщики делают как ручное тестирование, так и пишут автотесты высокого уровня. В других командах мы идем к тому же, для сравнения — в iOS команде мы недавно обязали ручных тестировщиков проверять результаты автоматизации и разбираться с падениями тестов. Затем планируем стимулировать самостоятельное исправление падений, а потом доберемся и до написания новых.
3) Есть. Несмотря на то, что тесты так или иначе пишут (или скоро будут) все, у нас есть выделенные люди, которые занимаются фреймворком, окружением, вырабатывают правила и методологии для остальных. Количество таких людей и их соотношение к ручным тестировщикам разное в разных командах.
4) Нагрузочного тестирования у нас нет. Вместо этого мы занимаемся планированием нагрузки, базируясь на текущих показателях перформанса на серверах, полученных от мониторинга. Плюс — плавная раскладка. В то же время для некоторых критичных демонов мы несколько раз нагрузку проверяли. Особой пользы от этого процесса не получили.
5) Команды тестирования разделены так же как и команды разработки. Есть разработчики, которые пишут серверную часть, биллинг, мобильные клиенты для iOS и Android и т.д. Каждая такая команда имеет свой выделенный пул тестировщиков. Между командами иногда происходит ротация для обмена знаниями, либо помощи коллегам в случае авралов.
Надеюсь, понял вопросы правильно.
1) Правила нет. Более того, мы пропагандируем полный шаринг знаний и взаимозаменяемость. Это позволяет избежать бас-фактора. В то же время, часто для оптимальной работы зачастую на повторных этапах назначается тот же самый человек, что был вначале. Так попросту быстрее. Мы оставляем этот вопрос за каждым лидом конкретной команды тестирования и прямо запрещаем разработчикам назначать задачу на того же тестировщика после доработки.
2) Это зависит от команды. В desktop web, где мы в этом плане продвинулись максимально далеко (ибо начали раньше остальных), тестировщики делают как ручное тестирование, так и пишут автотесты высокого уровня. В других командах мы идем к тому же, для сравнения — в iOS команде мы недавно обязали ручных тестировщиков проверять результаты автоматизации и разбираться с падениями тестов. Затем планируем стимулировать самостоятельное исправление падений, а потом доберемся и до написания новых.
3) Есть. Несмотря на то, что тесты так или иначе пишут (или скоро будут) все, у нас есть выделенные люди, которые занимаются фреймворком, окружением, вырабатывают правила и методологии для остальных. Количество таких людей и их соотношение к ручным тестировщикам разное в разных командах.
4) Нагрузочного тестирования у нас нет. Вместо этого мы занимаемся планированием нагрузки, базируясь на текущих показателях перформанса на серверах, полученных от мониторинга. Плюс — плавная раскладка. В то же время для некоторых критичных демонов мы несколько раз нагрузку проверяли. Особой пользы от этого процесса не получили.
5) Команды тестирования разделены так же как и команды разработки. Есть разработчики, которые пишут серверную часть, биллинг, мобильные клиенты для iOS и Android и т.д. Каждая такая команда имеет свой выделенный пул тестировщиков. Между командами иногда происходит ротация для обмена знаниями, либо помощи коллегам в случае авралов.
Надеюсь, понял вопросы правильно.
По второму вопросу. Вы считаете, что ручным тестировщикам заниматься автоматизацией — это благо? Я слышал очень много мнений и сам придерживаюсь противоположного мнения, однако, было бы интересно услышать вашу аргументацию.
Как я уже писал выше, отвечая на вопрос про то, должны ли тестировщики уметь программировать — однозначного ответа у меня нет.
С точки зрения эффективности удобнее, когда человек, тестируя ветку задачи, так же покроет ее автотестом. Чтобы на последующих стадиях проверки все той же задачи, все ручные проверки не повторять еще раз. Ведь это лишнее время и мы стремимся к оптимизации параметра β. И каждый раз повторять одни и те же проверки в Exploratory testing, для одной и той же задачи — это утомительно. Человек устает, глаз замыливается, начинают влиять масса факторов чисто человеческой природы.
С другой стороны, автоматизация во время первого сеанса тестирования не всегда достижима и в моей практике в том числе встречаются ребята, которым вообще не интересно заниматься автоматизацией и они только демотивируются и начинают делать работу хуже. Обратные примеры так же имеются — есть ребята, которые замечательно тестируют руками, но считают автоматизацию единственно возможным путем дальнейшего развития.
Более того, в нашем жизненном цикле задач, даже выкладка на продакшен не всегда означает завершение работы над фичей. Ведь мы ее после этого обкатываем, дорабатываем, улучшаем, делаем А/Б тесты и даже поведение фичи может поменяться впоследствии. Часто это происходит так быстро, что автоматизировать тест для каждого чиха становится непомерно дорогим удовольствием. Поэтому мы автоматизацию некоторых фич откладываем до завершения периода ее стабилизации. Тестируем руками и ставим отдельный тикет на автоматизацию, приступаем к которому через некоторое время после завершения работы над фичей.
Я бы сказал так: мы даем возможность и дальше смотрим. Я описывал пример desktop web команды, где тестировщики делают и то и то. Так вот в ней тоже есть исключения, есть люди, которые не проявляют интереса к автоматизации.
Соответственно, мы стимулируем чтобы имеющиеся тесты 1) использовали 2) фиксили 3) улучшали все в команде. А написание новых тестов для новых фич и уж тем более, развитие фреймворков, окружения, подходов и практик автоматизации — дело добровольное.
С точки зрения эффективности удобнее, когда человек, тестируя ветку задачи, так же покроет ее автотестом. Чтобы на последующих стадиях проверки все той же задачи, все ручные проверки не повторять еще раз. Ведь это лишнее время и мы стремимся к оптимизации параметра β. И каждый раз повторять одни и те же проверки в Exploratory testing, для одной и той же задачи — это утомительно. Человек устает, глаз замыливается, начинают влиять масса факторов чисто человеческой природы.
С другой стороны, автоматизация во время первого сеанса тестирования не всегда достижима и в моей практике в том числе встречаются ребята, которым вообще не интересно заниматься автоматизацией и они только демотивируются и начинают делать работу хуже. Обратные примеры так же имеются — есть ребята, которые замечательно тестируют руками, но считают автоматизацию единственно возможным путем дальнейшего развития.
Более того, в нашем жизненном цикле задач, даже выкладка на продакшен не всегда означает завершение работы над фичей. Ведь мы ее после этого обкатываем, дорабатываем, улучшаем, делаем А/Б тесты и даже поведение фичи может поменяться впоследствии. Часто это происходит так быстро, что автоматизировать тест для каждого чиха становится непомерно дорогим удовольствием. Поэтому мы автоматизацию некоторых фич откладываем до завершения периода ее стабилизации. Тестируем руками и ставим отдельный тикет на автоматизацию, приступаем к которому через некоторое время после завершения работы над фичей.
Я бы сказал так: мы даем возможность и дальше смотрим. Я описывал пример desktop web команды, где тестировщики делают и то и то. Так вот в ней тоже есть исключения, есть люди, которые не проявляют интереса к автоматизации.
Соответственно, мы стимулируем чтобы имеющиеся тесты 1) использовали 2) фиксили 3) улучшали все в команде. А написание новых тестов для новых фич и уж тем более, развитие фреймворков, окружения, подходов и практик автоматизации — дело добровольное.
Спасибо за развернутый ответ.
Если у вас будет время и/или желание, я бы почитал про то как вы настроили автотестирование ios. Особенно если у вас много тестов (больше сотни) и вы выполняете их не на живых девайсах.
Ждем xcode новый, там, вроде как обещали распараллеливание симуляторов нативное, но сейчас ничего, похоже, кроме bluepill и нет. Да и тот работает криво косо, увы
Если у вас будет время и/или желание, я бы почитал про то как вы настроили автотестирование ios. Особенно если у вас много тестов (больше сотни) и вы выполняете их не на живых девайсах.
Ждем xcode новый, там, вроде как обещали распараллеливание симуляторов нативное, но сейчас ничего, похоже, кроме bluepill и нет. Да и тот работает криво косо, увы
У нас есть вот такая статья и видео выступления там же о том, как мы тестируем iOS в параллель. Правда, есть недостаток — материал на английском языке.
К слову, у нас для автоматизации используется calabash и тесты мы пишем кросс-платформенные. Вот тут и тут можно прочитать еще немного про автотестирование в мобайле у нас в компании.
К слову, у нас для автоматизации используется calabash и тесты мы пишем кросс-платформенные. Вот тут и тут можно прочитать еще немного про автотестирование в мобайле у нас в компании.
Да, всё правильно поняли, спасибо за ответы.
Спасибо, отличный материал! Его обязательно нужно дать почитать разработчику и тестировщику!
PS: как то многовато времени уделяется для «Corner cases». Судя по описанию, это типовые тест кейсы, которые просто стоит прогнать один раз перед релизом.
PS: как то многовато времени уделяется для «Corner cases». Судя по описанию, это типовые тест кейсы, которые просто стоит прогнать один раз перед релизом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование в Badoo «с высоты птичьего полёта»