Домашним заданием второго дня стало оформление багов в багтрекере MantisBT:
свободно распространяемая система отслеживания ошибок в программных продуктах
кроссплатформенная
сделана на PHP
С другим не работала, но уже точно знаю, чего мне не хватает в этой:
отдельного поля для версии тестируемого сайта (сначала лепила не туда, где тренеры желали бы ее увидеть, а именно - в название бага, скромненько и в скобках). В итоге, мне посоветовали писать номер версии в поле с описанием, в конце и отдельным блоком). А для версии ОС полей аж 2.
со следующим пунктом я даже не знаю, недостаток это или полезная вещь. Если долго оформлять баг-репорт, то время сеанса заканчивается. Мои несохранившиеся версии репортов плакали, причем несколько раз. Буду считать, что это все-таки полезная вещь, и чего мне не хватает на самом деле, так это скорости.
Самым трудным оказалось не раздобыть баги в заданном количестве 4 штук. Нет.
Самое трудное -- чтобы баг-репорт засчитали (приняли к рассмотрению, пометили confirmed) сначала первый тренер, а потом и второй (который разработчик).
Для себя я поняла:
язык мой что-то совсем беден стал.
а если и не беден, то такой-то он коряво-витиеватый в попытке выразить проблему одним предложением.
если баг - нужно писать на одном языке с разработчиками;
если фича - нужно написать, что именно улучшить, и какая выгода - тут свой язык.
писателями баг-репортов не рождаются, а становятся.
если с изучением программированию 100% работает подход "пишем код - пишем код - пишем код...", то здесь спасет только "переписываем репорт - читаем комментарии - переписываем репорт - читаем комментарии - переписываем репорт...". И лучше набить шишки и руку сейчас, чем наломать дров в рабочей ситуации.
повезло с тренерами: подход к обучению на 10 из 10.