Как сократить ручное тестирование и можно ли без него обойтись

С развитием технологий мир меняется. Все больше функций и процессов автоматизируются, все менее востребован ручной труд. И это применимо не только к рабочим специальностям, но и к самой IT-индустрии. Manual QA как отдельная специализация может со временем уйти в историю.

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

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

Разработка с ручным тестированием

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

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

Тогда ходило много разговоров о юнит и интеграционном тестировании, но на практике не так много команд (включая нас) применяли эти подходы. Если за тебя баги будут искать другие люди, писать тесты — уже не твоя головная боль.

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

Трансформация подходов к тестированию продуктов

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

Мы изучали успешные примеры на рынке и экспериментальным путем выявили для себя несколько ключевых подходов и техник, которые используем и сегодня:

  • Юнит-тесты и интеграционные тесты — неотъемлемая часть кода. Абсолютно все инженеры на всех проектах обязаны сопровождать фичи автоматическими тестами.
  • Непрерывная интеграция (Continuous Integration) — система, при которой автоматические тесты прогоняются при любом изменении кода. На рынке существует множество решений для такого рода автоматизации, вот некоторые из них: Jenkins, Circleci, Travis CI.
  • Обязательное использование валидаторов качества кода, таких как Rubocop, ESLint.
  • Pull Request Policy. Любой код, который попадает в основную ветку проекта (master branch), должен быть проверен и утвержден одним или более участником, но не самим разработчиком.
  • Парное программирование — техника разработки, которая предполагает совместную одновременную работу двух инженеров над одним кодом.

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

Значит ли это, что мы полностью исключили мануальное тестирование?

С внедрением подходов, описанных выше, загрузка мануальных тестировщиков на проектах существенно сокращалась. Для full-time загрузки тестировщиков привлекали part-time сразу на несколько проектов (если говорить о небольших и средних продуктах). Но эта модель оказалась неэффективной: QA не погружался полностью в контекст тестируемого продукта, не был в курсе всех принимаемых решений. Такая вовлеченность приносила больше проблем, чем пользы. Потому мы покрыли функцию мануального тестирования с помощью еще одного подхода, который позаимствовали у наших голландских коллег по проекту Philips Directlife (у них на тот момент уже не было собственных QAs).

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

Результат TestFest — список багов, каждый из которых получает свой приоритет и добавляется в общий скоуп.

Применение данного подхода естественным образом убрало какую либо потребность в отдельном человеке на позиции manual QA.

Выводы

Railsware постепенно ушла от необходимости иметь отдельного manual QA в команде.

В процессе трансформации бизнес-модели мы, в первую очередь, стремились повысить качество кода. За счет применения новых подходов к разработке количество багов значительно уменьшилось, как и объем работ для тестировщиков. Part-time загрузка QA не позволяла им полноценно погружаться в контекст продукта, что сказывалось на результатах работы. В итоге, роль мануал QA была полностью исключена из организационной структуры, а функция тестирования распределена между участниками команды.

Разработчики, в свою очередь, смогли значительно улучшить качество создаваемого кода за счет изменений подходов к разработке. Это повысило их квалификацию, и, как результат, качество создаваемых продуктов.

В таком формате мы разрабатываем продукты (как небольшие, так и достаточно крупные платформы) вот уже 7 лет. Очевидно, что в продуктах есть баги. Но если сравнить качество продуктов Railsware до и после трансформации QA — последние выигрывают со значительным отрывом.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному1
LinkedIn

Схожі статті

  • Знайомтесь, TestOps!Знайомтесь, TestOps!

    Oleksii Ostapov

    Ця стаття — спроба осмислення не до кінця сформованої в професійній спільноті концепції TestOps. Що це за спеціалізація, чому виникла, чи буде розвиватись — читайте у матеріалі Олексія Остапова та Михайла Чуба. 51

  • Лояльні й мотивовані QA-спеціалісти: як їх розпізнати та виховатиЛояльні й мотивовані QA-спеціалісти: як їх розпізнати та виховати

    Alyona Chernenko-Dyba

    Управляти людьми, підтримувати рівень їхньої мотивації — легко! Тільки в книгах! Але Альона Черненко-Диба QA Manager з 11-річним досвідом в ІТ переконана, що лояльні та мотивовані тест-спеціалісти таки існують. 87

  • Як тестувальнику розпочати роботу на проекті з нуляЯк тестувальнику розпочати роботу на проекті з нуля

    Oleksandra Zubal

    Як тестувальникам стартувати проекти з погляду забезпечення якості? Заповнити всі прогалини, поговорити з усіма ключовими особами й учасниками команди, скласти план, використовуючи категоризацію, яку пропонує Олександра Зубаль, QA Lead. 4




