Всем привет! На связи Анастасия Макеева. В Утконос Онлайн я работаю лидом автоматизации тестирования на проекте витрины. В мои обязанности входит организация и реализация автоматизированного тестирования сайта, систем и сервисов.
Свой путь в Утконосе я начинала с мануального тестирования, поэтому в этой статье хочу поделиться с вами подходом, который я применила для создания удобной структуры и информативного содержания тестовой документации.
Привет, я Михаил Шваркунов, директор по качеству ВКонтакте. Расскажу, как выглядят наши ежечасные релизы с точки зрения тестирования: как мы переложили часть задач по тестированию на разработчиков, сколько у нас автотестов и что мы ими покрываем. А ещё как команда тестирования сопровождает релиз, какие у нас при этом SLA и что делаем после. И вообще — зачем так часто что-то выкатывать? Что, нельзя подкопить и катать раз в день?
“I`ll be back”, - сказал себе я, начиная вторую статью и…наконец, сделал ее спустя два месяца. Но лучше поздно, чем никогда ( главное - не берите себе это за правило, если вы QA-лид, потому что в этом случае вовремя - всегда лучше, чем поздно). Но что-то я отвлекся от главного. В комментах к прошлой статье просили сделать продолжение. Я подумал-подумал и решил, а почему бы и нет. Ну в общем, что долго тянуть.
Для всех новоприбывших - меня зовут Ваня и QA-лид в международном агентстве аутсорс-тестирования “Кавычки”. В прошлый раз я рассказывал о болях QA - лида и, собственно, что же с ними делать-то. Сегодня поговорим о том, что делать после того, как вы приложили подорожник к ранкам и теперь пора определить, сработало или нет.
Намбер уан. Выстроенный релизный цикл
Вот давайте только глаза не закатывать тут, ладно? Видел я, как на очень многих проектах, когда приходишь, тебе говорят - “у нас все-все работает”. Даже старый дедушкин приемник. Но стоит чуть забросить удочки и уже можно подсекать - клев на ошибки удался. Релизы выходят, когда захотят (например, в третьи лунные сутки), команда ждет знака свыше, в общем, почти пир во время чумы. Вот так не надо.
Надо вот так.
Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»
Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.
Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.
После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =)
Всем привет! Меня зовут Сергей, и сегодня я расскажу о том, как я искал носки мы выстраивали процессы тестирования в команде.
Исторически сложилось, что мы делаем бэкенд для мобильного приложения, из-за чего многое приходилось проверять вручную, а на автоматизацию выделялся один «технический день», когда тестировщики могли посвятить своё время задачам из бэклога QA. В принципе, этого хватало, так как в нашей молодой команде чаще всего разрабатывалась новая функциональность и не было необходимости рефакторинга, а полная функциональность проверялась на регрессе мобильного приложения.
C ростом команды, функциональности и технического долга процессы перестали быть эффективными. В какой-то момент мы поняли, что с нашим маленьким покрытием, заброшенными тестами и текущими инструментами нам далеко не уйти, поэтому решили изменить стек, процессы и подружить тестировщиков и разработчиков. Обо всём этом — в статье.
