Как заставить разработчиков сдать протестированный продукт?
Добрый вечер!
Моя гос. контора заказывает ПО у сторонней, которая является монополистом в данной области. Последнее время эти товарищи стали сдавать нам, такое чувство, совсем не протестированную версию продукта. В связи с чем приходится тратить огромное количество времени на тестирование тех аспектов продукта, которые не были затронуты в обновлении версии (не должны были быть).
В итоге, получается, что мне приходиться быть их тестером, отсылая отчёты об ошибках (а ошибки иногда банальные: то кнопка не работает, то поле неактивное, то селекты из несуществующих таблиц), а должен лишь проверять соответствие заявленным требованиям технологической постановки.
Слышал, что есть всякие там «юнит-тесты» и прочее, что процесс может быть автоматизирован на этапе разработки.
Может есть какие отчёты методик испытаний, которые будут подтверждать проведенную работу/тестирование или ещё что?
Как можно проверить что продукт подвергался тестированию и что он его (не)успешно прошёл?
1. Поговорите с начальством о штрафах за дыры (исправление бесплатно итд)
2. Поменяйте цену без учета тестирования и наймите отдельно тестировщиков
Заставить никак не получится, их это устраивает, «вам нужен продукт и вы 100% его проверите, зачем тогда париться?»
С административными мерами всё ясно. Но так как это гос. структуры — планы уже утверждены. На всякого рода штрафы и специализированных тестировщиков, боюсь, никто не пойдёт :(
Думал может есть какой «гиковский метод».
Юнит-тесты прекрасная вещь, но они не снимают необходимости в приемочных тестах. К томуже написание юнит-тестов это тайное знание, которое передается только от разработчика к разработчику и практически не раскрыто в литературе. Большая часть разработчиков не пишут тестов просто потому, что не владеют этими навыками.
Если наймете тестера он может оттестировать функционал вручную и написать автоматические приемочные тесты. Конечно такая работа должна производить на стороне разработчиков, но раз там все так грустно, может быть подумать о грамотном тестировании на своей стороне.
Есть такое понятие как acceptance testing (типа госприёмка) заказчиком (вами). Если софт с багами, то лучше на стенде исполнителя (до установки в продакшен). Если acceptnace не проходит — софт на доработку. Поидее при контракте с госстуктурами это должно быть оговорено.
Про испытания на стенде:
Стенд существует, на нём и проходит наше тестирование. Но вместо того, что бы проверять реализацию своих технологических постановок, банально приходится отправлять на доработку софт из-за мелочей не связанных с реализуемой технологией.
Можно попробовать задерживать финансирование пропорционально потерям времени на доработки и исправления, если оплата идет по этапам и есть такая возможность. То есть, из-за мелких багов вы не принимаете очередной этап и задерживаете оплату.
Найти серьезного разработчика, который не будет пытаться сдать вам бажную программу.
Спросить по какой методологии работают, какой процент кода и функционала покрывается тестами, поговорить с заказчиками, которые уже работали с этой конторой.
Можно ввести шрафы/премии за баги, но это не решит проблему в корне. Если контора хреновая, то она вдруг не станет хорошей.
Так уж получилось, что смена этого монополиста просто невозможна по ряду причин, самой большой из которых является обучение огромного числа рабочих новой программе, а это ой как тяжело с людьми, которые работают больше, чем я живу, у которых свои тараканы… ну, я думаю, вы меня поняли.
Простой
