Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Обзор
unittest – это стандартный Python-фреймворк для юнит-тестов. Создатели вдохновлялись JUnit, и он включается в стандартный дистрибутив CPython. unittest содержит базовый класс TestCase, дающий методы для утверждений и рутин настройки и очистки. Все классы тест-кейсов должны наследоваться от TestCase. Каждый метод в подклассе TestCase, чье имя начинается с "test", будет прогоняться как тест-кейс. Тесты можно группировать и загружать с использованием класса TestSuite и методов загрузки – используя их совместно, можно создавать свои собственные тест-загрузчики. unittest также может генерировать XML-отчеты (как и JUnit), используя unittest-xml-reporting.
unittest поддерживается и в Python 2, и в Python 3. Однако для версий старше Python 2.7 нужно пользоваться портированием unittest2.
Возможно ли тестировать без требований? Нет! Потому что именно они определяют, что должен представлять собой тот или иной продукт, и без них он фактически не может быть создан.
Распространенные возражения, как правило, сводятся к двум пунктам:
У нас нет ТЗ, но проект-то есть, и тестирование ведется.
Мы работаем по agile — функциональный продукт важнее документации, которая бы описывала его исчерпывающим образом.
Однако в любом случае необходимо понимать, кто будет пользоваться продуктом, как он должен выглядеть, из чего состоять и какими обладать функциями. Несмотря на то что эта информация не содержится в спецификациях, в ней как раз и заключены требования к ПО. Их источником служат не составленные по всей форме документы, а знания вашей команды, имеющиеся у заказчика представления, короткие разговоры за обедом, общепринятая практика, нормативно-правовые акты, то есть всё то, что порождает так называемые неявные требования.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Любой, кто хоть раз стирал, сталкивался с этой ситуацией: складываешь постиранные вещи и обнаруживаешь отсутствие одного носка. Иногда он пропадает, потому что вообще не попал в стирку. Иногда он остается в стиральной машинке. Шутят даже про то, что она отправляет носки в другое измерение!
Интересна тут реакция людей на пропавший носок. Кто-то пожмет плечами и решит, что рано или поздно носок найдется. Другие потратят весь день на поиски утраченного носка, перерыв прачечную, все непостиранное белье, шкаф, подкроватное пространство, и много чего еще.
Это отличная метафора для тестировщиков, столкнувшихся со странным и сложным в воспроизведении багом. Некоторые решают, что раз баг сложно воспроизвести, надо идти дальше и тестировать что-нибудь еще. Другие немедленно посвящают все свое время поиску причин этого странного поведения, забивая на прочее тестирование. Как тут правильно поступать? Зависит от обстоятельств. В этой статье я перечислю три причины охотиться на юркий баг, и три причины отложить охоту на потом.
Регулярные выражения (их еще называют regexp, или regex) — это механизм для поиска и замены текста. В строке, файле, нескольких файлах... Их используют разработчики в коде приложения, тестировщики в автотестах, да просто при работе в командной строке!
Чем это лучше простого поиска? Тем, что позволяет задать шаблон.
Например, на вход приходит дата рождения в формате ДД.ММ.ГГГГГ. Вам надо передать ее дальше, но уже в формате ГГГГ-ММ-ДД. Как это сделать с помощью простого поиска? Вы же не знаете заранее, какая именно дата будет.
А регулярное выражение позволяет задать шаблон «найди мне цифры в таком-то формате».
Автор: Мануэль Матюшович (Manuel Matuzovic) Оригинал статьи Перевод: Ольга Алифанова
Я работаю на компанию около года, и многое тут отличается от фриланса. В частности, мне регулярно нужно оценивать доступность различных сторонних инструментов. На полный аудит обычно нет времени, поэтому мне нужно получить хорошее представление о качестве продукта как можно быстрее.
Допустим, вам удалось набрать 100 в аудите доступности Lighthouse. Это необязательно значит, что у вашего сайта хорошая доступность – вы просто заложили основу для настоящего тестирования. Следующий шаг – убрать мышь и пройтись по вашему сайту при помощи клавиатуры.
В автоматизации тестирования я уже более 11 лет. Скажу сразу, что являюсь поклонником старомодного тестирования на Java и очень настороженно отношусь к различным готовым фреймворкам. Если вы придерживаетесь такого же мнения или только задумываетесь об использовании Robot Framework, в этой статье я постараюсь рассказать вам о его ограничениях и, конечно же, опишу все его достоинства.
Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов. Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework.
В этой статье я бы хотела поговорить про свой опыт создания тест-фреймворка роботизированной автоматизации процессов (RPA) с использованием ведущего поставщика на рынке UiPath.
Я познакомилась с UiPath в этом году, когда одной из первых сдавала их новый базовый экзамен – UiRPAv1. Я официально сертифицирована, но почти не работала с этим инструментом после сдачи экзамена, поэтому это показалось хорошей идеей для обучения на ходу.
Я очень довольна тем, как продвигается работа над моим портфолио, учитывая, с чего я начинала, но не думайте, что этот код занял у меня пару минут. Я потратила несколько дней, и много времени ушло на Google. Но все мы с чего-то начинаем, и я уверена, что кривая обучения ускорит работу в следующий раз. Еще один дополнительный бонус – симпатичный шаблон, с которого я смогу начать в следующий раз.
У клавиатуры снова я — Женя Пономаренко. Мы в «Кавычках» занимаемся тестированием и обеспечением качества для российских и зарубежных компаний. И мы — аутсорс агентство, т. е. тестируем проекты клиентов из разных сфер: от сложных — авиа и медицина, до ритейла и небольших стартапов. За свою карьеру в тестировании (а это ни много, ни мало — лет 15) я успел поработать в продуктовых командах, на фрилансе и в итоге стартанул агентство аутсорс тестирования. Пришел я к этому, потому что на одном проекте мне быстро становилось скучно, а аутсорс модель оказалась решением этой проблемы. Можно работать как компания со всеми корп. плюшками, по условиям ТК, но с разными проектами. А значит не сохнуть годами на одних и тех же задачах и непрерывно развиваться.
Автор: Дейв Вестервельд (DaveWesterveld) Оригинал статьи Перевод: Ольга Алифанова
API - отличная штука. Это мощный способ заставить разные приложения работать вместе. API позволяют легко интегрировать приложения, и на них основана львиная доля современного Интернета. Они прекрасны.
Но.
API может меняться. Если это внутренний API, то особой проблемы нет, хотя в некоторых компаниях API-команда может быть полностью отделена от тех, кто пользуется API, и поэтому даже изменения внутреннего API могут вызывать проблемы. В больших компаниях с отдельными командами разработки API принято относиться к внутреннему API так же, как к постороннему. API-разработчики также зачастую версионируют API, чтобы вы могли пользоваться устаревшими версиями, ничего не переделывая на своей стороне, но что будет, когда компания решит отказаться от старых версий или перестанет их поддерживать?
Когда разрабатывается новая функциональность системы, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
