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

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

В этой заметке мы расскажем о том, как появлялись различные сообщества тестировщиков в странах СНГ, что было причиной их возникновения, как они развивались и о текущем состоянии дел.

Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

На форуме тестировщиков и в блогах часто появляются вопросы: с чего начинать тестировщику, который только-только выбрал свою стезю?

С одной стороны, сейчас много курсов в этой области, которые проводятся на базе портала Software-Testing.Ru, УЦ Luxoft, EPAM Systems и т.д.
С другой стороны, начинающему тестировщику далеко не всегда нужны курсы. Если вы ещё не знаете, в каком направлении развиваться, какие области интересны, какие знания хочется получать – то о каких курсах идёт речь? А комплексного ВУЗовского образования для тестировщиков в СНГ пока что нет… В итоге, многие люди не могут быстро «влиться» в профессию, найти направление для развития и понять, «что и как надо изучать для быстрого старта?».

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

Итак, 7 шагов от чайника к тестировщику.

Вместо вступления

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

Я работаю в автоматизации тестирования уже более пяти лет. Более всего я работал с ОС Windows. Мы пишем скрипты на Borland SilkTest. Я знаком и с другими средами разработки автоматизированных тестов, такими как QTP и TestComplete – у каждого продукта есть свои достоинства, но, к сожалению, и свои недостатки. Возникают проблемы, которые очень сложно решить «не выходя из системы»*

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

Но если присмотреться внимательнее, то под видимостью продуктивного сотрудничества зачастую скрывается абсолютное непонимание разработчиков: «зачем эти тестеры вообще нужны??». Это непонимание нередко является взаимным, и несмотря на кажущуюся миролюбивость, оставляет в совместной работе лишь видимость продуктивности.

В апреле этого года в Казани пройдёт 9-я конференция SQA Days. На ней, как и всегда, соберутся ведущие умы, гуру и эксперты в области тестирования. Её участниками, как и всегда, будут наиболее активные представители сферы контроля качества. На ней, как и всегда, каждый получит желаемое: тонны информации, века консолидированного опыта, террабайты мотивашечек.

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

Есть типовая корпоративная задача — создать и развить практику тестирования для нескольких подразделений, продуктов или проектов. Как один из универсальных вариантов решения рассмотрим организацию отдела.

Вопрос эффективности и рациональности я ставлю во главу угла, поэтому вопрос быть или не быть практике тестирования нужно обсуждать не в этом разделе. Кому не нужно тестирование и кто хочет сделать это самостоятельно силами разработчиков — могут не читать далее :) или все-же взвесить аргументы:
1. Профессия тестировщика не нуждается в обосновании, жизнь доказала потребность :)
2. Независимое тестирование позволяет выполнять работу для нескольких подразделений, продуктов или проектов.
3. Сложные виды тестирования требуют организационной формы для закупки инструмента, который будет использован (и амортизирован) для нескольких подразделений, продуктов или проектов.
4. Тестирование на этапе приемки в корпорациях выполняется для большого спектра продуктов или технологий.
5. Тестирование длительных жизненных циклов требует взаимозаменяемости участников и групповой (не только персональной) компетенции, например, тесты сопровождаемых систем со стороны заказчика или организации внедрения или сопровождения.

Disclimer: универсальных рецептов не бывает, автор исходит из опыта создания и развития практики тестирования в крупных ИТ-компаниях и не претендует на истину во всех инстанциях :)

Зачем нужны тестеры набранные из пользователей

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

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

Если присмотреться к различным ИТ-профессиям, складывается ощущение, что «движухи» у тестировщиков больше, чем в любом другом направлении. Оно и понятно: отрасль молодая, незрелая, и уровень квалификации по сравнению с западным отстаёт.

При этом может показаться, что обучение — это сложно или дорого. Как бы не так! У тестировщиков есть масса возможностей учиться либо совсем недорого, либо вообще бесплатно! Сегодня я хочу поделиться новостями в мире обучения тестировщиков: надеюсь, каждый заинтересованный найдёт для себя что-то подходящее.

Мы c камрадом eagleson провели не претендуя на научность небольшой опрос «Чего не хватает и что мешает тестировщикам ПО?» и были не на шутку заинтересованы лидерами голосования, в числе который оказался, например, такой вариант ответа как «Понимание целей и задач процесса тестирования» за который проголосовало около 50% респондентов.

