Всем добрый день!
Писатель из меня, мягко говоря не очень. Но все таки решил поделиться своими мыслями. Не судите строго)
Любая компания хочет постоянно улучшать свой продукт. Где-то функцию новую добавить, где то изменить логику старой. И вот буквально через год, из маленькой "системки", написанной на php, вырастает огромный ресурс с кучей интегрированных систем.
И вот тут должны появиться тестировщики. При чем они должны сразу включиться в работу! И не только найти новые баги, но и не дать повториться старым.
Я убежден на 99%, что тестировщики - это люди. И как все люди, они могут что-то забыть протестировать. Не буду спорить - это плохо. Но к нашему счастью у нас есть инструменты для автоматизированного тестирования, которые сокращают время тестирования и помогают протестировать те вещи, про которые забыли...
Наверняка, когда пишите тесты - то многие методы используете довольно часто. Например: зайти в систему, проверить на ошибки страницу, кликнуть на кнопку создать и так далее и тому подобное. Т.е. набор тестов проверяет самые стандартные вещи. Наши тесты через какое то время стали проходить на УРА! Я придерживаюсь мнения: "Нет систем без багов. Есть плохо протестированные".Решил посмотреть трекер проекта... И увидел, что наши тесты не находят самые тривиальные баги, которые могли бы найти, стоило бы их чуток поменять. Можно конечно говорить о том, что тесты должны писаться по тест кейсами тест планам. Это совершенно правильно! Но садится и быстро писать тест кейсы и тест планы - это слишком долго, а ждать качества никто не будет. Нет ТЗ на доработки, нет тест планов, нет обдуманных автотестов. Но качество в срок нужно...
Мы стали автоматизировать баги. Процесс поставлен следующим образом:
1) Ручник находит баг и отдает его автоматизатору.
2) Автоматизатор вместе с ручником оценивают стоит ли автоматизировать его (зачастую случается, что баг мелкий и не критичный, но для его атоматизации требуется много времени)
3) Смотрят: мог ли баг проявится еще в каком либо месте.
4) Пишем тесты на баг. Пока тесты не проходят - баг не исправлен.
P.S. Что мне это дало?
Из плюсов
- При выкладке на бой, после прохождения стандартных тестов + тестов на баги - я довольно комфортно себя чувствую. Сразу видно, что программисты забыли выкатить, где не прописали.
- Эффект пестицида сразу исчез)
- Повышает квалификацию в автотестах
- Пропускается гораздо меньше багов и продукт качественнее
- Как ни странно, программисты остались довольны от такого нововведения, хотя процесс далек от совершенства
Из минусов
- Тесты нужно поддерживать. Если компания динамично развивается, то нужно иметь 3-4 "авто - человека"
- Иногда это нерационально. Баг копеечный, а времени ка автоматизацию уходит масса
- Лишние тесты нужно исключать. Представьте, что будет через год? 1000 тестов? Да они будут проходить только рабочий день.
Буду рад комментариям. Если у кого то есть мысли на этот счет, то прошу высказывайтесь.
Надо дрючить программистов: каждая зачинка должна "закрываться" их автотестом. Хотя отдельный дивижен автоматизаторов тоже работает, но очень скоро он перейдет на руление инструментом автоматизации, а не написанием тестов.
ОтветитьУдалитьМысль интересная, но мне кажется что затачиваясь под автоматизацию багов, а не пользоватеских воркфлоу вы наоборот увеличиваете влияние эффекта пестицида.
ОтветитьУдалитьИ опять таки теряются бест-практис тест-дизайна, то есть через год мы получаем набор автотестов которые проверяют практически одно и то же (и за счет одного минора в середине воркфлоу падает сразу 3-4 десятка тестов)
Из плюсов тут очень понравилось то, что решение очень быстро внедряется и, кроме того, идет наработка методов для автоматизации.
Кстати, можно уйти от поддержки тестов которые проверяют баги если покрывать те же пути в обычных автотестах по пользовательским сценариям.