Суть эксперимента

1. Всегда фиксируйте «правила игры» в договоре

1. Данный чек-лист не является самодостаточным документом или руководством. Это лишь необходимый минимум проверок, которые желательно сделать. Дополнительные (расширенные) рекомендации можно получить только после детального обследования инфраструктуры.
2. Чек-лист будет актуален не только для владельцев Check Point. Аналогичные проблемы с дефолтными настройками наблюдаются и у других вендоров: Fortigate, PaloAlto, Cisco FirePower, Kerio, Sophos и т.д.

Ведение документации для тестирования в Google-доках и Google-таблицах — не лучший способ работы с тестовой документацией. Такой подход имеет свои недостатки.

В этой статье я расскажу, как мы перешли от хранения тестовой документации с Google docs к специализированным SaaS-решениям, сделаю сравнение трех разных инструментов (HipTest, Leantesting, Test Management for Jira) и поделюсь результатами такого перехода.

Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA. 

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

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

Что самое первое, что мы изучаем в тестировании? - Правильно, тест-идеи, которые являются базой для всего тестирования в дальнейшем! Возможно, кому-то покажется, что это очень простая тема - берем требования, пишем на основе требований тесты и тестируем. НО мой практически опыт (15 лет) показывает, что все не так просто, и тесты на основе требований — это в лучшем случае одна треть из того, что можно и нужно протестировать. А две третьих - то, что не отражено в требованиях, что необходимо собирать по крупицам во всем что окружает проект: окружение, код, домен и т.д. На сколько успешным будет подобный сбор чаще всего зависти от опыта тестировщика, кто этим занимается. Но даже опыт тестировщика не может быть гарантией того, что все возможные области будут покрыты. А если в проекте нет опытных тестировщиков, что же делать? Выпускать проект недотестированным?

Мы просыпаемся, умываемся, чистим зубы, делаем зарядку, завтракаем и начинаем готовиться к полёту. Мы просыпаемся не потому, что прозвенел будильник, а потому, что прилетел алерт и сегодня ваша очередь дежурства. Выясняется, что в новом приложении задеплоенном в продакшн не были выставлены лимиты на выделение ресурсов в pod’е kubernetes и при росте нагрузки приложение изволило скушать всю память, как следствие к нему пришел ООМ, ну дальше вы знаете. 

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

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

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