Экстремальное тестирование

Хотелось бы уточнить название поста. Я хотел бы написать о тестировании в XP команде.
Экстремальное программирование XP базируется на 12 основных практиках:

1. Разработка через тестирование (Test driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Whole team, Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous Integration)
6. Рефакторинг (Design Improvement, Refactor)
7. Частые небольшие релизы (Small Releases)
8. Простота (Simple design)
9. Метафора системы (System metaphor)
10. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
11. Стандарт кодирования (Coding standard or Coding conventions)
12. 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Теперь же попробуем проецировать практики на тестирование.

Из QAS в Dev, из Dev в QAS, реально ли?

Ну а вы как думаете дорогие читатели?

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

Вопрос на самом деле другой: Кому легче и быстрее будет переквалифицироваться? На самом деле описать такую тему меня подвигнул пост одного из популярных IT блогов в СНГ блог Виктора Ронина на тему Программист против QC . Этот пост обрел очень большую огласку в то время среди QA(QC) среды.

Кому легче в принципе опять же зависит от многих факторов: желания человека, базы как таковой, прошлой специализации и т.д. Но давайте рассмотрим по 2-м усредненным типам специалистов. Предположим у нас есть Саша – хороший разработчик ПО и Ваня – хороший QAS.

Программисты и QAS в одной комнате

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

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

Теперь поговорим о ситуации Dev+QAS. В принципе достоинства такого подхода думаю можно понять сразу же после примера с программистами. В команде, занимающейся над проектом, не должно быть людей лишних или мешающих. Все должны работать над одной большой целью:

Ты тестировщик ты должен уметь всё

Уже после создания опроса понял, что название темы дает двойственное понимание. Посему решил, что опишу оба варианта:
1. Совмещение позиции QA специалиста с какими то другими обязанностями
2. Необходимость большой базы знаний для качественного тестирования ПО

Итак, поехали по 1-му пункту:
Совмещение обязанностей, наверное, бесит абсолютно всех QA-специалистов(QAS). Если вы кроме тестирования занимаетесь программированием или администрированием сети, либо круче этого, вы - офис менеджер, то бросьте вы эту затею. Профессия тестировщика одна из тех, которым не пойдет «в плюс» совмещение позиций. Ведь вы профессионально тестируете софт, т.е. вы имеете деструктивное мышление, это вам не поможет не в обслуживании сети или офиса, а при разработке ПО будет всячески мешать, хоть и в некоторых случаях и помогать тоже.
При всем этом я вполне допускаю вариант тестировщика:

1. Выясняющего и пишущего постановку бизнес требований
2. Внедряющего ПО
3. В роли похожей на «Product owner» в Scrum
4. IT-консультанта

Почему?

1. Я уже много раз писал, что еще в начале проекта на этапе сбора требований нужно подключать QAS. А при должном опыте работы общения с заказчиками, такая задача вполне по плечу тестировщику. Если не верите, то у меня и Ромы был личный опыт.
2. Об этом я тоже давно пишу, что тестировщик лучше всех знает как установить и использовать софт. Не редкие случаи, когда тестировщик знает работу всего продукта лучше любого из разработчиков. Это объясняется тем, что QAS обычно работает со всем функционалом сразу. Кроме этого сборку и установку ПО каждый нормальный тестировщик обязан автоматизировать и в этом случае у него при внедрении все карты на руках :)
   
3. Этот пункт, что-то вытекающее из 1-го пункта, в довесок просто плотное общение с заказчиком
4. В принципе этот пункт я оставил напоследок, поскольку все скорее будет зависеть от самого человека, нежели от профессии, но я бы подчеркнул, что для QAS это не противоречивая должность

При этом нужно понимать, что тестирование программного обеспечения для компании является очень дорогим удовольствием. Содержать целую QA команду, не всегда является оптимальным по стоимости решением. Поэтому некую проверку продукта(релиза, проекта и т.д.) выполняют разные специалисты, еще чаще сами программисты.

Теперь по 2-му пункту:
База знаний QAS немногим уступает, а в идеале и вовсе должна быть больше базы разработчика. Кроме фундаментальных типов тестирования и инструментария к нему, тестировщик должен знать бизнес логику, архитектуру и наиболее рискованные участки софта. Знание всего вышеперечисленного уже является не малым багажом знаний.
Почему же я написал, что в идеале QAS должен знать больше самого разработчика? Я уже писал здесь, о том, какие знания разработчика должен иметь тестировщик и чем он должен владеть для меня в идеале.
Я понимаю, что в больших командах тестирования специалисты в большей мере узко специализированы и мое видение может показаться неправильным и не фундаментальным. Но я пока не имел опыта работы в действительно огромной команде тестирования и являюсь приверженцем, того что QAS должен быть универсально подкован во всех видах и типах тестирования.
Наверное, хватит! Извините за небольшой сумбур в описании. Получился 1 из примеров когда хотелось рассказать многое но не клеилось. Комментарии опять же приветствуются.

P.S. Обратно создал опрос на следующую интересующую тему. Выбирайте, срок почти тот же - 10 дней.

Опрос на то "О чем мне стоит написать?"

В общем то меня с каждым днем все больше и больше одолевает лень что то писать, поскольку все QA по сути пишут об одном и том же. Посему я решил создать опрос в этом блоге и написать пост так сказать "по заказу". Справа на странице вы можете увидеть все предлагаемые мной темы. Голосуйте, если вам это вообще интересно. Опрос продлится одну неделю после чего я отпишу пост на самую популярную. Может быть это станет традицией, кто знает :)

P.S. Не забывайте, что возможно выбрать несколько интересующих тем сразу.
Если вам не нравится вообще такая идея с опросом то это лично ваше мнение, которое вы можете отписать открыто в комментариях.

Так сказать "Welcome"

Закончил экспорт своих предыдущих сообщений с прошлого блога. Если кому интересно переход из ЖЖ в блоггер можно сделать вот так.
И еще для тех кто хочет добавить так называемую функцию "Read More" в блоггере вот сюда.
После экспорта через тулзу, Гугл обвинил меня в спаме и начал втыкать captcha везде где было возможно, но после нескольких писем все вернулось.
Ну теперь главное Welcome на мой блог товарищи)

Первый пост. Ознакомительный

Всем привет. Это мой первый пост в этом блоге. Кто я такой можно посмотреть в профиле.
В принципе это не первый мой блог. Предыдущий находился вот здесь. Все посты с того блога перенесу сюда и не буду париться. Причина перехода - это закрытый доступ к ЖЖ из моей страны, да и вообще функции Блоггера мне нравятся больше.
Теперь о чем буду писать.... Ммм. Ну в основном конечно писать буду о финтифлюшках и мыслях по своей специальности - QA. Интересно это будет или нет, решайте сами. Цель моего блога простая: хочу зафиксировать свое видение разных вещей и поделиться с другими. Ну начнем экспортировать старый блог с флагом в руках :)