Нанимать тестировщика или тестировать самому?

Что у вас за пользователи такие, которые баги репортят? :)

У нас как раз MVP сейчас и решаем либо командой разработки тестировать, либо каким-то сервисом типа test.io пользоваться, либо тестировщика на парттайм брать. Интересно узнать, какие есть плюсы минусы у этих вариантов

@voropavlik, Если разработчики достаточно покроют юнит и интеграционными (а не только happy path, как обычно бывает), скорей всего хватит просто потыкать их же руками. Если же с нижней частью пирамиды все печально, то лучше нанимать человека, который начнет выстраивать процесс тестирования.

@eeHQBUT5LMVkJr9R, насколько есть смысл нанимать в штат, если задач пока даже на парт тайм еле-еле набирается?

@eeHQBUT5LMVkJr9R, зачем репортить? В ELK логи/метрики в sentry ошибки

@voropavlik, Не могу сказать точно, не зная специфику проекта, но:
Если под задачами подразумевается проверка тасок перед деплоем и периодический регресс - то да, тут смысла нанимать в штат нет.
С другой стороны, этот же человек может писать тестовую документацию, организовывать в целом процесс, автоматизировать эти же самые тест-кейсы, устраивать вам нагрузочное тестирование и так далее (И гонять разрабов, чтобы писали тесты). В таком случае времени ему, скорее всего, будет не особо хватать.

Из собственного опыта, у нас был не особо популярный продукт и маленькая команда разработки (4 или 5 человек) и мы вдвоем зашивались все это тестировать.

@eeHQBUT5LMVkJr9R, а насколько хорошая идея не в штат, а, наример, на фрилансе найти человека на пару дней в неделю?

@voropavlik, зависит от сложности проекта. Если там формочки потыкать и на инъекции проверить - будет достаточно. Если рокетсаенс, первое время вы будете платить человеку за то, как он просто разбирается в вашей системе.

Это получается не бесплатно, а негативным опытом 1-5% пользователей.
В принципе это может быть не важно. Для большинства проектов такая цена ошибки действительно небольшая. Если поедет верстка в интернет-магазине, ну кто-то не купит себе кроссовки, ничего страшного в целом.

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

Канарейка хороша там, где мы можем умеренно опираться на метрики; например, во многих случаях она позволяет избежать нагрузочного тестирования. Что же касается тенденции к замене канарейкой тестирования функционального - то это, разумеется, полная хуета. Есть разные классы ошибок, и далеко не все из них можно поймать метриками.

Доп. вопрос не вполне понятен. QA - это quality assurance, обеспечение качества. Тестирование - это quality control, QC. QC есть подмножество QA. Канарейка - это тоже инструмент QC, и тестировщики (речь, вероятно, идет о них?) занимаются QC, хоть их и принято громко называть QA-инженерами.

Можно ли на проекте обойтись без QA? От проекта зависит, на каком-то и без программистов можно обойтись. Если качество не нужно (а такое тоже бывает: всякого рода MVP, пилоты, эксперименты, или бизнес-модель "втюхать и убежать") - то и обеспечивать его незачем. Непонятно, в общем.

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

Про разные классы ошибок выше все правильно написали. Метрики не покроют все.

Мы только выложили приложение, пользователей сейчас совсем немного. И раз в 2 недели выкатываем апдейты. Хочется их тестировать, что ничего не сломалось. Хочу понять, какие плюсы и минусы у варианта тестировать командой разработки и у варианта найти на парт тайм тестировщика. Ну и как обычно на таком раннем этапе люди делают, когда тестировщик нужен условно на 1 день в неделю?

@voropavlik, нанял бы на Апворке или на Fl.ru (но это менее вероятно) человека в дешевой локации, кому скидывать билды перед релизом, чтобы прокликивал про сценариям.

Я так делал в своей веб-студии и в общем оно работало. Нужно было только выдавать релиз-ноутс что проверять (экспорт из условной Джиры или рид-онли доступ по ссылкам) и сделать форму отправки багов (Эйртейбл или Гугл Шитс). Скриншоты со всех экранов в подтверждение тестирования человек заливал в Дропбокс. Я даже не вникал в их - просто смотрел, что если там 30 скриншотов (по числу экранов в нашем приложении) - значит он всё просмотрел хотя бы.

Это достаточно хорошо работало, когда исполнители не пропадали конечно - всё-таки такая работа быстро надоедает или же люди находили более объёмную работу и забивали на мою задачу, которая требовала часов 5-6 в неделю).

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

@voropavlik, смотри. Тут дьявол прячется в словах "ничего не сломалось". Для проверки, что "ничего не сломалось", нужен полный список того, что могло сломаться. Этот список называется "тестовая модель", он может состоять, например, из тест-кейсов или чек-листов. И основная сложность в тестировании не в прокликивании этих сценариев, а в поддержании этого списка актуальным; то есть он должен перед релизом учитывать все изменения, что вы за две недели внесли.

Без списка тоже можно, это называется "исследовательское тестирование". Для регрессионного тестирования (а вам нужно именно оно) это хреновая штука: набор проверенных сценариев непредсказуем, затраты времени непредсказуемы, и то, и другое сильно зависит от личности тестировщика. Так что я бы рекомендовал начать с постановки вопроса: кто и как будет поддерживать тестовую модель в исправном состоянии? А там уже можно либо студентуса за еду искать, либо самим прокликать.

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