Автор: Маарет Пюхяярве (MaaretPyhäjärvi) Оригинал статьи Перевод: Ольга Алифанова
Хорошее исследовательское тестирование балансирует наш выбор того, что делать сейчас – поэтому, когда время вышло, мы уверены, что сделали наилучшую из возможных работу в заданных временных рамках, и способны рассказать об идеях и рисках, которые мы не покрыли. Для баланса выбора нам надо знать, какие варианты у нас есть, и недавно я заметила, что количество вариантов, из которого выбирают некоторые тестировщики, ограничено. Многое из того, что мы сейчас называем тест-дизайном – это припоминание информации с целью сделать информированный выбор. Как говорится:
"Если единственный известный вам инструмент – это молоток, все становится похожим на гвоздь".
Автор: Энди Найт (AndyKnight) Оригинал статьи Перевод: Ольга Алифанова
Тест – это процедура, которая проверяет поведение с целью определить, правильно ли оно функционирует. У тестов много видов – юнит, интеграционные, end-to-end, но все функциональные тесты по сути делают одно и то же: пробуют что-то и сообщают PASS или FAIL.
Тестирование дает эмпирическую петлю обратной связи разработке, и тем самым обеспечивает нашу безопасность. Имея тесты, мы знаем, когда что-то ломается. Без тестов программирование может быть опасным. Мы же не хотим отправить в релиз большие страшные баги!
Как же нам написать хорошие тесты, если мы планируем потратить время на создание тестов? Существует простой, но мощный паттерн, которому следую я: "Настрой – действуй – проверь" (Arrange-Act-Assert).
Автор: Энди Найт (AndyKnight) Оригинал статьи Перевод: ОльгаАлифанова
Писать эффективные тесты трудно. Неустойчивые, непонятные и медленные тесты в целом бесполезны, потому что приносят больше вреда, чем пользы. Паттерн "Настрой – действуй – проверь" дает хорошую структуру, но какими же еще характеристиками должны обладать тест-кейсы? Ниже – 12 характеристик высокоэффективных тестов.
Всем привет! Агеева Нина, автор курса «Погружение в тестирование. Jedi Point» продолжает тему визуального менеджмента в тестировании и знакомит вас с техниками тест-анализа и тест-дизайна: ДПЗ, тестированием на основе диаграммы состояний и переходов, блок-схемами и классами эквивалентности. В своем видео Нина расскажет, почему стоит прибегать к визуальному менеджменту и что это даёт тестировщику.
Тест-кейс (test case)— это документ, который содержит последовательность действий проверки функционала. В него входят наименование функционала, инструменты проверки, инструкции для проверки, ожидаемый результат.
Станислав Марков, тренер курса «Первый Онлайн ИНститут Тестировщиков», расскажет, зачем нужны тест-кейсы, поделится правилами описания тест-кейсов и сделает обзор одного из наиболее эффективных инструментов.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
В прошлый раз мы с Фридой рассматривали визуализации времени, потраченного на различные задачи тестирования, включая работу над тест-покрытием продукта (Т-время), изучение багов и оформление баг-репортов (В-время), и работу по подготовке системы к тестированию и уборке за собой (S-время).
Вышеописанные фазы тест-дизайна в реальности не происходят линейно. Они могут идти во всех направлениях, растягиваться на несколько релизов, и в них будет множество изменений и новых идей по мере интерпретации результатов тестирования.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
В ходе этой серии статей мы рассматриваем альтернативу подходам на основе артефактов к выполнению и отчетности о тестирования: подход на основе деятельности.
Мы с моей клиенткой Фридой обсуждали, как управлять тестированием, не завися от формализованных, скриптованных, процедурных тест-кейсов. Часть любого подхода к отчетности о работе – это коммуникация между менеджером или тест-лидом и исполнителем. В сессионном тест-менеджменте часть этой коммуникации – это разговор, который мы называем дебрифингом, и об этом мы говорили в прошлый раз.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал Перевод: Ольга Алифанова
Часть тест-дизайна лучше отложить на этап выполнения тестов. Имея под рукой продукт, вы можете лучше принимать решения о деталях, а также поймете, какие вариации и отклонения будут быстрыми и полезными. Вы найдете часть нужной вам информации, а также информацию, о необходимости которой вы и не подозревали. Вы узнаете, какие области подвержены ошибкам, что можно быстро протестировать, о чем стоит узнать больше, что на самом деле можно делать с ПО, как все взаимосвязано, и, возможно, самое важное: что можно улучшить.
Используйте эту информацию в тест-дизайне, пересоздайте и перегруппируйте ваши тесты, вернитесь к источникам информации, которые оказались более важными, чем вы думали изначально.
