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

DenisN89:

Ну такое если и будет, то изменение разовое. Допустим, 2 недели спринт. Раз в 10 спринтов может быть такое изменение. Его глянуть сколько, час?

Гм, вы удивитесь, но на внезапных изменениях компонент не написано, что они что то ломают. Тут или повальное ревью фронтовых коммитов тестировщиками(соответствующей квалификации), или сделать тесты и не париться. А так на активно развивающемся продукте - куда чаще 10 спринтов. У нас раз в спринт при активной стадии разработки были такие баги, связанные с активной модификацией фронтовых компонент.

DenisN89:

А запилить тесты и потом их переделать?

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

DenisN89:

Ui автоматизация почти всегда бестолковая вещь. Часто тратиться куча времени ради одного случая обнаружения регрессионного бага

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

DenisN89:

Ну как бы не большая проблема следить за тем, что меняется. Что за разработчики, которые не знают, что меняет? Это часто до начала разработки уже известно

Вопросов больше не имею, картина ясна.

oOFlyAngelOo:

Так если продукт динамично развивается, то там и верстка меняться будет постоянно. Соответственно и тесты править. А беглый просмотр верстки сколько вручную займет? 5 минут на страницу?

Сколько то секунд на матчинг экрана, делается только для изменившихся элементов. Думаю 5-10 человеко-минут на проверку изменений для всей верстки регресса для новой фичи - QA найдут. Тесты менять не нужно, они меняются только если меняется кардинально флоу.

DenisN89:

Часто бывает такое, что разработчик меняет компонент и не знает, где ещё он используется? Я такого ни разу не встречал. А если и не усмотрел, то все равно есть код ревью. Чтобы прямо несколько человек не знало, надо постараться

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

Ivan Igorevich, не соглашусь. Если проект развивается, то обычно не будет десятилетних кусков, которые работают неизвестным способом. Обычно части переписываются, обновляются, оптимизируются
И тем более вряд-ли там ui не менялся 10 лет, а разговор в первую очередь о нем был и о его автоматизации

oOFlyAngelOo:

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

т.е. вас учили ненормальные? Советую не набрасывать.

Дымов, у Баранцева есть пару уроков в онлайн курсе по C#

Ребята, подскажите, наверняка уже многие 100 раз спрашивали. Реально ли отучиться на курсах ( без высшего образования) и быть востребованным на рынке труда? Какие курсы можете посоветовать не глядя ( их бесчисленное множество). Если английский на нуле (немного лексики на общем развитии)- это проблема? Я так понимаю, что тестирование ПО - это наиболее благоприятный вариант для входа в сферу IT?! Спасибо!

DenisN89:

Часто бывает такое, что разработчик меняет компонент и не знает, где ещё он используется?

Часто, особенно не в Джава мире. Не менее часто даже крутая команда разработчиков не имеет 100% покрытия всего проекта юнит тестами, чтобы понять на что повлияли изменения в рамках всего проекта. И очень часто тестирование силами самих разработчиков несколько ограничено, так как они на этом не специализируются, да и это не их прямая задача.

DenisN89:

Я такого ни разу не встречал. А если и не усмотрел, то все равно есть код ревью. Чтобы прямо несколько человек не знало, надо постараться

А я встречал, и многократно. Ошибаются все, плюс влияние обстоятельств. В последний раз например - человек весьма хороший разраб, но в процессе финализации рефакторинга его отвлекали много по сторонним задачам. Ревьювившие нашли все ошибки, кроме одной. Эта одна ломала верстку на части страниц для залогинненых аккаунтов с парой специфических критериев.
Вышеописанный тест позволит найти это еще до мержа в мастер. Без него - найдется только в полном ручном регрессе перед релизом. Если такого нет (ускоренная схема с CD) - найдется уже на проде. Пользователями.
Пара тройка таких находок, и репутация у финтех проекта уходит на дно. Это не какой-нить беларусьбанк с темой "а куда вы все равно от нас денетесь", тут пользователи и вправду денутся, рынок то динамичный.

DenisN89:

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

Такие куски есть даже в Яндексе (Поиск) и в Гугле(Поиск), что уж говорить про не настолько технологические компании, не привыкшие управлять тех долгом, и про банковский сектор, где софта работает десятилетиями, ибо цена ошибки при его обновлении весьма высока.

anisimau:

т.е. вас учили ненормальные? Советую не набрасывать.

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

Дымов:

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

Де факто автоматизация десктопа делается обычно двумя путями:
1. Инструментация прилаги. Это когда разработка (или вы при необходимой квалификации) создаете дев билд прилаги, с торчащими наружу ручками для автоматизации. Например если у вас в приложении используется для гуя какая то типовая либа(скейлформ например), в ней уже есть какие-никакие методы работы с деревьями объектов и их аттрибутами, и их нужно только вытащить наружу. В этом случае тесты пишутся очень похоже на селениумные, только вместо вебдрайвера вы используете собственный самопальный драйвер-враппер над этими торчащими ручками.
2. Если все очень плохо - работа с гуем как с изображением, распознавание контролей как картинок, клики эмуляцией мышки по области, проверки строго через сравнения скриншотов. Тулзы есть на рынке, но сама автоматизация в этом случае крайне неблагодарное дело, в 90% случаев имеет смысл так автоматизировать только смоук. В этом случае надо идти к разработке, и работать над развитием автоматизации с ориентацией по пункту 1. Если все глухо - обдумать смену работы, обычно это весьма однозначный звоночек.

Дымов:

А я соглашусь. Работаю на большом продукте, сам с таким столкнулся - во время проверок нашёл кусок кода в скриптах, который не вызывается никогда. Оказалось, оно отсохло почти год назад и уже давно не нужно
И таких кусков море.

Угу, причем даже хороший упор на постоянную проверку code coverage и статик аналайзеры не гарантирует отсутствие таких кусков. Часто бывают частично задизэйбленные куски, которые вызываются, что то выполняют, но аутпут не используется.

oOFlyAngelOo:

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

seeman--s., для каждого конкретного вайтишника свой.