Махмуд, поджигай!
Ведь это же прекрасно, ящетаю:
Еще лет пять назад, когда мы нанимали тестировщиков, мы делали это в предположении, что вообще работа эта не очень квалифицированная (то есть большого ума не требует), но хороший старт в компании. Человек потестирует годик, а потом мы его (ну, чаще всего, ее:) переквалифицируем в аналитики или в менеджмент какой-нибудь. Ну, или в декрет проводим 🙂 И, в общем-то, это устраивало обе стороны.
А теперь ситуация изменилась. Тестировщики стали хотеть заниматься тестированием и QA. В эту профессию приходят очень неглупые люди. С амбициями. Они активно учатся. У них получается. Они достигают в этом деле очень неплохого уровня в среднем, а кое-кто уже считает себя гуру 🙂
Теперь вопрос: а готова ли компания вообще и руководители разработки в частности к такому развитию событий?
Степень “готовности” может сильно отличаться и внутри одной компании. Мой заказчик одним депертментом набирает только сильных тестировщиков, требует высокой продуктивности и ставит серъёзные задачи (автотесты, CI, technical tests), а другим департментом – не берёт тестировщиков совсем, аргументируя тем, что и без них никакой катастрофы не происходит.
LikeLike
> Теперь вопрос: а готова ли компания вообще и руководители разработки в частности к такому развитию событий?
Это зависит от заказчика/компании/команды. Есть готовые. Есть не готовые.
LikeLike
Вернее даже, не столько не готовые, сколько не желающие / не заказывающие / имеющие другие приоритеты.
LikeLike
Согласна с Димой.
На работе таже ситуация.
Не готовы. совсем.
а то что начинают тестировать иногда очень даже раздражает. (меня лично)
я же не лезу править сама баги в их код? Даже если знаю как и имею доступ?
нипарядок(
LikeLike
Кого раздражает, а кого и не раздражает 🙂
Меня вот больше раздражает, когда после коммита и билда эта задача помечена как fixed, а она не работает, а потом “Ой, я не то закоммитил”. Закоммитил – вот возьми и проверь сразу, меньше новых билдов надо будет делать.
А если нерабочий код будет закоммичен в транк, и билд не собирается, то зла будет вся команда, и в случае рецидивов такого разработчика могут довольно скоро уволить.
Или вот раздражает э-ле-мен-тар-ное отсутствие проверки ввода пустой строки для поиска. Блин, программеры, это ж первое, что я сделаю.
Или вот вспоминается, как на проекте N разработчику выделили время и дали задачу написать автотесты для сервера, потому что чем быстрее выявляются большие проблемы в новой сборке сервера, тем меньше времени теряется впустую (если без автотестов, то проблема может быть выявлена минут через 40, а не через 10, и все по новой).
Крооооооме того, если так широко посмотреть, то даже code review это white box testing, а оно-то уж точно является рекомендованной на ряде проектов практикой.
LikeLike
Мало того, и разработчики начинают все больше и больше тестировать. Вот и получается, что разработчики пишут программы, в которых все меньше и меньше багов. Тестировщики хотят управлять процессами. Что же остается руководителям проектов? – Только идти и кликать на кнопки по екселю 🙂
LikeLike
There’s so many different worlds,
So many different suns
And we have just one world,
But we live in different ones.
(c) Dire Straits, “Brothers in arms”
Видел разных заказчиков, видел разные проекты, разные приоритеты, разных разработчиков и разный код.
– Заказчик может навешать на разрабочиков столько, что им будет вообще не до тестирования
– Разработчики очень даже могут считать, что не их (“касты” 🙂 ) это дело
– Заказчик может не выделять времени/денег на какие-то виды тестирования вообще (автотесты, тестирование серверной части, да что угодно).
– Приоритетом проекта может быть выкладывание приложения в appstore еще до того, как оно будет хорошо протестировано
– Наконец, в заказе-“доработке” первая версия может прийти страшно глючное приложение на говнокоде — непонятно, что за *люди* это разрабатывали и как оно тестировалось, блин (если вообще тестировалось).
Проекты бывают очень разные, и далеко не во всех картина сколь-нибудь близка к райской.
LikeLike