Привет! Меня зовут Кирилл, я работаю тестировщиком в R‑Style Softlab. Ни для кого не секрет, что работа тестировщика в области информационных технологий окутана мифами и непониманием со стороны обывателей. Я вспомнил несколько самых распространенных и раздражающих меня мифов и постарался объяснить, почему это неправда.
Работа тестировщика — просто нажимать кнопки и проверять сканеры на ошибки
Этот миф один из самых распространенных, и он весьма далек от правды. Да, кнопки нужно нажимать, очень много нажимать, затем снова нажимать, потом сверять результат, затем нажимать эти кнопки по‑другому и снова проверять результат. Работа тестировщика включает в себя не только рутинное проведение функциональных тестов, но и анализ требований к программному продукту, разработку тестовых сценариев, создание автоматизированных тестов, а также поиск и исправление ошибок. Тестировщик должен быть технически компетентным и иметь хорошее понимание полного жизненного цикла ПО.
Тестировщикам не нужно образование в ИТ
Это неправильное представление, возникающее из‑за того, что многие люди полагают, что работа тестировщика не требует специализированного образования. Однако для успешной работы в этой сфере важно иметь хорошее понимание основ программирования, баз данных и структур данных. Наличие диплома по ИТ или прохождение специальных курсов и сертификаций даст тестировщику преимущество в поиске работы и повышении профессионального уровня. Но кроме этих преимуществ еще можно приобрести понимание цели этой профессии и знание инструментов для ее достижения.
Тестировщики полностью заменяемы автоматизированными тестами
Хотя автоматизация тестирования имеет свои преимущества и может значительно повысить эффективность процесса тестирования, она не может полностью заменить тестировщика. Это связано с тем, что автоматизированные тесты могут проверить только то, что было предусмотрено при написании сценария тестирования, тогда как тестировщик способен обнаружить неожиданные ошибки, проанализировать контекст и принять во внимание множество факторов, которые могут повлиять на работу программного продукта.
Работа тестировщика скучна и монотонна
Хотя работа тестировщика может включать рутинные задачи, такие как проверка функциональности или проведение стандартных тестовых сценариев, она также предоставляет возможность для творчества и саморазвития. Тестировщик может разрабатывать новые методы тестирования, искать самые сложные ошибки и участвовать в разработке высококачественного ПО.
Тестировщики всегда находят все ошибки и недочеты в программном продукте
Несмотря на то, что обнаружение ошибок — это одна из основных задач тестировщика, невозможно гарантировать, что все ошибки будут найдены. Количество возможных путей использования программного продукта огромно, и тестировщик должен сосредоточиться на наиболее важных аспектах и наиболее вероятных проблемах. Кроме того, определенные ошибки могут быть сложными для воспроизведения или возникать только при специфических условиях, что делает работу тестировщика еще более сложной.
Добавлю, что обнаружение ошибок — это одна из основных задач, но не основная! Цель тестировщика — проверить, что ПО соответствует требованиям, работает как задумано и качественно выполняет свои задачи. А ошибки — это последствия контроля качества. Также при моделировании нестандартных действий будущих/текущих пользователей находятся уязвимые места, которые заставляют вести ПО неправильно или же ломают его полностью. Так вот эти уязвимые места в следствии работы команды (ПМ, аналитик, разработчик, тестировщик и т. д.) устраняются, и на выходе у нас получается еще более качественный продукт. т. е. цель у всех одна — качественный продукт, который решает поставленные перед ним задачи быстро, бесперебойно, качественно.
Тестировщики не влияют на процесс разработки ПО
Работа тестировщика имеет важное значение для обеспечения качества программного продукта. Они активно взаимодействуют с разработчиками и аналитиками, обсуждают требования, предлагают улучшения и помогают выявлять и исправлять ошибки еще на ранних этапах разработки. Тестировщикам также приходится работать в команде с другими специалистами и выполнять задачи по согласованию и тестированию изменений программного продукта.
Тестировщикам не нужны коммуникативные навыки
На самом деле, коммуникативные навыки являются неотъемлемой частью работы тестировщика. Они должны уметь ясно и доступно общаться с другими членами команды, передавать информацию о найденных ошибках и обсуждать возможные улучшения. Кроме того, тестировщикам приходится работать с пользователями обычно не напрямую, а через другого члена команды из сопровождения (support) и помогать им разобраться с проблемами в программном продукте. Ведь кто бы ещё мог предположить, что пользователь в момент ввода информации в ПО случайно заденет клавишу Insert и все поломается. Правильно, тестировщик, который учел положение рук.
Тестировщики работают только на конечных этапах разработки
Этот миф тоже не соответствует действительности. Тестирование выполняется на всех этапах жизненного цикла ПО, начиная с анализа требований и проектирования и заканчивая поддержкой и сопровождением готового продукта. Раннее вовлечение тестировщиков помогает выявлять проблемы на первых этапах, что значительно снижает затраты на исправление впоследствии.
Работа тестировщика не творческая
На самом деле, работа тестировщика требует проявления творческого подхода. Они должны предлагать новые способы тестирования, находить нестандартные сценарии и подходы, которые могут привести к обнаружению скрытых проблем. Тестировщик должен мыслить нестандартно и иметь возможность смотреть на программный продукт с разных точек зрения.
***
Работа тестировщика в ИТ — это серьезная и ответственная профессия, требующая профессионализма и технической компетенции. Важно помнить, что тестировщики являются неотъемлемой частью команды разработки ПО и вносят существенный вклад в повышение качества продукта.
Да, и не забываем, что после своей подписи мы, тестировщики, снимаем некую ответственность с разработчика. Если что‑то у пользователя пошло не так в функциональности ПО, в которой мы поставили свою подпись, в первую очередь — это наш косяк, мы не усмотрели или не предположили. Но помните, что любой косяк — это не повод для самобичевания. Да, неприятно, но все же с его помощью мы повышаем нашу экспертизу и профессионализм, делаем выводы и расширяем кругозор. У древнегреческого мудреца Еврипида есть высказывание: «Человек, который много совершает, и ошибается во многом». Но всt же учиться лучше на чужих ошибках. :)
Комментарии (19)
PoksPoks
02.05.2024 14:37+2Почему люди вообще считают, что бывает какая-то легкая работа? На любой работе приходится работать, вот что я могу сказать.
Ivan_Pod
02.05.2024 14:37Обыватель вообще слабо представляет себе отличие тестировщика от верстальщика. Для обывателя все айтишники на одно лицо - главное, чтобы утюг могли починить
Больше всего мифов о тестировании у самих тестировщиков - правильное положение рук в следствии (которое ведут Колобки?) это наглядно демонстрирует
ALapinskas
02.05.2024 14:37+1Просто есть два типа тестировщиков, которые умеют программировать и которые не умеют. И между ними пропасть.
enil78
02.05.2024 14:37+1Начал изучать тестирование (курс на степике,пока бесплатный,ютуб, книга Назиной) и питон( тоже самое- ютуб,книги). В надежде,что может быть смогу уйти в IT. Из-за проблем с ногами- болят,а работа у меня физическая и комп(оператор на заводе). И вы тут так меня воодушевили. И мне УЖЕ 45 лет. Короче,мне ничего не светит и нет смысла.
ProTestingInfo_QA
02.05.2024 14:37Очень хорошая статья для рекомендаций прочтения в телеграм каналах.
Спасибо!
Iskatel_S
02.05.2024 14:37+1Вы ещё про саппортов напишите, вот где днище: это когда у тебя диплом It-шника, но получаешь ты меньше чем плиточник, да ещё и работаешь сутками, и перспективы роста - никакой.
Batalmv
Хорошая статья
Могу только добавить, что этот факт
активно использую, когда собеседую QA. К сожалению, подавляющее большинство кандидатов именно ищет ошибки :(
Откуда это - даже сказать сложно. Но даже люди с претензиями на позиция лида не знают, зачем они вообще есть
Ivan_Pod
и правильно делают
от Майерса, вестимо. Собеседующий лидов не читал Майерса?
Batalmv
Ну дайте почитать :)
Вообще грустно, оказывается, некоторые не только не знают, но и упорствуют в своем незнании
Я поясню. Поиск ошибок не имеет смысла в качестве цели, так как QA команда не отвечает на простой вопрос: софт выполняет требования или нет?
А если нет ответа на этот вопрос, то неясно,чего делать с текущим релизом. Можно идти в прод или нет.
Это вкратце. Поэтому тестировшики, которые идут не от требований, на соответствие которым надо проверять релиз, а ищут баги - просто занимаются не тем. Потому что пропускают требования и оказывается, что-то вообще не протестировано. Либо в релизе есть настолько очевидные баги, что аж стыдно, но QA искренне не понимает, а он тут причем. Я ж вон сколько нашел
Но ... я лично вас не нанимаю, можете и дальше искать баги
Ivan_Pod
Это прелестно, нанимающий лидов не слышал об основных принципах тестирования, один из которых говорит о том, что тестирование демонстрирует наличие дефектов, а не их отсутствие
Batalmv
Видите ли, дя еще раз приведу абзац из статьи
Обратите внимание, что использовано слово "ЦЕЛЬ".
И ЦЕЛЬ - это именно проверка на соответствие требованиям :)
А вот одной из ЗАДАЧ, для достижения ЦЕЛИ и является поиск ошибок. Хотя тоже не совсем. ЗАДАЧЕЙ является отработка тест кейсов, в результате которых могут быть найдены баги.
А ПРИНЦИП, на который вы сослались - говорит банально о том, что тестирование не гарантирует отсутствие ошибок, что и так понятно
---------------------
Но если вы не видите разницы между целью, задачей и принципом - мне будет сложно вам пояснить суть вопроса в рамках оьщения на данном ресурсе
Ivan_Pod
О том, что тестирование не гарантирует отсутствия ошибок говорит другой принцип - заблуждение об отсутствии ошибок
А тот принцип говорит, о другом. Если взять конкретное требование - если уж собеседующему лидов так нравится это слово - расхождение выявленное в процессе его тестирования - или, по другому баг - вещь неоспоримая. Вот AR, вот ER и они различны. Т.е. мы уверенно говорим - баг есть!
Если же AR и ER в нашей проверке совпали - т.е. требованиет "проверено" - мы не можем сказать - бага нет!
Что касается целей - собеседующий лидов лихо машет шашкой и своим "определением" лихо лишает права на существование исследовательского тестирования, unit-тестирования, тестирования самих этих требований... etc
Batalmv
Я не совсем понял, почему вы до сих пор обсуждаете принципе в контексте целей?
Ну правда, вы не видите разницы между целью и принципом?
----------------------------
Про определение - я напомню, что требования бывают как функциональные, так и не функциональные. И QA валидирует решение на соответствие ВСЕМ требованиям
Поэтому установка такой цели никак не может ничего лишить права на существование
Более того, то что вы пишете, QA лид обязан явно учесть в тестовой стратегии, как факт, почему что-то надо делать или почему чего-то не надо делать
------------------------
Я вам поясню по простому. QA команда делает test report. Если в нем явно с самого верху не указана готовность релиза к выходу на следующий этап в виде списка требований, который валидированы и с каким результатом - он уже бесполезен от слова совсем. Потому что совершенно неясно что делать дальше всей команде
А уже потом можно написать, сикоко нашли багов, какой категории, сколько переоткрыли и все остальное
Вот к примеру так указано, что баги есть. Ок, допустим есть критические. Понятно, что дальше идти не стоит (я упрощаю). А если нет, но не ясно, чего тестили и что хотели тестить - ясно что ничего не ясно
Также когда вы идете от требований, вы думаете как их покрыть, какие тестовые данные собрать, какие тестовые системы подключить и т.д.
Ivan_Pod
Здесь два принципиальных момента
1) Если багов нет - приложение пойдет на прод ровно в том самом виде, в каком и пришло в тестирование. Т.е. польза от тестирования даже не нулевая - она отрицательная, т.к. были затраты на это самое тестирование и задержка деплоя. Информация о том какое там у вас тестовое покрытие очешуенное и тесты зелёненькие - по большому счету никому не нужна - всем нужно рабочее приложение
2) Аббревиатура QA уже настолько набила аскомину нормальным пацанам от тестирования, что для неё уже начали придумывать всякие эвфемизмы - например, quality assistans. Потому что quality assurance - это вовсе не то, чем должен, будет, может заниматься нормальный тестировщик
Batalmv
Все верно, но только это :)
Вот QA и нужны, чтобы это проверить. А чтобы проверить самих QA - надо хотя бы знать, что именно они делали, а что нет.
Но если QA ищет "баги", то вряд ли он тут помощник. Но я допускаю, что есть команды, где QA держать для других целей
Ну, все в мире относительно. Как говорится, врач в психушке это тот, на ком халат.
Но отдельно взятый индивидум может решать, что он "наполеон".
Ivan_Pod
О, извиняюсь за беспокойство, месье
TyVik
Самые сложные баги, которые я исправлял, были прописаны в требованиях. Так что на мой взгляд, тестировщик должен не формально следовать спецификации, но и попутно её валидировать от имени пользователя.
Batalmv
Да, но после чего все равно проверять на соответствия уже исправленным требованиями :)
Boethiah
Эээ, поиск багов это одна из целей тестирования. Если по факту приложение/сайт работает не как написано в требованиях, то это в основном квалифицируется как баг. Баги бывают и в требованиях. Помимо этого баги ещё нужно искать вне требований, так сказать.