Найкращі коментарі пропустити

Вопрос в том какую роль у Вас выполнял QA? Просто у многих понимание назначения QA — это тестер, как вольтметр, которым измеряют напряжение. Сказали чтоб сравнил фактический результат с ожидаемым и по тому что не сошлось завел баги.

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

Если взять позвать QA в конце, когда все уже якобы готово и сказать, что вот тестируй, то толку мало будет. Оно так не работает и Ваш подход лучше! Но если все организовать правильно, вы получите пользу от тестирования, ту которую оно и должно приносить. QA будет занят всегда и от него будет польза!

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

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

Ярко светит солнце, лучики тепла...
На любимом ДОУ новая статья.

Развалился в кресле и достал попкорн
Все, теперь готов я... принимать хардкор

И от удивленья... вдруг упал попкорн
Вдуг это читает... счас начальник мой (

Дальше по сюжету лучики ушли
Пули из говнища... лужи из крови...

Как живем мы круто! Как же хорошо!
Выгнали мы нахиг обаное зло!

Нет теперь кюэев! Багов тоже нет!
Как же офигенен наш большой проект!

Всюду обнимашки... лучики тепла...
Тестит тот кто кодит... нет нигде багла...

Только бедный юзер... плачет за столом...
И охеревает, где же млять оно....

Где логина поле? как сюда зайти?
Нет сабмита кнопки... как ее найти?!

Плавают картинки... гребанный дизайн...
Их никто не тестил... никто не проверял...

404... все... пипец... хана...
Работа тестировщика вовсе не видна...

Добрый мой читатель... что хотел сказать...
Работу тестировщика — надо уважать!

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

129 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Огромное спасибо за статью.
TestFest / BugBush / etc — имеет как плюсы, так и минусы.
Плюсы — это разные люди с разным бекграундом внутри компании могут проверить функционал.
Минусы — крайне редко эти самые люди обладают достаточно глубоким знанием продукта. Как результат — это скорее всего приведет к куче багов UI/UX, но крайне небольшому количество действительно критичных багов.
Плюс ко всему возникает вопрос — кто формирует конфигурацию для тестирования, если требуется пройти кейсы на куче операционных систем, девайсов, разрешениях, версиях и тд?
Как в таком случае проходит тестирование безопасности, производительности, и тд?

Если говорить o QA как просто «пройди вот эти кейсы и отметь несоответствия бездумно» — то да — такой подход с фестами и код кавередж метриками подойдет.

«QA не погружался полностью в контекст тестируемого продукта, не был в курсе всех принимаемых решений. » - а зачем они были нужны?

«Юнит-тесты и интеграционные тесты
Непрерывная интеграция (Continuous Integration)
Обязательное использование валидаторов качества кода, таких как Rubocop, ESLint.
Pull Request Policy.
Парное программирование.»

а какое это всё имеет отношение к тестированию вообще-то? это всё программирование, а тестирование тут где?
вы просто спихнули тестирование вашего продукта на конечных пользователей

ну есть инфа что тестирование раньше всегда было на программисте, а потом чтобы побольше синьоров продать начали появлятся qa, которые не qa вовсе, а ручные тестеры и оно так хорошо прижилось что теперь уже: «как же тестирование?!»

Тема, конечно, холиварная, но из моего опыта на энтерпрайзных проектах наилучшим было соотношение 1 QA на 2-3 Dev. Да, наверное, если пилить хипстерский стартап или брать заказы на фрилансе и адаптировать процесс ху8к-ху8к и в продакшн, то вполне можно работать и без QA. Если проект долгоиграющий, то кто-то должен поддерживать документацию, писать тест-кейсы, готовить тестовые данные, проводить смок тестирование, интеграционное тестирование, репортить баги, трекать их, готовить релизную документацию и так далее.

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

Этот комментарий о чем?

некомпетентные

в принципе не должны принимать участие в продакшине

Этот комментарий о чем?

О целесообразности и способах сокращения ручного тестирования. Весьма странно что вы этого не поняли.

в принципе не должны принимать участие в продакшине

Это если в компании есть человек способный отличать компетентного от некомпетентного. А если есть — то удалось ли вообще найти компетентного менеджера. Представители обеих групп — редкость.

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

Конечно удалось найти, и не одного.

Хммм ... А почему вы им не дали статью на вычитку?

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

Тексты читают. Но в этом конкретном случае под вычиткой подразумевалось нечто другое. Для меня не до конца прозрачный намек.

Очевидно, что в продуктах есть баги. Но если сравнить качество продуктов Railsware до и после трансформации QA — последние выигрывают со значительным отрывом.

«Мы отказались от стирки одежды, потому что решили не валяться в грязи. Опрятность значительно повысилась!»

Сарказм зря — аналогия достаточно неплохая, учитывая, что в грязи в с среднем по палате поваляться очень даже любят, т.к. стирают другие. Поэтому гораздо лучше отучить валяться в грязи путём периодических самостоятельных стирок (такой подход работает на ура — собственный опыт подтверждает инф-ю в статье), чем валяться бесконтрольно и стирать каждый день.

Наблюдаю похожую картину. Думал, я один такой ковбой, просил тестеров в команду не набирать. Оказалось, другие тимы тоже предпочитают взять разраба вместо отдельного тестировщика. Причины: наличие выделенного человека рано или поздно приводит ко вредной привычке «код написан, дальше пусть тестировщик разбирается». И когда этот тестировщик один, а девелоперов больше, и они шустрые, то это приводит к закономерной пробке на пути к релизу. Если же девелопер знает, что по коммиту в мастер его код диплоится пайплайном на продакшн, задумчивость о качестве заметно увеличивается.

Тестировщики в нашей организации озадачились, начали опрашивать контакты — выявился тренд по индустрии. Переквалифицируются теперь. Кто в разраба (с упором/прокачанным скилом тестирования). Кто в аналитика. Кто ops’ом увлекается, некоторые в infosec смотрят. Есть ниши, где совсем без тестировщиков стремновато, само собой.

ИМХО картина напоминает судьбу DBA, которые раньше держали ключи от баз данных во многих организациях, но сейчас как правило занимаются более специализированными задачами поддержки соответствующей инфраструктуры или привлекаются как консультанты / члены команды в особо сложных случаях.

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

Потому желательна обратная пропорция, или как минимум один тестер на каждого разработчика. (Только фиг это кому докажешь в начальстве.)

правильно, то есть разработчик и есть тестер.

Нет, таки разные люди. Это однозначно эффективнее.

однозначно? это в твоем контексте может и однозначно, но скорее нет, и начальство это чувствует.

В моем вот — совершенно нет.

Что этому разному человеку-тостеру делать пока фича в процессе разработки?

Мануальщику совсем еще нечего, разве что exploratory testing вокруг будущего изменения, но это уж очень дорогое удовольствие в большинстве своем.

Автоматизатор может параллельно тесты возводить, но обычно дисбаланс велик или в одну или в другую сторону (или тесты намного дольше писать, или фичу), так что все равно намного более эффективно делать и то и то вместе, то есть парное программирование/тестирование, то есть опять же грань специализации стирается.

Дополнительный (но не отдельный) человек однозначно более эффективен с точки зрения того, что парное программирование таки обычно более эффективно в перспективе. Но это не значит, что команду нужно жестко делить на тестеров и разрабов. Другое дело, что в паре может быть разный фокус, и тоже динамически.

но скорее нет, и начальство это чувствует.

Начальство обычно чувствует, что «типа» можно сэкономить. И экономит — в ущерб процессу.

Что этому разному человеку-тостеру делать пока фича в процессе разработки?

Тестировать что-то другое. Я не предлагаю привязывать тестера к конкретному разработчику — тут про общее количество.

намного более эффективно делать и то и то вместе, то есть парное программирование/тестирование

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

Я не предлагаю привязывать тестера к конкретному разработчику — тут про общее количество.

это не тот случай, когда количество перейдёт в качество. Скорее наоборот. Описывается типичный силос тестирования, мы уже знаем, что это не работает.

При котором совместные ошибки пролетают не хуже индивидуальных.

ошибки будут всегда. Даже в НАСА. Речь шла не об эффективности как отлове ошибок, более в общем процессе и распределении знаний.

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

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

Начальство обычно чувствует, что «типа» можно сэкономить. И экономит — в ущерб процессу.

Экономить в ущерб и с умом использовать ресурсы — разные вещи. В 99% случаев держать выделенного тестировщика на каждого разработчика в наши дни совершенно не оправдано и есть суть показатель неправильно настроенных процессов. В 80% (IMHO) держать выделенного тестировщика на команду — тоже самое. Сильно сомневаюсь, что ты в тех малых процентах.

Что этому разному человеку-тостеру делать пока фича в процессе разработки?

Заниматься разработкой тех самых «тестов через программирование» по согласованной спецификации контрактами апишкам и пр.?

Заниматься разработкой тех самых «тестов через программирование» по согласованной спецификации контрактами апишкам и пр.?

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

Нет нужды в такой пропорциональности.

Нужны небольшие рабочие группы, в которых программисты с тестировщиками наравне делают продукт, а не «выкатывают фичи». И пропорция там неопределенная, как team velocity, но с какого-то момента весьма точно определяема.

делают продукт, а не «выкатывают фичи»

1) эти две вещи друг другу не противоречат
2) не противоречат они и наличию тестеров

