Из моего рассказа на подкасте Testing In the Pub многие знают, как меня ценят на моей работе. Меня всегда приглашают на kick off-встречи, на которых мы говорим о том, что мы создаем и почему, и команды просят меня составить ментальные карты для тестирования.
Однако так я работала не всегда. Всегда важно понимать, что изменения могут зависеть лично от вас. На моем нынешнем месте работы изменения произошли еще до того, как я сюда пришла, поэтому дам несколько советов, основываясь на своем опыте на предыдущей работе, где я была первым и единственным тестировщиком.
Раньше я работала в компании, которая выпускала вполне успешный продукт, уже вышедший на окупаемость, но отдела тестирования у них не было. Когда я спросила, а как же они тестируют, они ответили, что у них нет тестировщиков – продакт-оунеры и заинтересованные лица тестируют самостоятельно, плюс имеется большой набор фронт-энд автотестов.
Они все-таки решили нанять меня, а потом – целую команду тестировщиков. О том, как это произошло и чему я научилась, я и хочу рассказать.
Выступление Александра Хози на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Не все начинающие тестировщики попадают в компанию с большим количеством классных тестировщиков-менторов. Поэтому некоторым из нас волею судеб пришлось начинать свой рост в тестировании с «обезьянок». И не всегда получается перерости этот этап, изжить «обезьянку», которая поселилась внутри вас.
В своем докладе я расскажу вам о том, как и почему появляются такие «обезьянки» и что можно с этим сделать.
Вот некоторые из них:
отсутствующий (или некомпетентный) наставник;
слаборазвитые процессы разработки и тестирования внутри компании;
вытекающее из слабости процессов: «Ну потестируй что-нибудь, ты же QA»;
отсутствие «вопросительности»
непонимание цели тестирования;
тестирование используется как вход в IT;
в профессию пришли за деньгами;
карма/другое :)
Также расскажу личную историю тестировщика-обезьянки: как я боролся с обезьянкой внутри меня :) как боролся с публичным мнением: «Тестировщик мобильных приложений – обезьянка». Кстати, иногда даже стоит давать обезьянке волю. Мы разберемся с ситуациями, когда это приносит пользу, и что я использую для этого.
Мы живем в такое время, когда все меняется с бешеной скоростью. В том числе в нашей области: появляются новые инструменты, техники тестирования, появляется все больше новых книг, блогов.
Это здорово! И в век интернета вы наверняка знаете почти обо всех нововведениях или по крайней мере слышали о них. Однако, чтобы быть хорошим специалистом, не достаточно отслеживать изменения в профессиональной области. Важно понять, что из обновленной информации подойдет именно вам и стоит ли применять новые техники или инструменты на своем проекте.
Участники конференции SQA Days 19 рассказали о том, на что стоит обратить внимание в первую очередь тем, кто хочет быть лучшим в своей области, и как сделать так, чтобы процесс собственного развития приносил удовольствие.
Тестировщики должны уметь исследовать свободным поиском так же хорошо, как ходить по шагам тест-кейсов. Но исследовательское тестирование – это вовсе не неорганизованная беготня как попало, как кажется некоторым. Об этом и поговорим.
Я уже говорил о ремесле тестирования и о том, что в тестировании есть элементы, делающие его искусством. Я верю, что ремесло и искусство наиболее сильно проявляются в эффективном, результативном и изящном исследовательском тестировании.
В большинстве случаев исследовательское тестирование – это тест-дизайн, происходящий одновременно с выполнением тестов и изучением продукта. В основном оно сводится к исследованию проблематики, которая зачастую довольно широкая, сложная и имеет динамическую структуру благодаря взаимозависимостям между своими составвляющими.
Джеймс Бах неоднократно писал об исследовательском тестировании, и он мыслит куда лучше меня, поэтому почитайте его блог на эту тему. Вне зависимости от того, согласен я с Джеймсом или нет, его слова заставляют меня задуматься.
Тут стоит отметить, что именно в исследовательском тестировании подход "задеть лампу", как правило, наиболее эффективен (см. примечание в конце статьи). Недавно я убедился в этом, тестируя Star Wars: The Old Republic (сокращенно SWTOR) для Bioware Austin. Приведу пример.
Опросы созданы, чтобы выявить наиболее популярные инструменты баг-трекинга и работы с тест-кейсами и понять причины выбора того или иного инструмента. Результаты будут опубликованы до 3 сентября и доступны по ссылкам выше.
Два месяца назад мы начали работу над созданием новой версии тренинга "Тестирование производительности веб-приложений". Всё прошло по плану, и вот уже первая группа завершает обучение по новой программе с обновлёнными учебными материалами, а через неделю стартует следующая учебная группа.
Необходимость периодического обновления технических учебных курсов определяется как внутренними, так и внешними причинами.
Внутренние причины более или менее одинаковы для всех тренингов:
не всегда удаётся с первой попытки объяснить какую-то сложную тему, чтобы это было понятно ученикам (а иногда и со второй попытки не удаётся :)), поэтому мы придумываем новые способы объяснения
если участники постоянно задают вопросы по теме, которая не вошла в предыдущую версию тренинга -- хочется эту тему добавить, ответить на эти вопросы превентивно
хочется добавить некоторые новые темы, даже если ученики про это не спрашивают :)
хочется научить студентов решать более сложные задачи, но не просто показать, как это делается, а добиться, чтобы студенты сами смогли их решить, для этого приходится делать более хитрые "подводки", меняя порядок изложения материала в лекциях и домашние задания
Внешние причины как правило более специфические, в технических тренингах рассматриваются какие-то инструменты, которые постепенно развиваются, изменяются, и вскоре материал тренинга уже выглядит устаревшим.
выход новой версии JMeter 3.0, инструмент достаточно долго не развивался, но за последний год разработчики проделали большую работу и внесли в инструмент много полезных изменений
изменение системы установки плагинов в JMeter, появление Plugin Manager
выход новой версии RapidMiner Studio, замечательного инструмента для анализа данных (да, мы рекомендуем использовать для анализа результатов тестирования профессиональные инструменты)
Всё это было учтено при подготовке новой версии учебного курса.
С одной стороны он стал более глубоким, в нём рассматриваются более сложные вопросы, чем в предыдущей версии. С другой стороны он стал более доступным, потому что мы как следует поработали над объяснением сложных вопросов. В частности, мы постарались как можно более подробно и понятно рассказать про корреляцию запросов, потому что эта тема вызывает больше всего трудностей у учеников.
Нередко от тестировщиков с небольшим опытом можно услышать, что автоматизированное тестирование - это решение чуть ли не всех проблем на проекте.
Специалисты, которые в тестировании не первый год, рассуждают уже более здраво и знают на каких проектах автотесты могут не понадобится, а где без них действительно нельзя обойтись.
Как раз этот вопрос обсуждали участники конференции SQA Days 19 и вот к каким выводам они пришли:
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Выступление Сергея Атрощенкова на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.
Когда-то давным-давно, в середине 60-х, в США появился праздник Кванза. Это один из афроамериканских фестивалей, представляющий собой неделю предновогодних торжеств. Считается, что праздник «первого плода» отмечался в древней Нубии в эпоху фараонов, кроме того, его праздновали в средневековых африканских государствах Йоруба и Ашанти. В основу праздника положены африканские традиции и глубинная мысль, провозглашающая Семь Принципов жизни и ценностей сообщества: Единство, Самоопределение, Коллективизм, Совместная экономика, Цель, Творческий потенциал и Вера.
Казалось бы, при чем здесь тестирование?
Да при том, что принципы данного веселого мероприятия очень хорошо ложатся в основу работы любых IT команд, а в нашем случае – тестировщиков.
А когда таких принципов целых семь… Есть где развернуться и организаторским навыкам, и фантазии, и аналитическим способностям всё-улучшающего ума.
Чем принцип Единства не прекрасная возможность объединять различные роли: аналитиков, разработчиков, программистов, системных администраторов в едином порыве, нацеленном на работу над качественным продуктом?
А принцип Творчества? Чем не возможность проявить себя в тест-аналитике?
Я расскажу о том, как принципы Кванзы можно применять в своей команде, например в команде тестирования, если есть полное взаимопонимание между различными проектными ролями.
После этого доклада у тест-менеджеров и им сочувствующих сложится понимание того, как можно работать с командой не держа в голове кучу умных слов. Простое мнемоническое правило, легко запоминаемое и покрывающее навыки: организации команды, персональной работы с сотрудниками, мотивации, создания миссии команды и межролевых взаимодействий после внедрения сможет упростить им жизнь.
Меня регулярно спрашивают, как измеряется эффективность тестировщика. Обычно я отвечаю "Зачем это вам? Чтобы что?" Мой ответ вызван желанием понять мотивы менеджмента: почему измерение эффективности конкретного человека так важно для них? Обычно этот вопрос задают именно менеджеры.
Конечно, важно знать, насколько хорошо человек справляется со своей работой и достигает поставленных целей. Но не менее важно понимать, что движет теми, кто пытается это измерять. Это делается, чтобы развивать и улучшать сотрудника, предоставить ему возможности для обучения и поддержку? Или исходя из чисто коммерческих соображений?
Поймите меня правильно, я люблю метрики. Мы измеряем кучу всяких параметров, но предельно осторожно относимся к результатам подобных измерений.
В ответ на свой вопрос я обычно слышу, что менеджеры (особенно тест-менеджеры) используют эту метрику, пытаясь обосновать, что этот тестировщик действительно стоит (или не стоит) своих денег.
Как правило, они пытаются измерять две вещи. Во-первых, одинаково ли ценны тестировщик А и тестировщик Б? Можем ли мы поменять их местами и продолжать достигать своих целей? Может, один из них лучше другого?
Во-вторых, они пытаются измерить, приносят ли тестировщик А и тестировщик Б вообще какую-то ценность (что произойдет, если мы от них избавимся?).
Зачастую это приводит к тому, что менеджеры начинают измерять какую-то дичь – скажем, количество выполненных тест-кейсов, или количество найденных багов, и считают это метрикой эффективности тестировщика.
Звучит бредово, но встречается достаточно часто! Менеджеры любят простые метрики для принятия информированных решений.
В современном мире мобильными приложениями никого не удивить, наверняка каждый из вас пользуется ими ежедневно будь то игры, социальные сети или учет финансов. Заказать такси, посмотреть новости, купить билет на самолет - сейчас все это сделать легко. Но при условии, что приложение на вашем устройстве работает корректно.
Поэтому вопрос тестирования мобильных приложений так актуален в наше время. Есть ли какие-то особенности у данного процесса? Конечно! Различные типы устройств, не один десяток разрешений экрана, несколько версий операционных систем, разные типы подключения к интернету - вот далеко не полный список того, что может усложнить этот процесс.
На конференции SQA Days 19 наши коллеги, которые сталкиваются с тестированием мобильных приложений каждый день, рассказали, как именно проводить данный вид тестирования, о чем нельзя забывать в процессе и как свои теоретические знания применить на практике.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Автор: Ким Нап (Kim Knup)
