Те, кто присутствовал на SQA Days-19, наверняка запомнили, как отбирались лучшие доклады конференции.
У каждого участника среди раздаточного материала были наклейки в виде позитивных (зеленых) и негативных (красных) смайлов. После каждого выступления слушатели могли оценить доклады, наклеив смайлики на специальные плакаты, стоявшие у аудитории, где были указаны названия докладов и имена тех, кто их подготовил. В конце дня подводились итоги: плакаты снимались, пересчитывались наклейки и определялись докладчики, набравшие большее количество голосов.
Таким образом на 19-ой Международной конференции в области обеспечения качества ПО среди выступавших были определены три победителя. Ими стали:
1. Мясников Андрей (Вредные привычки в тестировании)
2. Варгин Герман (Пополняем арсенал тестировщика. Учимся применять новые техники)
3. Семенченко Антон (Quality Assurance, Quality Control и метрики Автоматизированного тестирования на пальцах)
Прежде чем начать, хочу рассказать, как эта идея пришла мне в голову. Я работал над докладом "Скрытая мудрость тест-тролля" и включил в него шутку, основанную на публичной шумихе вокруг органической еды. Затем я задумался о том, что тестирование органично по своей природе, и решил написать об этом отдельно.
Тут также стоит упомянуть, что Джеймс Бах делал доклад "Органическое QA" для Apple. Я нашел эту информацию в его архиве, но не знаю, о чем именно Бах говорил – это был внутренний доклад для сотрудников компании. Поэтому моей целью не было дополнить Джеймса.
Меня часто спрашивают, что значит быть "хорошим тестировщиком", и еще чаще – как преуспеть в тестировании. Тут нет никаких секретных рецептов, однако, с моей точки зрения, хорошие тестировщики похожи тем, что они делают определенные вещи для того, чтобы двигаться вперед.
Не все хорошие тестировщики добиваются успеха, и не все те, кто его добился, хороши. Что же тестировщику сделать, чтобы преуспеть? И, кстати, что такое "успех", это же довольно субъективное понятие?
Что, я уже запутала вас? Я пытаюсь донести, что тут нет проторенных дорог – только те, которые выбираете лично вы. Моя цель – помочь вам выбрать хорошую дорогу, которая подходит именно вам.
Я хочу поговорить о том, что, с моей точки зрения, означает быть "хорошим тестировщиком".
Если говорить о будущем тестирования и тестировщиков, для начала стоит обдумать текущую ситуацию и то, почему она нуждается в переменах.
Последние десять лет тестированию постоянно угрожают вымиранием. "Тестирование умерло", "Тестировщики должны учиться программировать", и как же обойтись без любимого лозунга торговцев автоматизацией "все тесты должны быть автоматизированы".
В середине мая 2016 года Джеймс и Джон Бах проводили воркшоп на тему "Преобразование тестировщиков". Я на нем не присутствовал, поэтому не буду вдаваться в детали. Он не произвел никаких потрясений в сообществе – мое внимание привлек один-единственный слайд, вырванный из контекста и опубликованный в Твиттере.
Если ваше приложение устанавливает в систему EXE, DLL, LIB или любые другие файлы (исчерпывающе описывает любые приложения, с которыми я сталкивался), вам нужно протестировать API. А может (по идее), не нужно – если только ваше приложение использует эти DLL, или только один API – если EXE не поддерживает аргументы командной строки. Но, как знает любой тестировщик, "по идее" не всегда коррелирует с "на самом деле".
Вы не закончили тестировать, если вы не проверили следующие моменты, работая с диалоговыми окнами:
Убедитесь, что каждая команда (элемент меню, сочетание клавиш, и т. д.), которая инициирует диалоговое окно, открывает его.
Убедитесь, что заголовок окна верен.
Убедитесь, что терминология, использованная в тексте диалогового окна, соответствует терминологии, использующейся в приложении.
Убедитесь, что принятие диалогового окна приводит к правильным изменениям состояния приложения.
Убедитесь, что отмена диалогового окна не меняет состояния приложения.
Убедитесь, что диалоговое окно запоминает свою позицию и открывается в том месте, где оно закрывалось в последний раз. Или, как вариант, что оно всегда отображается на одном и том же месте, если оно не должно запоминать свою позицию.
Убедитесь, что содержание диалогового окна или отображает состояние приложения, или всегда имеет значения по умолчанию, если это окно не зависит от текущего состояния приложения.
Убедитесь, что вызов помощи (например, нажатие F1) открывает соответствующий раздел помощи. Обратите внимание, что это, возможно, нужно проверить для каждого элемента, так как у некоторых диалоговых окон есть специфическая контекстная помощь для элементов управления.
Выберите что-нибудь, что угодно – функцию в вашем любимом приложении, игрушку, предмет мебели. Подумайте о том, что можно сделать, чтобы протестировать это, придумайте максимальное количество тестов, которые только придут вам в голову. Продолжите чтение, когда закончите.
Что, вы снова здесь? Я гарантирую, что есть тесты, о которых вы не подумали. Откуда я знаю? Оттуда, что даже для крошечной части продукта – например, для диалогового окна поиска в вашем браузере – можно придумать миллиарды тестов. Некоторые из них найдут интересные баги с большей вероятностью, некоторые с меньшей. Некоторые из них стоит провести, чтобы убедиться, что функциональность работает корректно. Такие кейсы – основа моего списка "Это еще не конец".
Это довольно большой, пугающе выглядящий список. Без паники! Возможно, многие тесты вы уже провели, а какие-то просто неприменимы к вашей конкретной ситуации. Возможно, ряд из них вы не проводите сознательно, и у вас есть для этого основания. Цель этого списка – спровоцировать размышления о том, какие тесты вы уже провели, а какие нет, и выявить области, которые вы собирались покрыть в своем тестировании, но пока не покрыли.
Не вздрагивайте при мыслях о тестах, которые вы еще не проводили. Подгоните мой список под свой контекст. Выбросите все, что неприменимо, используйте его, как стартовую точку для поиска моментов, которые применимы к вашей ситуации, но не вошли в мой список. Пусть он станет основой организации вашего тестирования или чек-листом, по которому вы пробегаетесь под конец тестирования. Неважно, как вы его используете – просто пользуйтесь им.
Когда вы попадаете в необычную для вас обстановку – например, выходите на новую работу, попадаете в новую для себя среду, учитесь обращаться с новыми приложениями – это, как правило, очень трудно. Да, какие-то основы не меняются, но вам приходится быстро учиться всяким мелочам и значимым деталям, чтобы начать продвигаться вперед.
Может быть, вы и не лучший в мире тестировщик этого конкретного продукта, потому что вам не хватает знаний, но вы хотите стать самым-самым лучшим. Как же этого добиться? Чтение документации помогает, но иногда занимает кучу времени, или документация давно уже устарела.
Как же вам раздобыть самую актуальную, полную информацию, понять, что тревожит ваших пользователей, и при этом не подписываться на длительные выматывающие тренинги, объясняющие каждый аспект интерфейса и кода вашего продукта? Если в вашей команде есть другие тестировщики, может, вопрос решится при помощи парного тестирования. Если их нет, то что тогда?
Выступление Алексея Петрова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Все мы люди, и всем нам свойственно ошибаться, даже тестировщикам, которые эти самые ошибки в силу профессии и призваны искать. И тут, к сожалению, как в старинной поговорке про “в чужом глазе соринку видим, а в своем собственном бревна не замечаем”, мы, тестировщики, часто можем найти множество ошибок в работе наших коллег, а вот в собственной работе их не замечаем или попросту не хотим замечать.
Мой доклад посвящен как раз таким ошибкам в работе специалистов по тестированию, опыт показал, что их можно типизировать и обособить, сформулировав симптомы, причины возникновения и потенциальные угрозы, более того я расскажу, как эти “болезни” вылечить!
Например, вот лишь парочка классических болезней тестировщиков:
“Я знаю систему, значит ее знают и все остальные”, приводящая к низкому качеству оформления багрепортов. “Замыленный взгляд”, которая нередко сводит на нет результаты тестирования, так как тестировщик, без фокуса на продукте, уже не в состоянии находить дефекты в нем. “Шеф, все пропало” – тяжелая болезнь упаднического настроения от чересчур критичного взгляда на возникающие в продукте ошибки. А таких болезней куда больше, о наиболее распространенных из них я вам и расскажу, выписав вдобавок рецепты для их лечения.
Когда я только начинал работать в компании, разрабатывающей ПО, я столкнулся с крашем приложения. Попытавшись воспроизвести краш, повторив шаги, которые привели к нему в первый раз, я потерпел неудачу. Я сделал скриншот, сохранил лог ошибок и спросил коллег, известна ли им эта проблема. Они ответили, что это "невоспроизводимый баг", который всем им хорошо знаком – каждый хоть раз да сталкивался с ним. После обеда я трудился над этим багом несколько часов, и в конце концов вынужден был признать свое поражение – баг не воспроизводился. Команда прочитала мантру, часто используемую в таких ситуациях – "Не можем воспроизвести – не можем исправить". Без стабильных шагов воспроизведения мое сообщение о баге было гласом вопиющего в пустыне.
Когда выяснилось, что этот плавающий невоспроизводимый баг вызывает проблемы у наших пользователей, команда решила разобраться в нем. Когда я поймал его повторно, я объединился с программистом и наблюдал за тем, как он пытается разъяснить проблему. Первое, что я заметил – его совершенно не интересовали шаги, которые привели к падению. Он рассматривал приложение в целом, представляя себе систему и взаимодействия внутри нее. Я попросил его рассказать, о чем он думает, показать, какая информация из трейсов привлекла его внимание, и что именно он сделал с кодом, чтобы собрать больше информации о баге, когда он появится вновь.
В итоге мы наконец смогли найти стабильные шаги воспроизведения, но не посредством интерфейса. На уровне интерфейса баг воспроизводился не всегда, и на убеждение команды в том, что мы локализовали проблему, ушло некоторое время. Мы потратили его на поиск доказательств, мы слушали свою интуицию и проверяли различные теории. Когда мы почувствовали, что абсолютно уверены – мы презентовали нашу находку коллегам. Нам разрешили исправить баг, и позднее мы были очень рады узнать, что пользователи больше не сталкиваются с этой спорадической проблемой, которая мешает им жить.
Так называемые "невоспроизводимые" баги всегда тревожили меня – особенно выражавшиеся в падениях, повреждении данных, и утечках памяти. Проблема, "плавающая" на тест-стенде, зачастую отлично воспроизводится у пользователя.
Когда я только начинал свою карьеру в тестировании, я копался в невоспроизводимых багах в свободное от релизов время. Благодаря удаче и упрямству я выяснил, что зачастую они вполне воспроизводимы. С тех пор я оттачиваю свое мастерство, пытаясь найти шаги воспроизведения для "невоспроизводимых" серьезных багов.
Автор: Виктор Славчев (Victor Slavchev)
