Если говорить о будущем тестирования и тестировщиков, для начала стоит обдумать текущую ситуацию и то, почему она нуждается в переменах.
Последние десять лет тестированию постоянно угрожают вымиранием. "Тестирование умерло", "Тестировщики должны учиться программировать", и как же обойтись без любимого лозунга торговцев автоматизацией "все тесты должны быть автоматизированы".
В середине мая 2016 года Джеймс и Джон Бах проводили воркшоп на тему "Преобразование тестировщиков". Я на нем не присутствовал, поэтому не буду вдаваться в детали. Он не произвел никаких потрясений в сообществе – мое внимание привлек один-единственный слайд, вырванный из контекста и опубликованный в Твиттере.
Выступление Иры Винокуровой на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Программисты пишут в студии. Версии хранятся в дженкинсе. Баги ведутся в редмайне, а тест-кейсы вообще лежат в Тестлинке… Знакомо? Так было и у нас. А потом все изменилось. На смену старой студии пришла новая, да не одна. А с TFS в придачу. Как и у нас, во многих офисах стоит Visual Studio. Многие команды разработчиков пользуются TFS для разработки проектов. Но немногие знают, что в этом во всем есть бонусное место для тестировщиков. О том, как можно использовать TFS для тестирования, что такое Test Manager и как с ним работать, почему все удобнее держать в одной системе — я попытаюсь рассказать в своем докладе на примерах.
Если ваше приложение устанавливает в систему EXE, DLL, LIB или любые другие файлы (исчерпывающе описывает любые приложения, с которыми я сталкивался), вам нужно протестировать API. А может (по идее), не нужно – если только ваше приложение использует эти DLL, или только один API – если EXE не поддерживает аргументы командной строки. Но, как знает любой тестировщик, "по идее" не всегда коррелирует с "на самом деле".
Вы не закончили тестировать, если вы не проверили следующие моменты, работая с диалоговыми окнами:
Убедитесь, что каждая команда (элемент меню, сочетание клавиш, и т. д.), которая инициирует диалоговое окно, открывает его.
Убедитесь, что заголовок окна верен.
Убедитесь, что терминология, использованная в тексте диалогового окна, соответствует терминологии, использующейся в приложении.
Убедитесь, что принятие диалогового окна приводит к правильным изменениям состояния приложения.
Убедитесь, что отмена диалогового окна не меняет состояния приложения.
Убедитесь, что диалоговое окно запоминает свою позицию и открывается в том месте, где оно закрывалось в последний раз. Или, как вариант, что оно всегда отображается на одном и том же месте, если оно не должно запоминать свою позицию.
Убедитесь, что содержание диалогового окна или отображает состояние приложения, или всегда имеет значения по умолчанию, если это окно не зависит от текущего состояния приложения.
Убедитесь, что вызов помощи (например, нажатие 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 человек приняли участие в опросе и сейчас мы подводим итоги.
Сначала диаграмма на которой представлены инструменты для работы с тест-кейсами, набравшие два и больше голосов. Все инструменты в порядке убывания голосов представлены в конце статьи.
Месяц назад мы анонсировали начало работы над новым тренингом по инструменту Selenium 3.0: 