Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi
Оригинал статьи
Перевод: Ольга Алифанова

В Министерстве тестирования я принадлежу к очень небольшой группе. Я участвую в независимых митапах, даже если они мне не близки, я делаю доклады, если меня приглашают (но меня не приглашают), и я тихо сижу в канале exploratory-testing в их Слаке. Сегодня я вдохновилась статьей Джамала Тодда в этом канале.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей вы столкнетесь с выдуманным, но реалистичным сценарием использования контрактного тестирования с Pact и Pactflow.

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

Этот распределенный подход к разработке ПО имеет ряд существенных преимуществ, особенно в плане гибкости и масштабируемости:

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

Помимо этих, есть и другие плюсы. Однако этот подход к разработке несет и проблемы, особенно в интеграции и end-to-end тестировании. Чтобы пристальнее взглянуть на эти проблемы и пути их решения, возьмем для примера приложение, состоящие из нескольких неплотно связанных компонентов.

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

Автор оригинала: Vladimir Khorikov

Автор: Eran Kinsbruner
Перевод: Татьяна Рыжова, тренер курса Английский для тестировщиков

Перед тем, как познакомиться с эффективной стратегией непрерывного тестирования, следует разобраться в том, что есть такое “непрерывное тестирование”? Ниже - определение, которое мне особенно импонирует:

“Непрерывное тестирование - это процесс выполнения автоматизированных тестов в рамках конвейера разработки программного обеспечения для получения немедленной обратной связи о бизнес-рисках, связанных с выпуском программного обеспечения-кандидата”.

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