Вы не закончили тестировать, если вы не проверили следующие моменты, работая с диалоговыми окнами:
Убедитесь, что каждая команда (элемент меню, сочетание клавиш, и т. д.), которая инициирует диалоговое окно, открывает его.
Убедитесь, что заголовок окна верен.
Убедитесь, что терминология, использованная в тексте диалогового окна, соответствует терминологии, использующейся в приложении.
Убедитесь, что принятие диалогового окна приводит к правильным изменениям состояния приложения.
Убедитесь, что отмена диалогового окна не меняет состояния приложения.
Убедитесь, что диалоговое окно запоминает свою позицию и открывается в том месте, где оно закрывалось в последний раз. Или, как вариант, что оно всегда отображается на одном и том же месте, если оно не должно запоминать свою позицию.
Убедитесь, что содержание диалогового окна или отображает состояние приложения, или всегда имеет значения по умолчанию, если это окно не зависит от текущего состояния приложения.
Убедитесь, что вызов помощи (например, нажатие F1) открывает соответствующий раздел помощи. Обратите внимание, что это, возможно, нужно проверить для каждого элемента, так как у некоторых диалоговых окон есть специфическая контекстная помощь для элементов управления.
Как наладить процесс тестирования при больших объемах работы? Как упорядочить свои задачи, не подвергая опасности качество продукта?
Скорее всего эти вопросы не раз задавали себе люди, тестирующие сразу несколько продуктов. Или те, кто работают с часто и быстро меняющимся продуктом. Перед ними стоит вопрос не только как успешно организовать свою работу, но и какие инструменты и техники тестирования при этом использовать.
На конференции SQA Days 19 наши коллеги делились тем, как они изменили рабочий процесс на своих проектах, чтобы добиться лучших результатов в тестировании.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Выберите что-нибудь, что угодно – функцию в вашем любимом приложении, игрушку, предмет мебели. Подумайте о том, что можно сделать, чтобы протестировать это, придумайте максимальное количество тестов, которые только придут вам в голову. Продолжите чтение, когда закончите.
Что, вы снова здесь? Я гарантирую, что есть тесты, о которых вы не подумали. Откуда я знаю? Оттуда, что даже для крошечной части продукта – например, для диалогового окна поиска в вашем браузере – можно придумать миллиарды тестов. Некоторые из них найдут интересные баги с большей вероятностью, некоторые с меньшей. Некоторые из них стоит провести, чтобы убедиться, что функциональность работает корректно. Такие кейсы – основа моего списка "Это еще не конец".
Это довольно большой, пугающе выглядящий список. Без паники! Возможно, многие тесты вы уже провели, а какие-то просто неприменимы к вашей конкретной ситуации. Возможно, ряд из них вы не проводите сознательно, и у вас есть для этого основания. Цель этого списка – спровоцировать размышления о том, какие тесты вы уже провели, а какие нет, и выявить области, которые вы собирались покрыть в своем тестировании, но пока не покрыли.
Не вздрагивайте при мыслях о тестах, которые вы еще не проводили. Подгоните мой список под свой контекст. Выбросите все, что неприменимо, используйте его, как стартовую точку для поиска моментов, которые применимы к вашей ситуации, но не вошли в мой список. Пусть он станет основой организации вашего тестирования или чек-листом, по которому вы пробегаетесь под конец тестирования. Неважно, как вы его используете – просто пользуйтесь им.
Когда вы попадаете в необычную для вас обстановку – например, выходите на новую работу, попадаете в новую для себя среду, учитесь обращаться с новыми приложениями – это, как правило, очень трудно. Да, какие-то основы не меняются, но вам приходится быстро учиться всяким мелочам и значимым деталям, чтобы начать продвигаться вперед.
Может быть, вы и не лучший в мире тестировщик этого конкретного продукта, потому что вам не хватает знаний, но вы хотите стать самым-самым лучшим. Как же этого добиться? Чтение документации помогает, но иногда занимает кучу времени, или документация давно уже устарела.
Как же вам раздобыть самую актуальную, полную информацию, понять, что тревожит ваших пользователей, и при этом не подписываться на длительные выматывающие тренинги, объясняющие каждый аспект интерфейса и кода вашего продукта? Если в вашей команде есть другие тестировщики, может, вопрос решится при помощи парного тестирования. Если их нет, то что тогда?
Выступление Алексея Петрова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Все мы люди, и всем нам свойственно ошибаться, даже тестировщикам, которые эти самые ошибки в силу профессии и призваны искать. И тут, к сожалению, как в старинной поговорке про “в чужом глазе соринку видим, а в своем собственном бревна не замечаем”, мы, тестировщики, часто можем найти множество ошибок в работе наших коллег, а вот в собственной работе их не замечаем или попросту не хотим замечать.
Мой доклад посвящен как раз таким ошибкам в работе специалистов по тестированию, опыт показал, что их можно типизировать и обособить, сформулировав симптомы, причины возникновения и потенциальные угрозы, более того я расскажу, как эти “болезни” вылечить!
Например, вот лишь парочка классических болезней тестировщиков:
“Я знаю систему, значит ее знают и все остальные”, приводящая к низкому качеству оформления багрепортов. “Замыленный взгляд”, которая нередко сводит на нет результаты тестирования, так как тестировщик, без фокуса на продукте, уже не в состоянии находить дефекты в нем. “Шеф, все пропало” – тяжелая болезнь упаднического настроения от чересчур критичного взгляда на возникающие в продукте ошибки. А таких болезней куда больше, о наиболее распространенных из них я вам и расскажу, выписав вдобавок рецепты для их лечения.
Работа вовсю кипит и мы решили рассказать, на каких принципах будет строиться новый учебный курс, чем он будет отличаться от наших предыдущих тренингов и от того, что предлагают другие учебные центры.
1. Selenium во главе угла
Достаточно часто можно встретить “тренинги по Selenium”, программа которых содержит всё, что пришло в голову автору тренинга -- основы программирования, XML, SQL, JUnit, Maven, Jenkins, Git, ну и немного про Selenium.
Это, конечно, выглядит привлекательно -- на одном тренинге выучить сразу всё. Но в итоге получается в точности наоборот -- ни одна из тем не покрывается достаточно полно.
В нашем новом тренинге главным будет Selenium.
Это не означает, что смежные темы совсем не будут рассматриваться. Целое занятие будет посвящено настройке инфраструктуры. Говоря о поиске элементов, нельзя обойти стороной XPath и CSS. При обсуждении способов запуска тестов попутно поговорим про Docker. Разговор о шаблоне проектирования PageObject и его альтернативах тесно связан с вопросом о том, как вообще строить архитектуру тестов.
Но про Selenium мы расскажем всё и с подробностями, а всё остальное -- по касательной, со ссылками для дальнейшего самостоятельного изучения.
2. Полнота материала
Ни на каком другом тренинге и ни в одной книге Вы не найдёте более полной информации о Selenium 3.0.
Если найдёте -- мы Вам дадим скидку 50% на этот учебный курс :)
3. Мультиязычность
Основные принципы и приёмы использования Selenium, рассматриваемые в тренинге, будут сопровождаться примерами на пяти языках, которые “официально” поддерживаются разработчиками Selenium: Java, C#, Python, Ruby, JavaScript.
Selenium это языковонезависимый стандарт, описывающий набор команд для управления браузером. Реализации этого стандарта для разных языков программирования похожи друг на друга, и это неудивительно -- они реализуют один и тот же набор команд.
Вместе с тем, особенности каждого языка, его стиль, накладывают отпечаток на реализацию Selenium для этого языка. Поэтому в тренинге будут специальные модули, посвящённые именно таким особенностям.
Даже если какой-то язык для вас “неродной” -- мы всё равно рекомендуем смотреть “чужие” модули. Может быть после этого вы решите сменить язык :)
4. Selenide, Protractor, PageObjects и другие модные темы
Отдельное занятие будет посвящено разнообразным надстройкам над Selenium.
Их много, они решают разные задачи, некоторые из них более популярны, другие не так известны, но ничуть не хуже.
Каждая надстройка добавляет что-то к функциональности Selenium, поэтому их удобно рассматривать не как самостоятельные инструменты, а именно в сравнении с Selenium -- чем именно каждая из них отличается от общего “базиса”.
Уже можно забронировать место на тренинге, тем более, что набор в первую группу ограничен. А при оплате до 30 сентября действует специальная льготная цена.
Для тех, кто проходил у нас следующие тренинги: Разработка тестов на языках Java/Python/C# с использованием Selenium, Все секреты и тайны Selenium действует 30% скидка (не суммируется с другими скидками). Для получения скидки при регистрации уточните на каком тренинге Вы были.
На прошлой неделе был опрос про использование инструментария для работы с тест-кейсами.
Более 150 человек приняли участие в опросе и сейчас мы подводим итоги.
Сначала диаграмма на которой представлены инструменты для работы с тест-кейсами, набравшие два и больше голосов. Все инструменты в порядке убывания голосов представлены в конце статьи.
Когда я только начинал работать в компании, разрабатывающей ПО, я столкнулся с крашем приложения. Попытавшись воспроизвести краш, повторив шаги, которые привели к нему в первый раз, я потерпел неудачу. Я сделал скриншот, сохранил лог ошибок и спросил коллег, известна ли им эта проблема. Они ответили, что это "невоспроизводимый баг", который всем им хорошо знаком – каждый хоть раз да сталкивался с ним. После обеда я трудился над этим багом несколько часов, и в конце концов вынужден был признать свое поражение – баг не воспроизводился. Команда прочитала мантру, часто используемую в таких ситуациях – "Не можем воспроизвести – не можем исправить". Без стабильных шагов воспроизведения мое сообщение о баге было гласом вопиющего в пустыне.
Когда выяснилось, что этот плавающий невоспроизводимый баг вызывает проблемы у наших пользователей, команда решила разобраться в нем. Когда я поймал его повторно, я объединился с программистом и наблюдал за тем, как он пытается разъяснить проблему. Первое, что я заметил – его совершенно не интересовали шаги, которые привели к падению. Он рассматривал приложение в целом, представляя себе систему и взаимодействия внутри нее. Я попросил его рассказать, о чем он думает, показать, какая информация из трейсов привлекла его внимание, и что именно он сделал с кодом, чтобы собрать больше информации о баге, когда он появится вновь.
В итоге мы наконец смогли найти стабильные шаги воспроизведения, но не посредством интерфейса. На уровне интерфейса баг воспроизводился не всегда, и на убеждение команды в том, что мы локализовали проблему, ушло некоторое время. Мы потратили его на поиск доказательств, мы слушали свою интуицию и проверяли различные теории. Когда мы почувствовали, что абсолютно уверены – мы презентовали нашу находку коллегам. Нам разрешили исправить баг, и позднее мы были очень рады узнать, что пользователи больше не сталкиваются с этой спорадической проблемой, которая мешает им жить.
Так называемые "невоспроизводимые" баги всегда тревожили меня – особенно выражавшиеся в падениях, повреждении данных, и утечках памяти. Проблема, "плавающая" на тест-стенде, зачастую отлично воспроизводится у пользователя.
Когда я только начинал свою карьеру в тестировании, я копался в невоспроизводимых багах в свободное от релизов время. Благодаря удаче и упрямству я выяснил, что зачастую они вполне воспроизводимы. С тех пор я оттачиваю свое мастерство, пытаясь найти шаги воспроизведения для "невоспроизводимых" серьезных багов.
DevOps - это не только модное слово, которое сейчас на слуху. DevOps - это подход к работе, помогающий активно взаимодействовать командам программистов, тестировщиков и админов, которые чаще всего изолированы друг от друга.
Какие проблемы решает DevOps? Чем это отличается от привычных ролей в сфере IT?
Давайте послушаем тех участников конференции SQA Days 19, кто уже на практике применил данную методологию и может поделиться результатами. Ниже вы сможете найти видео их выступлений.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Месяц назад мы анонсировали начало работы над новым тренингом по инструменту Selenium 3.0: 
