Вебинар "Работа с требованиями: анализ, тестирование" состоялся. Отчет.

Вчера я провела свой первый вебинар на тему тестирования требований. Мне понравилось, как прошло. Теперь жду отзывов с подтверждениями и с критикой.
Группа хорошая, ребята активные, решали задания, задавали вопросы, просили говорить помедленнее :)

Структуру я построила таким образом, чтоб индукторам было легко сразу, а дедукторам не пришлось долго ждать, чтоб включиться. Поясню. Есть такое понятие в методиках обучения взрослых людей, как Цикл Колба. Для того, чтобы взрослому человеку обучиться какому-либо сложному навыку максимально эффективно, то он должен пройти по четырем стадиям:

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

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

Оставив нашего героя чесать репу над тем, что же он сделал не так, мы обратились к теории.

Второй этап был теоретический:
1. Что такое требования. Методы их фиксации.
2. Какие бывают требования
3. Что с ними можно делать.
4. Где здесь тестирование. Зачем нам это?
5. На что тестировать? Критерии хороших, качественных требований.
6. Методы тестирования требований
7. Заключение

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

И получили домашнее задание.

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



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









Читать далее...

Где брать тестировщиков: методы поиска, найма и обучения

Многие наверняка уже видели слайдкаст моего выступления на Test Labs 2009. В дополнение я выкладываю сам текст доклада. Он не содержит вставок анализа методов набора сотрудников в зависимости от ситуации на рынке, а вот сам костяк сообщения, которое я хотела до вас донести, здесь есть.

Где брать тестировщиков

View more presentations from jnechaeva.

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

Думаю, каждый из вас сталкивался с ситуацией, когда нужного человека в нужный срок за нужные деньги подобрать не получается. Причин тому может быть множество. Сессия, – и способные студенты не ходят по собеседованиям. Или Гугл открыл филиал в вашем городе, и все хорошие специалисты уже там, и их оттуда не переманить ни деньгами, ни статусом компании, ни интересными проектами. Или на рынок вышел Слава Панкратов и набирает себе подмастерий, и тут уже даже у Гугла проблемы с набором сотрудников :)
Нам же деваться некуда – люди нужны.

Успех зависит от стратегии компании в наборе сотрудников, от её гибкости и способности к адаптации, а также от понимания ситуации на рынке, сопоставления её с потребностями и возможностями компании.

Как же можно набирать людей:

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

Да, и, конечно же, – не есть правильно просто следовать однажды выбранной стратегии независимо от ситуации на рынке и от того, какие именно специалисты, в какой срок, в какой бюджет нам нужны.

Способ 1. Набор специалистов с опытом работы в тестировании:

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


Плюсы метода:

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

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

Минусы метода:

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

Методика набора готовых специалистов оправдывает себя в том случае, если вам нужен и сразу (!) специалист с определенным набором знаний и умений и вы готовы за это платить.

Способ 2. Набор людей без опыта работы в тестировании и обучение их на производстве:

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

Плюсы метода:

- Мы сами обучаем ребят тому, что нам нужно;
- На первых порах зарплата такого сотрудника меньше: важно к моменту становления человека как специалиста достичь адекватного уровня оплаты;
- Стремление к обучению и отсутствие «звёздности»: вероятность ситуации «я уже всё знаю и мне нечему больше учиться» минимальна при условии выбора правильного человека;

Перед вами чистый лист, который вы сможете обучить так, как вы хотите, и тому, чему вы хотите. Относительно недорого. .

Минусы метода:

- Большой поток на собеседованиях;
- Возможность вырастить очень узкого специалиста;
- На обучение студента тестированию нужно дополнительное время: такой сотрудник войдет на проект не сразу;
- Возможность промаха с «обучаемый» и способный.

Таким образом, этот способ оправдывает себя, если вы не можете позволить себе платить большую зарплату готовому специалисту, если вам не горит вход ресурса на проект, то есть вы можете себе позволить потратить время на его обучение, если вам НУЖНЫ такие ребята, чистые и гибкие. Это может зависить от специфики проекта и специфики коллектива. .

