Меня зовут Ира и я руковожу отделом тестирования мобильной платформы: наш отдел занимается разработкой инструментов для автоматизации тестирования мобильных приложений Ozon и тестированием внутренних библиотек, которые используются в наших приложениях. Около года назад мы пытались понять, почему у одной из команд джоба с автотестами отваливается по тайм-ауту. К слову, это был проект мобильного приложения для продавцов, и на нем у нас для автоматизации тестирования используются нативные фреймворки: Kaspresso + Kotlin для Android и XCTest + Swift для iOS.
Одна из гипотез заключалась в том, что в приложении могут быть утечки памяти и что-то зависает. Спойлер: дело было не в этом. В общем, около года назад я проверяла, что к чему там у нас с памятью приложения, а сейчас поняла, что полученными знаниями можно и поделиться.
Эта статья будет полезна тем, кто только начинает изучать, что происходит со стабильностью мобильного приложения. Внутри статьи разберёмся с тем, как приложение работает с оперативной памятью; что такое утечки памяти и когда они возникают; как утечки влияют на стабильность работы приложения и как их находить.
Как исправлять найденные проблемы в своей статье я не описываю.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Обращаюсь ко всем менеджерам и руководителям: неважно, что сейчас в моде – сейчас не тот момент, чтобы увольнять тестировщиков или бросать их неподготовленными и необученными.
ПО может творить чудеса. Оно может помочь нам с чем угодно и делает это невообразимо быстро и крайне масштабно. Звучит привлекательно. Опытные тестировщики, как минимум, точно знают, что к результату работы машины надо подходить с должным скептицизмом – машина и ПО созданы людьми, а люди склонны ошибаться. Последствия этих ошибок выразятся в том, что урон и ущерб будут распространяться с той же скоростью и тем же масштабом, что и положительные эффекты.
Если кто-то намеренно создает программу или алгоритм, следует предполагать, что в них, вероятно, есть проблемы – скрытые, неочевидные, возникающие и пропадающие, внезапные. Эти проблемы могут возникать даже тогда, когда разработчик тщательно проверил результат работы функций в своем коде.
Автор: Матвеева Юлия, backend разработчик компании CDEK
Привет любителям котиков! Меня зовут Юля, я backend‑разработчик компании CDEK. Я сама не так давно изучала все эти сложные понятия в программировании, поэтому решила помочь и вам разобраться с одним из них.
С какой стороны IT вы бы не пытались войти — в какой‑то момент столкнётесь с понятием REST API. Эта статья создана, чтобы смягчить данное столкновение. Новые темы всегда легче воспринимаются на простых примерах, ну а если это примеры с котиками, то варианта не разобраться просто нет. Хочется обойтись без сложных научных определений, а рассказать самым простым языком. Поэтому, если вы любите сухие и точные формулировки, то вам нужна другая статья :)
Для написания автотестов используются XPath и CSS-селекторы. Они помогают найти элемент на странице, чтобы потом с ним как-то взаимодействовать (кликнуть, ввести текст, или что-то другое).
Я видела много статей о том, что это вообще такое, но мне очень не хватало шпаргалки по разным селекторам, причем в разрезе «Вот он в CSS и он же в XPath» для сравнения.
А мне такое для студентов надо. Поэтому решила сделать сама. Вдохновлялась страничкой «Xpath cheatsheet», но сделала на свой вкус — под автоматизацию, а не XPath вообще. И с комментариями, с ними удобнее.
Пишите, если где-то накосячила. Хотя я все селекторы проверяла на тестовых страницах, но мало ли… И надеюсь, вам такая шпаргалка тоже пригодится! =)
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Как вы, вероятно, догадываетесь, мне приходит много писем об инструментах тест-автоматизации. КУЧА. Я открываю почти все и бегло их просматриваю. Если что-то цепляет мой взгляд, неважно, хорошее или плохое, я тщательно читаю письмо. Думаю, многие из нас делают так же.
«Плохие» сообщения – это не что-то, полное ненависти или совершенно неуместное (с таким я управляюсь иным образом) – зачастую они относятся к активному продвижению идей автоматизации вне всякого контекста, для чего эти идеи подходят, и что нужно, чтобы их внедрить. Как правило, я просто удаляю это и еду дальше. Иногда мне хочется – конечно, вежливо, - ответить отправителю, что его компания тем или иным образом отклоняется от цели. Иногда я использую их в качестве идей для статьи; это как раз такой случай.
Изначально планировала в этой статье сравнить работу с ментором с курсами, однако, поскольку это будет сильно не объективно (курсов сейчас много, как и менторов), решила провести небольшое исследование на тему того, откуда люди изначально получали знания перед тем, как пойти в тестирование. В этой статье я постаралась собрать опыт 55 человек, заполнивших мой опрос или согласившихся провести со мной интервью, большая часть которых устроилась на свою первую работу в период с 2021 по 2024г. (т.е. когда конкуренция на стартовых должностях уже начала принимать серьезные обороты).
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Новый год – время задуматься, как ваша команда может улучшить качество продукта! Я часто слышу, как тестировщики жалуются, что стали «бутылочным горлом» для своей команды. На них постоянно давят, чтобы они закруглялись с тестированием, и им кажется, что у них не остается времени на качественное исследовательское тестирование или хорошую автоматизацию.
Мой опыт говорит, что тому есть девять основных причин. Читайте дальше, чтобы проверить, применимы ли они к вашей команде!
Всем привет! Я Тимур — iOS разработчик в платформенной команде hh.ru. Сегодня я расскажу о нестабильных UI-тестах в iOS, и как мы с ними справляемся.
Мы уделяем массу внимания UI-тестам, ведь именно они обеспечивают качество и стабильность в наших iOS-приложениях. Сейчас у нас включено около 600 UI-тестов: они гоняются утром, вечером и на каждом PR в develop. О том, как мы обеспечиваем качество мобильной разработки есть отдельная статья.
Рано или поздно большое количество UI-тестов скорее всего начнут тормозить разработку, потому что их стабильность зависит от множества факторов: стенды (API), инфраструктура (обновление Xcode, машин, СI), кодовая база. Даже из‑за проблем в самом XCUITest тесты могут начать выдавать аномалии.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Расхожая фраза «как у всех нормальных людей» означает приобретение лишних «вещей» или особое поведение – только потому, что ваши друзья, соседи, коллеги уже имеют эти вещи или так себя ведут. Идея тут в том, что если вы не хотите выглядеть лузером на их фоне, вам нужно хотя бы идти в ногу с их социальной и экономической позицией. Мой сосед купил новую машину – мне тоже надо. У коллеги новый MacBook – мне тоже надо. Netflix использует Chaos Monkey – мы тоже должны. Даже в мире технологий мы можем стать жертвами схожего феномена, изучая, как другие компании и организации обращаются с различными дисциплинами и технологиями, и тестирование/автоматизация тут не исключение.
Принцип хорошего автотеста — «Подготовь себе данные сам. Не надейся, что они уже существуют». Такой тест можно прогнать на любом стенде, даже пустом. Сам себе всё подготовил, прогнал тест, а потом ещё почистил за собой.
В Postman тоже есть возможность подготовить себе данные для запроса. Причем это можно использовать не только для автоматизации, но и для ручного прогона. Удобно же, когда можно запустить конкретный запрос на конкретный метод, а он отработает успешно хоть на пустой базе, хоть на заполненной.
Подготовка данных делается через функцию pm.sendRequest() в pre-request скриптах, и в этой статье я покажу, как её использовать. Показывать буду в стиле «бери и повторяй» с примерами на бесплатной системе Users.
