"Делаешь что-то неоднократно – автоматизируй это" – довольно частая присказка. Тестирование ПО, при котором зачастую приходится многократно выполнять одинаковые действия – отличное поле деятельности для автоматизации. В современном мире разработки ПО, учитывая использование микросервисов и методологию непрерывной разработки, мы стремимся к быстрому, частому внедрению новой функциональности. Важность автоматизации в связи с этим растет, но связанные с ней проблемы все еще не решены. Вот мой список пяти самых распространенных ошибок, которые совершаются при автоматизации приемочных тестов.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Очень серьезные изменения произошли в линейке тренингов по Selenium. Плохая новость состоит в том, что большинство тренингов были сняты из расписания. Но есть и хорошая новость. Идет работа над новым тренингом по инструменту Selenium 3.0: Selenium WebDriver: полное руководство. Уже сейчас можно посмотреть на каких принципах будет строиться новый учебный курс, чем он будет отличаться от наших предыдущих тренингов и от того, что предлагают другие учебные центры.
Если говорить о будущем тестирования и тестировщиков, для начала стоит обдумать текущую ситуацию и то, почему она нуждается в переменах.
Последние десять лет тестированию постоянно угрожают вымиранием. "Тестирование умерло", "Тестировщики должны учиться программировать", и как же обойтись без любимого лозунга торговцев автоматизацией "все тесты должны быть автоматизированы".
В середине мая 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% скидки.
Выберите что-нибудь, что угодно – функцию в вашем любимом приложении, игрушку, предмет мебели. Подумайте о том, что можно сделать, чтобы протестировать это, придумайте максимальное количество тестов, которые только придут вам в голову. Продолжите чтение, когда закончите.
Что, вы снова здесь? Я гарантирую, что есть тесты, о которых вы не подумали. Откуда я знаю? Оттуда, что даже для крошечной части продукта – например, для диалогового окна поиска в вашем браузере – можно придумать миллиарды тестов. Некоторые из них найдут интересные баги с большей вероятностью, некоторые с меньшей. Некоторые из них стоит провести, чтобы убедиться, что функциональность работает корректно. Такие кейсы – основа моего списка "Это еще не конец".
Это довольно большой, пугающе выглядящий список. Без паники! Возможно, многие тесты вы уже провели, а какие-то просто неприменимы к вашей конкретной ситуации. Возможно, ряд из них вы не проводите сознательно, и у вас есть для этого основания. Цель этого списка – спровоцировать размышления о том, какие тесты вы уже провели, а какие нет, и выявить области, которые вы собирались покрыть в своем тестировании, но пока не покрыли.
Не вздрагивайте при мыслях о тестах, которые вы еще не проводили. Подгоните мой список под свой контекст. Выбросите все, что неприменимо, используйте его, как стартовую точку для поиска моментов, которые применимы к вашей ситуации, но не вошли в мой список. Пусть он станет основой организации вашего тестирования или чек-листом, по которому вы пробегаетесь под конец тестирования. Неважно, как вы его используете – просто пользуйтесь им.
Когда вы попадаете в необычную для вас обстановку – например, выходите на новую работу, попадаете в новую для себя среду, учитесь обращаться с новыми приложениями – это, как правило, очень трудно. Да, какие-то основы не меняются, но вам приходится быстро учиться всяким мелочам и значимым деталям, чтобы начать продвигаться вперед.
Может быть, вы и не лучший в мире тестировщик этого конкретного продукта, потому что вам не хватает знаний, но вы хотите стать самым-самым лучшим. Как же этого добиться? Чтение документации помогает, но иногда занимает кучу времени, или документация давно уже устарела.
Как же вам раздобыть самую актуальную, полную информацию, понять, что тревожит ваших пользователей, и при этом не подписываться на длительные выматывающие тренинги, объясняющие каждый аспект интерфейса и кода вашего продукта? Если в вашей команде есть другие тестировщики, может, вопрос решится при помощи парного тестирования. Если их нет, то что тогда?