И пропорция там неопределенная, как team velocity, но с какого-то момента весьма точно определяема.

Но для неё всё равно есть разумные границы.

очевидно что не один :)

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

Это потому что не хватает знаний/умений как построить процесс с минимальным использованием мануального тестирования

По моим наблюдениям как раз таки автоматизация сейчас переживает спад, хайпанутая тема отживает своё

не видно такого. Выделенного человека держать для автоматизации — то да, плохо работает.

количество вакансий на мануальщиков рекордно растёт.

где? абсолютно или относительно (и чего) ?

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

с другой стороны, если бы это была статья не о том, какой процесс был построен, а:
— как вы пришли к этому процессу(мета-процесс)
— альтернативные варианты
— мотивы выбора именно тех, а не иных вариантов
— неверно выбранные варианты
— корректировка неверных путей
— и т д.

это был на несколько порядков более качественный материал(хотя некоторая часть здесь есть, что безусловно радует)

У этой болезни существует два проявления:
— Мы все автоматизировали
— Мы избавились от тестировщиков

И много последствий:
Раз

Два (кому лень разбираться, в бесплатном аккаунте разрешен только один мейлбокс)

Три

В общем, качество растет.

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

Ярко светит солнце, лучики тепла...
На любимом ДОУ новая статья.

Развалился в кресле и достал попкорн
Все, теперь готов я... принимать хардкор

