Тестирование программного обеспечения – одно из быстроразвивающихся направлений, которое пользуется большим спросом в IT-сфере. Тестировщикам открыты возможности от тестирования работы внутренних систем сложных платформ до тестирования мобильных приложений или сайтов.
Я всегда говорю: “Тестировщиком может стать любой”. Всё зависит от мотивации, исходной базы знаний и скорости восприятия информации. Если вы решите выбрать тестирование как профессию, то сможете повысить свои компетенции в разных сферах, выбрав подходящее направление для роста.
В IT-сфере существуют стереотипы насчет профессии тестировщика. Многие стереотипы сильно обобщены и не имеют под собой основы. Я – Илюся Усманова, старший инженер по тестированию. На 4 курсе университета я ещё не знала, чем именно в IT буду заниматься. Но мои глаза загорелись, как только начался курс по тестированию. Я поняла, что делать качественное ПО для меня интереснее, чем писать код и общаться с заказчиками. В роли QA я уже 7 лет, и за это время сталкивалась с разными мнениями как внутри команды, так и в сообществах тестировщиков. Давайте рассмотрим самые популярные из них.
Стереотип № 1. Один разработчик говорит другому разработчику: “Тестировщики этого не поймут, они не разбираются в технических вещах”.
Это один из самых распространённых стереотипов. Для всеобъемлющего тестирования нужна база в технических знаниях, например, тестировщику нужно:
Быть с ОС на “ты”;
Работать с командной строкой;
Знать, как создавать тест-кейсы и баги так, чтобы любой человек из команды мог понять и выполнить их;
Уметь работать с JIRA/Confluence. С их помощью тестировщики управляют ходом работы, контролируют процесс устранения багов, хранят необходимую информацию об этапах, результатах тестирования и параметрах оценки;
Понимать, как работает клиент-серверное приложение;
Иметь базовые знания в SQL;
Уметь найти и понять логи сервера;
Научиться работать с Postman/SoapUI;
Знать, как пользоваться панелью разработчика в браузерах;
-
Понимать, что такое:
Система контроля версий. Пример: Git;
Системы непрерывной интеграции;
Разбираться в понятиях работы: HTTP/HTTPS, REST/SOAP;
Знать виды кодов и их значение.
Стереотип № 2. Каждый мануальный тестировщик хочет стать автоматизатором.
Необязательно мануальному тестировщику становиться автоматизатором. Есть и другая ветка развития: от мануального тестирования в менеджера.
Стереотип № 3. На тестирование должно уходить не больше времени, чем на разработку.
На самом деле, это зависит от проекта. Где-то ты можешь потратить больше времени на тестирование, чем на разработку, если разработкой затронуты многие части системы и необходимо обширное функциональное тестирование, интеграция между сервисами и регресс. Если все пройдёт хорошо и без ошибок (1 случай из 100) – то отлично. Если нет – то нужно дополнительное время на исправление и перепроверку.
Стереотип № 4. Разработчик говорит тестировщику: “Твоя работа проста! Сломать систему, залогировать баги и пойти домой, испортив наши выходные”.
Часто разработчик думает, что тестировщик так или иначе хочет ему насолить, упрекнуть в ошибке и вообще унизить. Особенно обидно старшему разработчику, когда он получает переоткрытые задачи с багами.
Делаю официальное заявление разработчикам от тестировщиков: мы не хотим вас обидеть, мы просто делаем свою работу! ????
Для того чтобы таких ситуаций не было, тестировщикам нужно в мягкой форме предоставлять всю информацию о найденной ошибке в деталях, со ссылкой на спецификацию, в крайних случаях с подтверждением аналитика.
P.S. Бывают исключения, когда хорошее отношение не помогает. Тогда можно пойти сразу к менеджеру проекта.
Стереотип № 5. Не подходите к тестировщикам, они накинут вам жучка ????
Были случаи, когда я звала разработчиков обсудить ошибку (даже если они не знали, что она там будет). Я видела, как они тяжело вздыхали и подходили со словами: “Ну давай, показывай”. Тестировщиков не нужно бояться – мы все работаем в команде. Есть код, значит есть и баг (ошибка) :)
Стереотип № 6. Разработчик думает, что тестировщики – это пессимисты. Они всегда недовольны и пытаются найти ошибку в идеальном.
Всё не так!
На самом деле мы те ещё оптимисты и пытаемся сделать всё, что нас окружает, лучше идеального ????
Стереотип № 7. Не разбирающийся человек скажет: "Ну что это за работа? Ты просто сидишь и тыкаешь кнопочки".
И он окажется не прав! Если бы я сидела и только тыкала по кнопочкам, чтобы найти хоть какую-то ошибку, то это было бы очень скучно. Да в таком случае и тестировщики вовсе не нужны были бы.
Стереотип № 8. Тестировщики с программистами – как собака с кошкой.
Если разработчики будут воспринимать выявленные ошибки как ошибки, а не как фичи, то всё будет нормально! ????
Я рассказала о стереотипах, с которыми сталкивалась лично. Может быть, вы тоже с ними встречались, а может быть и нет, и что-то для вас стало сюрпризом. Расскажите об этом в комментариях! Будет интересно узнать ваши истории! ????
Комментарии (15)
unsignedchar
21.03.2022 09:23Стереотип № 7. Не разбирающийся человек скажет: "Ну что это за работа? Ты просто сидишь и тыкаешь кнопочки".
Тыж программист? ;)
gruzoveek
21.03.2022 10:14Мне обычно везло на тестировщиков, могли пойти навстречу и дать быстро исправить багульку, не откатывая статус задачи. Один раз только попался тестер жизненной целью которого было унижать программистов. А еще я работал с парнем, правда не тестером а программистом, у которого был талант рушить чужие программы с пары тройки тычков.
ruomserg
21.03.2022 10:23+4Обычной проблемой между программистами и тестировщиками является несовпадение приоритетов. Это обычно случается в компаниях во-первых, больших — а во-вторых, не очень внутри себя синхронизированных. Как это выглядит? А вот как:
— Команда тестировщиков получает палочку в табель за нахождение багов. Любых. Чем больше, тем лучше — надо же как-то оправдывать затраты на ФОТ подразделения тестировщиков!
— Команда программистов получает палочку в табель за реализацию фичей. И не любых, а тех которые ждет заказчик/выбраны в итерацию/whatever.
В результате, программисты заняты реализацией фичи X. Сосредоточены, работают. Их прерывает условный тестировщик и просит посмотреть баг. Этот баг может быть как реально существующим, серьезным, влияющим на продакшн — так и возникающим в результате маловероятного сочетания разных внешних и внутренних обстоятельств. Разумеется, если вы пишете в аэроспейс, и от вашего отношения к багам зависит жизнь двух сотен человек в самолете — это одно дело. А бывает и так, что для бизнеса важнее выпустить новый релиз с «достаточно работающим» функционалом… В результате, тестировщики ищут не те баги которые надо, и отвлекают разработчиков от приоритетных задач. Потом тестировщики жалуются что программисты их футболят, а разработчики — что тестеры их уже достали… Если обе команды синхронизированы по целям, то и проблемы не возникает. Тем более не возникает такой проблемы если тестровщики интегрированы в команды разработки, а не сидят в своем собственном королевстве.
Ну и разумеется, не следует спихивать на тестировщиков рутинное тестирование, которое может быть автоматизировано через юниты. Тестировщик зачастую не может увидеть, являются ли несколько наблюдаемых аномалий результатом одной ошибки, или наоборот? Лучше разработчика, который писал код — никто тесты на низком уровне не напишет. Тестировщикам для работы должна предъявляться уже работающая и покрытая тестами система, насколько это возможно.
AllexIn
21.03.2022 10:48Сама ситуация "тестировщик пишет программисту" - не верная концептуально.
Тестировщик пищет в багтрекер. Если считает что баг супер критический - дополнительно к багтрекеру пишет Менеджеру Проекта. Менеджер проекта смотрит загрузку программистов и кидает кому-то из них баг.
Прямое общение Тестировщик<->Программист в 99% случаев это когда оба прямо сейчас занимаются решением конкретной проблемы. Программист ищет, тестировщик помогает: например показывает быстрый способ репро.
В остальных случаях общение просто не нужно и даже вредно.ruomserg
21.03.2022 11:17В целом, согласен. Но в реальной жизни это может не работать тысячью разных способов. Если тестировщики получают систему для работы достаточно рано — она может быть сырой, и как минимум часть багов благополучно пофиксятся сами по себе в процессе рефакторинга и фиксинга других багов. Тестировщики (в отличие от пользователей) могут тестить граничные случаи и выходить на ситуации, в которых поведение системы не определено (напоминаю, что любая логическая система — к которым уж точно относятся спецификации на сложное ПО — по Геделю, либо неполна, либо противоречива). И в результате, потом требуется еще дополнительно взять откуда-то ресурсы чтобы разбирать баги в трекере. Обычно, у менеджера не хватает квалификации это делать — и оно свешивается опять же на разработчиков. И хорошо, если часы на все это заложены. А если нет — крутитесь как хотите. Опять-таки, это не проблема тестировщиков или разработки. Это проблема процесса и менеджмента. Но это частая проблема больших компаний — причем менеджмент не в состоянии ее ни осознать, ни тем более, исправить… :-(
Palomnik
21.03.2022 10:56В начале моей карьеры, лет восемь назад, я устроился в компанию, которая разрабатывала мобильные приложения на заказ.
У меня был довольно большой парк устройств и в какой-то момент я обнаружил, что ровно на одном устройстве, при старте приложения все запросы почему-то дублируются. Я тогда еще только начинал разбираться в тестировании мобильных приложений и не мог сказать, как так вышло, но тут была очевидная проблема - на всех остальных девайсах так, а на этом не так. Ну и явно два одинаковых запроса подряд (и так с каждым) - это какая-то ерунда.
Ну я и завел баг, что мол, так и так, какая-то ерунда.
Буквально через пять минут ко мне прибегает разработчик и начинает орать на меня матом. В целом суть претензий свелась к тому, что мал я еще в архитектуре приложения разбираться и не пошел бы я куда-нибудь далеко с таким багом. И вообще это не баг, а я ничего не понимаю.
Вот это я конечно тогда знатно оху... удивился. Сейчас меня бы такое уже не выбило бы из колеи и я знаю, что в таких ситуациях делать, но тогда я аж засомневался, а стоит ли вообще тут работать с таким подходом.
Всё закончилось хорошо, через месяц этот человек ушел в Сбертех, а я еще год работал в той компании.
ruomserg
21.03.2022 11:22Ну, тут основной вопрос — а является ли обнаруженное (и безусловно, странное) поведение — багом? Если в спецификации написано, что некие запросы должны генерироваться только один раз — тогда это баг. Если вызовы API идемпотентны, то может быть и не баг. Как раз тот тонкий случай, когда действительно без знания архитектуры нельзя поставить знак равенства между необычно = неправильно. Может быть это какая-то особенность устройства? И да, ругаться матом при обсуждении рабочих моментов — моветон, мы это осуждаем! :-)
Palomnik
21.03.2022 11:36Если у меня десять разных айфонов и пять разных айпадов с одинаковым приложением на нем и на одном из них запросы дублируются - это однозначно баг. Есть конечно маааааленький шанс того, что в спецификации указано, что на конкретном айпаде, условно, нужно делать двойные запросы и даже может быть это правильное поведение, но я не очень в это верю. Ну и да, в том маловероятном случае, когда я таки не прав, объяснить это можно разными способами.
ruomserg
21.03.2022 11:57+1Давайте я скажу аккуратно: как хороший тестировщик, вы безусловно правы, когда замечаете странную ситуацию "… на одном из них запросы дублируются". Однако, контроль качества подразумевает что баг — это несоответствие поведения некоторой спецификации (в лучшем случае) или общепринятой недокументированной норме (в худшем). Соответственно, если есть спецификация которая говорит об определенной последовательности и числе вызовов API — ваше наблюдение дает возможность завести баг. Если спецификации нет — тогда труднее. Ваше представление о недокументированной норме — может отличаться от такового у разработчиков. Они могли уже встречаться со странным поведением некоторых устройств, и встроить от этого какую-то защиту со стороны бэка. Кроме того, в такой ситуации есть еще шанс перепутать адресата бага. Вы пишете баг против приложения, а дублировать запросы может, например, сетевой уровень устройства или другое приложение на этом же устройстве, имеющее доступ к исходящим пакетам… Вы же тоже понимаете, что если приложение болт-в-болт одинаковое, на двух устройствах ведет себя по-разному — велики шансы что дело не в приложении…
zaiats_2k
21.03.2022 16:15+1Ну а материться то зачем? Разобраться. Если не баг - закрыть с пояснением, и создать таск на документирование этой фичи.
iam_const
21.03.2022 11:17+3Стереотип № 9. Наличие тестировщика на проекте обеспечит отсутствие багов
Да. тестировщик занимается тем. что улучшает продукт. Но наличие QA-специалиста не означает, что у продукта не будет никаких багов. По разным причинам: начиная от отсутствия необходимой техники до простого человеческого фактора. Так что если есть возможность, помимо тестировщика, продукт нужно тестировать всем: и разработчику, который сделал продукт, и менеджеру, который несет за продукт ответственность перед клиентом.zaiats_2k
21.03.2022 16:32+1>нужно тестировать всем
И даже это не означает что не будет никаких багов.
AllexIn
Разумные программисты благодарны за существование QA в компании.
Если программист занимается работой, а не изображает занятость - QA для него друг, который помогает решать проблемы на начальном этапе, когда они еще не фатальны.
Бывает что баги сложно воспроизводимы и опять QA приходят на помощь гоняя тесты раз за разом и выявляя закономерности.
К счастью, необходимость существования QA осознает всё больше компаний и с QA наконец-то научились нормально работать.