testomat.io управление авто тестамиЕсть такие. Я заканчивал АУТС(Автоматизация Управления Технических Систем)
Тестировщиком :)
Много раз сталкивался с тем, что приемы (и, в общем-то, довольно азбучные) тестирования программистами не применяются. Другие шаблоны мышления, "как построить", а не "где может упасть".
Не вижу причин, по которым это не было бы справедливо и для автоматизациии.
для полноты картины не хватает только следующего:
... а еще если что-то криво пойдет - гуся можно и запечь в яблоках. страуса жалко, орла не просто словить, пингвин далеко. а гусь - вот он - под ногами крутится. ох, говорю со своего опыта....
я как-то по-молодости работал в (простите за выражение) Майкрософте, как раз таким тестером-програмером (у них это называется SDET - Software Developer In Testing). Могу подтвердить - зарплаты такие-же как у чистых програмеров с тем же количеством лет опыта
Когда тестируем для подтверждения работоспособности, а когда тестируем для поиска слабых мест (fault injection, load tests, input validation, wrong data injections, ...). Это ведь разные активности. В идеале, и там, и там, иметь бы и тестеров, и программистов.
Извиняюсь за некропостинг, не хотелось создавать отдельную тему, когда такая уже была. К тому же тут в обсуждении были всякие оценки, прогнозы. Интересно понять насколько они сбылись и изменили ли люди своё мнение и отношение по данному вопросу.
Решил воскресить тему, потому что буквально сегодня с мануальными тестировщиками обсуждали процесс разработки авто-тестов, подготовки тестов на автоматизацию, приемку тестов и т.д. Ну, и я сам вспомнил свой опыт и будучи на стороне того, кто отдавал тесты на автоматизацию и наоборот со стороны того, кто принимает тесты для автоматизации.
Так кем же автоматизатор должен быть в большей части - программистом (разработчиком) или тестировщиком (QA-инженером). И сразу оговорюсь, что я не имею ввиду тут очень краткосрочные проекты или с очень точными целями, например, как в презентации ReportPortal’а рассказывали про проект на 2 месяца, где команду из EPAM’а попросили прикрутить к автотестам их отчет, чтобы показать красивые графики какому-то руководству. Они сделали отчет, закончили проект, пожали друг другу руки и разошлись. В таком случае разработка это конечный продукт, а автоматизатор вовсе и не автоматизатор по сути, а просто разработчик. Но меня больше интересует сценарий, когда автоматизацию строят как некий процесс на проекте для обеспечения качества. Потому как я считаю, что в этом случае покупают не тесты, покупают качество - как сервис. А с помощью рук мы его обеспечиваем или же с помощью кода - то дело десятое.
Вот тут в теме был ответ от человека про то кем должен быть автоматизатор. С его слов он должен быть программистом, но аргументы приведены такие, что я бы их мог привести в пользу QA - http://automated-testing.info/t/dolzhen-li-avtomatizator-byt-bolshe-testirovshhikom-ili-programmistom/1597/3
И после прочтения я задумался, почему их отнес к QA, а не к разработке и понял, что просто используются уж слишком собирательные образы. Которые обо всем и ни о чем.
Я бы выделил тут как минимум несколько подкатегорий специалистов, например:
- тестер, умеющий немного кодить (автокликеры и чутка более сложные вещи)
- QA-имеющий хороший бэкграунд разработки, умеющий писать ПО. Изучающий методологии, паттерны и т.д.
- тяп-ляп программист
- хороший программист, тестирующий свой код
- и т.д.
И когда люди начинают сравнивать эти категории, то одному может придти в голову раздолбай Вася программист, который никогда не тестит свой код и отдает сразу тестерам, типа сами все найдут, другому неумеха Петя, который умеет только кликать и создать авто-сценарии или простенькие скрипты. Тут надо понять о каких людях мы говорим.
Я могу описать очень и очень стандартный кейс в автоматизации, особенно в заказной отрасли: есть некий отдел QA, который тестирует продукт или продукты N1…NN, в какой-то момент люди понимают, что гонять регрессию они не успевают или им кто-то из руководства говорит, что был на каком-то супер-крутом тренинге о супер-успешной организации тестирования и теперь модно стильно молодежно все автоматизировать и CI/CD и вот это вот всё и вообще DevOps. Неважно по каким причинам и как возникает потребность в таких ситуациях. По сути даже не очень важно внутренняя ли это вакансия или аутсорс. Далее процесс обычно движется так: из процесса тестирования выдергивается мануальный тестировщик, который должен готовить тесты для автоматизации, решать проблемы автоматизатора и т.д. Автоматизатор берет эти тесты и для него они по сути это ТЗ, т.е. спецификация по которой он и должен создать сценарий. При этом далеко не каждый автоматизатор будет задумываться о том нужен ли данный сценарий вообще, как он влияет на обеспечение качества тестируемого продукта. Он просто берет сценарий в работу и кодит. А потом отдает это обратно, снова отвлекая ручного тестировщика на проверку полученного автотеста. Также если какие-то вещи оказались в описании неоднозначны или там закралась ошибка, то такой автоматизатор ни за что не исправит его. А вернет тестеру и попросит его исправить, уточнить сценарий, снова отрывая того от работы.
И вот подобных “кодеров” автотестов по моему сугубо оценочному суждению очень сложно отнести и к QA и к разработке. Это больше относится к тяп-ляп. Но снова оговорюсь, что это не относится к краткосрочным проектам или с очень чёткими целями и задачами или с нереально круто построенными процессами тестирования, где всегда отличная и всесторонне развитая тестовая модель, постоянно в актуальном состоянии, а разработка ведется по очень подробным и очень хорошим спецификациям и вообще на проекте идеальное документирование и планирование. Тогда, конечно, также можно просто кодить по готовому, ведь по сути именно это и требуется - за это и платят, т.к. QA обеспечили другие люди.
6 лайков
Программистом он должен быть =)
3 лайка
Я знаю несколько людей, кто сразу пришел в автоматизацию тестирования. Кто-то до того делал веб-странички, кто-то для эксела скрипты писал. Но я не могу сказать, что они были программистами. И тестировщиками не были. Но автоматизаторами стали 
У меня так коллега перешёл из автотестирования в андройд разработку
Моё мнение, что больше тестировщиком. Объясню. Я считаю, что тестировщик, это даже больше не профессия, а наверное, склад характера или если хотите, громко сказано, призвпние. Большинство программистов не любят тестировать своё ПО или им лень этим заниматься. Ну вот так, как-то сложилось.
А программированию можно научиться и набраться опыта даже не в тестировании.