Написание эффективных концепций тестирования очень важно, поскольку это может повлиять на качество самого тестирования
Может повлиять - интересная формулировка. А может и не повлиять. Из этого следует, что утверждение о важности - сомнительно, потому что опирается на «может повлияет, в может не повлияет»
лучше всего приобретать железо с процессорами одного производителя. Тогда откроется возможность переезда работающих виртуальных машин с одной ноды кластера без остановки самой виртуальной машины
Инженер-робототехник, в 2009 устроился в техподдержку IT конторы за 9к. Благодаря тому, что у самого всегда был интерес и дела делал в соответствии с ним :) До сих пор в IT
Рост ЗП - 20к в конце 2010, 60к в середине 11г, 100к в середине 2012, 130 в середине 15, 150 в середине 17, 200 в 19, 250 в 20, 300 в 22, дальше умолчу ;)
Мне кажется, у вас сложилось неправильное впечатление, что своим комментарием я принижаю чью-то значимость. Совершенно не принижаю, однако продолжу говорить, что тестировщик не может «руководить качеством». Это просто факт.
Тестировщик (как специалист) начинает руководить качеством
Ощущение, будто тестировщик (который, как я писал выше, руководит качеством)
Тестировщик не может руководить качеством. Тестировщик может находить несоответствие требованиям.
Даже если представить, что есть примитивный критерий качественности/некаяественности - «несоответствие в больше чем 5% бизнес требований признак некачественности » - всё, что может тестировщик - выявить эти несоответствия/завести баги. Дальше нужно влияние на соседние процессы - аналитики, поставки, разработки. У обычного тестировщика этого влияния нет. Без влияния на соседние процессы руководить/управлять качеством не получится. Не каждому тимлиду тестирования позволят на эти процессы влиять.
Не передергивай. Я сказал о том, что с планом будет шанс, а не гарантия. Шанс выпадает не всем. Можешь сказать той тысяче, о которой ты даже не знаешь, что кто-то тысяча десятый шанс использовал.
Процесс обеспечения качества предполагает, что при тестировании мы оцениваем, как будет тестироваться ПО, какие проверки на каком уровне или этапе будут проведены.
Необходимо понимать, что нам нужно тестировать свой продукт, а не логику, элементы дизайна или компоненты, например, другой команды.
Что-то вы тут не самым удачным образом смешали тестирование и обеспечение качества. Заговорив про последнее, вы резко скатились в тестирование. Проведение тестирования вам ни разу не обеспечит качество. Оно вам обеспечит нахождение багов, подтверждение соответствия требованиям, может быть немного удовольствия.
Однако, у вас должны быть критерии качества продукта, тогда да - тестирование вам даст результаты, которые можно будет рассматривать на предмет соответствия/не соответствия критериям качественности.
Теперь обсудим, что лучше: пойти в крупную корпорацию или стартап?
Вы правда встречали в достаточном количестве ситуации, когда стартапы берут стажеров или джунов? На мой взгляд, такие ситуации настолько редки, что стартапы можно даже не упоминать в качестве варианта. Разве что у вас есть знакомый со своим стартапом и желанием помочь вам.
Давайте посмотрим в корень, почему нужно понимать как работает продукт с точки зрения бизнеса, что он дает клиенту. Для этого рассмотрим такую последовательность и поймем суть и связь каждого ее элемента:
Тестирование - Качество - Потребность
1. Тестирование - один из процессов, необходимых для контроля качества. 2. Качество - это степень, с которой продукт удовлетворяет явным и неявным/подразумеваемым потребностям заинтересованных сторон. * 3. Подразумеваемые потребности - те, которые могли быть не сформулированы, однако являются фактическими потребностями. **
То есть, тестируя - вы (может быть неосознанно) собираетесь оценить качество/степень соответствия потребностям. Поскольку подразумеваемые потребности характерны для той области, задачу в которой решает продукт, их не всегда указывают или не указывает вовсе (пример - никто не будет указывать, что зуб не должен выезжать за пределы щеки при моделировании его положения в ПО для печати капп для исправления прикуса).
Поэтому важно не только понимание продукта, тех функций\проблем, которые он решает, но и предметной области. Иначе этот "специалист" лишает себя способа выхода за рамки и как результат - проводит однобокое неполноценное тестирование опираясь только на явные потребности. Подобно тому как копать, держа лопату одной рукой - неудобно да и не получится хорошо.
* Определение из стандарта ISO\IEC 25010:2011, также используется в ISTQB глоссарии. ** Определение из ISO\IEC 25040:2011
Мы можем условно разделить ответы, в которых есть варианты 1 и 2 и методом исключения уже выбрать «группу», которая нам наиболее подойдет
Человек идет сдавать экзамен, чтобы подтвердить знания, однако выбирать группу ответов методом исключения - это не знания, а логика. К многочисленным экзаменам в форме тестов с вариантами ответов и так много претензий, здесь же вы своим опытом раскрываете очевидное - вместо знаний на тестах можно угадать/логически домыслить. Получается демонстрация не знания, а умения найти правильный ответ.
Минус в карму за правду? Это мощно.
Вообще этим надо заниматься с самого начала, а не когда приходит выгорание.
Может повлиять - интересная формулировка. А может и не повлиять. Из этого следует, что утверждение о важности - сомнительно, потому что опирается на «может повлияет, в может не повлияет»
В некоторых случаях также будет работать между AMD и Intel, описано тут https://forum.proxmox.com/threads/live-migration-between-intel-xeon-and-amd-epyc2-linux-guests.68663/
https://forum.proxmox.com/threads/live-migration-cpu-types-and-performance.137946/
Инженер-робототехник, в 2009 устроился в техподдержку IT конторы за 9к. Благодаря тому, что у самого всегда был интерес и дела делал в соответствии с ним :) До сих пор в IT
Рост ЗП - 20к в конце 2010, 60к в середине 11г, 100к в середине 2012, 130 в середине 15, 150 в середине 17, 200 в 19, 250 в 20, 300 в 22, дальше умолчу ;)
Пришлось даже скрипт писать, чтобы успеть купить 4 места в одном купе. По другому не получилось в этом году.
Очередная инновация - «дать возможность» купить то, что даже продать нельзя. Их сметают в первые секунды открытия продаж.
Мне кажется, у вас сложилось неправильное впечатление, что своим комментарием я принижаю чью-то значимость. Совершенно не принижаю, однако продолжу говорить, что тестировщик не может «руководить качеством». Это просто факт.
Тестировщик не может руководить качеством. Тестировщик может находить несоответствие требованиям.
Даже если представить, что есть примитивный критерий качественности/некаяественности - «несоответствие в больше чем 5% бизнес требований признак некачественности » - всё, что может тестировщик - выявить эти несоответствия/завести баги. Дальше нужно влияние на соседние процессы - аналитики, поставки, разработки. У обычного тестировщика этого влияния нет. Без влияния на соседние процессы руководить/управлять качеством не получится. Не каждому тимлиду тестирования позволят на эти процессы влиять.
Не передергивай. Я сказал о том, что с планом будет шанс, а не гарантия. Шанс выпадает не всем. Можешь сказать той тысяче, о которой ты даже не знаешь, что кто-то тысяча десятый шанс использовал.
Что-то вы тут не самым удачным образом смешали тестирование и обеспечение качества. Заговорив про последнее, вы резко скатились в тестирование. Проведение тестирования вам ни разу не обеспечит качество. Оно вам обеспечит нахождение багов, подтверждение соответствия требованиям, может быть немного удовольствия.
Однако, у вас должны быть критерии качества продукта, тогда да - тестирование вам даст результаты, которые можно будет рассматривать на предмет соответствия/не соответствия критериям качественности.
Вы правда встречали в достаточном количестве ситуации, когда стартапы берут стажеров или джунов? На мой взгляд, такие ситуации настолько редки, что стартапы можно даже не упоминать в качестве варианта. Разве что у вас есть знакомый со своим стартапом и желанием помочь вам.
Неверный ответ. Нужно всего лишь хорошенько продумать и спланировать шаги.
Пример:
Для себя понять, что должно быть в работе мечты
Найти вакансию, сравнить их требования с тем, что можешь предложить
Наработать то, чего не хватает
И вот мы уже имеем не безальтернативную ситуацию «никак не найти», а ситуацию где есть шансы на трудоустройство на желаемую позицию.
Давайте посмотрим в корень, почему нужно понимать как работает продукт с точки зрения бизнеса, что он дает клиенту. Для этого рассмотрим такую последовательность и поймем суть и связь каждого ее элемента:
Тестирование - Качество - Потребность
1. Тестирование - один из процессов, необходимых для контроля качества.
2. Качество - это степень, с которой продукт удовлетворяет явным и неявным/подразумеваемым потребностям заинтересованных сторон. *
3. Подразумеваемые потребности - те, которые могли быть не сформулированы, однако являются фактическими потребностями. **
То есть, тестируя - вы (может быть неосознанно) собираетесь оценить качество/степень соответствия потребностям. Поскольку подразумеваемые потребности характерны для той области, задачу в которой решает продукт, их не всегда указывают или не указывает вовсе (пример - никто не будет указывать, что зуб не должен выезжать за пределы щеки при моделировании его положения в ПО для печати капп для исправления прикуса).
Поэтому важно не только понимание продукта, тех функций\проблем, которые он решает, но и предметной области. Иначе этот "специалист" лишает себя способа выхода за рамки и как результат - проводит однобокое неполноценное тестирование опираясь только на явные потребности. Подобно тому как копать, держа лопату одной рукой - неудобно да и не получится хорошо.
* Определение из стандарта ISO\IEC 25010:2011, также используется в ISTQB глоссарии.
** Определение из ISO\IEC 25040:2011
Человек идет сдавать экзамен, чтобы подтвердить знания, однако выбирать группу ответов методом исключения - это не знания, а логика. К многочисленным экзаменам в форме тестов с вариантами ответов и так много претензий, здесь же вы своим опытом раскрываете очевидное - вместо знаний на тестах можно угадать/логически домыслить. Получается демонстрация не знания, а умения найти правильный ответ.