Комментарии 18
-1. Не предлагайте ему работу в mail.ru
Mне как-то раз ТЛ сказал «в идеале багрепорт должен содержать минимум шагов для воспроизведения». А я в тот раз в спешке сделал запись экрана, что баг все еще воспроизводится, чтобы его просто не закрыли. Как я обиделся на такое замечание! Один единственный раз мне пришлось поступить «не по Кодексу Самурая», и сразу прилетело. Я же молчу, что в идеале программа которую пишет человек с профессией Software Engineer не должна нуждаться в тестировании…
А еще очень полезно, если разработчик эти базовые сценарии задокументирует, т.к. некоторые вещи, очевидные разработчику не всегда очевидны тестировщику и наоборот, и такой сценарий иногда позволяет увидеть / понять причину логических ошибок.
Так agile поможет или не?)
Насчёт второго пункта и рекомендации использовать agile — а чем это собственно поможет? Допустим есть спринт две недели, есть куча задач, которые занимают скажем неделю и больше. Разработчики делают эти задачи, тестировщики в лучшем случае занимаются какими то exploratory задачами, в худшем просто курят бамбук. И за два дня до закрытия спринта и вваливается дохрена задач от разработчиков на валидацию — и привет аврал.
О какой равномерной загрузке может идти речь, если большинство задач в спринте занимают полспринта и больше? При таких условиях за два-три дня как раз и будет приходить вал задач. Да, это лучше, чем если бы задачи делались три месяца, а потом у тестировщиков неделя на валидацию, но проблема не решается — вместо огромного аврала раз в несколько месяцев регулярные авралы раз в две недели. В компании где я работаю это как-то обходится тем, что разработчики берут задачи из следующего спринта, в результате в начале каждого спринта длинные задачи уже наполовину выполнены и нагрузку на тестировщиков действительно получается размазать, но даже так случаются факапы. Плюс при этом сами спринты размазываются и становятся сложнее предсказуемыми (а ведь это одна из главных фишек скрама). Поэтому и интересно — может есть решение лучше?
Опять же, в компании в которой я тружусь, мы имеем право переносить задачи и снимать их с релиза в том случае, когда они не аффектят задачи параллельных команд и подразделений, что добавляет дополнительную гибкость в рабочий процесс. Также мы можем при необходимости вывести задачу в не до конца готовом виде, если в ней есть критические недостатки, чтобы не откатывать всю разработку или выводить задачи поэтапно — на часть пользователей или дробить разработку на малые части. Плюс можно выводить доработку в заблокированном или скрытом виде. В общем, возможностей море.
И да, как показывает практика, скрам более гибок нежели водопад. Но есть области, где водопад единственно возможен.
Плюс не все задачи приходят за 2 дня до конца спринта. Если разработчики выкатывают новый билд каждый раз, когда что-то готово, то спринт проходит довольно мирно. Аджайл не спасение ото всех бед, конечно. Но он довольно неплохая штука.
7 советов, как не взбесить коллегу-тестировщика в его праздник