Отчет о SQADays-6, Москва, 28-29 октября 2009

Всем доброго дня!
Хочу и я внести свою лепту, свое видение прошедшего мероприятия - совместной конференции SQADays & CEE-SECR.
Как организатор конференций я безусловно видел много проколов. Однако, на мой взгляд, лучше заострять внимание на позитиве, ну и на объективных фактах, от которых не уйти.
Совместная конференция в моем видении создавалась как площадка для общения специалистов, представляющих разные роли на проекте. Ни для кого не секрет, что в ситуации, когда люди не представляют, чем занимаются другие специалисты на проекте, это вызывает напряженность, откровенную неприязнь. И с другой стороны, когда люди четко представляют чем занимается коллега за соседним столом, это вызывает желание сотрудничать, помогать друг другу, ну и в конце концов, у каждого есть возможность доказать свой профессионализм. Для того чтобы сгладить непонимание ролей друг друга и создавалась эта конференция. Соединение инженерных ролей (в рамках CEE-SECR)и ролей, связанных с качеством (в рамках SQA Days) неслучайно. Очень часто я наблюдаю ситуацию, когда специалист по качеству на проекте самый "затюканный" человек. Отчасти виноват и он сам. Поскольку нужно стремиться к совершенствованию знаний и навыков, а не оставаться "monkey" тестером. Другая проблема, что существует сложившийся стереотип (который я и стараюсь разрушить), что специалист по качеству скорее мешает, чем помогает. "Я могу протестировать и сам", - часто можно услышать от разработчика. В этом кроется безграничное заблуждение. Ведь вдумайтесь: специалист по качеству обеспечивает конечное звено в выпуске программного продукта. Далее продукт будет оценивать заказчик. И кому он будет "давать по балде"? Во многом от специалиста по качеству зависит, будет доволен заказчик или нет. А это уже напрямую влияет на бизнес-результаты компании.
Мое видение специалиста по качеству следующее:
тестировщик - это аналитик (он обязан уметь читать ТЗ, анализировать требования, находить в них противоречия, в конце концов, приводить их в божеский вид),
это разработчик (тестировщик без знания навыков программирования не совсем полноценный тестировщик (прошу прощения у тех, кто так не считает. Здесь только мое мнение.) Знания языков программирования нужно для умения читать код программного продукта, тем самым находить потенциальные проблемы. Знание языков программирования позволяет тестировщику создать эффективный фреймворк для выполнения тестов. И т.д. Надеюсь, я говорю достаточно убедительно)
это Тестировщик (здесь пишу с большой буквы, поскольку в настоящее время нельзя быть просто тестировщиком, а нужно быть специалистом, владеющим широким спектром инструментов по тестированию и подходами к тестированию. Повторюсь, не стоит быть "monkey" тестером. Нужно быть специалистом с большой буквы).
это технический писатель (как это не прискорбно звучит, но часто выделенная роль технического писателя в проекте отсутствует и ее успешно выполняют тестировщики (хоть и возмущаются немножко :) ). Проблема выделенной роли технического писателя имеет те же корни, что и проблема понимания роли тестировщика. К сожалению, в этом направлении очень непросто работать. Но это тема не для этого блога, и я обязуюсь написать о проблеме более подробнее).
это внедренец (тестировщик присутствует на приемо-сдаточных испытаниях у заказчика и часто ему приходится выполнять "танцы с бубном", чтобы проект был сдан. Очень часто ему приходится терпеть откровенное хамство, недовольство заказчика (проект никогда не бывает готов на 100%), но не забываем, что прямое общение с заказчиком, это также и задел на будущее. Угадайте к кому заказчик обращается в первую очередь по вопросам бизнес-процессов программного продукта?

Надеюсь, я в достаточной мере раскрыл роль тестировщика. По крайней мере, как я ее вижу. Именно с такими людьми я работал, и стараюсь воспитывать именно таких специалистов.
Жизнь показала, что такие специалисты пользуются уважением у коллег, представляющих другие роли. Полагаю, их есть за что уважать.

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

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

Кстати, наконец был услышан призыв приносить визитки и обмениваться ими. Сам лично наблюдал, как шел этот процесс :)

Не хочу останавливаться на деталях, касающихся тематики докладов и организационных моментах (даю это на откуп участникам, т.к. не хочу показаться необъективным). Как всегда были интересные доклады и были не очень. Свои отпечаток наложил большой конкурс, в результате которого докладов, связанных с тематикой Quality Assurance оказалась не так много как хотелось бы. В любом случае мы собираемся восполнить этот недостаток на 7й конференции SQA Days, которая пройдет в мае 2010 в Харькове.

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

Хочу пожелать всем дальнейшего профессионального совершенствования. Ну и, конечно, удачи по жизни.

Встретимся на будущих мероприятиях. Уже скоро!