И от удивленья... вдруг упал попкорн
Вдуг это читает... счас начальник мой (

Дальше по сюжету лучики ушли
Пули из говнища... лужи из крови...

Как живем мы круто! Как же хорошо!
Выгнали мы нахиг обаное зло!

Нет теперь кюэев! Багов тоже нет!
Как же офигенен наш большой проект!

Всюду обнимашки... лучики тепла...
Тестит тот кто кодит... нет нигде багла...

Только бедный юзер... плачет за столом...
И охеревает, где же млять оно....

Где логина поле? как сюда зайти?
Нет сабмита кнопки... как ее найти?!

Плавают картинки... гребанный дизайн...
Их никто не тестил... никто не проверял...

404... все... пипец... хана...
Работа тестировщика вовсе не видна...

Добрый мой читатель... что хотел сказать...
Работу тестировщика — надо уважать!

я больше не смогу смотреть на namecheap так как раньше

по сути вы платите неквалифицированным тестировщикам за тестирование по

$75/час

в чем проффит кроме

Railsware постепенно ушла от необходимости иметь отдельного manual QA в команде.

?

Ну зачем же так искажать суть статьи?

эт не искажение, а квинтэссенция.

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

Реальная метрика это то что нам клиенты платят $75/час тут детали
dou.ua/...​mns/software-consultancy

У facebook тоже все ок с клиентами и финансами, при этом глюкавое у них про ВСЕ

Спасибо за статью! Благодаря Вам мануальщики без работы не останутся )
Так же ожидаем цикл статей:

Как сократить ручную уборку помещений и можно ли без нее обойтись
Как сократить ручное приготовление еды и можно ли без него обойтись
Как сократить ручное управление командой и можно ли без него обойтись
Как сократить хождение в туалет и можно ли без него обойтись

Остроумно :) так когда-то шутили машинистки

я не настолько стар, что б это помнить, Бро )))

Ну с такими стихами ты как минимум локальный стар ;)

А что если софт работает совместно с девайсом, кнопки на девайсе робот будет нажимать?

Отрывок из статьи

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

Но даже в описанном случае можно попробовать эмулировать нажатия или роботизация

видел на хармане робота, который вынимал и вставлял сиди диски

Молодцы что смогли, толковая статья! Хочется отметить что данный подход будет работать только для продуктовых компаний, для аутсорса данная модель слишком дорогая.
П.С хотя в той же iOS багов немеряно.

А почему дорого? Мы эту модель активно используем для разработки клиентских продуктов.

Спасибо за статью, идеально. Вставлю пять копеек, у нас, когда создаётся новый PR, автоматически поднимается проект (docker+jenkins) и прогоняются lint и тесты. Если что-то из этого не пройдено, то Github показывает «checks have failed». Без этого и аппрува от хотя бы одного другого члена команды нельзя смержить PR. Плюс ещё внедряем автоматическую генерацию карты покрытия, так PR ещё будет падать, если каких-то тестов не хватает.
Только вот как тестировать UI мне не совсем понятно. Наверное, всё же всё ещё надо создавать автотесты на Selenium.

примерно так и работаем.
для тестирования UI (и в целом всего в интеграции) — Capybara + какой либо драйвер (Selenium, Webkit)

Все правильно сделали! Молодцы. Кстати Wix тоже без тестировщиков обходится.

p.s. Но обязательный pair programming это перебор...

Вот прям то же самое хотел написать — всё круто, но PP как-то подозрительно смотрится в плане дефолтной эффективности). Хотя, возможно, у меня просто предрассудки.

У нас обязательное но не 100% времени. Отдельно напишу в следующей статье про ПП, на самом деле очень эффективный инструмент.

Эффективный, но очень выматывающий и шумный)

Ололо, а я пару лет назад презентацию их видел что как-то обходятся. Видимо инфа устарела)

мы покрыли функцию мануального тестирования

кровь из глаз
правильно писать «мы закаверили функцию манульного тестирования»

Это конечно очень существенное замечание :) А по сути есть какие-либо комментарии?

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

немануальное тестирование конечного продукта

Хм... у них специальные человекоподобные манекены напичканные датчиками есть специально для разбивания ))

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

я и говорю — плохо тестируют

Это пока что даже не автопилот, а только «ассистент водителя». Так что наличие водителя подразумевается.

Вопрос в том какую роль у Вас выполнял QA? Просто у многих понимание назначения QA — это тестер, как вольтметр, которым измеряют напряжение. Сказали чтоб сравнил фактический результат с ожидаемым и по тому что не сошлось завел баги.

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

Если взять позвать QA в конце, когда все уже якобы готово и сказать, что вот тестируй, то толку мало будет. Оно так не работает и Ваш подход лучше! Но если все организовать правильно, вы получите пользу от тестирования, ту которую оно и должно приносить. QA будет занят всегда и от него будет польза!

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

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

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

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

Я к тому, что в статье изначально описаны неправильные подходы к построению процесса разработки ПО, а именно процесса тестирования на проекте.

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

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

Я к тому, что в статье изначально описаны неправильные подходы к построению процесса разработки ПО, а именно процесса тестирования на проекте.

Они-то неправильные, просто

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

Как также указано в статье, к сожалению, такой подход к QA весьма распространён и встречается чаще, чем правильный...

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

Как сократить ручное тестирование и можно ли без него обойтись

