Тестирование веб-сервисов *

20-25 лет назад у профессии тестировщика на территории постсоветского пространства не было престижа от слова совсем. Тестировщиками брали тех, кого называли «уверенными пользователями компьютеров». В какой-то момент они были подобны «менеджерам по уборке помещений» — прибраться за разработчиками, рассказать, что вот тут они букву потеряли. Представления о качестве, процессах и разработке развивалось очень медленно.

Со временем такое отношение сильно изменилось, и сейчас хороших, грамотных специалистов в тестировании расхватывают просто мгновенно. Но одновременно это повысило требования к ним. Прошли те времена, когда тестирование было лёгкой точкой входа в IT. Сейчас начинающему тестировщику нужно преодолеть технический барьер и многое изучить, чтобы войти в профессию. При всём этом, все еще нет единой системы обучения тестированию.

Об этом я и хочу сегодня поговорить.

Конференция по тестированию Heisenbug грядет: до старта осталось меньше месяца. В программу вносят последние штрихи, поэтому уже можем рассказать Хабру, какие доклады в неё попали.

Будут полюбившиеся зрителям спикеры, работающие над популярными инструментами: Артем Ерошенко (автор Allure Framework), Андрей Лушников (занимается Playwright), Олег Ненашев (из команды Jenkins).

Будут и совершенно новые темы. Например, впервые на Heisenbug поговорят о тестировании Flutter-приложений и умных девайсов. Более того, речь зайдёт даже о беспилотных автомобилях и экзоскелетах!

А помимо обычных докладов, пройдёт ряд воркшопов, где на экране вместо теоретических слайдов будет происходить сплошная практика.

Для хабрапоста мы разбили полный список докладов на тематические блоки —  так что можете выбрать интересное вам и перейти к нему.

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

У обоих подходов есть свои плюсы и минусы. Компании всегда хотят принять правильное решение, чтобы не рисковать временем и деньгами. Так что же лучше – покупать или создавать самим? Постараюсь ответить на этот вопрос ниже.

Привет, Хабр. Меня зовут Макс. Я специализируюсь на реконструкции и развитии процессов. Сегодняшняя история про баги. Не баги вообще, а про вполне конкретную их категорию.

Представьте себе космический мусор. Или пластиковые острова в океане. Или гору фантиков от конфет в холодильнике. По отдельности каждый смятый фантик, пустая бутылка или деталь спутника не заслуживают внимания. Куда важнее прямо сейчас заняться новым спутником, целой конфетой и полной бутылью. Вместе же, эти кучи представляют проблемы. Хотя и проблемы будущих нас.

О таких багах и пойдёт речь. Они не блокируют выпуск релиза. Они всегда оказываются на дне беклогов. Им нет числа, т.к. даже на подсчёт не находится времени. Они напомнят о себе ровно в тот момент, когда вы окажетесь не готовы.

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

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

В этой статье я расскажу о причинах такой катастрофической разницы, а также об инженерных практиках, которые позволят поддерживать высокий темп разработки:

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

Я аналитик, который сам недавно оказался в ситуации первого типа (вообще не слышал ничего о GraphQL и Hasura, каюсь), поэтому статья не претендует на глубокое погружение в тему и нацелена скорее на аналитиков и тестировщиков, которые не работали с упомянутыми инструментами.

Теперь всё, переходим к контенту с чистой совестью.

Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.

Для тех, кто хочет войти в профессию

В 1947-м 9 сентября зарегистрировали первый баг в истории IT. Это было забавно: Гарвард, учёные тестируют вычислительную машину Mark II Aiken Relay Calculator и вдруг видят застрявшего между контактами электромеханического реле мотылька. «Bug» (англ. «жук»)! — сказала Грейс Хоппер, одна из первых писавшая программы для предыдущей версии гарвардской ЭВМ Mark I. Уснувшее навеки насекомое извлекли из реле и вклеили в технический дневник, сопроводив надписью: «First actual case of bug being found (первый случай в практике, когда был обнаружен жучок)». Так багами стали называть ошибки в программах, а процесс их исправления — debugging (отладка). И так 9 сентября стало Днём тестировщика.

Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.

