DReeborn

 

Я тоже являюсь джуном, но о этой херне(видах и методах тестирования) с первого дня вообще не думал. Первые полтора месяца я занимался только исследовательским тестированием т.к. документации нет вообще. 4 платформы и везде приложение ведёт себя по разному. ИМХО исследовательское тестирование первое чему надо учится.

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

С этими знаниями ты уже будешь иметь общую картину и уже сможешь оптимизировать её и улучшать. В моём случае кейсы излишне и займут слишком много времени для поддержки, поэтому я ввёл чек листы которые весьма легко поддерживаются и помогают организовать тестирование. Теория тестирования это оптимизация процесса, улучшение его эффективности и уменьшение затратности. В корне это просто умение поставить раком систему, а теория тестирования это уже вопрос о том, что система раком нам даёт.

Не стоит сразу делать всё как в гугле, везде разные требования и разные условия. Разберись со всем, а дальше всё само придёт.

 

Это замечательно, но мне кто-нибудь ответит на вопрос или будет пытаться убедить в чем-то своем?) Исследовательское  тестирование тоже требует определенных подходов, а не просто по сайту лазить!

 

Если вы ожидаете, что кто-то вам скажет какие кейсы делать, то зря. Даже "рекомендации" т.к. они просто могут ввести вас в заблуждение. Вам сразу об этом сказали: "Вы ставите абстрактные задачи и даете на них сферические ответы". Хотите научится рассуждать, решайте реальные задачи в реальной компании с реальными людьми.

Я тоже являюсь джуном, но о этой херне(видах и методах тестирования) с первого дня вообще не думал. Первые полтора месяца я занимался только исследовательским тестированием т.к. документации нет вообще. 4 платформы и везде приложение ведёт себя по разному. ИМХО исследовательское тестирование первое чему надо учится.

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

С этими знаниями ты уже будешь иметь общую картину и уже сможешь оптимизировать её и улучшать. В моём случае кейсы излишне и займут слишком много времени для поддержки, поэтому я ввёл чек листы которые весьма легко поддерживаются и помогают организовать тестирование. Теория тестирования это оптимизация процесса, улучшение его эффективности и уменьшение затратности. В корне это просто умение поставить раком систему, а теория тестирования это уже вопрос о том, что система раком нам даёт.

Не стоит сразу делать всё как в гугле, везде разные требования и разные условия. Разберись со всем, а дальше всё само придёт.

 

 

 

Мне совсем не понятен бросок камня в сторону регресса. Автоматизация не заменит человека, это и так понятно, но она является подушкой для тестировщиков. И где ей лучше всего если не в регрессе? Где ещё лучше реализуются плюсы автоматизации как не в рутине?

автор утверждает что вот это “Automate your regression” не имеет смысла

 

что нормальное регрессионное тестирование это творческий процесс а не "прокликивание кнопок". Но если у вас манки-тестеры сидят делают "регрессию" и только кнопки прокликивают по скрипту, тогда пожалуйста, можно автоматизировать

 

Я согласен, что тупо и беспощадно переводить ручной тест в автоматизированный без учёта особенностей автоматизации. Но стоило написать лучше, о том, что кейсы для автоматизации должны быть свои и использовать плюсы автоматизации, а не просто переделкой ручных кейсов. Можно сказать проще, автоматизацию стоит рассматривать как отдельного "специфического" тестера требующего специфический кейсов.

"Прокликивание кнопок" тоже кейс и тоже имеет место быть, и чтобы не делать из тестеров манки-тестеров, почему не дать эту работу автотесту? Этот кейс идеально подходит под автоматизацию и плохо подходит для ручного тестирования, в чём же подвох? Разве автоматизация таких "прокликов" не даст людям больше время на творчество, что наверное и есть главной целью автоматизации как таковой?

З.Ы. Я могу быть не прав, т.к. нов в этой области, поэтому прошу объяснить если я в чём то ошибаюсь.

Мне совсем не понятен бросок камня в сторону регресса. Автоматизация не заменит человека, это и так понятно, но она является подушкой для тестировщиков. И где ей лучше всего если не в регрессе? Где ещё лучше реализуются плюсы автоматизации как не в рутине?

Самое простое, что могу посоветовать, исходя из "страница генерируется с помощью javascript", влепить пару ожиданий в код. Драйвер очень быстро выполняет шаги и спокойно может успеть вперёд планеты всей.

Из сложного стоит посмотреть который из элементов обрабатывает клик.