Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Саманта Коннелли (Samantha Connelly)
Оригинал статьи
Перевод: Ольга Алифанова

Я рекомендую всем соло-тестировщикам регулярно проводить bug bash/групповое тестирование. Этим можно заняться в конце спринта или цикла разработки функции. Вы приглашаете команду, запасаетесь закусками и напитками и вместе тестируете около часа.

Автор: Александр Асмаков 

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

Автор: Ирина Соколова, Senior QA Engineer, qualsolife.ru

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

При этом у меня бывает, что на тестировании документации сложно сфокусироваться, особенно если это затянувшееся коллективное ревью, автор рассказывает детали, а скука обволакивает и затягивает в сон. Я попыталась себе помочь, и зафиксировала некоторые азы рецензирования. Держу их перед собой. Добавим чашку кофе, и ревью превращается в осмысленное мероприятие.
Тем, кто формирует свой стиль работы, пригодится. Делюсь!

Автор: Артём Сапегин
Оригинал статьи
Перевод: Ольга Алифанова

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