Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“Доступность” или ещё один малоизвестный вид нефункционального тестирования

Под проведением функционального тестирования чаще всего мы понимаем деятельность в оценке качества бизнес-алгоритмов работы программы, которые изначально в общем виде были сформулированы заказчиком. Затем их переработали в техническое задание аналитики, по которому было реализовано ПО  программистами в программном коде приложения. Да, к функциональному тестированию также можно отнести и тестирование безопасности использования программного продукта.

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

Автор: Ольга Назина (Киселёва)

Тестирование стабильности или надежности (Stability / Reliability Testing) — проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.

Если не перезагружать компьютер, рано или поздно начнет даже ворд тупить. Потому что «ну хватит уже, месяц ап-тайма, дай мне почистить внутренние кеши!». Или браузер — открыли вы кучу вкладочек, работает нормально. А через день-два-три-неделю начинает тормозить, пока не перезапустите. Это и есть надежность приложения — сколько он проработает в нормальном режиме?

Особенно важно для мобильных телефонов — вы вообще часто закрываете приложение? Я обычно просто жму на домашнюю кнопку, сворачивая его. А потом снова открываю. Приложения, не тестировавшиеся на надежность, постоянно зависают / вылетают / теряют соединение с сетью.