Pull to refresh

Comments 20

За последнюю таблицу из №7 отдельное спасибо.

Возник вопрос про 1/20 на оргтехнику от ЗП сотрудника, откуда такой коэф взялся?
Коэф. сложился путём аудита отделов тестирования наших клиентов. Стоит иметь ввиду, что там учтено не только помесячное распределение стоимости организации одного рабочего места (с учётом амортизации). Но и стоимость ежемесячного поддержания/обеспечения этого места в рабочем состоянии.
Ага, а типа аутсорсерам руководитель не нужен, их искать, нанимать и увольнять(прекращать договор) не нужно. Пусть оно само саморганизуется.
А кто-то говорит, что не нужен? Таблица про расходы заказчика — сколько тот будет платить в итоге при прочих равных условиях. В случае с аутсорсом — управленческие и иные виды издержек никуда разумеется не исчезают, просто их на себя берёт аутсорсинговая компания. А как она оптимизирует свои затраты — это уже отдельная история и боль самих аутсорсеров.
Из собственного опыта — в последних трёх местах всё тестирование делалось одним человеком, который рулил тестовым сетапом. В последнем месте это был студент, работавший даром. На качестве тестинга это никак не сказывалось.
Многое зависит от масштаба и отрасли проекта. Теоретически, в компактных проектах всё можно выстроить и на нематериальной мотивации студентов. Главное убедиться в том, что качество и сроки, которые вчерашний студент выдаёт на моральной подпитке, не выйдут боком потребителю на этапе релиза. Про крупные проекты молчу, там такой сценарий неприемлем.
Я не об этом. Грамотное тестирование сейчас делается машинами при минимальном человеческом участии. Присматривает за машинами кто-нибудь вспомогательный, типа интерна или проект манагера, писать эту затрату отдельной строкой в бюджет выглядит, как развод дурачков на деньги.
Статья замечательная, но в последней табл натяжки. Рук-тель аутсорсеру не нужен? Завязка на стоимость оборудования, мебели к з/п начинает иметь место только для топов. Для рядового сотрудника — сомнительно. Не учтены риски организации отказоустойчивого канала связи то локации аутсорсера. Постановка задача для аутсорсера должна быть более формальная, не учтены затраты на коммуникации, на организации встреч.
Для сотрудника на аутсорсе считаем таки ЗП или оплату часов по договору? Если ЗП, то почему без НДФЛ в случае аутсорса и включаем НДФЛ для штатного? Или все же это оплата услуг, а не ЗП.
В правом столбце, сумма, которую вы видите, это сколько конкретно платит заказчик. А уже из этой суммы мы платим и НДФЛ, и ЗП руководителям (аккаунт-менеджерам), и ставим нужным сотрудникам софт, и обеспечиваем бесперебойные каналы.
Тогда давайте будем точны в деталях — в правом столбце стоимость услуги.
При этом в компании — вашем клиенте, — тем не менее должен быть рук-тель или ответственный сотрудник, ответственный за постановку вам задач, контроль исполнения и т.д. Бесперебойный канал нужен не только вам, но и клиенту.

А уж если из этой суммы выплатите ЗП всем своим, то альтернатива у клиента еще может быть лучше — нанять студента за 20-30 т.р. Просто исходный ваш посыл был, что дорогой специалист с вашей стороны за 130тр в итоге дешевле наемного за 70тр. Теперь получается, что ваш спец еще неизвестно сколько стоит == какая у него квалификация. Даже как-то хуже получилось.
Да — по факту это услуга, но тут нас должна интересовать сумма конечных расходов.
Если углубляться в детали, то любой проект вариативен и структура затрат в обоих столбцах может принципиально меняться. Мы привели примерную таблицу расходов для среднестатистического разработчика. Учли самое распространённое.
Ещё раз подчеркнём, схема аутсорсинга и его преимущества подходят не всем. Призываем учитывать все нюансы каждого проекта при расчёте такого рода таблиц для реальных проектов или заказывать экономическое обоснование на стороне.
Хотите экономить на тестах?
1. Не пишите unit-тесты, пишите функциональные. Unit-тесты накаладывают кучу ограничений на архитектуру. Вы сможете выкинуть половину интерфейсов, фабрик и прочего архитектурного халама, который вам нужен только ради возможности что-то замокать.
2. Если ваши требования меняются, то не пишите тесты на ранних этапах всё равно их надо будет переделывать. Помните, что тесты тормозят развитие. Ваши разработчики будут бояться что-то делать, чтобы не поломать тесты. Потому вводить тесты хорошо на поздних этапах.
Помните, что тесты очень дорого сопровождать, особенно, если для написания тестов вы наняли аутсорсеров.
3. Хорошая аналитика частично заменяет тесты. Можно вообще не писать тесты и обойтись A/B-Тестированием в продакшене, если у вас хорошая система аналитики. Для частых релизов тесты вообще вредны — вы просто не будете успевать сопровождать тесты.
4. Не гонитесь за 100% покрытием. Это менеджерский булшит. Покрывайте основные сценарии и реально критичные сценарии. Часто цена отказа намного меньше, чем цена тестирования.
Вы забыли подписать, что это вредные советы))
Это как раз полезные советы. На своём опыте и опыте индустрии неоднократно убеждался.
senior, middle тестировщики? О чем вы? Десяток студентов дипломников, работающих за бесплатно, въезжают в любую тему в кратчайшие сроки и работают не хуже. Курсы повышения квалификации для тестировщиков? Серьёзно?
Сами в шоке. Квалификации, грейды, на крупных проектах заказчики требуют от наших тестеров опыт работы не менее 2-ух лет, знание отрасли и предметной области. А ещё есть ISTQB (скоро выйдет статья по нему) и тендеры от Сбербанка на функциональное тестирование по 200-300 млн. руб. за штуку. Докатились )
Очень неправильный подход. Протыкать по тесткейсам могут и студенты и аутсорсеры.
Только вот написать годные тесткейсы, и главное, сопровождать их — это задача для настоящего QA.
Плюс QA — это определённый склад ума. Мне столько раз приходилось работать с некомпетентными QA, из серии «руки есть — будешь QA интерфейсов»
Все это в принципе возможно, но до первого критического косяка. Возможно разработчики хорошего уровня и не оставляют явных багов, а что если нет? Ну либо ваш софт можно в любую секунду выключить никто и не заметит или даже переписать за вечер юниором.
Sign up to leave a comment.

Articles