[Тестирование веб-сервисов] Как не надо заводить баги. Часто встречающиеся ошибки
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Всем привет. Меня зовут Дарья и я – специалист по контролю качества программных продуктов компании «Ренессанс страхование», а проще говоря – тестировщик. «Ренессанс страхование» — не первое мое место работы тестировщиком. Я расскажу о том, как не надо делать, то есть на подробно, на примерах, распишу наиболее частые ошибки при заведении бага. Сначала я опишу два примера багов из реальной жизни, которые меня ужаснули, а потом перейду к советам, как не надо делать. Все примеры, которые привожу в статье, взяты мною с предыдущих мест.Итак первый баг - «Вот в эту систему захожу и нажимаю отключить» 
непонятно:)Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).- «При кодировке UTF 8 русские слова переносятся кракозябрами»
милая ккракозябраЕдинственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой:). Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Неужели нельзя затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?Самое горькое и печальное – это последующие коммуникации по подобным багам с краснеющим от стыда лицом. Еще хуже – краснеть перед разработчиками и аналитиками за баг, который перешел к тебе «по наследству» от уволившегося тестера. Объяснять, что это не мое – «меня заставили» – последнее дело, зачастую всем абсолютно все равно, но при этом каждый коллега по такого рода багам предопределяет уровень «горе-тестировщиков». Подобные случаи встречаются очень часто и, к сожалению, влекут за собой немало неприятных последствий, а именно:- подрыв репутации конкретного тестировщика и всех тестировщиков компании;- занижение значимости процесса тестирования;- дискуссии о том, что тестировщики – лишнее звено в процессе (вроде их цель находить и оформлять баги, а они и этого не могут сделать по-человечески);- появление разговоров о том, что тестирование – это проще некуда – горе-тестировщик смог, значит, и обезьяна сможет.Ни в коем случае не хочу обидеть или запугать людей, которые только собираются окунуться в тестирование. Лично для меня тестирование – это безумно интересный и сложный мир, в котором нет места халяве и выполнению задачи на «абы как». Поэтому мне очень хочется, чтобы тестировщик следил за уровнем выполняемой работы. А уж к заведению багов вообще относился как к «святая святых».Поэтому я решила написать памятку: «Как не надо заводить баги. Или часто встречаемые ошибки»:1. Работа на скоростьСкорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Мне кажется, ответ очевиден
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Тестирование веб-сервисов, DevOps] Вы неправильно используете docker-compose (перевод)
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр, Карьера в IT-индустрии] Welcome on board или по ту сторону оффера
- [Информационная безопасность, Тестирование веб-сервисов] Meetup «Тестирование в IVI: На страже кино»
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений] Какие вопросы ожидать на позицию автоматизатора и причем тут сортировка?
- [Информационная безопасность, Тестирование IT-систем, DNS, Тестирование веб-сервисов] Путаница зависимостей. Как я взломал Apple, Microsoft и десятки других компаний (перевод)
- [Информационная безопасность, Тестирование IT-систем, Тестирование веб-сервисов] Как я нашел баг, который раскрывал ваш пароль от PayPal (перевод)
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений] TestOps: писать автотесты недостаточно
- [Scala, Браузеры, Тестирование веб-сервисов] Scala + Selenium. Самый стремительный взлет в Лиги наций УЕФА?
- [Тестирование веб-сервисов, Управление проектами, Софт] Минцифры запустило тестирование новой версии портала госуслуг
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр] Паттерны и Методологии Автоматизации UI: Примеры из жизни (перевод)
Теги для поиска: #_testirovanie_vebservisov (Тестирование веб-сервисов), #_zavedenie_bagov (заведение багов), #_testirovschik (тестировщик), #_vrednye_sovety (вредные советы), [url=https://torrents-local.xyz/search.php?nm=%23_blog_kompanii_«renessans_strahovanie»&to=0&allw=0&o=1&s=0&f%5B%5D=820&f%5B%5D=959&f%5B%5D=958&f%5B%5D=872&f%5B%5D=967&f%5B%5D=954&f%5B%5D=885&f%5B%5D=882&f%5B%5D=863&f%5B%5D=881&f%5B%5D=860&f%5B%5D=884&f%5B%5D=865&f%5B%5D=873&f%5B%5D=861&f%5B%5D=864&f%5B%5D=883&f%5B%5D=957&f%5B%5D=859&f%5B%5D=966&f%5B%5D=956&f%5B%5D=955]#_blog_kompanii_«renessans_strahovanie» (
Блог компании «Ренессанс страхование»
)[/url], #_testirovanie_vebservisov (
Тестирование веб-сервисов
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 14-Май 05:57
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Всем привет. Меня зовут Дарья и я – специалист по контролю качества программных продуктов компании «Ренессанс страхование», а проще говоря – тестировщик. «Ренессанс страхование» — не первое мое место работы тестировщиком. Я расскажу о том, как не надо делать, то есть на подробно, на примерах, распишу наиболее частые ошибки при заведении бага. Сначала я опишу два примера багов из реальной жизни, которые меня ужаснули, а потом перейду к советам, как не надо делать. Все примеры, которые привожу в статье, взяты мною с предыдущих мест.Итак первый баг - «Вот в эту систему захожу и нажимаю отключить»  непонятно:)Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).- «При кодировке UTF 8 русские слова переносятся кракозябрами»  милая ккракозябраЕдинственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой:). Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Неужели нельзя затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?Самое горькое и печальное – это последующие коммуникации по подобным багам с краснеющим от стыда лицом. Еще хуже – краснеть перед разработчиками и аналитиками за баг, который перешел к тебе «по наследству» от уволившегося тестера. Объяснять, что это не мое – «меня заставили» – последнее дело, зачастую всем абсолютно все равно, но при этом каждый коллега по такого рода багам предопределяет уровень «горе-тестировщиков». Подобные случаи встречаются очень часто и, к сожалению, влекут за собой немало неприятных последствий, а именно:- подрыв репутации конкретного тестировщика и всех тестировщиков компании;- занижение значимости процесса тестирования;- дискуссии о том, что тестировщики – лишнее звено в процессе (вроде их цель находить и оформлять баги, а они и этого не могут сделать по-человечески);- появление разговоров о том, что тестирование – это проще некуда – горе-тестировщик смог, значит, и обезьяна сможет.Ни в коем случае не хочу обидеть или запугать людей, которые только собираются окунуться в тестирование. Лично для меня тестирование – это безумно интересный и сложный мир, в котором нет места халяве и выполнению задачи на «абы как». Поэтому мне очень хочется, чтобы тестировщик следил за уровнем выполняемой работы. А уж к заведению багов вообще относился как к «святая святых».Поэтому я решила написать памятку: «Как не надо заводить баги. Или часто встречаемые ошибки»:1. Работа на скоростьСкорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Мне кажется, ответ очевиден =========== Источник: habr.com =========== Похожие новости:
Блог компании «Ренессанс страхование» )[/url], #_testirovanie_vebservisov ( Тестирование веб-сервисов ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 14-Май 05:57
Часовой пояс: UTC + 5