Способ 3. Создание пула тестировщиков, откуда при открытии горящей вакансии сразу же берется нужный человек:

- Предсказываем расширение проектов количественно и качественно;
- Не торопясь, заранее набираем специалистов;
- Вводим их на проекты по мере надобности.

Плюсы метода:

- Уменьшение зависимости от колебаний рынка;
- Доступность специалистов в любой момент;
- Предсказуемость специалистов по техническим умениям и человеческим качествам;
- Снижение рисков, связанных с уходом сотрудников.

Минусы метода:

- Дорого: это может себе позволить только большая компания;
- Риск неоправдания предсказаний существует: нельзя полагаться на бекап полностью, может не оказаться нужного специалиста, может не оказаться нужного количества и т.д.;
- Люди могут «скиснуть»: бекап должен быть правильно организован, чтобы не превратиться в скамью запасных.

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

Способ 4. Организация бекапа снаружи компании – внешняя система обучения:

- Изучаем предложение: смотрим на ВУЗы и студентов;
- Изучаем спрос: смотрим внутрь себя, понимаем, какие специалисты нам нужны в перспективе, чему их нужно научить;
- Создаем программу обучения;
- Стартуем программу, обучаем ребят, снимаем сливки, то есть по мере необходимости приглашаем ребят на работу.

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

Плюсы метода:

- Обучаем «под себя», но достаточно широко;
- Предсказуемость ребят в плане обучаемости и желания работать;
- Предсказуемость ребят в плане способностей и склонностей;
- За время обучения ребята становятся лояльными к вашей компании;

Обратите внимание – это готовые специалисты! Да, без опыта, но с теоретическими знаниями, широкого профиля, гибкие, мы наблюдаем их во время обучения, то есть они не преподнесут нам сюрпризов вроде неспособности обучаться.

- Имиджевая составляющая: компания, организующая собственную систему обучения, воспринимается как стабильная, серьезная компания с далекоидущими планами;
- Колоссальный и очень полезный опыт для компании и специалистов, которые к этому имеют отношение.

Минусы метода:

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

Если вы можете себе это позволить – это очень хорошая активность, очень полезная и очень интересная. Главное – определиться с целями и потребностями.

Нет верного ответа на все времена «как лучше и эффективнее нанимать тестировщиков». Перед тем, как принимать решение, где и как мы будем искать человека, нужно сесть и подумать: ЗАЧЕМ?

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

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




Читать далее...

Аналитика для тестировщиков

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

Можно научиться методикам и инструментам работы с требованиями. Но для того, чтобы делать что-то эффективно, нужно в первую очередь понимать цель. И только затем – знать методики. Тестировщик должен уметь работать с требованиями, и он должен делать это также осознанно, как процедуру утренней чистки зубов. А то и более ;-)

Серию семинаров «Аналитика для тестировщиков» открывают два первых семинара:

«Работа с требованиями: анализ, тестирование» (10 декабря, 13:00-15:00)

• Когда и зачем привлекать тестировщиков к анализу и тестированию требований.


• Критерии качественного требования.


• Свойства требований.


• Функциональные и нефункциональные требования.


• Явные и неявные требования.


• Методики тестирования требований.


• Полномочия и компетенции тестировщиков при работе с требованиями.

«Работа с требованиями: управление изменениями» (24 декабря, 13:00-15:00)

• Требования будут изменяться. Всегда!


• Влияние изменений в требованиях на тестирование.


• Изменения объема.


• Изменения сути.


• Изменения конфигурации.


• Конфликты и гибкость требований и тестов.


• Трассировка изменений требований.


• Повторное использование.

Семинары в формате вебинаров будут проходить совместно с порталом http://Software-Testing.Ru. Условия участия здесь.

Бытует мнение, что основная задача тестирования – проверка соответствия разработанного приложения требованиям и поиск ошибок. Но как же часто встречается ситуация, когда сами требования содержат ошибки. Ошибки нефункциональные, а логические, ошибки бизнес-логики, недомолвки, двусмысленности.

