Работаю на второй (местами третьей) линии поддержки нескольких КИС. Так вот, у нас нет как таковых тестировщиков, это либо коллеги из поддержки у кого есть время тестировать обновления на тестовых серверах, или мы, или пользователи. Ну и случаются не очень приятные моменты из-за отсутствия полноценного тестирования, к примеру перед НГ вышло большое обновление, которое нужно было достаточно быстро растиражировать по всем регионам в нашей зоне ответственности. Нас попросили, мы сделали. Буквально на следующий день после того, как закончили все обновлять, выходит ещё одно обновление, так как что-то забыли доделать. И его тоже надо срочно установить, ну мы установили. А еще через день выходит срочный патч, который исправляет косяки, которые возникли у пользователей после этих обнов. И так за неделю обновили одну систему 3 раза. Мне кажется, что если бы провели нормальное регрессивное тестирование обновления, то не было бы такой суеты и спешки...

.. и открывают вакансии на проджектов с обязанностями тестера 🙃

Я встречал не то что мнение, а прям аргументированное обоснование некоторых проектных менеджеров, что тестировщики — это лишняя трата бюджета. Ведь можно просто сделать "чик-чик и в продакшен" и деньги уже в кармане, а за всякие баги и сваливания от нагрузок можно навешать заказчику лапши и состричь с него деньги на исправление этих самых багов и подсадить его на техподдержку. С этого момента его можно будет доить с разной степенью интенсивности. То есть это не то чтобы мнение, а прям существующий и "экономически обоснованный патерн проектирования".

Тестировщики очень нужны. У меня в команде эту роль выполняют системные аналитики. Пишут ЧТЗ, в нём обязательно описывается тестовая задача для разработчика. Далее аналитик проводит тестирование по задаче. Так получается дешевле и эффективнее.

У нас теперь толковые тестировщики на вес золота. У нас был проект в котором была замена API со старого на новый. Работала команда из 3-х разрабов, 1 фронт, 1 бэк и 1 фулстек, ну и РП приглядывал. Разрабы дали отмашку, у нас все готово, можно заливать на прод. РП попросил дополнительно протестировать командой в 6 глаз, нашли пару багов, пофиксили, отчитались что все ОК. И тут к нам на работу выходит тестировщик, Артём, это была его первая задача у нас. Он ушёл на неделю в тестирование, потом вернулся и сказал что ему надо ещё 3 дня минимум, опять ушёл. Вернулся с таблицей из 252-х мать его багов, отсортированных по степени критичности, от наиболее критичных до потенциальных фичей которые можно не трогать если не мешают. Наиболее критичными были 20+ и если бы мы все что разработали залили на прод, то это был бы фиерических факап. Кроме того, для каждой 252 строк были подробные картинки, а местами и видео с примером как воспроизвести ошибку. 3 разраба и РП не увидели эти ошибки потому что после 4-месяцев работы над проектом у них давно глаз замылился.

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

Знаете кто самые лучшие тестировщики? Нет?

А я вам подскажу 🤫

Это менеджеры по продажам.

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

Ух, же вам править не переправить потом 😉 Столько наслушаетесь. И я скажу это реально работает, только перед этим глицина вагон для разработчиков купите и продукт продебажится мигом 🤣

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

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

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