Comments 17
Разумные программисты благодарны за существование QA в компании.
Если программист занимается работой, а не изображает занятость - QA для него друг, который помогает решать проблемы на начальном этапе, когда они еще не фатальны.
Бывает что баги сложно воспроизводимы и опять QA приходят на помощь гоняя тесты раз за разом и выявляя закономерности.
К счастью, необходимость существования QA осознает всё больше компаний и с QA наконец-то научились нормально работать.
Стереотип № 7. Не разбирающийся человек скажет: "Ну что это за работа? Ты просто сидишь и тыкаешь кнопочки".
Тыж программист? ;)
Мне обычно везло на тестировщиков, могли пойти навстречу и дать быстро исправить багульку, не откатывая статус задачи. Один раз только попался тестер жизненной целью которого было унижать программистов. А еще я работал с парнем, правда не тестером а программистом, у которого был талант рушить чужие программы с пары тройки тычков.
— Команда тестировщиков получает палочку в табель за нахождение багов. Любых. Чем больше, тем лучше — надо же как-то оправдывать затраты на ФОТ подразделения тестировщиков!
— Команда программистов получает палочку в табель за реализацию фичей. И не любых, а тех которые ждет заказчик/выбраны в итерацию/whatever.
В результате, программисты заняты реализацией фичи X. Сосредоточены, работают. Их прерывает условный тестировщик и просит посмотреть баг. Этот баг может быть как реально существующим, серьезным, влияющим на продакшн — так и возникающим в результате маловероятного сочетания разных внешних и внутренних обстоятельств. Разумеется, если вы пишете в аэроспейс, и от вашего отношения к багам зависит жизнь двух сотен человек в самолете — это одно дело. А бывает и так, что для бизнеса важнее выпустить новый релиз с «достаточно работающим» функционалом… В результате, тестировщики ищут не те баги которые надо, и отвлекают разработчиков от приоритетных задач. Потом тестировщики жалуются что программисты их футболят, а разработчики — что тестеры их уже достали… Если обе команды синхронизированы по целям, то и проблемы не возникает. Тем более не возникает такой проблемы если тестровщики интегрированы в команды разработки, а не сидят в своем собственном королевстве.
Ну и разумеется, не следует спихивать на тестировщиков рутинное тестирование, которое может быть автоматизировано через юниты. Тестировщик зачастую не может увидеть, являются ли несколько наблюдаемых аномалий результатом одной ошибки, или наоборот? Лучше разработчика, который писал код — никто тесты на низком уровне не напишет. Тестировщикам для работы должна предъявляться уже работающая и покрытая тестами система, насколько это возможно.
Сама ситуация "тестировщик пишет программисту" - не верная концептуально.
Тестировщик пищет в багтрекер. Если считает что баг супер критический - дополнительно к багтрекеру пишет Менеджеру Проекта. Менеджер проекта смотрит загрузку программистов и кидает кому-то из них баг.
Прямое общение Тестировщик<->Программист в 99% случаев это когда оба прямо сейчас занимаются решением конкретной проблемы. Программист ищет, тестировщик помогает: например показывает быстрый способ репро.
В остальных случаях общение просто не нужно и даже вредно.
В начале моей карьеры, лет восемь назад, я устроился в компанию, которая разрабатывала мобильные приложения на заказ.
У меня был довольно большой парк устройств и в какой-то момент я обнаружил, что ровно на одном устройстве, при старте приложения все запросы почему-то дублируются. Я тогда еще только начинал разбираться в тестировании мобильных приложений и не мог сказать, как так вышло, но тут была очевидная проблема - на всех остальных девайсах так, а на этом не так. Ну и явно два одинаковых запроса подряд (и так с каждым) - это какая-то ерунда.
Ну я и завел баг, что мол, так и так, какая-то ерунда.
Буквально через пять минут ко мне прибегает разработчик и начинает орать на меня матом. В целом суть претензий свелась к тому, что мал я еще в архитектуре приложения разбираться и не пошел бы я куда-нибудь далеко с таким багом. И вообще это не баг, а я ничего не понимаю.
Вот это я конечно тогда знатно оху... удивился. Сейчас меня бы такое уже не выбило бы из колеи и я знаю, что в таких ситуациях делать, но тогда я аж засомневался, а стоит ли вообще тут работать с таким подходом.
Всё закончилось хорошо, через месяц этот человек ушел в Сбертех, а я еще год работал в той компании.
Если у меня десять разных айфонов и пять разных айпадов с одинаковым приложением на нем и на одном из них запросы дублируются - это однозначно баг. Есть конечно маааааленький шанс того, что в спецификации указано, что на конкретном айпаде, условно, нужно делать двойные запросы и даже может быть это правильное поведение, но я не очень в это верю. Ну и да, в том маловероятном случае, когда я таки не прав, объяснить это можно разными способами.
Стереотип № 9. Наличие тестировщика на проекте обеспечит отсутствие багов
Да. тестировщик занимается тем. что улучшает продукт. Но наличие QA-специалиста не означает, что у продукта не будет никаких багов. По разным причинам: начиная от отсутствия необходимой техники до простого человеческого фактора. Так что если есть возможность, помимо тестировщика, продукт нужно тестировать всем: и разработчику, который сделал продукт, и менеджеру, который несет за продукт ответственность перед клиентом.
>нужно тестировать всем
И даже это не означает что не будет никаких багов.
"не.. ну я не понЯл..."
А при чем всем этом пользователь? Не клиент, который заказал и оплачивает "музыку",
а тот, кто вынужден пользоваться этим продуктом.
Вот к примеру "Сбер" и его мобильное приложение, сомневаюсь в том что экономили на тестировании, тогда почему:
- при входе в мобильное приложение сначала надо ввести пароль, а только потом (бывает через пару минут) приложение оповещает что связь плохая и надо попробовать ещё - А наоборот никак??
- почему не про все расходы приходят уведомления? Особенно это бесило с платными СМС??
- почему в некоторых операциях надо по несколько раз подтверждать многократно вводимую информацию (Тройка)
Так понятно - эта же фигня записана в ТЗ! а то, что это ошибки, а может издёвка над пользователем, это ерунда.
И так происходит во многих приложениях
как уже здесь писал, что на тестирование любой начальник и кадровик лучше возьмёт зеленого, чем седого..
// или вот ещё - у меня открыт Хабр, а в Хабр.Карьера я перейти не могу, пароль запрашивает... а почему? где "бесшовные" технологии и любовь к посетителю?
Как же достали тут однотипные мимишные посты об обязанностях QA..
Стереотип №1 отнюдь не стереотип-посмотрите требования в офферах хотя к джунам и там вы его найдете
8 стереотипов, с которыми сталкиваются тестировщики