Я вот совсем пропустил этот этап обучения, всё познавал уже на собственных шишках)
Но по отзывам могу порекомендовать три книжки:
Скучную, но дельную «Testing computer software» от Cem Kaner и Jack L. Falk
Более читаемую, но менее интересную для опытного специалиста «Software Testing» от Ron Patton
Отличное пособие по тест-дизайну «A Practitioner’s Guide to Software Test Design» от Lee Copeland
Ну и что-нибудь вроде «Как тестируют в Google» чтобы узнать о реальных практиках. Ну или почитать другие наши статьи о тестировании (:
Технически да — в данный момент я уже упёрся в потолок развития для чисто технического специалиста. Поэтому сейчас стал больше заниматься отвлечёнными делами — продуктовыми проектами, геймдевом, деврелом.
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
Если считать обязанностью тестировщика только прокликать все возможные кейсы в чёрном ящике — да, тут конечно расти дальше следования инструкциям некуда. Точно так же как до сих пор кое-где есть программисты, которые занимаются только переводом написанного другим человеком алгоритма в код. Там тоже нет особого пути развития.
В большинстве же случаев сейчас «программист» — не машина для выдачи кода, он занимается такими «кросс-доменными» делами как проектирование, алгоритмизация, оптимизация, поиск новых способов решения задач… То же самое и с тестировщиками. Кликать кнопки — самый базовый уровень, начало карьеры. Хороший тестировщик должен уметь намного больше. Немного автоматизации, немного UX, немного аналитики и оптимизации архитектуры…
С тех пор всё стало ещё лучше, но все равно полная сборка кавериджа занимает чуть более часа и порядочно нагружает машину. Делать это на каждый тикет (ещё раз повторю — до 40 тикетов релизится в день) несколько затруднительно :)
В полностью автоматическом режиме — да, об уменьшении покрытия какого-то конкретного места мы не узнаем. Но мы дважды в день собираем полный каверидж по всему проекту — и по уменьшившемуся покрытию компонента можно будет узнать, что что-то не так. А на плохо покрытые тестами места у нас регулярно заводятся тикеты.
Сами удивились. Изначально сценарии «на коленке» написал для себя один из наших разработчиков, а потом выложил это дело в общий доступ (вообще многие наши qa-инструменты имеют подобный жизненный цикл).
А сам он выбрал lua потому что он прост как две копейки, наши сценарии на нём выглядят почти человекопонятными фразами, да ещё и в php он встраивается простым расширением.
Как бы хорош не был Selenium Manager, он позволяет в автоматическом режиме обнаружить только часть проблем. Если же проблема возникает только в комбинации задач — да, сидим и проверяем различные комбинации руками, либо всё же по текстам ошибок и симптомам пытаемся сразу обнаружить виновников — всё таки редко из 20 задач более двух затрагивают один и тот же компонент. Не представляю, как это можно было бы эффективно и дёшево автоматизировать.
По поводу отката вам лучше ответит кто-нибудь из наших релиз-инженеров, постараюсь прикастовать кого-нибудь из них в эту ветку (:
Да, багфиксы и мелкие исправления логики обычно даже не проходят полноценный этап PRD, а начинают жизнь уже в задаче в JIRA — в таком быстроразвивающемся проекте как наш иначе жить было бы невозможно
Надеюсь, я правильно понял ваш вопрос, если нет — уточните, пожалуйста.
Ревью задачи/проекта у нас выглядит так:
1. Когда PRD готово оно проходит ревью команды продукта: разработчик PRD проводит презентацию и все участники продукт-команды обсуждают все кейсы, вопросы за и против и так далее.
2. После проведения данного ревью, идет почтовая рассылка, в которой каждый заинтересованный может оставить свой фидбэк.
3. Также есть техническая API-команда, которая тесно содействует с продуктом при написании протокола (то есть также проводит процесс ревью).
4. Kick off внутри команды разработки. Совещание, которое проводится до начала разработки проекта, где как раз обсуждаются все кейсы, продукты рассказывают про проект, а тех отдел делает свое ревью по данному проекту. До проведения kick-off'a все участники проекта знакомятся с PRD.
5. По выполнении задачи она отправляется на код-ревью, где коллеги-разработчики могут проверить детали реализации и подходы к решению той или иной проблемы.
6. После прохождения код-ревью разработчик составляет сообщение для отдела QA, в котором рассказывает, как с технической точки зрения был реализован проект, чтобы мы при изучении задачи могли понять ход его мысли.
И на каждом из этих этапов в PRD могут вноситься различные поправки и дополнения, чтобы проект ушё на продакшн максимально проработанным и развитым.
Дождёмся автора Selenium Manager'а с больничного и отпишем развёрнутый ответ, может быть даже полноценную статью :)
Совсем вкратце — это веб-приложение, которое позволяет просмотреть результаты тестов в шоте каждой задачи, находящейся сейчас в билде и запустить на каждом шоте тест, который по той или иной причине не запускался. По результатам прогона этого теста на каждом шоте часто можно найти, какой шот виновен в поломке теста:
Насчёт автоматизаторов: разработчики пишут только интеграционные и юнит-тесты. В нашем отделе QA есть три специалиста, занимающиеся поддержкой Selenium и smoke-тестов фулл-тайм, они же занимаются поддержкой инфраструктуры, Selenium-grid фермы и всего такого. Все остальные QA-инженеры занимаются разработкой тестов наравне с непосредственным тестированием задач.
Вам спасибо! Когда я выступаю с докладом или пишу статью и это кажется полезным хотя бы одному человеку (а тем более если это побуждает его к каким-либо созидательным действиям), то я знаю, что работа была сделана не напрасно. Думаю, мои коллеги придерживаются того же мнения.
Доброго времени суток!
Нет, насколько мне известно, партнёрская программа работает исправно.
В будние дни обращусь к ответственным лицам, попробую разъяснить ситуацию. Результаты ждите в личке (:
Хочу всё же отдельно написать, что это совершенно не значит что «отдел мониторинга биллингу не нужен»!
Они непрестанно мониторят более низкоуровневые вещи, которые я могу пропустить (или даже могу не иметь доступа к ним): нагрузку на сервера, количество API-запросов к биллингу или от него и многое другое. К тому же их триггеры помогают нам обнаруживать растянутые по времени аномалии, например, быстрее увеличивающийся объём баз данных или необычные тренды на тех или иных графиках.
Так что мы ни коим образом их не заменяем в нашей работе, просто стараемся изо всех сил сделать её эффективнее (:
Некоторые агрегаторы предоставляют тестовые API или SDK, позволяющие нам полностью проводить весь флоу покупки на девел-окружении, включая полную процедуру общения с платёжной системой — заодно и наши автотесты могут таким способом платить без ограничений.
При этом абсолютно все платёжные методы мы полностью проверяем и на продакшне с «живыми» API. Некоторые методы оплаты поддерживают рефанды и мы платим со своих собственных карточек или пэйпалов (благо при быстром рефанде деньги возвращаются сразу же и без штрафов), для SMS-методов оплаты в разных странах мы используем сервис онлайн-аренды сим-карт SimTest. Иногда приходится связываться с партнёрами, чтобы они помогли нам провести тесты без затраты реальных денег. Автотесты, конечно же, таким не занимаются. Во избежание.
По поводу мониторинга, здесь есть несколько вещей:
Поиск причины проблемы у мониторщиков займёт сильно больше времени, чем у тестировщика, который прекрасно знает, что изменяется в новом билде;
В принципе время реагирования мониторинга может быть ниже (они же тоже не могут бить в бубен при каждом странном поведении графика), а для нас это могут быть потерянные деньги каждую секунду. Потому следить за потенциально рискованными метриками очень важно — и начинать искать возможные причины проблемы даже при малейшем отклонении значения от нормы;
Довольно сложно сделать адекватные автоматические триггеры на каждую метрику (приведённые примеры «аномалий» хорошо это демонстрируют), а их у нас сотни;
Всего под наблюдением мониторинга находятся ТЫСЯЧИ метрик, так что лишних ложных срабатываний от хитрых биллинговых систем им точно не нужно;
К сожалению, не все шли на мероприятие с этой целью — и далеко не все были открыты к общению. Особенно те, кто пришли командой в 5 человек и совершенно растерялись после перемешивания команд)
Если мы будем относиться ко всему так, как к объекту нашего профессионального тестирования, то лопнем от перенапряжения — слишком много дефектов на нашей планете)
Но по отзывам могу порекомендовать три книжки:
Скучную, но дельную «Testing computer software» от Cem Kaner и Jack L. Falk
Более читаемую, но менее интересную для опытного специалиста «Software Testing» от Ron Patton
Отличное пособие по тест-дизайну «A Practitioner’s Guide to Software Test Design» от Lee Copeland
Ну и что-нибудь вроде «Как тестируют в Google» чтобы узнать о реальных практиках. Ну или почитать другие наши статьи о тестировании (:
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
В большинстве же случаев сейчас «программист» — не машина для выдачи кода, он занимается такими «кросс-доменными» делами как проектирование, алгоритмизация, оптимизация, поиск новых способов решения задач… То же самое и с тестировщиками. Кликать кнопки — самый базовый уровень, начало карьеры. Хороший тестировщик должен уметь намного больше. Немного автоматизации, немного UX, немного аналитики и оптимизации архитектуры…
С тех пор всё стало ещё лучше, но все равно полная сборка кавериджа занимает чуть более часа и порядочно нагружает машину. Делать это на каждый тикет (ещё раз повторю — до 40 тикетов релизится в день) несколько затруднительно :)
А сам он выбрал lua потому что он прост как две копейки, наши сценарии на нём выглядят почти человекопонятными фразами, да ещё и в php он встраивается простым расширением.
Так что ответ на ваш вопрос — «Так получилось»
По поводу отката вам лучше ответит кто-нибудь из наших релиз-инженеров, постараюсь прикастовать кого-нибудь из них в эту ветку (:
Ревью задачи/проекта у нас выглядит так:
1. Когда PRD готово оно проходит ревью команды продукта: разработчик PRD проводит презентацию и все участники продукт-команды обсуждают все кейсы, вопросы за и против и так далее.
2. После проведения данного ревью, идет почтовая рассылка, в которой каждый заинтересованный может оставить свой фидбэк.
3. Также есть техническая API-команда, которая тесно содействует с продуктом при написании протокола (то есть также проводит процесс ревью).
4. Kick off внутри команды разработки. Совещание, которое проводится до начала разработки проекта, где как раз обсуждаются все кейсы, продукты рассказывают про проект, а тех отдел делает свое ревью по данному проекту. До проведения kick-off'a все участники проекта знакомятся с PRD.
5. По выполнении задачи она отправляется на код-ревью, где коллеги-разработчики могут проверить детали реализации и подходы к решению той или иной проблемы.
6. После прохождения код-ревью разработчик составляет сообщение для отдела QA, в котором рассказывает, как с технической точки зрения был реализован проект, чтобы мы при изучении задачи могли понять ход его мысли.
И на каждом из этих этапов в PRD могут вноситься различные поправки и дополнения, чтобы проект ушё на продакшн максимально проработанным и развитым.
Совсем вкратце — это веб-приложение, которое позволяет просмотреть результаты тестов в шоте каждой задачи, находящейся сейчас в билде и запустить на каждом шоте тест, который по той или иной причине не запускался. По результатам прогона этого теста на каждом шоте часто можно найти, какой шот виновен в поломке теста:
Насчёт автоматизаторов: разработчики пишут только интеграционные и юнит-тесты. В нашем отделе QA есть три специалиста, занимающиеся поддержкой Selenium и smoke-тестов фулл-тайм, они же занимаются поддержкой инфраструктуры, Selenium-grid фермы и всего такого. Все остальные QA-инженеры занимаются разработкой тестов наравне с непосредственным тестированием задач.
Нет, насколько мне известно, партнёрская программа работает исправно.
В будние дни обращусь к ответственным лицам, попробую разъяснить ситуацию. Результаты ждите в личке (:
Они непрестанно мониторят более низкоуровневые вещи, которые я могу пропустить (или даже могу не иметь доступа к ним): нагрузку на сервера, количество API-запросов к биллингу или от него и многое другое. К тому же их триггеры помогают нам обнаруживать растянутые по времени аномалии, например, быстрее увеличивающийся объём баз данных или необычные тренды на тех или иных графиках.
Так что мы ни коим образом их не заменяем в нашей работе, просто стараемся изо всех сил сделать её эффективнее (:
При этом абсолютно все платёжные методы мы полностью проверяем и на продакшне с «живыми» API. Некоторые методы оплаты поддерживают рефанды и мы платим со своих собственных карточек или пэйпалов (благо при быстром рефанде деньги возвращаются сразу же и без штрафов), для SMS-методов оплаты в разных странах мы используем сервис онлайн-аренды сим-карт SimTest. Иногда приходится связываться с партнёрами, чтобы они помогли нам провести тесты без затраты реальных денег. Автотесты, конечно же, таким не занимаются. Во избежание.
По поводу мониторинга, здесь есть несколько вещей: