Всем привет. Меня зовут Дарья и я специалист по контролю качества программных продуктов в компании «Ренессанс Страхование», а проще говоря, тестировщик.
«Ренессанс Страхование» — не первое мое место работы тестировщиком.
Я расскажу вам, чего не следует делать, то есть подробно, на примерах, опишу наиболее распространенные ошибки при создании бага.
Сначала я опишу два реальных примера ошибок, которые меня напугали, а затем перейду к советам, чего не следует делать.
Все примеры, которые я привожу в статье, взяты из предыдущих мест. Итак первый баг: «Я захожу в эту систему и нажимаю отключить» 
не понятно:) Бывает, что то, что нам, тестировщикам, кажется очевидным и простым, для других сотрудников таковым не является, потому что они одновременно работают с разными системами.
Из-за неудовлетворительного качества бага им придется потратить время на выяснение того, о чем идет речь (какой продукт, какая среда, какая система и т. д.).
- «При кодировке UTF 8 русские слова переводятся хреново»
сладкая кракозебра Единственное, что хочется сказать после прочтения, так это то, что кракозябра вполне может быть милой :).
Да, сейчас ИТ-специалисты понимают, что хотел сказать автор этого бага.
Но тут уже встает вопрос об отношении к коллегам и работе.
Неужели нельзя потратить чуть больше времени и вместо использования «знакомых» выражений технически грамотно описать проблему? Самое горькое и печальное — это последующие сообщения о таких багах с покрасневшим от стыда лицом.
Еще хуже — краснеть перед разработчиками и аналитиками за ошибку, «унаследованную» вам от уволившегося тестировщика.
Объяснять, что это не мое дело — «меня заставили» — это последнее дело, часто вообще никого не волнует, но в то же время каждый коллега по такого рода багам предопределяет уровень «горестных тестировщиков».
Подобные случаи происходят очень часто и, к сожалению, влекут за собой множество неприятных последствий, а именно:
- подрыв репутации конкретного тестировщика и всех тестировщиков компании;
- недооценка значимости процесса тестирования;
- рассуждения о том, что тестировщики — это дополнительное звено в процессе (типа их цель — найти и зафиксировать ошибки, но по-человечески они этого сделать не могут);
- появление разговоров о том, что тестирование не может быть проще — несчастный тестировщик может это сделать, а значит, и обезьяна может.
Лично для меня тестирование — это невероятно интересный и сложный мир, в котором нет места халяве и выполнению задачи «абы как».
Поэтому очень хочется, чтобы тестер контролировал уровень выполняемой работы.
А к внедрению багов он вообще относился как к «святая святых».
Поэтому я решил написать памятку: «Как не создавать баги.
Или распространенные ошибки»:
1. Работайте на скорость
Скорость хороша в спорте, но при тестировании стоит обратить внимание на качество.Представим себе следующую ситуацию: один тестировщик создал 50 ошибок, но 30 из них требуют общения и уточнения, а 15 можно вообще закрыть, т.к.
это вообще не ошибки, а особенности или особенности, которые можно изменить в настройках браузера.
Другой тестировщик создал 15 информативных ошибок, которые можно сразу принимать в работу без отклонений и уточнений.
На чьей стороне будет «победа»? Мне кажется, ответ очевиден?
2. Отсутствие конкретики
Помимо первого пункта: ошибка должна быть настолько понятна разработчику, чтобы ему не нужно было писать вам и задавать дополнительные вопросы.
3. Использование сленга при формулировании ошибки
Как уже говорилось в примере про «крокозябру»: если вам не хватает технической грамотности, Google может помочь.Иначе в глазах коллег вы олицетворите мальчика с картинки: смешного и нелепого.
4. Пренебрежение примерами и скриншотами
Этот широкий жест не будет лишним и сэкономит много времени для максимально быстрого выполнения задачи.P.S. Не путайте: экран — необходимое и полезное дополнение, а не полное описание ошибки.
Скрин не должен заменять описание.
5. Своевременная передача ошибки разработчику.
Разработчикам гораздо приятнее видеть актуальную и четко описанную версию ошибки.
Это убережет вас от ненужных трат.
6. Обновление критериев приемки
Условия игры могут измениться во время тестирования.И зачастую не один раз.
Обсуждения могут проходить не только на общих собраниях со всеми коллегами.
Также есть официальная и неофициальная переписка, обсуждения по телефону, комментарии к заданию в багтрекере и в различных мессенджерах.
А здесь сотрудники хотят быстрее докопаться до истины, и зачастую никто не дублирует задачу в реальном времени и не обновляет критерии приемки.
Прежде чем закрывать какую-либо задачу (созданную вами ошибку или задачу, тестируемую на новый функционал), было бы здорово потратить немного времени и, пока все свежо в памяти, собрать «экстремальную» информацию из всех источников (документация, общение с коллегами, чаты, телефония) и укажите это в критериях приемки.
Да, я хотел бы сказать, что такая работа – это обязанность аналитика, но, исходя из своего опыта, могу сказать, что по уважительным причинам или по невнимательности аналитики редко возвращаются к закрытой задаче.
Ведь через какое-то время тестировщик, успешно забыв тестируемый функционал, может столкнуться с задачей, которая повлечет за собой регрессию.
И здесь тестировщик, вместо того чтобы тратить время на выяснение, где находится текущая информация и кому доверять, сможет сразу приступить к своим обязанностям.
7. Институт «псевдожуков»
Под «псевдобагами» я подразумеваю особенности тестовой среды или опции, которые можно отключить в настройках браузера.Как тривиальный пример, при входе на страницу авторизации автоматически предлагаются логин и пароль.
Эту проблему можно решить, очистив файлы cookie. Другой пример — кроссбраузерная совместимость.
В одном браузере картинка четкая и отлично отображается на экране, а в другом поля перекрывают друг друга.
Возможно, дело в масштабе? Прежде чем паниковать, сначала следует убедиться, что установка одинакового размера масштаба в обоих браузерах не решит проблему.
8. Изменение ожидаемого результата
Бывают случаи, когда тестировщику не хватило информации для полного понимания процесса (отсутствие или наличие недостаточного/слабого анализа).И может возникнуть ситуация, что через некоторое время после внесения ошибки окажется, что ожидаемый результат, который вы указали, неверен.
Он должен быть другим.
И тут начинается самое интересное: тестировщик, чтобы замести следы «преступления», удаляет описание ожидаемого результата или (что еще хуже) начинает спорить с разработчиком, что имелось в виду нечто иное.
Допустить ошибку – это нормальная рабочая ситуация.
Не бойтесь это признать и исправить: либо закройте задачу с соответствующими примечаниями и создайте новую с актуальной информацией, либо по согласованию с командой измените описание в текущей задаче.
Еще одна жизненная ситуация — внедрение ошибки без ожидаемого результата.
В этом случае приходится винить себя и понимать, что разработчик исправит, как он понял из описания.
И далеко не факт, что правка совпадет с тем, что вы ожидали.
И было бы непрофессионально отвергать решенную задачу, заявляя, что вы ожидали «чего-то другого».
Поэтому все ваши ожидания и пожелания должны быть указаны в критериях приемки.
9. Неспособность отличить перед от задницы.
Одним из важных критериев при внесении ошибки является возможность различить, к какой части сервиса относится ошибка — к фронтэнду или бэкенду.
Пример: проверка не работает в поле.
Ошибка была продублирована и затронула как фронтальную, так и серверную команды.
Обе команды тратят время и ресурсы, пытаясь исправить ошибку.
Если тестировщик не может определить это самостоятельно, лучше обратиться за помощью к коллегам: другим тестировщикам, тимлиду, разработчикам.
Ответ обязательно будет найден, будет затрачено меньше ресурсов, не будут дублироваться ошибки, засоряющие систему отслеживания ошибок.
Все довольны.
10. Работа с логами
Тестировщик должен уметь работать с логами, чтобы определить и понять, какая ошибка произошла, где именно она воспроизводится (в какой системе, при каком переходе).Является ли ошибка специфичной для тестируемой системы или вызвана другими внешними системами.
При создании ошибки следует прикреплять ссылки на логи, чтобы сэкономить время.
такое тоже случается Работа тестировщика напрямую и неотъемлемо связана с ошибками: мы их обнаруживаем, добавляем в системы отслеживания ошибок и следим за их устранением.
Поэтому очень важно правильно их начать, ведь без них никуда не денешься.
Ошибки являются жизненно важным органом в процессе работы системы.
Постарайтесь включать их поаккуратнее, тогда всем станет легче.
Теги: #Тестирование веб-сервисов #тестер #плохой совет #выявление ошибок
-
Игры Для Гламурных Девочек
19 Oct, 24 -
Легко Используйте Сканер Hp В Локальной Сети
19 Oct, 24 -
Тормоза В Snow Leopard
19 Oct, 24 -
Html5: Доступ К Батарее Через Javascript
19 Oct, 24 -
Услуги Wcf Ria. Начинать. Часть 1
19 Oct, 24