Если вы когда-нибудь думали: «С какого же языка программирования мне следует начать свое путешествие в тестирование?» Ваш ответ – Python. Но он подойдет не только начинающим! В недавнем опросе, который я провела в LinkedIn, мы видим, что среди опытных программистов 35% проголосовали за то, что Python является их самым любимым языком программирования (немного опередив всеми любимую Java, которая заняла 2-е место с 32%).

На протяжении многих лет Python действительно набирает обороты как среди тестировщиков, так и среди разработчиков, да и в целом является самым динамично развивающимся языком программирования (как видно на диаграмме трендов Stack Overflow), и мы прекрасно понимаем, что это значит. Популярность = релевантность!

К концу этой статьи я ставлю своей целью дать вам понимание того, насколько мощным является язык программирования Python и какой фреймворк для тестирования лучше всего подойдет вашему проекту исходя из его потребностей.

Ошибки допускают все, это нормально. Но их нужно разбирать и принимать решения по их недопущению. Это и называется учится на ошибках. А обеспечение качества - это учиться на чужих ошибках.

В этом посте узнаешь про распространённые ошибки, какие повстречал, как их увидеть, как с ними бороться и к чему приводит их допущение.

Когда мы работаем с API-схемами, обычно существует несколько моделей, и они синхронизируются на разных уровнях. Обычно есть база данных, код и схема. И всё это нужно держать между собой в синхроне, чтобы они нормально друг с другом взаимодействовали.

Я расскажу об обычных проблемах, с которыми люди сталкиваются при использовании API-схем. Как можно использовать API-схемы для описания property-based-тестов, и чем здесь может помочь Schemathesis. И покажу на практике, как его можно интегрировать в  существующий проект.

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

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

Жизнь QA станет проще, если использовать чек-листы из статьи.

Рынок автоматизированного тестирования — один из самых быстрорастущих в ИТ-индустрии. К 2024 году его объем достигнет планки в 30 млрд долларов. В то же время все больше компаний нанимает инженеров-тестировщиков широкого профиля, которые сопровождают продукт на протяжении всего жизненного цикла. 

Под катом Мария Снопок, руководитель команды тестирования Х5 Технологии, рассказывает о том, кто такие SDET и каким компаниям они нужны, а также делится собственным опытом обучения кадров.

Обычный пятничный вечер. Ты уже расслабился, попивая кружечку чая или чего покрепче... Но тут, как назло, бомбит личку в телеге твой надоедливый коллега DevOps со скринами ошибок твоего кривого коммита на серваке. Спустя четно потраченные нервы и логирование всего и вся, все же удалось найти ту самую строчку кода, что так мешала всем жить. Не хотелось бы попадать часто в такие ситуации, да и обременять последующее поколение на те же муки.

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

В 2018 решил освоить Vue.js, так, для общего развития, а как известно, лучший способ освоить язык/фреймворк/etc — начать писать. В голову пришла довольно простая идея, которая со временем выросла в довольно большой проект — онлайн сервис «Места», позволяющий создавать свои коллекции мест на карте, геометок, с подробной информацией о них. Собирать их в альбомы, сортировать в дереве папок, просматривать, редактировать, обмениваться с другими, открывать для просмотра другим пользователям сервиса. Привязывать к местам фотоальбомы, экспортировать свои библиотеки в файлы JSON и GPX (для навигаторов, например), импортировать в свои библиотеки места других людей.

Идея была проста. Есть множество средств создания фотоальбомов, музыкальных плейлистов — с описаниями, возможностью сортировки, ссылками, преферансом и барышнями. А похожей полноценной картографической реализации толком нет. По крайней мере, я не нашёл.

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

Проект свободный (https://github.com/assador/places, сам действующий сервис пока здесь: http://places.scrofa-tridens.ru). Сейчас в планах помимо API Яндекс.Карт, которые отвечают, собственно, за карту, подключить и другие — OSM, 2ГИС и пр. Хочу добавить возможность добавлять к местам не только фото-, но и видео-, и аудиоальбомы. Развивать структуру прав и ролей пользователей, их связь друг с другом на сервисе, расшаривать библиотеки в соцсети и пр. Короче, для меня штука интересная.