Тестирование ПО (Тестировщик, QA инженер)

DenisN89:

Тест кейсами покрыть все случаи невозможно, тест кейсы затратно создавать и поддерживать, а польза далеко не всегда есть от них. Поэтому часто банально тратой времени они являются. Можно использовать чек листы для того, чтобы не упустить какие-либо части функциональности. тест кейсы в основном живут в компаниях, где много джуниоров. Один с оптыом пишет тест кейсы, а несоклько джуниоров тупо кликают по ним.

вы шутите, да ?
в тест кейсах пишутся требования к функционалу - требования заказчика , а не фантазии тестировщика , обычно они разрабатываются до начала разработки и на основе их валидируют продукт на тему соответствия требованиям - это я про более менее серьезные компании
(мне приходилось видеть помесь тестировщика с продукт менджером но обычно на крупных проектах есть отдельные продукт менеджеры )

кроме этого еще гоняют на предмет багов - руками и на проектах чуть больше пукалки автоматически . по мере разработки
часть автоматических тестов пишут программеры до или чаще по ходу написания кода, другую часть продвинутые тестировщики

sap12345:

вот тут уже не первый раз слышу упоминание сеньор тестера какого-то мифического у которого скилы, которых нету у мид тестера и зп 100500 тыщ баксов. Что это за сеньор тестер такой и какими скилами он отличается? В два раза больше кликов в минуту чем мидл производит или что?

мой знакомый говорил что они стали платить молодому тестировщику около 2К за феерическую работоспособность
имхо мега скилы тестировщику нужны на мегапроектах, а так достаточно мозга и английского, остальному наверное проще научить в процессе
- дешевле чем брать QA с понтами, но в этом вопросе я могу глубоко ошибаться
и это я про qa от года - человека ведь еще в принципе научить работать надо
с qa до года или с dev до года мало кто работать хочет в принципе

DenisN89:

Программеры пишут до или во время не для того, чтобы на предмет багов гонять, а чтобы сразу после сборки было понятно стоит ли давать на тестирование или нет. Автоматически в принципе невозможно протестировать продукт.

на более-менее крупных проектах тесты гоняются постоянно для отслеживания не поломалось что
протестировать до конца продукт в принципе не возможно - баги перестают приходить только после его смерти

DenisN89:

Иногда (даже довольно часто) автотесты пишутся для галочки. Типо серьезно работаем, нужно добавить автоматические проверки. А времени на это может уйти больше чем потратил бы тестер на ручные проверки.

все можно извратить и испоганить и нет одного решения на все случаи жизни

DenisN89:

От ситуации зависит.

это точно

"в тест кейсах пишутся требования к функционалу - требования заказчика"

+1 к бреду)))

Х.З. вы видели приписку в моих постах "на более-менее крупных проектах" ?
вам не кажется что проекты бывают разные - вы считаете андроидные пукалки однодневки или к примеру системы управления поездами разрабатываются и тестируются одинаково?
я не куа и не знаю что такое чек лист (типа смок теста ?) не знаю что вы на большом проекте за человеко-день прогоните,
не говоря о том как вы к примеру сложную геометрию глазками прочекаете

К тому же ваш знакомый Вам врет )

вам виднее

Electra_venik:

"в тест кейсах пишутся требования к функционалу - требования заказчика"
+1 к бреду)))

у нас требования заказчика перерабатываются в тест кейсы, то есть он решает что конкретно должно происходить по нажатию кнопки - у вас иначе ?

Х.З.:

версию с изменениями достаточно прогнать 1 раз по чек-листу. смысл делать работу одного дня эквивалентной другому?

У нас в среднем 150-200 коммитов в репозиторий день, тесты стартуют по кулдауну, что намного реже, чем после каждого изменения.

Все зависит от специфики.

tempo-rary:

в тест кейсах пишутся требования к функционалу - требования заказчика

Я думаю (надеюсь), вы неправильно выразились.
Тестировщик действительно довольно часто выступает в роли заказчика, где проверяет все ли требования реализованы согласно ТЗ (позитивные кейсы). А вот прорву всех остальных кейсов тестировщик "берет из головы" основываясь уже на своем знании об объекте тестирования.

tempo-rary, какая разница большой проект или маленький? Маленький проект длится в среднем до полугода и минимальный набор проверок маст-хэв.

у нас требования заказчика перерабатываются в тест кейсы, то есть он решает что конкретно должно происходить по нажатию кнопки

А каким органом они перерабатываются?))) Я Вам рекомендую изучить значения терминов "тестовая документация", "тест", "текст-кейс", "чек-лист", "спецификация". И тем кто у Вас в компании пользуется формулировкой которую я сейчас прокомментировал.

в зависимости от языка локейшина и тд по одной кнопке разные сервисы используются и результаты разные

Возьмите любую операционную систему на любом языке - всё выполняется одинаково. Разница только для стран, где текст читается справа налево.

У нас в среднем 150-200 коммитов в репозиторий день, тесты стартуют по кулдауну, что намного реже, чем после каждого изменения.

У программистов изменения - коммит, у тестера изменения - версия с этими коммитами

tempo-rary, если Вы программист, то зачем пытаетесь тестеру объяснить ваши подходы?
О тестах. Написали вы его за 2-3 минуты, прогнали и что? Вы даете гарантию что проверенные пути будут так же работать после сборки?
Пару минут на компонентный тест, я еще пойму. Но на интеграционный - уж извините. 90% ошибок обнаруживают как раз интеграционные и модульные тесты.

Statik1987:

не соглашусь с этим. юнит тесты находят 80% ошибок.

Но они находят ошибки, из-за которых в принципе даже на тестирование отдавать сборку нельзя. Крупные нарушения бизнес логики.

http://baraholka.onliner.by/viewtopic.php?t=12799734
халтур-ка, мужики