Home

Опубликован предновогодний выпуск рассылки.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Дорогие наши читатели и подписчики! Портал Software-Testing.ru поздравляет вас с наступающим новым 2021 годом. Мы желаем вам, чтобы год прошел без багов здоровья и с успешными релизами во всех областях вашей жизни. Пусть удаленная работа будет только вашим выбором (и желательно с пляжей Таиланда)! Будьте счастливы и здоровы!

Автор: Даниил Тимашов
Оригинальная публикация

Привет, Хабр. Я работаю QA Automation инженером в компании Wrike и хотел бы поговорить о том, как нам удалось оптимизировать процесс код-ревью для репозитория с 30 000+ автотестов при помощи IntelliJ IDEA плагина. Я расскажу о внутреннем устройстве плагина и о том, какие проблемы он решает в нашей компании. А еще в конце статьи будет ссылка на Github репозиторий с кодом плагина, с помощью которого вы сможете попробовать встроить плагин в ваши процессы.

Автор: Кристин Джеквони (KristinJackvony)
Оригинал статьи
Перевод: ОльгаАлифанова

Если вы работаете на компанию, разрабатывающую ПО для конечных пользователей, то, возможно, вы слышали о пользовательских персонах. Персона – это репрезентация сегмента конечных пользователей вашего приложения. К примеру, если вы делаете сайт для продажи товаров для дома, одной из ваших персон может быть Свежий Домовладелец Ник, который только что купил свой первый дом и не особенно разбирается в починке всяких мелочей. Другой персоной будет Все-Сама-Дора, которая много лет чинит все в доме самостоятельно.

Недавно мне пришло в голову, что в тестировании тоже есть персоны. Однако, в отличие от пользовательских, этих нужно избегать? Читайте дальше, чтобы узнать, применимы ли эти персоны к вам.

Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout

У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.

Автор: Тоби Стид (TobySteed)
Оригинал статьи
Перевод: Ольга Алифанова

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

К сожалению, такие компании – редкость, поэтому, обнаружив себя в такой ситуации, легко испытать головокружение от всего, что вы хотите сделать и чего достичь. Однако куда меньшая редкость – это в один прекрасный день открыть бэклог или доску JIRA (или того инструмента, которым вы пользуетесь), и увидеть, что все сложности по запуску новой тест-автоматизации, все ее проблемы и задачи дистиллированы в один-единственный тикет – зачастую с расплывчатым именем вроде "Создание автотестов".

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

Автор: Богданов Валерий, руководитель группы тестирования, Мир Plat.Form (НСПК)

Привет! Меня зовут Валерий Богданов, и я отвечаю в Мир Plat.Form за тестирование в команде мобильных платежей. Я уже писал, что в 2018 году мы запустили сервис мобильных платежей и в связи с этим, примерно одновременно, мы начали разрабатывать 2 мобильных платежных приложения:

• наше собственное приложение Mir Pay;
• приложение, разрабатываемое одним из наших партнеров по нашим спецификациям.

Автор: Майкл Болтон (MichaelBolton)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщик из "Agile"-команды жалуется на объем регрессионного тестирования, который, по его словам, должен выполняться в конце каждого скрипта.

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

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

Изменения несут риск регресса, поэтому разумно сосредоточить часть тестирования на этом риске. Но разве тестирование – это безотказный, надежный способ решить вопрос с риском регресса?