Корпоративная рассылка письма с объявлением подготовки к Devel Camp. В нем мы пишем сотрудникам «если вам есть о чем рассказать, свяжитесь с организаторами». В итоге 70% заявок на доклады приходят к нам в ответных письмах.
Ох, обманываете, ох врете. Помнится, работал только персональный подход и индивидуальные нападения на потенциальных докладчиков. Или с 2014 года ситуация кардинально поменялась?:)
Классная конференция с неплохим качеством докладов. Гостей, кстати, перестали приглашать? А то я б рассказал чего. Могу на заданную тему. ;)
Анастасия, статья мне понравилась, идея тоже.
Забавно, что и у меня есть доклад «Автотестеры не нужны» в нем я описал очень похожие шаги. И, кажется, сделал еще один, следующий.
В команде, в которой я работаю, тесты всех уровней — от юнитов до тяжелых UI тестов пишут все: бекендеры, фронтендеры, тестировщики, аналитики. Только дизайнер-проектировщик не пишет. Но раньше писала.
Вы едете на дамп через пару недель, надо обязательно встретиться и поболтать. А на кодефесте не появитесь случайно?
Сколько времени обычно проходит от момента, когда программист отдал на ревью код и до момента когда ему поставили два аппрува?
Как сильно вырос техдолг от введения такой системы?
«Мы хотим приучить себя и других мыслить в доходах и расходах»: кто будет думать о качестве?
«Мы просим каждого сотрудника оценить по 10-бальной шкале следующие параметры его самоощущения в организации.»: Ни в одной компании, где я работал, IT специалисты всех уровней не относились всерьез к таким анкетам. Вы верите их результатам?
В момент, когда разработчик закончил создание нового функционала, в agile команде для него готовы тестовые сценарии, подготовленные тестировщиками. Автоматизатор в этот момент читает документацию и пишет автоматические тесты, постоянно взаимодействуя с командой.
Увеличение количества рабочих центров и специализация это прямое противоречие Agile. Кроме того, описанная система предельно медленная и неустойчивая к флуктуациям.
У меня в команде автоматизация не отделяется от разработки, аналитики и тестирования. Чем по вашему agile команда отличается от не-agile?
Разве в agile команде возможен «тестировщик-автоматизатор»?
Текст протворечит своим же утверждениям: «Тестирование НЕ фаза. Все занимаются тестированием.»
Это раз.
Два.
«Автоматизация не требует вмешательства человека. Их запуск не требует наблюдения (например, на ночь).» — смешной бред.
Три. Вы все еще делите тестирование на ручное и автоматизированное? Почитайте определения.
Четыре. А можно примеры если не по пунктам, то хотя бы по заголовкам? С чиселками.
Я прожужжал все уши начальнику и добился установки SVN.
Если я не ошибся в подсчетах, шел 2010 год? Тогда вы правильно сделали что
заявление на увольнение я написал тем же вечером.
Путь тестировщика не заканчивается на бездумном клацании кнопок и следовании инструкциям — он с него только начинается. <...> Предпочитаю находить в этом и свой скромный вклад.
Вклад определенно есть. С удовольствием советую всем доклады от badoo и смело иду на них на любых конференциях.
Про путь тестировщика
Шикарный список уровней. В свое время предложил такой:
Тестер. Ищет баги
QA. Не наносит вред. Уменьшает количество багов в проекте.
Гуру. Учит команду писать меньше багов.
Евангелист. Все, кто с ним общаются создают меньше багов.
Пророк. Меньше багов создают даже те, кто с ним не общаются.
Любовь к тестированию
Справедливо стоит на первом месте. Илья, большое спасибо за статью.
Елена, вы читали книгу Коберна «Современные методы описания функциональных требований к системам»? Кажется, что там есть ответы на многие вопросы, которыми вы задавались в процессе создания инструментов.
Было принято решение расширять чек-листы <...> Так мы пришли к написанию подробной юзер-стори <...> по факту являющей собой один громадный тест-кейс.
Я вижу в этом тексте прямое противоречие. Вы уверены, что верно используете терминологию?
В какой-то момент мы оказались в ситуации, когда правка тестов после релиза занимала почти всё время, которое было у автоматизатора до следующего релиза.
Вы поднимаете тесты после релиза? Почему не до?
1.
В какой-то момент мы оказались в ситуации, когда правка тестов после релиза занимала почти всё время, которое было у автоматизатора до следующего релиза.
Почему поднятием тестов занимается не программист? Зачем лишнее звено — автотестер?
2.
функционал
Функциональность.
3.
Первое решение, которое приходит в голову, — нанять ещё одного автоматизатора.
Именно это решение вы и реализовали, разве нет? Вы попытались сделать из «ручных тестеров» «автоматизаторов», но почему-то не путем повышения квалификации, а путем снижения порога входа и упрощением системы тестов (что само по себе стоит дорого)
4.
Когда ребята начали работать с тестами в своих задачах, мы договорились, что правки будут вноситься в ту же ветку, где лежит код задачи.
До этого не так? Как вы убивались об версионирование кода приложения и кода тестов?
5. Вы не считаете порочным деление на «автоматизаторов»" и «ручных тестеров»? Автоматизация всего лишь инструмент. Ваши автоматизаторы тестировать умеют?
Обычно нанимают тестировщика, который периодически выполняет одни и те же действия и ждет того дня, когда его, наконец, переведут на другую должность или появится возможность поменять работу.
Судя по всему, с тестировщиками вы не сталкивались, только с обезьянками.
Восьмичасовой рабочий день и пятидневная рабочая неделя установлены именно из соображений максимальной продуктивности.
Это не так.
Частая интеграция, Соглашение о кодировании
Это уже давно не экстремальное программирование, а гигиеническая норма.
Не очень понятно, эта статья вообще релевантна вашему опыту? Какие проблемы и ограничения обнаружены при использовании этих практик?
У меня в команде действует принцип преемственности, когда прошлогодние стажёры помогают новичкам и курируют их работу: когда ты сам прошёл стажировку — лучше других знаешь, какая помощь и советы понадобятся стажёру.
Вчерашние стажеры учат стажеров? Четвертое правило воронки намекает, что таким образом мы быстро получим треш и угар.
1. Какие криптопровайдеры поддерживаются в системе?
2. Используется ли простая электронную подпись? Если да то почему и зачем?
3. Используется ли в системе усовершенствованная подпись, если да то каким образом решается проблема множества различных удостоверяющих центров в России в части обновления их СОС? Ведь СОС необходимы для того чтобы точно определять отозван ли был сертификат во время подписи или нет
Очень ждал увидеть в статье ограничения применимости. Когда нужно применять гибкие методологии, а когда их применять ни в коем случае нельзя. Аналогично — ограничения на размер и состав команды.
Функционал — отображение на произвольном множестве. Не следует путать с функциональностью — совокупностью возможных вариантов использования. Вики
Почему вы QC специалистов называете QA?
Всегда есть техзадание?
Тяжелый процесс с привлечением ПМа и разработчика на самых ранних этапах начинается с задач какого размера? Или у вас все достаточно крупные? Как делите?
Если фича приезжает в QA сырая, то мы выставляем ей низкий уровень, и она сразу же, без дальнейшего рассмотрения, уезжает обратно в разработку со списком открытых багов.
Все-таки без рассмотрения или со списком открытых багов?
"Автоматическое тестирование" — автоматизированное, вы хотели сказать?
Автоматизированное тестирование выполняется после передачи фичи в руки тестировщиков? Не до? Разработчик не может запускать тесты?
Я все же не понял, в чем заключается участие тестировщиков в постановке задач для программистов?
Соответственно то, что будет динамично меняться не стоит переделывать до завершения всех работ и вместо автотестов временно тестировать данную область вручную.
Вы, наверное, шутите? Автоматика — как средство многократного и быстрого тестирования нужна именно там, где все меняется. Чтоб проверить не сломали ли чего изменения. То, что не будет меняться — можно проверить и вручную. Изредка.
Оценка эффективности автоматизации в целом.
И опять на те же грабли, оцениваем автоматизированное тестирование по отношению ручному. Да еще и эффективность в отрыве от результативности. Это разные виды тестирования с разными тактическими целями и задачами. Автоматизация — во многом — скорость и воспроизводимость.
Функциона́л — это отображение, заданное на произвольном множестве.
Не следует путать с функциональностью — совокупностью возможных вариантов использования или возможных действий выполняемых неким объектом (программой).
Статья понравилась, большое внимание уделено подготовке, описаны роли в контексте автоматизации — это редко где встретишь. Спасибо.
в наше время редко кто-то работает на одном месте больше года, а тем более больше трех
Не стоит так уж обобщать. Мои наблюдения — противоположны. Среднее время работы на одном месте среди тех, кого я знаю и с кем работал — больше двух лет точно и наверняка больше трех. Те, с кем я хотел бы работать, компании меняют в разы реже.
И да, судя по качеству выпускаемых продуктов, сервисов, по кратности продалбывания сроков, по объему трудозатрат на единицу продукции — именно вред.
Один мой руководитель говорил, что сотрудник в том месте, где надо думать, через год работы только перестает приносить вред, а через два начинается хоть какая-то польза. Не на третий год опыта, а на третий год работы в одном месте.
Я с ним согласен.
Я добавлю еще причин низкого уровня. Например, уход квалифицированных тестировщиков в другие направления, как следствие их неспособности объяснить руководству ценность квалифицированных кадров. Непонимание направлений роста. Странное, непонятное и глупое, но все же бытующее среди тестировщиков поверье, что они делятся на «ручных» или «мануальных» и «автоматизированных».
А еще — самая простая причина. Это просто молодая профессия. Судя по ощущениям, а также опросам, которые я проводил, примерное время старта 2005-2010год. То есть специалистов, которых с трудом еще можно назвать опытными — 10 лет работы — единицы.
Искать новые баги при помощи классификации старых — странная идея. Обычно для поиска новых используют классификацию рисков, это немного другое, хоть и близко.
Я бы предложил вам идти от юзкейсов. Что делают с багами и как поможет классификация. Поиск и расстановка приоритетов для починки — типовые кейсы, на мой взгляд.
Для поиска классификация должна быть непересекающейся, однозначной и запоминающейся (4-6 одинаково понятных всем пункта).
Для приоритетов — сложнее, зависит от процесса. Влияние на пользователя, ресурсы, требуемые для починки и так далее.
Ох, обманываете, ох врете. Помнится, работал только персональный подход и индивидуальные нападения на потенциальных докладчиков. Или с 2014 года ситуация кардинально поменялась?:)
Классная конференция с неплохим качеством докладов. Гостей, кстати, перестали приглашать? А то я б рассказал чего. Могу на заданную тему. ;)
Забавно, что и у меня есть доклад «Автотестеры не нужны» в нем я описал очень похожие шаги. И, кажется, сделал еще один, следующий.
В команде, в которой я работаю, тесты всех уровней — от юнитов до тяжелых UI тестов пишут все: бекендеры, фронтендеры, тестировщики, аналитики. Только дизайнер-проектировщик не пишет. Но раньше писала.
Вы едете на дамп через пару недель, надо обязательно встретиться и поболтать. А на кодефесте не появитесь случайно?
Увеличение количества рабочих центров и специализация это прямое противоречие Agile. Кроме того, описанная система предельно медленная и неустойчивая к флуктуациям.
У меня в команде автоматизация не отделяется от разработки, аналитики и тестирования. Чем по вашему agile команда отличается от не-agile?
Текст протворечит своим же утверждениям: «Тестирование НЕ фаза. Все занимаются тестированием.»
Это раз.
Два.
«Автоматизация не требует вмешательства человека. Их запуск не требует наблюдения (например, на ночь).» — смешной бред.
Три. Вы все еще делите тестирование на ручное и автоматизированное? Почитайте определения.
Четыре. А можно примеры если не по пунктам, то хотя бы по заголовкам? С чиселками.
Если я не ошибся в подсчетах, шел 2010 год? Тогда вы правильно сделали что
Вклад определенно есть. С удовольствием советую всем доклады от badoo и смело иду на них на любых конференциях.
Шикарный список уровней. В свое время предложил такой:
Справедливо стоит на первом месте. Илья, большое спасибо за статью.
Функциональность.
Я вижу в этом тексте прямое противоречие. Вы уверены, что верно используете терминологию?
Вы так уверенно заявили, как будто правы. Ревью вполне может производиться именно с целью поиска определенного класса ошибок. Практикуем.
P.S. Результаты одного годного исследования эффективности разных способов поиска ошибок. Ревью — не худший способ.
Вы поднимаете тесты после релиза? Почему не до?
1.
Почему поднятием тестов занимается не программист? Зачем лишнее звено — автотестер?
2.
Функциональность.
3.
Именно это решение вы и реализовали, разве нет? Вы попытались сделать из «ручных тестеров» «автоматизаторов», но почему-то не путем повышения квалификации, а путем снижения порога входа и упрощением системы тестов (что само по себе стоит дорого)
4.
До этого не так? Как вы убивались об версионирование кода приложения и кода тестов?
5. Вы не считаете порочным деление на «автоматизаторов»" и «ручных тестеров»? Автоматизация всего лишь инструмент. Ваши автоматизаторы тестировать умеют?
Спасибо большое, очень интересная статья.
Судя по всему, с тестировщиками вы не сталкивались, только с обезьянками.
Это не так.
Это уже давно не экстремальное программирование, а гигиеническая норма.
Не очень понятно, эта статья вообще релевантна вашему опыту? Какие проблемы и ограничения обнаружены при использовании этих практик?
Вчерашние стажеры учат стажеров?
Четвертое правило воронки намекает, что таким образом мы быстро получим треш и угар.
Спасибо за статью, хороший разбор.
2. Используется ли простая электронную подпись? Если да то почему и зачем?
3. Используется ли в системе усовершенствованная подпись, если да то каким образом решается проблема множества различных удостоверяющих центров в России в части обновления их СОС? Ведь СОС необходимы для того чтобы точно определять отозван ли был сертификат во время подписи или нет
правильно «регрессионном»
правильно «автоматизированным»
Очень ждал увидеть в статье ограничения применимости. Когда нужно применять гибкие методологии, а когда их применять ни в коем случае нельзя. Аналогично — ограничения на размер и состав команды.
Все-таки без рассмотрения или со списком открытых багов?
Планируете ли переход к continuous deployment, как к следующему шагу?
И да, в терминах путаница, в статье идет речь о QC, а не QA инженерах.
Вы, наверное, шутите? Автоматика — как средство многократного и быстрого тестирования нужна именно там, где все меняется. Чтоб проверить не сломали ли чего изменения. То, что не будет меняться — можно проверить и вручную. Изредка.
И опять на те же грабли, оцениваем автоматизированное тестирование по отношению ручному. Да еще и эффективность в отрыве от результативности. Это разные виды тестирования с разными тактическими целями и задачами. Автоматизация — во многом — скорость и воспроизводимость.
Статья понравилась, большое внимание уделено подготовке, описаны роли в контексте автоматизации — это редко где встретишь. Спасибо.
Не стоит так уж обобщать. Мои наблюдения — противоположны. Среднее время работы на одном месте среди тех, кого я знаю и с кем работал — больше двух лет точно и наверняка больше трех. Те, с кем я хотел бы работать, компании меняют в разы реже.
И да, судя по качеству выпускаемых продуктов, сервисов, по кратности продалбывания сроков, по объему трудозатрат на единицу продукции — именно вред.
Я с ним согласен.
Я добавлю еще причин низкого уровня. Например, уход квалифицированных тестировщиков в другие направления, как следствие их неспособности объяснить руководству ценность квалифицированных кадров. Непонимание направлений роста. Странное, непонятное и глупое, но все же бытующее среди тестировщиков поверье, что они делятся на «ручных» или «мануальных» и «автоматизированных».
А еще — самая простая причина. Это просто молодая профессия. Судя по ощущениям, а также опросам, которые я проводил, примерное время старта 2005-2010год. То есть специалистов, которых с трудом еще можно назвать опытными — 10 лет работы — единицы.
Тесты совершают больше 1 действия?
Проверяют больше 1 условия?
С идеей согласен, но объем функциональности продукта кажется небольшим. Или нет?
И ни слова о том, что лучший выбор — тот язык, на котором написан проект?
Вы работаете на проектной, не продуктовой разработке?
Я бы предложил вам идти от юзкейсов. Что делают с багами и как поможет классификация. Поиск и расстановка приоритетов для починки — типовые кейсы, на мой взгляд.
Для поиска классификация должна быть непересекающейся, однозначной и запоминающейся (4-6 одинаково понятных всем пункта).
Для приоритетов — сложнее, зависит от процесса. Влияние на пользователя, ресурсы, требуемые для починки и так далее.