Home

Автор: Саймон Томс (Simon Tomes)
Оригинал статьи
Перевод: Ольга Алифанова

Когда я впервые занялся исследовательским тестированием, я понял, что мне нужно научиться ему, чтобы продвигаться в карьере тестировщика. Я прямо-таки подсел! По моему опыту, исследовательское тестирование – ключевой фактор для непрерывного обучения, создания более качественных продуктов, и более тесного сотрудничества с командой. Ниже – очень полезный список, покрывающий нужды исследовательского тестирования.

Автор: Виталий Никоноров
Оригинальная публикация

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

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

Современные сайты определяют местоположение пользователя множеством способов. Прежде, чем начать их тестировать, очень важно понять, как сайты это делают.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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