К основному контенту

Заблуждения о профессии тестировщика в России

На одном из занятий в МГТУ им. Баумана была рассмотрена интересная тема, касаемая профессии тестировщика. Ниже приведена схема "Топ 10 заблуждений о профессии тестировщика в России".
(источник: http://www.xmind.net/m/mKd7)
           Так как данная профессия установилась относительно недавно, многие заблуждения постепенно развеиваются. Но поговорить о них все таки стоит.
           Я бы сравнила тестировщика с поваром. Он тестирует продукт по рецепту, который написан в книге, но добавляет свою изюминку, что позволяет найти больше несоответствий в программном продукте. Ведь не все люди могут готовить одинаково.
          В профессии повара есть разделения: кто-то идеально готовит десерты, кто-то горячие блюда, а кто-то закуски. Так и в тестировании: кто-то функциональщик, кто-то автоматизатор, а кто-то нагрузочник. У тестирования, как и у кулинарии, есть свой шеф-повар, гуру, к уровню которого стоит стремиться.
           "Тестировщик - это профессия для молодежи", "Тестировщикам не надо много платить, тестировщик должен работать за идею" - данные заблуждения меня удивляют. Чем тестировщик - автоматизатор отличается от разработчика? Практически ничем, только разработчик пишет код программы, а тестировщик - автоматизатор пишет код, тестирующий программу. Почему разработчики могут быть любого возраста, а на тестировщиков накладывается ограничение? Тогда можно утверждать, что и разработчик - профессия для молодежи, и ему можно не платить)
           "Тестировать может каждый, так как у каждого сейчас есть ПК и смартфон", "Не нужно вкладываться компании в обучение тестировщиков, так как можно взять любого с улицы ...", "Можно стать тестировщиком ничего не зная и не умея, просто прийти, сесть за ПК и начать работать", "Тестирование - это просто, тут нечему учиться" - эти заблуждения можно сгруппировать в одно "Тестирование и профессия "тестировщик" самое простое, что есть в сфере IT". Но! Почему же тогда на собеседовании требуют от кандидата знаний столько, сколько от разработчика? Как работать тестировщику в команде, не понимая о чем они разговаривают? Не все гуманитарии знакомы с терминологией IT-шников, например.
             Такое заблуждение, как "Ответственность за качество продукта лежит только на тестировщиках", достаточно популярно. За качество продукта отвечает вся команда разработки, от аналитика до тестировщика. Как может отвечать тестировщик, например, за некачественно спроектированную БД аналатиком? Или за полностью неработающий код программиста? Ответ прост: тестировщик может помочь избежать несоответствия продукта на ранних стадиях жизненого цикла разработки, но не отвечать за все качество продукта.
             Подводя итог моего монолога, хочется сказать, что тестировщик должен думать и как аналитик, и как разработчик, и как дизайнер, а главное как заказчик - пользователь. Он отвечает за качество продукта, но не за весь продукт. Утверждать, что тестирование - это просто, как минимум странно, так как данная сфера достаточно многогранна и сложна, и требует понимания любой сферы деятельности, для которой разрабатывается продукт.

Комментарии

  1. Casinos Near Me - DrmCD
    There is 군산 출장안마 no gambling 광주광역 출장마사지 guide for casinos in 순천 출장안마 Las Vegas, Nevada. Casinos 공주 출장샵 Near Me 경주 출장마사지 · Treasure Island Casino & Resort · The Mirage Hotel & Casino · Harrah's Las Vegas

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша