Тестировщики не тратят время на заведение и полное описание багов, которые даже никто не прочтёт.
По мне так это звучит, как не грамотно настроенные процессы работы тестирования и взаимодействия с тестированием. Мне совершенно не понятно, как можно не читать дефекты
Но баг-трэкинговая система это не обязательный атрибут тестирования. Её не нужно использовать только потому, что используют большинство компаний и так принято в индустрии.
Гибкое решение, но это только потому-что бизнес позволяет и рабочая методология
1. Автоматизированное тестирование
2. Лид
3. Продукт
4. Аналитик
5. Разработчик
6. SDET
Экзотические я даже позабыл уже, так как не встречал на практике, чтобы человек туда развивался, но они имеют пра на жизнь, так что +2 экзотики ещё (Нагрузочное + Безопасность)
Кто из каких ипостасей куда развивается это зависит сугубо от способностей человека. Я описал выше, только реальные случаи, куда мои коллеги развивались
Некоторое время я потратил на то, чтобы понять, чем же действительно занимаются тестировщики. Не давал покоя вопрос, не буду ли я просто сидеть и бездумно нажимать какие-то кнопки без какой-либо перспективы развития.
Человеку сильно повезло, что он попал в ТАКУЮ структуру работы тестирования. Пока ещё на рынке лидирует положение «Много задач и манки тестирование».
Мысли о том, что «немного посижу, потестирую, а потому буду пилить приложения», исчезают со временем сами собо
Самое вбитое предположение у всех, кто только начал работать в тестировании и тех кто только думает войти в него — это то, что все видят свой путь развития из ручного тестирования в автоматизацию. По факту просто многие не знают, что путей развития штук 6-8
Хорошая статься, которую по моему мнению стоит почитать многим копаниям и пересмотреть свой подход к процессам тестирования и взаимодействию с тестировщиками, но ожидал большего начиная читать статью
Интересное начало статьи про процессы работы QA в Альфа-банке с небольшим душком, как будто я читаю вакансию на HH, а дальше просто история про то, как человек пришёл в QA и ему сильно повезло, что в Альфе именно такие процессы
По мне так это звучит, как не грамотно настроенные процессы работы тестирования и взаимодействия с тестированием. Мне совершенно не понятно, как можно не читать дефекты
Гибкое решение, но это только потому-что бизнес позволяет и рабочая методология
2. Лид
3. Продукт
4. Аналитик
5. Разработчик
6. SDET
Экзотические я даже позабыл уже, так как не встречал на практике, чтобы человек туда развивался, но они имеют пра на жизнь, так что +2 экзотики ещё (Нагрузочное + Безопасность)
Кто из каких ипостасей куда развивается это зависит сугубо от способностей человека. Я описал выше, только реальные случаи, куда мои коллеги развивались
Человеку сильно повезло, что он попал в ТАКУЮ структуру работы тестирования. Пока ещё на рынке лидирует положение «Много задач и манки тестирование».
Самое вбитое предположение у всех, кто только начал работать в тестировании и тех кто только думает войти в него — это то, что все видят свой путь развития из ручного тестирования в автоматизацию. По факту просто многие не знают, что путей развития штук 6-8
Хорошая статься, которую по моему мнению стоит почитать многим копаниям и пересмотреть свой подход к процессам тестирования и взаимодействию с тестировщиками, но ожидал большего начиная читать статью
Интересное начало статьи про процессы работы QA в Альфа-банке с небольшим душком, как будто я читаю вакансию на HH, а дальше просто история про то, как человек пришёл в QA и ему сильно повезло, что в Альфе именно такие процессы