То есть, 50% респондентов (выборка не большая, 500 человек, по ссылке все результаты голосования и все варианты опроса) считаю, что тестировщики с которыми они работают не вникают в цели и задачи процесса тестирования?

Мы решили обсудить эту тему и пригласили записать небольшой подкаст нашего коллегу из Харькова Глеба Рыбалко.

Мы с eagleson работали в тестировании каждый лет по 7-8, а Глеб Рыбалко и сейчас работает в области тестирования и обеспечения качества уже около 6-ти лет. Он успел поработать в Харькове, Львове и Днепропетровске. За это время прошел долгий путь от младшего инженера тестировщика до руководителя нескольких групп тестирования на большом проекте в крупнейшей украинской IT компании.

Подскаст получился небольшой, всего 20 минут. Мы не ставили целью разобраться в деталях, хотели просто понять, почему могли возникнуть такие странные результаты.

Тестировщики и правда не понимают целей и задач тестирования ПО?

Мы продолжаем говорить со специалистами в области тестирования ПО, чтобы разобраться в вопросе «Что случилось с тестировщиками?»

В теме продолжают разбираться Слава Панкратов (case) и Саша Орлов (eagleson) — в славном боевом прошлом специалисты и руководители команд по тестированию.

Напомним, что мы провели небольшой опрос на сайте www.it4business.ru к которому присоединились наши коллеги из сообщества www.happy-pm.com и сообщество Стратоплан.Ру в Фесбуке из которого узнали, что половина опрошенных считает проблемой тестировщиков ПО непонимание целей и задач тестирования ПО.

Мы уже записали и опубликовали на Хабре небольшой подкаст с Глебом Рыбалко, который работает в тестировании более 6 лет.

Сегодня мы пригласили побеседовать на эту тему Алексея Лянгузова: 11 лет в тестировании, tech lead команды тестирования в Oracle, до этого работал в TogetherSoft и Borland, со-основатель сообщества тестировщиков Санкт-Петербурга.

Причины, которые, как нам показалось, могут пояснить, почему 50% опрошенных, солидарны в своей позиции: «Тестировщики не понимают целей и задач тестирования».

1. Мы не говорим, что и как мы делаем: недостаток визибилити и прозрачности нашей работы для других членов команды или соседних рабочих групп и отделов.
2. Мы не можем банально посчитать в цифрах эффективность наших решений и показать результаты нашей работы.
3. Мы не готовы честно провести анализ полученных результатов и сказать «Да, я провтыкал и ошибся».
4. Мы закапываемся в работу и забываем, что «пилу надо точить»: книги, вебинары, публикации, тренинги – всего этого в нашей отрасли сейчас навалом.
5. Мы не смотрим шире своих рабочих задач: многие из нас тестировщиков «стажировались» в группе разработки за последний год? Не барское дело, понятно.
6. Мы не делимся опытом и наработками с другими группами: аналитики, программисты, менеджеры, наконец! А у нас есть что сказать: тестировщики — это пользователь номер 1 любого программного продукта. И только они знают готов ли он к запуску или нет.

Конечно, есть еще одна, банальная причина того, что тестировщиков ПО не воспринимают, как специалистов, которые понимают, что и зачем они делают. Даже не причина, а источник проблем — мы сами.

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

Мы просто делаем все последовательно. Есть проблема? Надо собрать мнения — собрали, предложили их вам обсудить. Если есть проблема, то, наверняка, есть и решение — и мы нашли людей, которые готовы поделиться с нами опытом своих побед проблем в тестировании, которые мы нашли.

Сегодня с нами Катя Каменева, менеджер по тестированию из Днепропетровска, которая подходит к решению этих и других вопросов просто: если надо учится самой, почему бы не делать это у самого Джеймса Баха, если выбираться на природу, то можно устроить выездной семинар для всей команды, а если уж учить команду тестировщиков, то нужно взяться и организовать Днепропетровское сообщество тестировщиков!

Вот такой способ решать проблемы, коллеги. Катя не читает себя «мастодонтом в ИТ», тоже голосовала за «Непонимание целей и задач тестирования» тестировщиками, но при этом берется решать задачи, не рассказывая чего ей для этого не хватает.

Мы запланировали еще одну интересную онлайн-встречу, чтобы окончательно закрыть тему и доказать, что если проблема решаема, то она решаема не одним способом!

