Подсветить проблемы, предложить улучшения - это, разве, не есть то самое улучшение качества продукта? Продукт, который не имеет критических багов и удовлетворяет ожидания пользователей = качество, в свою очередь это тоже в некоторой степени позволяет повысить удовлетворённость продуктом со стороны пользователей, соответственно, количество жалоб будет не в огромных объёмах. "Значительно" естественно, не получится, но в целом имеет место быть. Кстати, тестировщики обычно выставляют не приоритет, а severity, поскольку бизнес владеет информацией о ресурсах, ожиданиях и прочем.
Относительно количества багов, тут тоже косвенно QA может влиять в том плане, что процессы будут совершенствоваться, приниматься дополнительные меры. Ну, например, на одном из моих проектов юнит тестирования поначалу не было, баги плодились в огромных количествах, по итогу менеджмент с подачи лида все таки ввел юнит тестирование, и вуаля, количество багов стало уменьшаться.
Если найден баг, то его без проблем закидывают на программиста, который фиксит его в том же спринте в основном, переносы на другие спринты бывают, конечно. Не понятно откуда у сочинителя статьи взялась проблема с якобы перекладыванием ответственности за баги.
Если есть что-то типа стандартов, как для QA от ISTQB, то курсы бесполезны, выучить необходимую инфу можно из материалов для подготовки к сертификации. А вот практика уже сложнее, тут уже курсы, если там практическая часть, могут помочь хотя бы фидбеком от преподов. Ну и если уж и идти, то лучше на курсы от самих айти компаний.
То есть до рождения ребенка автор была таким себе тестировщиком. Остаётся открытым вопрос с мужчинами, они то обычно в декрет не ходят. Странная статья, однако.
Вообще не понятно, зачем переживать по этому поводу. Смысл такой проверки в том, чтобы определить навыки решения практических задач, а не за сколько времени ты решишь новую, не имеет ровным счётом никакого значения, когда задача была решена.
Извечная проблема: не имеешь опыта работы с инструментами - не достоин вакансии:) Почему бы кандидату, который никогда не имел опыта в использовании Appium, но имеет опыт работы с другими инструментами автоматизации, не дать шанс показать себя на проекте? Ну или соискатель не имеет опыта работы, допустим, с Android studio, но ориентируется в программе - почему бы такому соискателю не дать шанс? Естественно, что прежде чем давать шансы, нужно оценить тулзовину, сложна ли она в освоении или нет.
Чтобы ссылаться на это требование для начала должна существовать реальная угроза, а ещё факты, "возможно мой код используют" - не является таковым фактом.
Прям все так идеально, а по факту тестировщики вступают в работу в основном, когда тикеты уже готовы для тестирования в спринте. Что "будем делать" настолько сырое, что можно создать лишь базовые проверки, которые в последствии нужно будет апдейтить, потому что недалеко от ready for testing в тикете появляются новые дополнения.
Одна вода, непонятные придирки к стандартам, абсолютно для всего существуют оные. Особенно про изучение модальный глаголов и будущего времени перед present simple насмешило. В общем, пук в лужу, как говорят
Роман Савин слегка устарел. Читать его только в ознакомительных целях и в последнюю очередь.
Английский это маст хэв, при чем на уровне intermediate/upper-intermediate.
Html/css/js - тоже. Не говоря уже о простеньких средствах, как инструменты разработчика в браузере. Selemium, Postman и подобные. Для мобайла это XCode and Android Studio.
Сейчас планка для тестировщиков значительно повысилась.
Кафка и Рэббит специфическое ПО, которое больше предназначено для программистов, а не тестировщиков. Обычно мануальщиков и автоматизацию не смешивают
В США это норма. Сегодня тебя хвалят, а завтра сократили.
Подсветить проблемы, предложить улучшения - это, разве, не есть то самое улучшение качества продукта? Продукт, который не имеет критических багов и удовлетворяет ожидания пользователей = качество, в свою очередь это тоже в некоторой степени позволяет повысить удовлетворённость продуктом со стороны пользователей, соответственно, количество жалоб будет не в огромных объёмах. "Значительно" естественно, не получится, но в целом имеет место быть. Кстати, тестировщики обычно выставляют не приоритет, а severity, поскольку бизнес владеет информацией о ресурсах, ожиданиях и прочем.
Относительно количества багов, тут тоже косвенно QA может влиять в том плане, что процессы будут совершенствоваться, приниматься дополнительные меры. Ну, например, на одном из моих проектов юнит тестирования поначалу не было, баги плодились в огромных количествах, по итогу менеджмент с подачи лида все таки ввел юнит тестирование, и вуаля, количество багов стало уменьшаться.
Если найден баг, то его без проблем закидывают на программиста, который фиксит его в том же спринте в основном, переносы на другие спринты бывают, конечно. Не понятно откуда у сочинителя статьи взялась проблема с якобы перекладыванием ответственности за баги.
Если есть что-то типа стандартов, как для QA от ISTQB, то курсы бесполезны, выучить необходимую инфу можно из материалов для подготовки к сертификации. А вот практика уже сложнее, тут уже курсы, если там практическая часть, могут помочь хотя бы фидбеком от преподов. Ну и если уж и идти, то лучше на курсы от самих айти компаний.
То есть до рождения ребенка автор была таким себе тестировщиком. Остаётся открытым вопрос с мужчинами, они то обычно в декрет не ходят. Странная статья, однако.
"Set Sort" был специфическим кейсом? Тогда это обычная практика, мало кто будет исправлять то, до чего додумались единичные пользователи
Так это из-за санкций, а так подано, будто реально зарубежное ПО стало терять популярность.
Смотрят не на курсы и доп. образование, а на наличие сертификатов от центров сертификации, широкоизвестных, конечно.
Вообще не понятно, зачем переживать по этому поводу. Смысл такой проверки в том, чтобы определить навыки решения практических задач, а не за сколько времени ты решишь новую, не имеет ровным счётом никакого значения, когда задача была решена.
Извечная проблема: не имеешь опыта работы с инструментами - не достоин вакансии:) Почему бы кандидату, который никогда не имел опыта в использовании Appium, но имеет опыт работы с другими инструментами автоматизации, не дать шанс показать себя на проекте? Ну или соискатель не имеет опыта работы, допустим, с Android studio, но ориентируется в программе - почему бы такому соискателю не дать шанс? Естественно, что прежде чем давать шансы, нужно оценить тулзовину, сложна ли она в освоении или нет.
В Functional testing пункты из non-functional. Например, посторонние предметы обнаружены не были - это явно секьюрити
Чтобы ссылаться на это требование для начала должна существовать реальная угроза, а ещё факты, "возможно мой код используют" - не является таковым фактом.
Прям все так идеально, а по факту тестировщики вступают в работу в основном, когда тикеты уже готовы для тестирования в спринте. Что "будем делать" настолько сырое, что можно создать лишь базовые проверки, которые в последствии нужно будет апдейтить, потому что недалеко от ready for testing в тикете появляются новые дополнения.
+к луддизму. Но ничего, скоро ИИ станет нормой
Одна вода, непонятные придирки к стандартам, абсолютно для всего существуют оные. Особенно про изучение модальный глаголов и будущего времени перед present simple насмешило. В общем, пук в лужу, как говорят
А на дале Твиттер загнётся из-за нехватки специалистов
Никаких смещений там нет, в целом помогает понять, кто чем занят и какие есть блокеры
Роман Савин слегка устарел. Читать его только в ознакомительных целях и в последнюю очередь.
Английский это маст хэв, при чем на уровне intermediate/upper-intermediate.
Html/css/js - тоже. Не говоря уже о простеньких средствах, как инструменты разработчика в браузере. Selemium, Postman и подобные. Для мобайла это XCode and Android Studio.
Сейчас планка для тестировщиков значительно повысилась.