Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

С большим волнением представляю вам довольно новую для вас и нашей отрасли идею: Открытое тестирование: что, если мы откроем наши тесты так же, как наш исходный код? Я говорю не просто о тест-фреймворках с открытым исходным кодом. Я говорю об открытии самих тестов. Что, если делиться тест-кейсами и процедурами автотестов станет нормой? Что, если для компаний будет нормальным открыто публиковать результаты тестов? И каков уровень открытости тестирования, к которому наша отрасль должна стремиться?

Автор: Джеспер Оттосен (Jesper Ottosen)
Оригинал статьи
Перевод: Ольга Алифанова

Если тестирование можно интегрировать в разработку, то кто тестирует, если кода еще нет? Должен ли код существовать для того, чтобы существовало тестирование, и в какой момент тестирование можно начинать?

Нынче появился новый тип бизнес-приложений – продукты "Мало кода / без кода". Например, это платформа WordPress, при помощи которой я это пишу. Еще пример более высокоуровневого решения - AirTable, позволяющий пользователю быстро и без кода организовать и автоматизировать информацию. Схожий тренд наблюдается в пространстве тест-инструментов вроде Cypress и Mabl, тест-кейсы и сценарии напрямую присоединяются к end-to-end бизнес-цели, а не к технологиям. Инструменты "низкого кода" – это новый тип бизнес-решений для "кастомизации" и "конфигурации".

В жизни многих разработчиков и большого количества IT-компаний настаёт момент, когда создание open source-проектов становится не менее важным, чем написание кода для внутренней разработки. По просьбе «Лаборатории Касперского» Евгений Мацюк, один из создателей open source-фреймворка для автотестов Kaspresso, делится своими рассуждениями, почему это решение оказалось полезно как для сообщества, так и для самой компании.

Что такое современный open source

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

Ещё до работы в «Лаборатории Касперского» я выкладывал на GitHub свои open source-проекты, например архитектурный CookBook по оформлению Android-проектов. Kaspresso мы с командой тоже выложили на GitHub.

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

Последнее время я спрашивала кандидатов и коллег вот о чем: как бы вы это протестировали?

Я показывала им пользовательский интерфейс. Я показывала им один-единственный тест настроек API, возвращающий настройки. И я показывала им серверный файл конфигурации. Протестировать надо настройки.

Автор: Джефф Найман (Jeff Nyman)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

Лучшие практики помогают обеспечивать долгосрочное здоровье ваших проектов. Но будьте осторожны и не дайте им помешать вам завершить свою работу.

Я разработчик широкого профиля и тестировщик-автоматизатор из Осаки, Япония. Я работаю в разработке с 2004 года и сейчас консультирую, помогая с автоматизированным тестированием.

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

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

У менеджеров, разработчиков и даже тестировщиков часто появляются нуждающиеся в ответе вопросы о тестировании:

• Почему мы не нашли этот баг до релиза?
• Почему мы не предотвращаем проблемы вместо того, чтобы тестировать?
• Тестирование улучшилось бы при использовании практики Х – прямо как у компании Y!

Автор: Михайлов Максим, Scrum Master компании DINS.

Слова благодарности

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

Проблема, которую мы заслужили

Мы участвуем в разработке продукта с долгой историей и сложной структурой. Продуктом пользуется 400 000 компаний по всему миру. В активную разработку вовлечены тысячи людей на 5 континентах. Разные языки, культуры и часовые пояса.

Баги на проде — неотъемлемая часть продукта. Не то чтобы это достойный повод для хвастовства. Просто данность. Подобную картину можно увидеть в известных продуктах с публично доступными трекерами.

Автор: Барри Эйгиатор (Barry Ehigiator)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Мне пишет тестировщик:

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

Мой ответ:

Никак.