Название немного не корректно. В таком свете лучше назвать — «Как мы изменили процесс разработки и повысили качество». Потому что мануальным тестированием, занимается вся команда, а не выделенный человек. Но оно есть, как бы они его не назвали!!!

Проблема была не в мануальном тестировании, а в подходах!

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

вся команда не занимается постоянным мануальным
тестированием

Да, я это понял, но оно все же есть.
На счет морали, я согласен! Есть такой эффект, но есть разные рычаги влияния на мораль)

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

Все описанные Вами подходы правильные и я тоже сторонник этих подходов, но они никак не уменьшают степени важности мануального тестирования.

Если не верите, я Вам тут сейчас пирамиду тестирования нарисую)))
P.S. Никакого негатива! Истинна рождается в спорах)

Чем Ваш TestFest отличается от привычного всем UAT?

UAT — это все же тестирование на реальных пользователях (бета-тестирование). Тест Фест все же проходит внутри команды. В следующей статье опишу детали.

Я бы почитал. Но, должен сказать, данную практику следует воспринимать лишь как дополнение к полноценному мануальному тестированию, а не замену.
Вот Atlassian начал экспериментировать с подобным. www.atlassian.com/inside-atlassian/qa
Blitz testing, в частности.
Результат — последняя Jira, катастрофа качества.

хехе, нормальний підхід. описати процеси на проекті. в коментарях розжують проблемні місця, поправити процеси — ляпота)
вангую, що зараз набіжить тестерів з криком... ааа, забирають хліб!

цікаво побачити було б відсотковому значенні на скільки менше багів і т.д.
Більшість того, що ви пишете воно звісно впливає в якійсь мірі на якість кінцевого продукту. Доцільність впровадження одгого чи іншого процесу впершу чергу залежить від проекту. Грубо кажучи — додали код ревю — стало краще там то. стали деви витрачати більше часу, але виловлюється певна кількість багів. Забрали тестерів, зекономили грошей, хз чи вплинуло на якість =)

TestFest

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

В ней участвуют инженеры, продакт-менеджеры, иногда UI/UX дизайнеры, команда со стороны клиента

така толока звісно класно, але без системного підходу, якогось мінімального плану не дає вам ніякої гарантії, що все буде перетестовано

Разработка с ручным тестированием

розділ це крах, якщо у вас так було... то проблема, здається, не в тестерах

якісних продуктів вам ;)

По

TestFest

будет отдельная статья

TestFest — это сессия мануального тестирования, которая проводится перед большими релизами. В ней участвуют инженеры, продакт-менеджеры, иногда UI/UX дизайнеры, команда со стороны клиента.

PM с рейтом 10n Devs c рейтом 5н Дизайнеры с рейтом 2-5н и команда клиента (рейт неизвестен) тестируют вместо того что-бы держать на проекте 1го постоянного QA с рейтом Н

Но в остальных случаях мануальное тестирование продуктов != набором подходов к разработке, что приведет к уменьшению технического долга и повышению качества продукта в целом

 У вас и так есть мануальное тестирование просто нет выделенного человека на это а этим занимаються все вовлеченные в проект

Такая сессия может быть раз в две недели на пару часов, это все равно будет дешевле чем manual QA фул тайм. И кроме всего прочего достигаются другие позитивные эффекты — вся команда знает продукт гораздо лучше. А ощущение того что твое слово последнее заставляет всю команду относиться более ответственно к своим обязанностями.

А сколько теряете на переключениях? QA проверит таску в тот же день что и дев запилит и выдаст баги. Ваш подход выявит баги через 2 недели, когда про фичу разработчик уже забыл.
Не проще ли нагрузить QA другими активностями, чтобы был смысл держать его фултайм?

TDD, BDD, code review — таска уже покрыта тестами и проверена другими инженерами перед принятием в бранч. Зачем тут QA?

Потому что dev покрыл тестами только то, что сам учел.

А с чего он один? Во первых пара. То есть пропустит один, тогда второй укажет. Ревью кода и тестов — тоже пара минимум. То есть потеря покрытием специфических кейсов должно пройти минимум 4 человек. Тем более есть типа тест-коверейдж системы , которые и так укажут, что покрытие кода тестами упало в процентном отношении

Конечно если работу 1 QA выполняют 3 разраба, то наверняка баги будут найдены.

