Home

Автор: Ульяна Муратова
Оригинальная публикация

Меня зовут Ульяна, я тестирую новые фичи и продукты Selectel. Обычно тестирую фронтенд сайта компании или панели управления, но сегодня выступлю немного в другой роли тестировщика.

Я завсегдатай Heisenbug — одной из самых крупных конференций для тестировщиков. На последнем митапе мне запомнился доклад про различные фичи и возможности браузерных инструментов разработчика. Некоторые были для меня в новинку, и я решила протестировать самые интересные и полезные, на мой взгляд. Оценила их на практике и составила обзор по каждому. Если вы в поисках новых инструментов для работы, вам под кат.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Эта статья – часть серии "Основы Cypress". В этой серии я попытался пошагово объяснить базовые вещи. Если вы хотите узнать больше, открывайте любую статью серии.

Автор: Никонов Владислав

Статья написана в рамках моего личного блога о тестировании и QA: https://t.me/qanva_blog

При изучении техники тест‑дизайна «доменный анализ», я столкнулся с тем, что многие авторы описывают ее по‑своему, что вполне логично. Перелопатить много разных статей об одном и том же, чтобы найти подходящее изложение материала и в конце концов понять желаемое — естественный процесс обучения. Но в случае доменного анализа, я заметил расхождение: кто‑то описывает данную технику сложно, а кто‑то ограничивается простой позицией — «это просто работа с классами эквивалентности и граничными значениями».

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я разговаривал с моим непосредственным руководителем про end-to-end (e2e) тесты и их предназначение. Возможно, дело в моем лингвистическом прошлом, но я лучше думаю, Когда пишу. Я решил перечислить, чем должен быть хороший e2e-тест и что он должен делать, а чего не должен. Так я и пришел к этому списку.

Автор: Никонов Владислав

QA инженер имеет внушительный арсенал техник тест-дизайна: классы эквивалентности, граничные значения, попарное тестирование, диаграммы состояний и переходов, таблицы принятия решений, сценарии использования и альтернативные сценарии, перебор комбинаций, деревья решений ...эмм, это все что я помню, если что-то забыл, поправьте. 

Так вот, сценарии использования и альтернативные сценарии, мы обычно получаем от аналитиков из спецификации.. таблицы, деревья и диаграммы мало кто чертит, так как это занимает много времени (при дефиците ресурсов). Как правило, в ходу две популярные техники: классы эквивалентности и граничные значения, и только отдельные умнички используют pairwise ( попарное тестирование ). 

Скажу честно, принять эту технику я смог далеко не сразу. Я тогда еще не до конца преисполнился познанием и из-за непонимания было недоверие к, сгенерированным инструментом, кейсам.

Конечно, на собесах, у всех от зубов отскакивает: "создаются все возможные отдельные комбинации каждой пары входных параметров" или "в 97 процентах случаев, баги находятся на комбинации двух параметров", но давайте разберемся, почему pairwise сложно применить ручками и поймем как забить на это и успешно применять его в своей работе.

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я слушал в Twitter про Page Object vs Screenplay. Это было интересное обсуждение, прозвучало много хороших точек зрения и идей. Затем я написал в Twitter, что эта сессия укрепила меня в убеждении, что автоматизированный стэк подходит для множества вариантов внедрения автоматизации. Стоит ознакомиться с сессией Spaces и тредом в Twitter.

Оригинальная публикация

В январе 2022 мы подводили командные итоги 2021 и обнаружили, что у нас довольно много приемочных багов при тестировании новых фич. Мириться с этим было нельзя, и за дело принялся знающий человек — наш тимлид. Он собрал команду и поставил задачу: снизить количество приемочных багов до минимально возможного значения, желательно разика в три. Это был челлендж, который казался невыполнимым. Но сдюжили! Расскажу, как мы всего добились и почему это хорошо.

Автор: Гаурав Синх (Gaurav Singh)
Оригинал статьи
Перевод: Ольга Алифанова

Сейчас очень распространено такое название должности автоматизатора, как SDET (расшифровывается, как инженер по разработке ПО в тестировании). Уф! У меня ушло почти семь секунд на то, чтобы полностью это произнести.

Шутки в сторону – эта роль была впервые популяризирована крупными техническими компаниями вроде Microsoft и Amazon, и сейчас ее часто можно встретить в описаниях вакансий по всему миру.