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

Где грань между программистом и тестировщиком?

Такой вот полет мысли, может достаточно сумбурный родился после прочтения сегодня двух хороших статей: "Roles and Fluidity" Алана Пейджа и история про изменения в процессе разработки в Yahoo! "Who Needs QA? Not Yahoo!"

Еще вчера с товарищем Papa Minos (aka Никита Макаров) делились впечатлениями от выпуска RadioQA "QA: Пациент жив или мертв?", где @umputun раскатывал всех в тонкое тесто (хотя получилось это у него натужно и скорее в силу авторитета, а не согласия оппонентов).

Как мне кажется, всё сходится к одному: ролей, которые приходится играть при разработке ПО, много (здравствуй, КО). И искусство, мастерство, если хотите, заключается в том, чтобы уметь между этим ролями переключаться.

Кому то это удается хорошо, кто то справляется хуже, а кому то это вообще неинтересно, но роли есть и это факт.


Дальше можно много спорить о том, что "нафига переключаться", "на переключение тратиться много времени", "требуется больше знаний" и тд, и тп.
Но, умеющие переключаться, перевоплощаться, решают свои задачи эффективней. Команда с такими "артистами" результативней и в целом работать становиться легче.

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

Аналогично и обратное: если для решения своей задачи тестировщику требуется (оставим за рамками вопрос зачем) написать хотя бы простой скрипт, а он этого делать не умеет, то и задачу он решит (если вообще решит) скорее всего не так хорошо, как мог бы. Хороший пример в статье Алана.

И даже если объединение профессий программиста и тестировщика в разработчика (привет Леше Виноградову) мы пока (пока?) рассматриваем только в отдаленной туманной перспективе, то что делать со специализациями в рамках этих профессий?
Например, уже есть тестировщики, которые занимаются только нагрузочным тестированием, при этом навыки проверки UI у них слабые. Программисты, которые с закрытыми глазами напишут драйвер, но спасуют перед SQL-скриптами. И таких примеров можно приводить много. Контраргументом часто приводят точку зрения, что "знать все невозможно", а "специализация рождает скорость и правильность".

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

Возможно вам будет интересно:

Комментарии

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются.

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.