Как обещала, выкладываю свою презентацию на тему "Аудит процессов тестирования при смене проектной команды". Доклад призван помочь всем, кто хочет оценить текущее состояние проекта, идентифицировать проблемы и наметить дальнейшие задачи по улучшению процессов тестирования. Только обладая знанием, где вы есть сейчас, можно определить дальнейший вектор развития. Я рассказываю про чек лист, который может использоваться менеджерами проектов, руководителями и тест менеджерами, чтобы понять как быстро и эффективно провести аудит существующих процессов тестирования.
На конференции писался звук. Если запись выложат организаторы конференции, то я обещаю свести звук с презентацией.
update: видео доклада можно посмотреть на сайте конференции
SQADays
Немного фоток:
Маргарита, доброго времени суток.
ОтветитьУдалитьЕщё раз спасибо большое за доклад - было очень интересно послушать и пообщаться с тобой после него.
Вопрос у меня вот какой. На 13-ом слайде у тебя задаётся вопрос "Как тестируется?". При этом речь идёт о белом/чёрном ящике и т.п. А предполагается ли в процессе делать анализ о том, что не все виды тестирования проводятся? Не очень понятно на каком этапе мы можем понять, что вроде тестируем как надо, но вот регресс у нас вообще не автоматизирован. Или очевидны требования по производительности, а нагрузочного тестирования нет, как не было. И самое главное - основания для понимания, что нужно провести тестирование ещё одного вида (есть какие-нибудь критерии, например о необходимости автоматизации регресса)?
Добрый день, Владимир! Спасибо, что оценил доклад.) Отвечаю на твой вопрос: я привожу в презентации примерный чеклист, который является базовым примером и не претендует на полноту. В каждом конкретном случае он может изменяться. На этапе, где мы выясняем "Как тестируется?", мы, конечно же, должны узнать какие виды тестирования есть, а какие отсутствуют. Себе в протокол при этом можно выписать список видов тестирования на проекте. Пример см. слайд 27. После того, как мы оценили текущее состояние дел, мы можем принимать решение - что делать дальше? Есть ли что улучшать? Например, как в твоем примере, аудит выявил, что есть нефункциональные требования, но нагрузочного тестирования нет. После завершения аудита мы можем принять решение - вводить\не вводить нагрузку. А это зависит от различных факторов - бюджета, сроков, критичности проведения нагрузки для пользователей. На основе анализа различных факторов, в том числе и рисков, вы принимаете решение – надо проводить или оставим как есть. Если сейчас нагрузка не проводится, но она супер критична и вы не хотите оставлять это в рисках, то конечно надо вводить. Тоже самое и с автоматизацией тестирования и регрессионного тестирования, в частности. После проведения аудита необходимо выявить целесообразность автоматизации. А нужна ли вообще она? Если у вас проект на 2-3 месяца, его не планируют развивать дальше и бюджет небольшой, тогда зачем автоматизировать? Лишние затраты на внедрение инструмента (пусть даже бесплатного), обучение людей и т.д. Оставляем ручное тестирование и все гуд! Я привела примеры того, как вы можете поступать после проведения аудита. Если появятся еще вопросы - я с удовольствием отвечу в почту. Обращайся!:)
ОтветитьУдалить