Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout
Каждый из нас сталкивался с технической поддержкой. Кто-то с ней взаимодействует по работе, кто-то по своей должности совмещает тестирование и поддержку, а кто-то стоит перед вопросом — взаимодействовать или делать самому? Мы расскажем, как это сделано у нас в Юле.
У пользователей любого сервиса всегда возникают вопросы, сомнения или проблемы с использованием продукта — именно этих клиентов крайне легко потерять. Грамотно организованная служба поддержки помогает исправить ситуацию и вернуть лояльность пользователя.
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
Я заметила, что во множестве компаний, в которых разработка и тестирование разделены, тестировщики чересчур доверяют разработчикам. Даже там, где разработка сильно интегрирована с тестированием, это может вылиться в пропущенные тесты, некоторые из которых могут быть критичными для поиска важных багов в разрабатываемом ПО.
Один из явных примеров такой ситуации связан с CI/CD. Обычно это настраивается администратором или DevOps. Тут очень важно подключить к процессу тест-эксперта этой области, потому что он умеет проектировать нужные для валидации билдов автоматизированные тесты. Я видела варианты, где тестирования не было вообще, или же была группа недостаточных или нерелевантных тестов.
Сегодня поговорим с вами про исследовательское тестирование. Причём про такое исследование продукта, которое никто не назовёт обезьяньей работой.
Бытует мнение, что исследовательское тестирование – удел молодых специалистов, якобы думать там совсем не нужно, тыкай себе хаотично всё подряд – авось и баги найдутся. Ан нет. Исследовательское тестирование – это целая наука со своими методологиями и техниками.
Давайте обратимся к теории, что же такое исследовательское тестирование? Что значит “мы исследуем”? Исследовать – значит изучать, знакомиться, смотреть на продукт и на то, как он будет реагировать на ваши действия.
Исследовательское тестирование – это одновременное создание тестов, их прохождение и корректировка в зависимости от поведения вашего продукта.
Автор: Энди Найт (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.
