— Артем, расскажите нам о своем секрете успеха, какой путь вы прошли?
— Мой путь начался достаточно давно, после института я пришел в молодую компанию ещё зеленым специалистом и, по сути, не имел никакого опыта. Команда, в которую я попал, была собрана из очень крутых специалистов и опытных профессионалов. Они поддерживали и помогали мне на каждом этапе моей работы. И это мне очень помогло получить такой сильный базис для мощного старта.
— Артем, расскажите, в чем заключается работа тестировщиков и какова их роль в проекте?
— Вообще работа тестировщика является значимым этапом в разработке любого проекта. Безусловно в проведении тестирования программ, либо программных продуктов участвуем не только мы, весь процесс требует пристального внимания со стороны, например, аналитиков, бизнес-аналитиков, продакт оунеров, разработчиков. И они тесно сотрудничают с командами QA-инженеров для понимания полной картины. Непосредственно тестировщики же необходимы для того, чтобы выявить баги в системе, понимать, насколько корректно работает программа, есть ли поведение, которое мы не ожидали и готова ли в она в целом уйти в реализацию для массовой аудитории. Так же тестировщики работают с программными продуктами как бы со стороны пользователя. Т.е. они на практике могут увидеть проблему в реализованном продукте или найти неточность и/или несоответствование реализации требованиям. В таком случае происходят обсуждения и согласование изменений с другими участниками разработки.
При этом, тестировщики могут заниматься как условно «простой» работой, так и комплексной. «Простая» работа — это прохождение уже написанных тестовых сценариев. Комплексная же работа предполагает знание программного продукта, как он выглядел в предыдущем релизе, какие изменения планируются в будущем и одновременно с этим поддерживать тестовую документацию в актуальном состоянии. Таких комплексных специалистов и принято считать QA-инженерами.
— А можете рассказать подробнее про работу QA-инженеров?
— QA-инженеры ведут проект с момента, когда он только зарождается. Они знакомятся с системными требованиями, чтобы понимать общую картину всей системы, в рамках которой будут взаимодействовать программы и их компоненты. Так же QA-инженеры разрабатывают тестовые сценарии, которые позволят наглядно отслеживать корректность работы тех или иных компонентов системы. При обнаружении багов (поведение системы, которое не соответствует ожидаемому), заводятся заявки на их исправления. После внесения исправлений командой разработки, QA-инженеры должны проверить не только исправление бага, но и то, что внесенные изменения не приводят к новым багам в этом же или смежных компонентах. По-другому QA-инженеров называют командой, обеспечивающая качество.
— Основываясь на вашем опыте, какие неожиданности могут встретиться в работе тестировщика?
— Однажды я завершил тестирование своей части функционала, которая вошла в релизную версию программы. Но, к сожалению, реальные пользователи сочли функционал, который я тестировал, излишним. Поэтому пришлось проводить новое тестирование релизной версии программы, но с уже убранной частью функционала. В таком случае нужно проверить, чтобы оставшиеся модули и компоненты программы продолжили корректно работать и взаимодействовать.
В другом случае, когда я участвовал в тестировании авиационного программного обеспечения, нам пришлось долго локализировать ошибку в системе. Возникали трудности при поиске источника проблемы из-за того, что на вход ПО подавались переменные, которые использовались в нескольких схемах и в свою очередь влияли на другие входные и, соответственно, выходные переменные. Было обнаружено, что одна и та же переменная использовалась как для включения/выключения освещения в кабине самолета, так и для отображения состояний шасси воздушного судна.
Так что, подводя итог, тестировщик должен быть готов к любым возможным сценариям, которые могут возникнуть с программным обеспечением, и уметь воспроизводить их на соответствующих данных для выявления причины. Желательно предсказывать и проверять такие сценарии заранее. Это могут быть неожиданные действия реальных пользователей или непредвиденные конфликты в работе программы или всей системы.
