Процесс обеспечения качества предполагает, что при тестировании мы оцениваем, как будет тестироваться ПО, какие проверки на каком уровне или этапе будут проведены.
Необходимо понимать, что нам нужно тестировать свой продукт, а не логику, элементы дизайна или компоненты, например, другой команды.
Что-то вы тут не самым удачным образом смешали тестирование и обеспечение качества. Заговорив про последнее, вы резко скатились в тестирование. Проведение тестирования вам ни разу не обеспечит качество. Оно вам обеспечит нахождение багов, подтверждение соответствия требованиям, может быть немного удовольствия.
Однако, у вас должны быть критерии качества продукта, тогда да - тестирование вам даст результаты, которые можно будет рассматривать на предмет соответствия/не соответствия критериям качественности.
Теперь обсудим, что лучше: пойти в крупную корпорацию или стартап?
Вы правда встречали в достаточном количестве ситуации, когда стартапы берут стажеров или джунов? На мой взгляд, такие ситуации настолько редки, что стартапы можно даже не упоминать в качестве варианта. Разве что у вас есть знакомый со своим стартапом и желанием помочь вам.
Давайте посмотрим в корень, почему нужно понимать как работает продукт с точки зрения бизнеса, что он дает клиенту. Для этого рассмотрим такую последовательность и поймем суть и связь каждого ее элемента:
Тестирование - Качество - Потребность
1. Тестирование - один из процессов, необходимых для контроля качества. 2. Качество - это степень, с которой продукт удовлетворяет явным и неявным/подразумеваемым потребностям заинтересованных сторон. * 3. Подразумеваемые потребности - те, которые могли быть не сформулированы, однако являются фактическими потребностями. **
То есть, тестируя - вы (может быть неосознанно) собираетесь оценить качество/степень соответствия потребностям. Поскольку подразумеваемые потребности характерны для той области, задачу в которой решает продукт, их не всегда указывают или не указывает вовсе (пример - никто не будет указывать, что зуб не должен выезжать за пределы щеки при моделировании его положения в ПО для печати капп для исправления прикуса).
Поэтому важно не только понимание продукта, тех функций\проблем, которые он решает, но и предметной области. Иначе этот "специалист" лишает себя способа выхода за рамки и как результат - проводит однобокое неполноценное тестирование опираясь только на явные потребности. Подобно тому как копать, держа лопату одной рукой - неудобно да и не получится хорошо.
* Определение из стандарта ISO\IEC 25010:2011, также используется в ISTQB глоссарии. ** Определение из ISO\IEC 25040:2011
Мы можем условно разделить ответы, в которых есть варианты 1 и 2 и методом исключения уже выбрать «группу», которая нам наиболее подойдет
Человек идет сдавать экзамен, чтобы подтвердить знания, однако выбирать группу ответов методом исключения - это не знания, а логика. К многочисленным экзаменам в форме тестов с вариантами ответов и так много претензий, здесь же вы своим опытом раскрываете очевидное - вместо знаний на тестах можно угадать/логически домыслить. Получается демонстрация не знания, а умения найти правильный ответ.
Что-то вы тут не самым удачным образом смешали тестирование и обеспечение качества. Заговорив про последнее, вы резко скатились в тестирование. Проведение тестирования вам ни разу не обеспечит качество. Оно вам обеспечит нахождение багов, подтверждение соответствия требованиям, может быть немного удовольствия.
Однако, у вас должны быть критерии качества продукта, тогда да - тестирование вам даст результаты, которые можно будет рассматривать на предмет соответствия/не соответствия критериям качественности.
Вы правда встречали в достаточном количестве ситуации, когда стартапы берут стажеров или джунов? На мой взгляд, такие ситуации настолько редки, что стартапы можно даже не упоминать в качестве варианта. Разве что у вас есть знакомый со своим стартапом и желанием помочь вам.
Неверный ответ. Нужно всего лишь хорошенько продумать и спланировать шаги.
Пример:
Для себя понять, что должно быть в работе мечты
Найти вакансию, сравнить их требования с тем, что можешь предложить
Наработать то, чего не хватает
И вот мы уже имеем не безальтернативную ситуацию «никак не найти», а ситуацию где есть шансы на трудоустройство на желаемую позицию.
Давайте посмотрим в корень, почему нужно понимать как работает продукт с точки зрения бизнеса, что он дает клиенту. Для этого рассмотрим такую последовательность и поймем суть и связь каждого ее элемента:
Тестирование - Качество - Потребность
1. Тестирование - один из процессов, необходимых для контроля качества.
2. Качество - это степень, с которой продукт удовлетворяет явным и неявным/подразумеваемым потребностям заинтересованных сторон. *
3. Подразумеваемые потребности - те, которые могли быть не сформулированы, однако являются фактическими потребностями. **
То есть, тестируя - вы (может быть неосознанно) собираетесь оценить качество/степень соответствия потребностям. Поскольку подразумеваемые потребности характерны для той области, задачу в которой решает продукт, их не всегда указывают или не указывает вовсе (пример - никто не будет указывать, что зуб не должен выезжать за пределы щеки при моделировании его положения в ПО для печати капп для исправления прикуса).
Поэтому важно не только понимание продукта, тех функций\проблем, которые он решает, но и предметной области. Иначе этот "специалист" лишает себя способа выхода за рамки и как результат - проводит однобокое неполноценное тестирование опираясь только на явные потребности. Подобно тому как копать, держа лопату одной рукой - неудобно да и не получится хорошо.
* Определение из стандарта ISO\IEC 25010:2011, также используется в ISTQB глоссарии.
** Определение из ISO\IEC 25040:2011
Человек идет сдавать экзамен, чтобы подтвердить знания, однако выбирать группу ответов методом исключения - это не знания, а логика. К многочисленным экзаменам в форме тестов с вариантами ответов и так много претензий, здесь же вы своим опытом раскрываете очевидное - вместо знаний на тестах можно угадать/логически домыслить. Получается демонстрация не знания, а умения найти правильный ответ.