Вряд ли среди читателей нашего портала есть такие тестировщики, которые не хотели бы научиться думать быстрее и принимать более подходящие решения для разных задач и проблем. К счастью, это вполне возможно!
Одна из техник, которые помогают нам хранить, структурировать и обрабатывать информацию - майнд-карты, или интеллект-карты. Многие тест-аналитики давно и активно используют их при исследовании программных продуктов, анализе функциональности и проектировании тестов. Но карты полезны не только в тест-анализе! Они помогают выявлять проблемы, находить решения, контролировать статусы продуктов и проектов. И, конечно, майнд-карты можно (и зачастую нужно) использовать во внерабочей деятельности.
Отвечая на вопросы учеников курса Школы Тест-Аналитика, Наталья Руколь записала вебинар, из которого вы узнаете:
Вряд ли среди читателей нашего портала есть такие тестировщики, которые не хотели бы научиться думать быстрее и принимать более подходящие решения для разных задач и проблем. К счастью, это вполне возможно!
Одна из техник, которые помогают нам хранить, структурировать и обрабатывать информацию - майнд-карты, или интеллект-карты. Многие тест-аналитики давно и активно используют их при исследовании программных продуктов, анализе функциональности и проектировании тестов. Но карты полезны не только в тест-анализе! Они помогают выявлять проблемы, находить решения, контролировать статусы продуктов и проектов. И, конечно, майнд-карты можно (и зачастую нужно) использовать во внерабочей деятельности.
Отвечая на вопросы учеников курса Школы Тест-Аналитика, Наталья Руколь записала вебинар, из которого вы узнаете:
Так получилось, что впервые приходится не просто просматривать тесты (апдейтить шаги, результаты, убирать неактуальные), а менять логику и 'архитектуру'.
Возникло две проблемы:
- жалко написанное МЫЖЕЦЕЛЫЙМЕСЯЦПИСАЛИ
- возможность, потерять покрытие.
изначально задача стояла так: написать минимальное количество кейсов, покрывающая максимальное количество функционала. Были бизнес требования и корявое описание архитектуры. Разбили функционала на блоки, перечислили тестовые данные, написали тесты по требованиям. Выбрали, по возможности : 'все пары'. Получили километровые предусловия, и кейсы из 4-5 проверок.
Функционал первой части системы был достаточно работоспособным, поэтому мы справились. К сожалению, во второй части все оказалось куда как хуже. Наши тесты падали все, при этом все в разных местах (хорошо, конечно, что так и получилось отловить косяки вдоль всего бизнес-процесса), но при этом сказать, что приложение 'совсемнеработает' нельзя.
Теперь нужно осознать где у нас плохо, а где не очень и что надо чинить. Приняли решение переписать тесты. Сижу я сейчас на работе. И плачу. Потому что все убивать -жалко и потому что страшно потерять что-то в покрытии требований.
А как вы проводите тест ревью?
Что делаете в случае: 'мы с самого начала делали все неправильно'? (или у вас такого не бывает