В этой статье решил рассказать о том, что и почему чаще всего спрашивают на позицию автоматизатора в тестировании. Я постараюсь рассказать о как можно большем количестве направлений. При этом не буду придумывать конкретные вопросы - их может быть великое множество. Своей задачей я вижу только наметить области, чтобы у вас осталась своего рода карта знаний.
Само собой, если вы проходите собеседование на позицию junior, от вас не будут требовать опыта и знаний по всем вопросам. Будет круто, если вы разбираетесь хотя бы в ~30% всего этого. От позиции middle я бы ожидал примерно ~50%-60% знаний перечисленных мною тем. Ну и далее по восходящей.
Автор: Алан Ричардсон (Alan Richardson) Оригинал статьи Перевод: Ольга Алифанова
Краткое содержание: вариация – полезная тактика для тестирования. Зачастую это случайная вариация внутри класса эквивалентности. Варьировать можно также и при исследовательском тестировании. Подумайте над варьированием порядка, данных, состояний, времени.
Наткнулся на ситуацию, похожую на потенциальный баг обработки хэштегов LinkedIn, и это заставило меня задуматься, как бы тут пригодилась тактика вариации.
Автор: Яковлев Станислав — 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) — это механизм для поиска и замены текста. В строке, файле, нескольких файлах... Их используют разработчики в коде приложения, тестировщики в автотестах, да просто при работе в командной строке!
Чем это лучше простого поиска? Тем, что позволяет задать шаблон.
Например, на вход приходит дата рождения в формате ДД.ММ.ГГГГГ. Вам надо передать ее дальше, но уже в формате ГГГГ-ММ-ДД. Как это сделать с помощью простого поиска? Вы же не знаете заранее, какая именно дата будет.
А регулярное выражение позволяет задать шаблон «найди мне цифры в таком-то формате».