Когда Филиппа Крухтена спросили, что такое качество продукта, он ответил: «Качество — это соответствие ожиданиям Заказчика/Пользователя».

А что, если ожидания пользователя были поняты неверно изначально? Тогда продукт, даже если он вопреки статистике (теории вероятности) не содержит ни одной функциональной ошибки, не сможет удовлетворить ни заказчика, ни конечного пользователя.

Составление требований – удел (хотите, называйте это обязанностью или компетенцией) аналитиков. А вот за создание качественного программного продукта ответственна вся команда. Именно поэтому все участники процесса разработки должны быть причастны к созданию продукта с самого начала и дополнять друг друга.

В процессе разработки тестировщик дополняет и проверяет работу разработчика. А где же тестировщик может дополнять и проверять аналитика? В тестировании до разработки. В тестировании требований.

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

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

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

Что же, если у вас в команде свои аналитики? Соглашусь с высказываением, что каждый должен заниматься своим делом. Действительно, тестировщик никогда не сравнится со «специально обученным» аналитиком. Ну и не нужно равняться. Нужно делать то, что по силам, и то, что работает на улучшение качества программных продуктов. Предотвращение дефектов – это уже не контроль качества (Quality Control), а элементы его обеспечения (Quality Assurance).

Сложно ли научиться дополнять и проверять работу аналитика? Не думаю. Ведь аналитический склад ума и так присущ нам, тестировщикам, иначе бы мы навсегда остались на уровне «маускликеров». Мы анализируем поведение приложения в различных ситуациях, придумываем эти самые ситуации, основываясь на бизнес-приоритетах и сценариях поведения пользователей. Мы выясняем все недовыясненные моменты и доказываем разработчикам, что заказчику нужно другое, отличное от реализованного.

Мы не будем с вами слушать теорию. Теорию можно почитать и самим. Мы будем с вами пробовать все руками на тестовом проекте с тестовыми требованиями.

Оговорюсь, что всему этому конечно же нельзя научиться за 2 часа. Моя цель – показать вам, где мы можем дополнять работу аналитика, и показать вам, что чем более осознанно мы это делаем, тем больше пользы это приносит продукту, команде и нашему профессионализму.




Читать далее...

Програма дистанционного обучения "Junior QC Engineer"

В октябре руководитель отдела HR предложил мне заняться дистанционным обучением студентов.

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

Ранее подобные практики применялись только к кандидатам в разработчики, и вот решено было начать подобное для тестировщиков.

Я, естественно, тут же согласилась и с полными карманами энтузиазма бросилась составлять для них программу. Сначала я не стала искать в Интернете готовые, а подумала «в каком виде мне хотелось бы получать те знания, которыми я обладаю сейчас». Именно по такому принципу я и построила свою программу. Конечно же а) практика первична, б) все спорные моменты объясняю с точки зрения реальных проектов, почему лучше так, а не иначе, и в каких случаях следует отступить от этого правила, и в) прошу задавать вопросы сразу же, по мере их возникновения.

Когда перед конференцией SQA Days-4 я изучила резюме организаторов и увидела, что Наташа Густыр является автором курса «Введение в тестирование ПО », который она же и читает в московском учебном центре «Интерфейс», то поняла, что мне просто необходимо с ней пообщаться И пообщалась. Результативно – советы были претворены в жизнь.

Кстати, когда я с уже готовой собственной программой, зашла в Интернет и скачала несколько разработанных до меня, я поняла, что попала в десятку :) Все освещаемые вопросы практически совпадали, разнился лишь порядок, да и то – не принципиально. Это не могло не порадовать.

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

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





Читать далее...

Как лучше обучать новых сотрудников.

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

