На прошлой неделе был опрос про использование инструментария для работы с тест-кейсами.
Более 150 человек приняли участие в опросе и сейчас мы подводим итоги.
Сначала диаграмма на которой представлены инструменты для работы с тест-кейсами, набравшие два и больше голосов. Все инструменты в порядке убывания голосов представлены в конце статьи.
Когда я только начинал работать в компании, разрабатывающей ПО, я столкнулся с крашем приложения. Попытавшись воспроизвести краш, повторив шаги, которые привели к нему в первый раз, я потерпел неудачу. Я сделал скриншот, сохранил лог ошибок и спросил коллег, известна ли им эта проблема. Они ответили, что это "невоспроизводимый баг", который всем им хорошо знаком – каждый хоть раз да сталкивался с ним. После обеда я трудился над этим багом несколько часов, и в конце концов вынужден был признать свое поражение – баг не воспроизводился. Команда прочитала мантру, часто используемую в таких ситуациях – "Не можем воспроизвести – не можем исправить". Без стабильных шагов воспроизведения мое сообщение о баге было гласом вопиющего в пустыне.
Когда выяснилось, что этот плавающий невоспроизводимый баг вызывает проблемы у наших пользователей, команда решила разобраться в нем. Когда я поймал его повторно, я объединился с программистом и наблюдал за тем, как он пытается разъяснить проблему. Первое, что я заметил – его совершенно не интересовали шаги, которые привели к падению. Он рассматривал приложение в целом, представляя себе систему и взаимодействия внутри нее. Я попросил его рассказать, о чем он думает, показать, какая информация из трейсов привлекла его внимание, и что именно он сделал с кодом, чтобы собрать больше информации о баге, когда он появится вновь.
В итоге мы наконец смогли найти стабильные шаги воспроизведения, но не посредством интерфейса. На уровне интерфейса баг воспроизводился не всегда, и на убеждение команды в том, что мы локализовали проблему, ушло некоторое время. Мы потратили его на поиск доказательств, мы слушали свою интуицию и проверяли различные теории. Когда мы почувствовали, что абсолютно уверены – мы презентовали нашу находку коллегам. Нам разрешили исправить баг, и позднее мы были очень рады узнать, что пользователи больше не сталкиваются с этой спорадической проблемой, которая мешает им жить.
Так называемые "невоспроизводимые" баги всегда тревожили меня – особенно выражавшиеся в падениях, повреждении данных, и утечках памяти. Проблема, "плавающая" на тест-стенде, зачастую отлично воспроизводится у пользователя.
Когда я только начинал свою карьеру в тестировании, я копался в невоспроизводимых багах в свободное от релизов время. Благодаря удаче и упрямству я выяснил, что зачастую они вполне воспроизводимы. С тех пор я оттачиваю свое мастерство, пытаясь найти шаги воспроизведения для "невоспроизводимых" серьезных багов.
DevOps - это не только модное слово, которое сейчас на слуху. DevOps - это подход к работе, помогающий активно взаимодействовать командам программистов, тестировщиков и админов, которые чаще всего изолированы друг от друга.
Какие проблемы решает DevOps? Чем это отличается от привычных ролей в сфере IT?
Давайте послушаем тех участников конференции SQA Days 19, кто уже на практике применил данную методологию и может поделиться результатами. Ниже вы сможете найти видео их выступлений.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Наверное, вы часто слышали разговоры о некоем особом "образе мыслей" тестировщика.
Скажите, вы никогда не задавались вопросом, что люди понимают под этим выражением? Я вот задаюсь им каждый раз, и каждый раз слегка напрягаюсь и думаю, правильно ли я понял собеседника.
Десять дней назад мы запустили опрос про популярность баг-трекеров. Мы предложили ответить на два вопроса: “Какие системы для работы с ошибками вы используете в своей работе?” и “Почему?”
В опросе приняли участие 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. Приведу пример.
Автор: Ким Нап (Kim Knup)