Нанимать тестировщика или тестировать самому?  Публичный пост

Кто как тестирует мобильное приложене на ранних стадиях? Своими силами или нанимаете тестировщика? Как устроен процесс?

21 комментарий 👇

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

Причины этому как мне видится 2:

  1. Экономия средств. 1-5% твоих пользователей получают обновление и находят баги, после фикса которых все остальные получают обновление. Получаешь то же самое что и с QA team но почти бесплатно.
  2. Убирая лишнее взаимозависимое событие из пайплайна идея -> фича в продакшене ты ускоряешь весь конвейер.

Некоторые компании включают специалиста по тестированию в составы dev тим. Если оно экономит время разработчиков то вероятно имеет смысл. Если же у вас MVP с тремя фичами и фултайм загрузки для QA не будет - думаю более продуктивно будет самим девелоперам и продактам ручками протыкать.

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

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

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

  Развернуть 1 комментарий

Как вы считаете, каких случаях в наше время QA вот просто необходим и без него никак?

В тех сферах где цена ошибки высока, конечно же.
Например ПО, которое управляет медприбором. Или финтех, где цена ошибки - миллиарды.

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

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

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

  Развернуть 1 комментарий

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

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

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

  Развернуть 1 комментарий

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

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

Не пренебрегайте TDD. Пишите юнит тесты. Гоняйте на них мутационные тесты + считайте покрытие, так будет уверенность в достоверности юнитов.

Накидайте happy path flow и пусть разрабы каждую фичу покрывают позитивным UI сценарием.

  Развернуть 1 комментарий

Если есть деньги - нанимать, если нет - не нанимать.

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

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

  Развернуть 1 комментарий
Olga Sentemova, python developer 4 июня 2020

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб