ЛаМпочка

фигассе тестовые данные для проверочки

Мда... а на собеседовании он тоже такими данными оперировал? :)

Короче я вам не завидую, будте поосторожнее с ним. Конечно он может и прикалываться, но шутки эти весьма не остроумны.

Я бы с ним поговорил об этом.

Сама в шоке - куда смотрела служба персонала :0

А поговорить с ним уже никто не решается... Сидящие с ним люди на всякий случай заказали в канцелярии по канцелярскому шилу :D

И кто виноват? Проводить служебное расследование по каждому пункту?

Интересно вот только , как должна выглядеть та самая процедура или инструкция, которая максимально эффективно позволила бы избегать подобные ситуации Регламент взаимодействия отделов??? Процедура фиксации ошибки? или Чернышевскийй "Что делать?"

А почему Вы задаёте такие вопросы и кем Вы работаете в этой фирме?

Если Вы работаете просто тестером, то никакая процедура Вам не поможет.
Как уже сказал Green, Вам надо просто брать и устанавливать рабочие отношения с вашими разработчтками.

Люблю встречные вопросы ))

Установка рабочих отношений не есть панацея. Если на голову разработчика или тестировщика из пары, установившей добрые рабочие отношения, падает кирпич, то приходится начинать все с нуля. А проект страдает.

А задаю я такие вопросы, потому как интересен опыт собравшихся.

Очень интересная беседа. Особенно спасибо (как в прочем обычно) Green
- весьма ценная информация.


Количество иттераций имхо еще не только показатель невнимательности разработчика, ведь и тестер может сделать невнятное (или заведомо неполное) описание. И кто виноват? Проводить служебное расследование по каждому пункту?

Интересно вот только , как должна выглядеть та самая процедура или инструкция, которая максимально эффективно позволила бы избегать подобные ситуации Регламент взаимодействия отделов??? Процедура фиксации ошибки? или Чернышевскийй "Что делать?"

Однако...

Если вашим регламентом работ (документально описанный внутренний процесс) предусмотрено обязательное создание такого документа, то заказчику и не нужно упоминать его в договоре. Вы обязаны выполнить все действия, предусмотренные вашим процессом, и передать заказчику все артефакты, полученные в результате выполнения процесса.

Да, все это так. И первый вариант плана тестирования был передан если с удивлением, но без разговоров. Потом клиенту потребовалась его переделка (им его неудобно смотреть ). И после этого клиент еще потребовал его передалать полностью. Вот тут то и закралось сомнение. Это уже как бы и не тест-план формально и в пакет документов, описанных в регламенте, он не входит.

Впрочем ситуация разрешилась к обоюдному согласию.
Просто действительно понимаешь, что клиент не прав, а поступать следует дипломатично (читай уступать).

Спасибо за советы! Они помогли.

Green

Спасибо за конструктивный совет!

Если же это заказная разработка, то клиент имеет право на все, что было создано в рамках проекта (кроме опыта, полученного участниками команды). Все, это значит - все, включая переписку, черновики и прочую дребедень (если она ему понадобится). Фактически, он мог оговорить любую прихоть. Например, порядок уничтожения документации и черновиков, выработанных но не примененных в процессе реализации проекта. И вы должны были бы подчиниться установленным правилам.

Однако же проект все таки "fixed price"..

Спасибо. Для себя очень много прояснилось.