Баг не пройде як проводити тестування сайту та записувати баги - Сибірікс
Переформулювали. Бачите, що це можна виправити - добре, візьміть з полиці пиріжок. Нормальне формулювання, майже ідеальне. Але надішлють. Тому що дехто забуває ставити пріоритети.
9. Розставляємо пріоритети
Наші розробники йдуть баглистами в порядку пріоритетів:
0 - критичні баги, сайт не працює взагалі або працює не так, як очікується; 1 - критичне юзабіліті, забуті фічі; 2 - некритичні баги; 3 - некритичне юзабіліті; 4 - помилки у текстах; 8 - хотілки.
Написали «Посилання мені зроби красиво». Ок. Баг без пріоритету. Розробник почне робити впереміш, якщо не проігнорує. І буде злитися і посилати в далеку пішу подорож.
За такого підходу програміст виправить баг, і навіть не особливо перенервує. Ну гаразд, якщо просить — зроблю.
10. Не підкидаємо посуд
Новий сайт Сибіріксу тестували щодня. Щодня створювався новий аркуш. Баги відловлювалися одразу.
У чому ж мінус постійної роботи над проектом?
Сидить програміст, думає над баглистом, а тестувальник тим часом підкладає нові баги. Чи доводилося вам мити посуд після великого свята? Її постійно приносять нову та нову. І як настрій був? Не дуже, так? Ти можеш не підкидати, блювати?
Термінальна стадія такого багтрекера — чат розробника та тестувальника як гуглодока. Замість того, щоб пройти три метри і голосом поставити запитання, починаються милі бесіди — листування по півгодини, де всі вважають один одного виродками. Ну чи не виродками, залежно від темпераменту. Але образа збирається. Тому в жодному разі тестувальник не повинен працювати в одній вкладці з програмістом. Ви у своїй робите, він пише у своїй. Це нормально і не дратує.
Буває й таке, щоне залили бойовий сервер для тесту. Про це краще відразу повідомити розробнику до початку тестування. З критичними речами, які не дають перевірити систему, краще по-швидкому попросити розібратися. Якщо поряд сидите. Це сильно убезпечить вас від отримання негативного зворотного зв'язку, а світ стане чистішим і добрішим ;)