Home

Автор: Сергей Никитченко

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

Я очень люблю тесты и считаю, что любой код должен быть покрыт ими, желательно качественными :)  

Поэтому хочу поделиться с вами опытом внедрения мутационных тестов в проект, рассказать зачем оно нужно и какую ценность несет. Рассмотрим пример внедрения Infection в приложение на Laravel. Но сначала немного теории.

Автор: Никонов Владислав

Статья написана в рамках моего личного блога о тестировании и QA: https://t.me/qanva_blog

При изучении техники тест‑дизайна «доменный анализ», я столкнулся с тем, что многие авторы описывают ее по‑своему, что вполне логично. Перелопатить много разных статей об одном и том же, чтобы найти подходящее изложение материала и в конце концов понять желаемое — естественный процесс обучения. Но в случае доменного анализа, я заметил расхождение: кто‑то описывает данную технику сложно, а кто‑то ограничивается простой позицией — «это просто работа с классами эквивалентности и граничными значениями».

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

После того, как блог почти год лежал, не шевелясь, время продолжить серию про глубокое и поверхностное тестирование (начинается тут). (Поверхностное тестирование (это не оскорбление!) – это тестирование, у которого есть шанс найти все простые баги. Глубокое тестирование максимизирует шансы нахождения всех скрытых значимых багов).

Автор: Тамоя Бекфорд, Жизель Тодд (Tamoya Beckford, Giselle Todd)
Оригинал статьи
Перевод: Ольга Алифанова

Исследование миграции данных 2017 года показало, что, согласно 61% респондентов, в среднем три или более легаси-систем причастны к какой-либо форме миграции данных. Можно предположить, что огромное количество компаний занимаются миграцией данных. То же исследование выявило, что 69% мигрировавших проектов были успешными – а что насчет оставшегося 31%? Вот в чем вопрос: насколько этот результат зависит от нехватки хороших практик тестирования?

Недостаточное тестирование было по факту указано как одна из причин провала проектов миграции данных. Работа с любой миграцией данных – это опасное дело, подверженное высокому риску. Мы, на основании нашего опыта, решили пролить свет на пять (5) наиболее важных факторов, которые нужно учитывать, проводя эффективное тестирование миграции базы данных – тогда проект будет успешным.

Автор: Алия Токарева, ICL Services
Оригинальная публикация

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

Время идет, сроки становятся все короче и короче, а тестировщику еще не предоставили возможности «познакомиться» с программой. Конечно, тестер задастся вопросом: «А как я успею изучить ПО и уж тем более протестировать, если у меня нет доступа к нему?». Здесь я вам отвечу, что изучить и протестировать – можно. Даже без входа в приложение.

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

1. Программное решение уже готово, но требуются значительные изменения или небольшие доработки;

2. Есть прямой контакт с заказчиком или с лицом, который имеет доступ к приложению.

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

«Присаживайтесь поудобнее, начинаем».

Автор: Корисса Е. Оури (Corissa E. Haury)
Оригинал статьи
Перевод: Ольга Алифанова

Когда меня спрашивают, чем я зарабатываю на жизнь, я отвечаю, что я инженер по управлению качеством данных. Люди не особо понимают, что это значит. Я пытаюсь объяснить, что тестирую данные - зачастую это не помогает. У меня есть друзья в технических отделах и отделах разработки, которые не очень понимают, что такое тестирование данных, почему это необходимо, и где его место в мире программирования. Это и понятно, так как аналитика данных - свеженькая область, и даже те, кто ежедневно работает с данными, должны быть готовыми к тому, что что угодно в нашей работе может измениться в любой момент.

Автор: Андрей Охлопков, Product Manager at inDriver

Автор: Александр Молодцов, Старший специалист по тестированию в ГК Юзтех

Добрый день! Меня зовут Александр, я старший специалист по тестированию в ГК Юзтех. В этой статье я постараюсь кратко рассказать историю создания новых исследовательских сценариев и поделиться с вами опытом их применения.

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

1. Статья направлена на популяризацию такого  подхода в тестировании как исследовательское тестирование с применением исследовательских сценариев.

2. Баг – это непреднамеренное преступление разработчика, которое он совершает во время своей работы, и нам, тестировщикам, необходимо локализовать этот баг, то есть раскрыть преступление :)

Автор: Александр Молодцов, Старший специалист по тестированию в ГК Юзтех

Ранее я писал об опыте создания новых исследовательских сценариев в мире исследовательского тестирования. Начало вы можете прочитать вот здесь.

Ну что ж, давайте продолжать, ведь мне ещё есть чем с вами поделиться :)

Автор оригинала: Onur Baskirt
Перевод: serverspace.ru

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

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

Давайте начнем с простого архитектурного представления микросервисов.