Наверное, вы часто слышали разговоры о некоем особом "образе мыслей" тестировщика.
Скажите, вы никогда не задавались вопросом, что люди понимают под этим выражением? Я вот задаюсь им каждый раз, и каждый раз слегка напрягаюсь и думаю, правильно ли я понял собеседника.
Десять дней назад мы запустили опрос про популярность баг-трекеров. Мы предложили ответить на два вопроса: “Какие системы для работы с ошибками вы используете в своей работе?” и “Почему?”
В опросе приняли участие 170 человек.
Ниже представлена диаграмма частоты использования инструментов по результатам этого опроса. На диаграмме представлены только те инструменты, который получили больше одного голоса (все инструменты в порядке убывания голосов представлены в конце статьи).
Чаще всего респонденты нашего опроса используют Jira, на втором месте по популярности - Redmine, а на третьем - MS TFS.
Теперь посмотрим на основные причины выбора той или иной системы.
Этот вопрос очень часто звучал в учебном чате первого потока тренинга Натальи Руколь Комплексная система подготовки тестировщиков по программе ISTQB FL. И хотя с каждым днём всё больше выпускников рассказывают об успешной сдаче экзамена, вопрос не утратил актуальности. Ведь все знают, что в заданиях экзамена ISTQB FL встречаются и опечатки, и пропущенные запятые, а иногда и два одинаковых ответа!
Главная дискуссия разгорелась по поводу вопроса о граничных значениях для заданного диапазона. Рассмотрим вопрос с таким же подвохом схематично, на примере обычного слова:
“Какие буквы входят в слово Каша?”
К Ш А
ш К
А а К к Ш ш
а ш а к р
Вся группа была уверена, что это просто ошибочный вопрос!
Но нет, в этом задании нет ошибок, а вот ловушек очень много! Важно внимательно прочитать каждое слово в нем!
Если вопрос будет звучать так: “Где указаны все буквы, которые есть в слове Каша?” - правильным ответом будет вариант 3.
Если так: “Не учитывая регистр, где буквы идут в том порядке, как и в слове Каша?” - правильным ответом будет 1.
А если его сформулировать так, как написано выше: “Какие буквы входят в слово Каша?” - то правильный ответ, конечно, 2.
Именно благодаря тому, что мы очень подробно разбираем вопросы на занятиях (а домашние задания на все вебинары - это пачки тестов на изученную тему), после сдачи экзамена ISTQB FL участники пишут нам подобные сообщения:
“Большинство вопросов с подковыркой, но спасибо Наташе и Юлии за то, что дали правильный вектор! Так как я сразу все подковырки распознавала и вспоминала: "А, а нам говорили, что будет такой вопрос)))". В общем, я его победила, чему рада)))“
Вот так поделилась с нами своим успехом выпускница тренинга Надежда.
За прошедший с окончания курса месяц 23 наших выпускника уже сдали экзамен ISTQB FL и получили сертификаты. Поздравляем с новой ступенькой на трудовом пути! Молодцы, ребята, так держать!
Поэтому, если вы планируете получить сертификат “ISTQB FL”, но никак не решаетесь записаться на сдачу экзамена, мы предлагаем вам прямо сейчас принять участие в тренинге Натальи Руколь Комплексная система подготовки тестировщиков по программе ISTQB FL. За время обучения мы разберем все тонкости, потренируемся отвечать на самые заковыристые вопросы и дружно будем делиться успехами! Неважно, на каком языке вы планируете сдавать экзамен, на русском или на английском, курс обеспечит подготовку к обоим вариантам.
Всем выпускникам данного тренинга предоставляется скидка 10 евро при оплате экзамена ISTQB FL!
Если у вас остались вопросы по этому тренингу - почитайте наше ЧАВО.
Из моего рассказа на подкасте 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 команд, а в нашем случае – тестировщиков.
А когда таких принципов целых семь… Есть где развернуться и организаторским навыкам, и фантазии, и аналитическим способностям всё-улучшающего ума.
Чем принцип Единства не прекрасная возможность объединять различные роли: аналитиков, разработчиков, программистов, системных администраторов в едином порыве, нацеленном на работу над качественным продуктом?
А принцип Творчества? Чем не возможность проявить себя в тест-аналитике?
Я расскажу о том, как принципы Кванзы можно применять в своей команде, например в команде тестирования, если есть полное взаимопонимание между различными проектными ролями.
После этого доклада у тест-менеджеров и им сочувствующих сложится понимание того, как можно работать с командой не держа в голове кучу умных слов. Простое мнемоническое правило, легко запоминаемое и покрывающее навыки: организации команды, персональной работы с сотрудниками, мотивации, создания миссии команды и межролевых взаимодействий после внедрения сможет упростить им жизнь.
Автор: Ким Нап (Kim Knup)