Comments 10
В целом все так. Как бывший тимлид команды автотестирования, поддерживаю. Есть только нюанс по поводу того, чтобы мануальные тестировщика писали автотесты - при нынешней агитации, что в ИТ можно войти через тестирование не профильным специалистам, навыков разработки у многих тестировщика не только нет, но нет и способностей к этому. Все же написание правильных автотестов с развитием фреймворка (не инструкций в Огурце) - это работа для разраба хотя бы уровня миддла.
Есть несколько факторов: на сколько сложно будет работать с фреймворком, готовы ли разработчики помогать, есть ли желание у ручных тестировщиков развиваться. У нас и на Android и на iOS нативные тесты с удобной оберткой (писали про них с Олей тут и тут). На текущий момент все наши QA справляются с автоматическим тестированием, более того, ребята отвоевали у разработчиков ответственность за написание автотестов)
Он сидит и тыкает в кнопки и вводит разную белиберду в поля формы в надежде что программа упадет?
господибоже вы мне своим уничижительным снисхождением монитор заляпали.
Никто не надеется что программа упадет, все ровно наоборот. кнопки "тыкаются" и "белиберда" вводится не просто так а на основе юзеркейсов и проблемных мест в коде, там где граничные значения всплывают, типы данных и прочие штуки. Плюс тыкается не просто интерфейс а установка программы, взаимодействие со средой в которой она работает, локализация, отжирание ресурсов, интеграция новых фич. Кто шарит за код конечно поможет себе подсматриванием в него в процессе тестирования, может прям туда разработчику указать.
Автотестирование это автоматизация либо обработки больших объемов данных, либо каких угодно постоянно повторяющихся действий нужных для тестирования. Чем тестить каждый релиз (а он может быть несколько раз в день) одно и то же поле ввода можно отдать это автоматизации, мне вот по работе иногда для проверок надо по нескольку сотен чертежей из формата в формат гонять, руками я естественно бы делал это бесконечно. Автоматизировать можно как угодно что угодно, на что хватит фантазии и на что целесообразно пустить автоматизаторские ресурсы.
Автоматизация не исключает ручное тестирование, что уже упомянуто в посте,качественный тестировщик знает очень много всего понемножку, и язык какой нибудь (а лучше два), и базы данных, и верстку, и сети, и оси на уровне админа, и всякие разные плодящиеся фреймворки и тулзы. лет 10 назад было конечно время, когда было достаточно
тыкает в кнопки и вводит разную белиберду
и не ходить под себя в офисе вне туалета, сейчас уже стандарты подросли конечно. В общем конечно формулу сложно вывести четкую, для каждого предприятия и ПО свои требования и нужды, обычно дележка специализаций это десктоп/мобайл/веб и ручник/автоматизатор, чем больше ты оркестр тем лучше
пишем:
-билиберду в 0, 1, 49, 50, 51 символ
-билиберду на кирилице, латинице, с иероглифами, с умляутами
-билиберду с цифрами, спецсимволами, пробелами, в разных регистрах
-смотрим остается ли она после перезагрузки страницы, есть ли ошибка на повторном вводе, че в базе данных остается после махинаций
-повбивать разные команды и скрипты в поле ввода, посмотреть не отвалится ли чего и не появится ли лишнего
На основе ТЗ сначала создается сценарий тестирования - т.е. как всё должно работать по-идее. А дальше смотрим уже по факту.
Проверяет софт, либо доработку какой-то функциональности на соотвествие ТЗ, либо той логике, по каторой всё должно было работать (нажал кнопку, что-то в базу записалось, проверяем что да записалось, проверяем что запись отображается на форме и тд). И само собой баги, например верстка поплыла при скроллинге страницы, или что-то не записалось в базе, т.к. например не прошло на соотвестие уникальности по какому то полю или ещё чего-то. Нет ли каких-то ошибок в логах, бывает вроде всё работает, но в логах какие-то ошибки есть.
Регресс тесты - чтобы проверить что после того как сделали доработку уже существующем софте, ничего не поломалось и всё работает плюс минус так, как работало раньше.
Нет ли 404 ошибки при открытии страницы и ещё что-то типа того, если это веб-приложение.
Нагрузочное тестирование - чтобы проверить, что всё работает с той производительностью, которая должна быть и система не падает из-за кривых алгоритмов.
Приемо-сдаточные испытания - чтобы проверить, что у заказчика работает всё штатно. По-идее это уже делает какой-нибудь инженер-внедренец, но бывает и тестер участвует, или это один и тот же человек)) Если есть какие-то косяки то соотвестенно пишем баг-отчеты (баг-репорты) и отдаем разработке, чтобы пофиксили.
Короче минимальные знания тестировщика - bash+linux, sql и умение использовать devtools или какой-нибудь postman и другие какие-то инструменты, ну либо руками сидеть и кнопки нажимать.
Прочитайте Сэм Канер "тестирование программного обеспечения", если осилите всю книгу, то есть перспективы.Там же будут ответы на все ваши вопросы.
ТОП-5 вопросов ручных тестировщиков про автоматизацию