А можно пример того как тестирование должно влиять на продукт и на бизнес?

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

Я, тащемта, не предлагал сидеть сложа ручки.
Хотите влиять на продукт и бизнес? Это здорово и прекрасно.

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

Потому что в отличии от тестировщика, принимать такие решения - его работа. Он несёт за них ответственность и вот это всё.

Пытаться принимать решения за него, теша себя иллюзиями что тебе-то виднее - плохой план.

Всем привет! как стать хорошим тестировщиком?

Для начала надо стать плохим тестировщиком

-_-

А потом улучшаться

хорошо
тогда как стать плохим тестировщиком?

как и куда улучшаться?

Я думаю вам туда

спасибо :)

Научиться гуглить, освоить правило 15 минут, читнуть вот тут текст по ссылке https://t.me/qa_ru/170749

Потом сходить в курсовой чат и читнуть вот этот пост: https://t.me/qa_courses/18270

Потом можно вопросы в @qajuniors набрасывать

Ты про @shooandendlessagony забыл.

Ахах ) я думаю, это уже четвёртым пунктом ;)

Если менеджеры не должны ничего понимать, то они не должны и ничего получить.

Практический случай.

10 лет назад был напилен функционал который преобразует pdf файлы в текст. При проектировании первоначального функционала максимальный размер pdf файла считался 3 мегабайта. Подобрали набор компонентов, для того типа и структуры файлов (pdf-ки они очень разные бывают) и с теми размерами оно работало.

Проходит 10 лет. Новые менеджеры захотели чтобы на похожем стеке и компоненте преобразовывались pdf файлы других типов и структуры, с размером 30 мб, 60 мб, 100 мб, а ещё лучше 1 гб (да, можно сделать пдфку и на 450 мб, и на 600+ , и некоторые регулярно такие делают).

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

Всё будет эксперименты, и экспериментов будет много. При экспериментах результат не гарантируется.

Также см. :

https://www.youtube.com/watch?v=6_eKPbigA1o

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

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

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

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