Хотите сказать, что мануальный QA проверяет качество кода и тестов? Я имею ввиду качество именно написанного кода, а не только качество, как получился функционал этой фичи.

Мы в Ardas стремимся к тому, чтобы QA мог проверить качество тестов. Качество кода это конечно на разработчиках. Приведу пример о чем я говорю
Например нам заказали фичу разработать алгоритм определения оптимального количества погрузочных машин для перевозки определенного груза. Да, фичу делали 2 разработчика. Да, еще один провел ревью кода.
Но кто-то должен взять и руками, не полагаясь на автотесты, проверить что фича выдает адекватные результаты. Подготовить тестовые данные, дернуть API, посмотреть что там в БД записалось.
И важно чтобы этот кто-то фичу не разрабатывал, т.к. те, кто разрабатывали уже наверняка все что придумали — проверили.
Если у вас это делает еще один программист, то ок, просто скажите ему что он QA :)

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

Вообще не проблема. И для аналитика не проблема написать код. Вопрос в разделении труда и кому что нравится. QA нравится тестировать, аналитик любит работать с требованиями, разработчики любят писать код. Так или иначе QA тоже чуть чуть кодит, разработчик работает с требованиями, а аналитик тестирует. Но на каждую роль есть как минимум один гарантированно сильный в этой роли человек.

Ну тут спорить не буду — пусть человек занимается тем, чем нравится. Главное, чтобы эта «специализация» была востребована.

Подготовить тестовые данные, дернуть API, посмотреть что там в БД записалось.

Это все ещё могут сделать интеграционные и системные тесты.

Тесты, которые написал тот, кто делал фичу? Как проверить что тесты тестируют то, что нужно? Фича как минимум один раз должна быть проверена так, как ей будут пользоваться конечные пользователи.

Ну код ревью это и делает. Тем более сегодня уже есть системы, которые автоматически скажут что не покрыто тестами, где что упущено.

Да можно даже аналог github.com/...​.js/blob/master/README.md чтобы ловить нестабильные кейсы.

Quis custodiet ipsos custodes? (Who Will Guard the Guardians?) :)

И важно чтобы этот кто-то фичу не разрабатывал, т.к. те, кто разрабатывали уже наверняка все что придумали — проверили.

Пока они сами не побывают в этой роли, эффективность гораздо ниже. Как только побывают, будут придумывать гораздо лучше — в этом и смысл. Тестировать же будут не только свои фичи, а любые.

Если у вас это делает еще один программист, то ок, просто скажите ему что он QA :)

Частично так и есть. Т.о. процесс разработки становится более устойчивым, т.к. каждый мыслит шире. Да, это может быть «дороже», но смотря с какой стороны посмотреть.

А задача QA выявить моменты, которые не были учтены или в требованиях или при разработке или даже предложить, как можно улучшить разработанную функциональность.

Рекомендую прочитать вот эту статью dou.ua/...​mns/software-consultancy для полноты картины.

Артем расскажи как по твоему разрабатываются огромные Open Source проекты без единого QA?

Поэтому они обычно на костылях и велосипедах )

Правда? Linux, Git, Ruby on Rails на

костылях и велосипедах

?

Именно ) сколько релизов прошло прежде чем допилили до чего то вменяемого ....

Так можно говорить про любой продукт сколько прошло пока начали выпускать нормальный Windows? А сколько прошло прежде чем смогли нормальный смартфон допилить.

Linux, Git, Ruby on Rails

были хороши изначально и взрослели вместе с рынком, и смогли вырости без QA ;)

Именно так, сейчас гиганты потребительского рынка тестируют на пользователях, в особенности (условно) бесплатные продукты

Артем Дукельский PM/BA в Ardas 19 часов назад

Сергей, то что у конкретного человека нет лейбы QA, не значит что никто не занимается ручным тестированием. В случае опен сорса тестирует и выписывает баги комьюнити. И судя по issues на гитхабе, багов хватает.

вот хороший ответ на ваш вопрос — Если вам нравиться что нет конкретно выделенного QA — да нет — нет Тестирования — неправильно тестирование выполняют другите люди — что экономически выгоднее — большой вопрос и предмет для холивара — зависит от конкретного проекта желаний и возможностей

Зашёл на 1 ваш продукт случайным образом
dom.ru — если не ошибся это ваш сразу видно написан без участия QA Заходишь и попап перекрывает поле поиска
никакой адаптации под мобильные девайсы
если ввести некоректное значение в поиск по порталу (англ буквами) — выдает пустую страницу без сообщений об ошибках ....
Вам точно QA не нужны?

Решил на вскидку пробежаться по «our products»: dom.ru — багов тьма, похоже на Дизайнерах решили тоже сэкономить. www.plumdistrict.com — не доступен (с прокси: не доступен)
www.hatch.co — не доступен (с прокси: не доступен)

Прошу обращать внимание на даты участия в проектах. Каждый кейс-стади содержит такую информацию.

Dom.Ru (2007 — 2008)
www.plumdistrict.com (2011-2013)
www.hatch.co (2012)

То что потом происходило с продуктами не наша ответственность.

Сергей, то что у конкретного человека нет лейбы QA, не значит что никто не занимается ручным тестированием. В случае опен сорса тестирует и выписывает баги комьюнити. И судя по issues на гитхабе, багов хватает.

Но это делают сами инженеры. Багов хватает в любых продуктах даже там где есть армии QA.

Вы уверены, что в Open Source проектах нет QA?

В стандартом представлении его там нет. Ну нет там людей чья основная работа сводиться к постоянному ручному тестированию. А вот подходы как выпустить качественный продукт там есть. Вот об этом собственно и статья.

Все-таки мы о выделенном QA вообще, или только о Manual QA?
Когда кто-то коммитит тесты в Open Source проект и тестирует его как в чистом upstream, так и в продукте компании, в которой он работает, то разве нет QA в проекте?

В стандартом представлении его там нет. Ну нет там людей чья основная работа сводиться к постоянному ручному тестированию. А вот подходы как выпустить качественный продукт там есть.

Я понимаю что есть желание словить меня на слове. Но если не брать только часть фразы, то смысл появляется другой. По сути они используют фидбек комьюнити для улучшения продукта. Так делают не только Open Source проекты и это отличная практика. И я не утверждаю в статье что вообще нет примеров использования ручного тестирования — я говорю о том что в Outsourcing индустрии его слишком много и используется там где можно обойтись без него.

И если зайти глубже в ссылки developer.mozilla.org/...​_one_of_our_quality_teams
то можно увидеть что речь идет не совсем о ручном тестировании.

По сути они используют фидбек комьюнити для улучшения продукта.

Я прошел глубже, что бы посмотреть чем занимается
quality.mozilla.org/...​egory/teams/firefox-team ->
public.etherpad-mozilla.org/p/testday-20180302 ->
docs.google.com/...​eMl5r8zutOaDUE/edit#gid=0

По сути есть определенная комманда, которая занимается тестированием, в том числе ручным.

Это учитывается ещё до написание кода через планинг покер командой

даже предложить, как можно улучшить разработанную функциональность.

А этот процесс называется ретроспектива, и тут участвует опять команда, а не какая то специальная должность для этого.

В статье перечислены подходы к разработке что бы вообще минимизировать переключения. Не стоит во главу угла ставить TestFest это лишь вспомогательная процедура. Основное качество добивается перечисленными методами.

10 человек 2 часа (сессия) = 20 человекочасов — 4 дня работы QA (это в случае с одинаковым рейтом а так как рейты не одинаковые то уже дней 7 работы QA -экономия в 3 дня работы QA при этом профессионализм и мотивация людей которых напрягли работать как QA — резко падает

Средняя команда 2-4 инженера + UX + PDM = 4-6 человек. А если продукт большой то там все равно Скводы по 4-6 человек и они работают отдельно.

А не думали PDM сократить? Думаю что команда из UX и инженеров могли бы легко выполнить и эту роль :)

Да и UX можно тоже сократить ... что девам стоит дом построить UI нарисовать

Пусть к тыжпрограммисту пройден :)

Сейчас тыжпрограмист уже не модно — сейчас это гордо именуется Full Stack

Тут немного другое скорее T-Shape

Вот тут более детально описана структура работы dou.ua/...​mns/software-consultancy

Підписатись на коментарі