Какие бывают баги

1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

В настоящее время, стать первопроходцем в географии достаточно сложно. Есть физика, химия, биология… Но там слово первопроходец несет немного другой смысл. Да, они тоже идут в неизведанные области, но все равно это как то не так. Нас, программистов, так же как биологов и etc, относить к первопроходцам тяжело. Но есть люди, с которыми мы часто спорим, но именно они истинные первопроходцы современности. Именно им, приходиться лезть в дебри наших интерфейсов, разбираться в сложных взаимосвязях наших ошибок, да и, что уж греха таить, ворчать на нас, за отсутствие торных путей.
Ладно, с лирикой завязываю, начинаю по теме. Те кто был на QADay и слушал Чарлза Стерлина, в принципе дальше может не читать, кстати, все кто уже пробовал Exploratory Testing, в принципе тоже. Для остальных, позвольте коротенько рассказать о исследовательском тестировании при помощи Visual Studio 11 и, соответственно, TFS 11.
Вперед, в пампасы?

И чем оно отличается от тестирования по сценариям (сценарного тестирования)

Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.
 

Исследовательское тестирование является мощным и приятным подходом к тестированию. В некоторых случаях оно может быть более продуктивным, чем привычное тестирование по сценариям. Я не встречал еще тестировщика, который бы не применял исследовательское тестирование, хотя бы на бессознательном уровне. Тем не менее, мало кто из нас подробно изучал этот подход, и он еще не так признан в нашей области. Пора нам прекратить его отрицание, и публично признать исследовательский подход, таким какой он есть: научным мышлением в режиме реального времени. Друзья, это классная вещь!

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

Требования к инструменту

На мой взгляд, такой инструмент должен:

1. Быть интегрирован с системой баг-трекинга, чтобы можно было заводить дефекты по мере их обнаружения
2. Автоматически документировать обнаруженный дефект. Это важно, когда тест идёт не по сценарию, а в произвольной последовательности, которую невозможно держать в голове
3. Обеспечивать возможность повторения последовательности исследовательского теста
4. Быть интегрирован с системой управления требованиями — чтобы по возможности привязывать обнаруженные дефекты к требованиям
5. Быть интегрирован с системой управления тестами, чтобы:

• проводить все виды тестирования в единой среде
• создавать новые сценарии тестирования на основе исследовательских тестов

Собственно, оптимальным вариантом в этом смысле будет наличие поддержки исследовательского тестирования в интегрированном инструменте управления требованиями, тестами и дефектами. Об одном из таких инструментов — Microsoft Test Manager 2012 — я и хочу рассказать.
В 2012-й версии MTM появилась поддержка исследовательского тестирования. Способы применения этого функционала мне видятся следующие:

1. Проведение исследовательского тестирования в дополнение к тестам по сценариям
2. Проведение тестирования в условиях отсутствия сценариев тестирования
3. Быстрое создание новых сценариев тестирования через сеансы исследовательского тестирования

Красивая идея продукта в рамках крупной компании или стартапа почти всегда неизбежно сталкивается с рядом сложностей на этапе воплощения. Частенько бывает, что работа идет, баги фиксятся, релиз приближается, но общего понимания состояния продукта нет как нет. Так бывает потому, что собственная гениальность создателей софта или сервиса (особенно если речь идет о стартапах) застит им глаза, и проблемы продукта понимаются неадекватно. Как результат — в лучшем случае команда не попадает в сроки релиза, а в худшем – на свет появляется нежизнеспособный продукт, который пользователи презрительно называют альфой и шлют создателям лучи ненависти через форму обратной связи.

Капитан Очевидность намекает: чтобы такого не допустить, важно уметь понимать, в каком состоянии находится ваш продукт на каждом этапе его развития. В этой большой статье предлагается методика оценки его состояния в самой наглядной форме – в форме таблиц и графиков. Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Чтобы было понятно: мы делаем Parallels Plesk Panel – хостинг-панель, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга. Применив эту методику, мы получили вот такие результаты:

1. существенно улучшилось качество выпускаемых релизов (согласно Incident rate);
2. релизы стали более предсказуемыми, точность наших прогнозов и оценок выросла в разы;
3. появилось понимание, почему что-то идёт не так и как этого избежать в будущем.

Заинтересованных лиц прошу под кат и в комменты. Отвечу на любые вопросы.

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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

Пролог

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

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