Признаться, в бытие мое студенткой, я утверждала, что никогда не стану преподавателем, потому что мне не нравится общаться с «детьми».
Когда мне достался мой первый подчиненный - новый сотрудник, которого пришлось обучать с нуля не только конкретному приложению, но и процессу тестирования в общем на примере конкретного проекта, я с удовольствием ринулась его обучать. Помня себя на его месте, когда я не получала ответов на тревожащие меня вопросы «а почему так?», «а может здесь кое-что изменить?» и это меня очень беспокоило, я старалась объяснять ему причины и нюансы процесса, который с первого взгляда кажется неудобным.
В каких-то моментах (благо позволяло время) я разрешала ему сделать так, как он считает нужным, и затем объясняла разницу на примере результата.
Когда по итогу испытательного срока было дано добро на то, чтобы мой подопечный стал полноценным cотрудником нашей компании, и он был переведен на постоянную работу в другой проект, он сказал мне спасибо :)

И тут я поняла, что ошибалась. Вот же она, педагогика! Вот они, дети! Значит все-таки мне это может нравиться? И неплохо получаться ;-)

В своей жизни я сталкивалась в двумя подходами к обучению:
1 – делай так, потому что так надо\принято\я_так_сказал;
2 – объяснять истинные причины и показывать достоинства и недостатки того или иного процесса или метода.

Также я интуитивно разделяю методы обучения по структуре на:
1 – индуктивные;
2 – дедуктивные.
Индукция и дедукция – понятия, знакомые нам всем из математики. Я использую понятие индукции для определения любого процесса, построенного на переходе от частного к общему. То есть сначала пример, и только затем теория.
Понятие дедукции в моем словаре описывает процесс, основанный на переходе от общего к частному, то есть сначала читай мануалы и знакомься с процессом, и только потом приступай к пецканью кнопочек и знакомству с трекинговой системой.

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

Лично я предпочитаю первый метод, потому что считаю, что проще объяснить человеку сразу, чем он будет тратить время, не зная где рыть (исключения - когда надо научить человека искать, и когда у меня нет времени. в таком случае на вопрос я отвечаю – ты должен найти ответ на этот вопрос сам, могу подсказать, где посмотреть). Ну действительно, не всегда ведь вся информация содержится в одном файле спецификации. Что-то вообще могло было быть выяснено в процессе переписки, да так там и остаться. Я считаю, что нужно ценить время и силы даже самых молодых сотрудников.

Мне встречались руководители, которые работали исключительно по второму методу. Такие же подходы, кстати, существуют и в повседневной работе, некоторых руководителей прямо таки раздражают вопрошающие подчиненные, и они огрызаются «как не работает? не может такого быть! ты что-то неправильно сделал. ах, ну конечно, а здесь кто галочку будет ставить? как не говорили, а кто тебе должен говорить? в релиз ноутах к патчу 5 на этот продукт о чем говорится?» и так далее, и так далее. Не знаю, чего они этим добиваются кроме кажущегося возвышения собственного «Я».

Своему первому «студенту», который уходил в другой проект, я дала совет: «Уточни у нового руководителя, как ты должен себя вести в случае возникновения у тебя вопросов? Спрашивать сразу или сначала попытаться найти ответ самостоятельно». Он поблагодарил меня за совет и через пару дней написал: «Спасибо ещё раз, новый тимлид одобрительно воспринял мой вопрос и мы с ним приняли систему «15 минут», то есть если я в течение 15 минут не могу найти ответ на свой вопрос – только тогда я спрашиваю у него или у других сотрудников».

Итак, если кто-нибудь спросит меня, каковы, на мой взгляд, основные принципы обучения, я отвечу так:
1 – всегда объяснять «студенту», почему нужно в данной ситуации делать так, а не иначе, возможно, стоит позволить ему сделать иначе, чтобы он пощупал достоинства и недостатки на практике;
2 – практика первоочередна, лучше сначала дать сделать, а потом прочитать, как можно было сделать иначе, в таком случае теория будет ложиться на практику, и студент будет видеть перед глазами то, о чем он читает;
3 – ценить время «студента», отвечать на вопросы по мере возможности, если это не противоречит «воспитательному процессу».

Я не утверждаю, что эта практика применима во всех случаях и ко всем студентам, но она помогает «студенту» почувствовать, что его ценят как специалиста.




Читать далее...