Если ваше приложение устанавливает в систему EXE, DLL, LIB или любые другие файлы (исчерпывающе описывает любые приложения, с которыми я сталкивался), вам нужно протестировать API. А может (по идее), не нужно – если только ваше приложение использует эти DLL, или только один API – если EXE не поддерживает аргументы командной строки. Но, как знает любой тестировщик, "по идее" не всегда коррелирует с "на самом деле".
Вы не закончили тестировать, если вы не проверили следующие моменты, работая с диалоговыми окнами:
Убедитесь, что каждая команда (элемент меню, сочетание клавиш, и т. д.), которая инициирует диалоговое окно, открывает его.
Убедитесь, что заголовок окна верен.
Убедитесь, что терминология, использованная в тексте диалогового окна, соответствует терминологии, использующейся в приложении.
Убедитесь, что принятие диалогового окна приводит к правильным изменениям состояния приложения.
Убедитесь, что отмена диалогового окна не меняет состояния приложения.
Убедитесь, что диалоговое окно запоминает свою позицию и открывается в том месте, где оно закрывалось в последний раз. Или, как вариант, что оно всегда отображается на одном и том же месте, если оно не должно запоминать свою позицию.
Убедитесь, что содержание диалогового окна или отображает состояние приложения, или всегда имеет значения по умолчанию, если это окно не зависит от текущего состояния приложения.
Убедитесь, что вызов помощи (например, нажатие F1) открывает соответствующий раздел помощи. Обратите внимание, что это, возможно, нужно проверить для каждого элемента, так как у некоторых диалоговых окон есть специфическая контекстная помощь для элементов управления.
Выберите что-нибудь, что угодно – функцию в вашем любимом приложении, игрушку, предмет мебели. Подумайте о том, что можно сделать, чтобы протестировать это, придумайте максимальное количество тестов, которые только придут вам в голову. Продолжите чтение, когда закончите.
Что, вы снова здесь? Я гарантирую, что есть тесты, о которых вы не подумали. Откуда я знаю? Оттуда, что даже для крошечной части продукта – например, для диалогового окна поиска в вашем браузере – можно придумать миллиарды тестов. Некоторые из них найдут интересные баги с большей вероятностью, некоторые с меньшей. Некоторые из них стоит провести, чтобы убедиться, что функциональность работает корректно. Такие кейсы – основа моего списка "Это еще не конец".
Это довольно большой, пугающе выглядящий список. Без паники! Возможно, многие тесты вы уже провели, а какие-то просто неприменимы к вашей конкретной ситуации. Возможно, ряд из них вы не проводите сознательно, и у вас есть для этого основания. Цель этого списка – спровоцировать размышления о том, какие тесты вы уже провели, а какие нет, и выявить области, которые вы собирались покрыть в своем тестировании, но пока не покрыли.
Не вздрагивайте при мыслях о тестах, которые вы еще не проводили. Подгоните мой список под свой контекст. Выбросите все, что неприменимо, используйте его, как стартовую точку для поиска моментов, которые применимы к вашей ситуации, но не вошли в мой список. Пусть он станет основой организации вашего тестирования или чек-листом, по которому вы пробегаетесь под конец тестирования. Неважно, как вы его используете – просто пользуйтесь им.
Когда вы попадаете в необычную для вас обстановку – например, выходите на новую работу, попадаете в новую для себя среду, учитесь обращаться с новыми приложениями – это, как правило, очень трудно. Да, какие-то основы не меняются, но вам приходится быстро учиться всяким мелочам и значимым деталям, чтобы начать продвигаться вперед.
Может быть, вы и не лучший в мире тестировщик этого конкретного продукта, потому что вам не хватает знаний, но вы хотите стать самым-самым лучшим. Как же этого добиться? Чтение документации помогает, но иногда занимает кучу времени, или документация давно уже устарела.
Как же вам раздобыть самую актуальную, полную информацию, понять, что тревожит ваших пользователей, и при этом не подписываться на длительные выматывающие тренинги, объясняющие каждый аспект интерфейса и кода вашего продукта? Если в вашей команде есть другие тестировщики, может, вопрос решится при помощи парного тестирования. Если их нет, то что тогда?
Выступление Алексея Петрова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Все мы люди, и всем нам свойственно ошибаться, даже тестировщикам, которые эти самые ошибки в силу профессии и призваны искать. И тут, к сожалению, как в старинной поговорке про “в чужом глазе соринку видим, а в своем собственном бревна не замечаем”, мы, тестировщики, часто можем найти множество ошибок в работе наших коллег, а вот в собственной работе их не замечаем или попросту не хотим замечать.
Мой доклад посвящен как раз таким ошибкам в работе специалистов по тестированию, опыт показал, что их можно типизировать и обособить, сформулировав симптомы, причины возникновения и потенциальные угрозы, более того я расскажу, как эти “болезни” вылечить!
Например, вот лишь парочка классических болезней тестировщиков:
“Я знаю систему, значит ее знают и все остальные”, приводящая к низкому качеству оформления багрепортов. “Замыленный взгляд”, которая нередко сводит на нет результаты тестирования, так как тестировщик, без фокуса на продукте, уже не в состоянии находить дефекты в нем. “Шеф, все пропало” – тяжелая болезнь упаднического настроения от чересчур критичного взгляда на возникающие в продукте ошибки. А таких болезней куда больше, о наиболее распространенных из них я вам и расскажу, выписав вдобавок рецепты для их лечения.
Когда я только начинал работать в компании, разрабатывающей ПО, я столкнулся с крашем приложения. Попытавшись воспроизвести краш, повторив шаги, которые привели к нему в первый раз, я потерпел неудачу. Я сделал скриншот, сохранил лог ошибок и спросил коллег, известна ли им эта проблема. Они ответили, что это "невоспроизводимый баг", который всем им хорошо знаком – каждый хоть раз да сталкивался с ним. После обеда я трудился над этим багом несколько часов, и в конце концов вынужден был признать свое поражение – баг не воспроизводился. Команда прочитала мантру, часто используемую в таких ситуациях – "Не можем воспроизвести – не можем исправить". Без стабильных шагов воспроизведения мое сообщение о баге было гласом вопиющего в пустыне.
Когда выяснилось, что этот плавающий невоспроизводимый баг вызывает проблемы у наших пользователей, команда решила разобраться в нем. Когда я поймал его повторно, я объединился с программистом и наблюдал за тем, как он пытается разъяснить проблему. Первое, что я заметил – его совершенно не интересовали шаги, которые привели к падению. Он рассматривал приложение в целом, представляя себе систему и взаимодействия внутри нее. Я попросил его рассказать, о чем он думает, показать, какая информация из трейсов привлекла его внимание, и что именно он сделал с кодом, чтобы собрать больше информации о баге, когда он появится вновь.
В итоге мы наконец смогли найти стабильные шаги воспроизведения, но не посредством интерфейса. На уровне интерфейса баг воспроизводился не всегда, и на убеждение команды в том, что мы локализовали проблему, ушло некоторое время. Мы потратили его на поиск доказательств, мы слушали свою интуицию и проверяли различные теории. Когда мы почувствовали, что абсолютно уверены – мы презентовали нашу находку коллегам. Нам разрешили исправить баг, и позднее мы были очень рады узнать, что пользователи больше не сталкиваются с этой спорадической проблемой, которая мешает им жить.
Так называемые "невоспроизводимые" баги всегда тревожили меня – особенно выражавшиеся в падениях, повреждении данных, и утечках памяти. Проблема, "плавающая" на тест-стенде, зачастую отлично воспроизводится у пользователя.
Когда я только начинал свою карьеру в тестировании, я копался в невоспроизводимых багах в свободное от релизов время. Благодаря удаче и упрямству я выяснил, что зачастую они вполне воспроизводимы. С тех пор я оттачиваю свое мастерство, пытаясь найти шаги воспроизведения для "невоспроизводимых" серьезных багов.
Наверное, вы часто слышали разговоры о некоем особом "образе мыслей" тестировщика.
Скажите, вы никогда не задавались вопросом, что люди понимают под этим выражением? Я вот задаюсь им каждый раз, и каждый раз слегка напрягаюсь и думаю, правильно ли я понял собеседника.
Из моего рассказа на подкасте Testing In the Pub многие знают, как меня ценят на моей работе. Меня всегда приглашают на kick off-встречи, на которых мы говорим о том, что мы создаем и почему, и команды просят меня составить ментальные карты для тестирования.
Однако так я работала не всегда. Всегда важно понимать, что изменения могут зависеть лично от вас. На моем нынешнем месте работы изменения произошли еще до того, как я сюда пришла, поэтому дам несколько советов, основываясь на своем опыте на предыдущей работе, где я была первым и единственным тестировщиком.
Раньше я работала в компании, которая выпускала вполне успешный продукт, уже вышедший на окупаемость, но отдела тестирования у них не было. Когда я спросила, а как же они тестируют, они ответили, что у них нет тестировщиков – продакт-оунеры и заинтересованные лица тестируют самостоятельно, плюс имеется большой набор фронт-энд автотестов.
Они все-таки решили нанять меня, а потом – целую команду тестировщиков. О том, как это произошло и чему я научилась, я и хочу рассказать.
Тестировщики должны уметь исследовать свободным поиском так же хорошо, как ходить по шагам тест-кейсов. Но исследовательское тестирование – это вовсе не неорганизованная беготня как попало, как кажется некоторым. Об этом и поговорим.
Я уже говорил о ремесле тестирования и о том, что в тестировании есть элементы, делающие его искусством. Я верю, что ремесло и искусство наиболее сильно проявляются в эффективном, результативном и изящном исследовательском тестировании.
В большинстве случаев исследовательское тестирование – это тест-дизайн, происходящий одновременно с выполнением тестов и изучением продукта. В основном оно сводится к исследованию проблематики, которая зачастую довольно широкая, сложная и имеет динамическую структуру благодаря взаимозависимостям между своими составвляющими.
Джеймс Бах неоднократно писал об исследовательском тестировании, и он мыслит куда лучше меня, поэтому почитайте его блог на эту тему. Вне зависимости от того, согласен я с Джеймсом или нет, его слова заставляют меня задуматься.
Тут стоит отметить, что именно в исследовательском тестировании подход "задеть лампу", как правило, наиболее эффективен (см. примечание в конце статьи). Недавно я убедился в этом, тестируя Star Wars: The Old Republic (сокращенно SWTOR) для Bioware Austin. Приведу пример.
Возможно, немедленно уведомить о баге сразу же после того, как вы его обнаружили – не самая удачная идея. Сильное заявление? Возможно. Я попробую обосновать его при помощи реальной истории, которая недавно произошла со мной, а дальше перейду к теории.
Мы проводили рефакторинг одной из частей нашего приложения. Там использовался Javascript, и присутствовала корзина интернет-магазина. Я решил проверить, как она среагирует на максимально большие числа, и нашел баг. Перемножение очень больших чисел приводило, судя по всему, к фризу всей корзины. Я нажал F12, чтобы проверить, что происходит конкретно. Виноваты оказались не большие числа как таковые. Виновно было переполнение, возникающее из-за ошибки точности в Javascript (я быстро выяснил все про эту ошибку: http://www.w3schools.com/js/tryit.asp?filename=tryjs_inaccurate2). Ага, вот в чем дело! Как еще можно вызвать эту проблему? Я попробовал ввести совершенно обычные числа, которые спровоцируют ту же самую ошибку – и фриз повторился. Призванный на помощь разработчик даже не нуждался в подробных разъяснениях.
Почему бы не сообщить о баге сразу? Потому что баг, возникающий при перемножении 999999999999.99 на 99 вызовет реакцию "Какой нормальный человек так сделает", или "Ну засунь ее в бэклог, где-нибудь в 2038 году мы разберемся" – и такая реакция может быть вполне оправданной. Но демонстрация, что баг воспроизводится и на вполне обычных числах, вроде умножения 25,89 на 3, приведет к мгновенному исправлению проблемы.
Автор: Ким Нап (Kim Knup)
