Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Джеймс Эспи (James Espie)
Оригинал статьи
Перевод: Ольга Алифанова

 Исследование

Если подумать о великих путешественниках, кто приходит вам в голову? Возможно, Тинтин, знаменитый журналист из комикса, исследующий мир в поисках разгадок тайн? Или Доктор (Доктор Кто), исследователь времени и пространства, спасающий вселенную от одной напасти за другой? А как насчет Даши-путешественницы? Она учит детей читать по слогам при помощи своих приключений и преодоления препятствий.

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

Когда мы говорим о глубоком и поверхностном тестировании в терминологии Rapid Software Testing, многие полагают, что "глубокое" тестирование – это хорошо, почетно и правильно, а "поверхностное" – оскорбление. Но это не так. "Поверхностное" – это не оскорбление.

Глубина и поверхностность – это способы обсудить тщательность тестирования, но они не оценивают его ценность. Ценность, качество, уместность тщательности можно оценивать только в контексте. Поверхностное тестирование может быть идеальным вариантом для определенных задач, а глубокое – патологическим. Как так? Начнем с объяснений, что же мы на самом деле имеем в виду.

Автор: Марсель Гелен (Marcel Gehlen)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Группируя эти источники, я обнаружил полезную мнемонику – CDMET.

Автор: Каллум Эйкхерст-Райан (Callum Akehurst-Ryan)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Ниже – инструменты, которые я использовал, и считаю очень простыми в освоении.