Всем привет. Меня зовут Дарья и я – специалист по контролю качества программных продуктов компании «Ренессанс страхование», а проще говоря – тестировщик. «Ренессанс страхование» — не первое мое место работы тестировщиком. Я расскажу о том, как не надо делать, то есть на подробно, на примерах, распишу наиболее частые ошибки при заведении бага.
Сначала я опишу два примера багов из реальной жизни, которые меня ужаснули, а потом перейду к советам, как не надо делать. Все примеры, которые привожу в статье, взяты мною с предыдущих мест.
Итак первый баг - «Вот в эту систему захожу и нажимаю отключить»
Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).
- «При кодировке UTF 8 русские слова переносятся кракозябрами»
Единственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой:). Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Неужели нельзя затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?
Самое горькое и печальное – это последующие коммуникации по подобным багам с краснеющим от стыда лицом. Еще хуже – краснеть перед разработчиками и аналитиками за баг, который перешел к тебе «по наследству» от уволившегося тестера. Объяснять, что это не мое – «меня заставили» – последнее дело, зачастую всем абсолютно все равно, но при этом каждый коллега по такого рода багам предопределяет уровень «горе-тестировщиков». Подобные случаи встречаются очень часто и, к сожалению, влекут за собой немало неприятных последствий, а именно:
- подрыв репутации конкретного тестировщика и всех тестировщиков компании;
- занижение значимости процесса тестирования;
- дискуссии о том, что тестировщики – лишнее звено в процессе (вроде их цель находить и оформлять баги, а они и этого не могут сделать по-человечески);
- появление разговоров о том, что тестирование – это проще некуда – горе-тестировщик смог, значит, и обезьяна сможет.
Ни в коем случае не хочу обидеть или запугать людей, которые только собираются окунуться в тестирование. Лично для меня тестирование – это безумно интересный и сложный мир, в котором нет места халяве и выполнению задачи на «абы как». Поэтому мне очень хочется, чтобы тестировщик следил за уровнем выполняемой работы. А уж к заведению багов вообще относился как к «святая святых».
Поэтому я решила написать памятку: «Как не надо заводить баги. Или часто встречаемые ошибки»:
1. Работа на скорость
Скорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Мне кажется, ответ очевиден
