Как себя вести, когда вообще нет Спека?

Я думаю, многие тестировщики сталкивались с такой проблемой, когда нет Спека вообще. К сожалению в компании, где я работаю, это считается нормальным явлением (по правде говоря, спек я видел только раз, за все время работы =(),все сводится к тому, что пока нет времени и нужного человека, который мог бы этим в плотную заняться, есть только что-то похожее на ТЗ, которое может быть полезно только разработчикам . Что более печально, что я начинающий тестировщик и пока единственный в компании, старый тестировщик уволился в тот же день, когда я пришел. Обо всем, что я тестировал мне приходилось узнавать у разработчиков ("которые вечно заняты") в устной форме, в результате о качестве тестов и речи быть не может. За последние две недели, у клиентов проявилось несколько критичных багов, после чего я начал замечать, не совсем доброжелательные взгляды, со стороны "разработки", ведь бонусный бюджет пострадает общий... Подскажите пожалуйста, как быть в такой ситуации? Как повысить качество тестов и тестируемого ПО?

+1

Если на проекте документацию состают только аналитики, либо роль аналитика распределена, если на проекте нет вообще нет документации...

То требования всё равно есть, и с ними приходится работать.

1. Убедится что мы используем одинаковые термины. (Говорим на одном языке, используем одинаковые поянтия)
2. Сопоставить требования со сформулироваными целями разработки системы. (бизнес требования реализованы корректно)
3. Определить меру качества для каждого требования. (не указано время отклика? найдите сами требуемое время)
4. Делим требования на управляемые группы.
5. Поднимаем всю связанную документацию. (Ищём всё что есть, проводим допросы...) пункт 4 и 5 чередуются как в карусели.
6. Входим в домен (тестируем). (моделируем пользователя)

Как я вас понимаю..., сам был в такой ситуации, да и сейчас тоже, почти всегда нет спеков. В моем случае без постоянных уточнений у програмистов и у менеджера никуда. Также нужно собрать всю документацию которая есть(что-то да есть наверняка), и проанализировать её. Еще я для себя всегда делаю описание функционала который требует такого внимания, в процесе уточняя все у менеджера. Поначалу было сложно и тоже косо смотрели на меня, но сейчас все как бы нормально. Вот так и работаем...

Отдавайте свои тесты на ревью разработчикам и другим членам команды. Качество это не только ваша головная боль, если пропускаются критические баги, это проблема всей команды, а не конкретно ваша. Наличие или отсутствие спеки тут не причем, у вас в целом процесс обеспечения качества хромает. Только тестировать очевидно недостаточно.

Огромное спасибо всем!

есть только что-то похожее на ТЗ, которое может быть полезно только разработчикам .

Ну там же должно быть описание того, КАК функционал должен работать. Я имею ввиду, не только какие контроллеры использовать и т.п. Должно же быть в этом ТЗ что-то, что Вы тоже сможете использовать.

Отдавайте свои тесты на ревью разработчикам и другим членам команды.

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

Если программисты будут тесты просматривать, их корректировать и новые придумывать - не проще ли тестировщика уволить, а его зарплату между программерами поделить?

Если тестировщик имеет опыт работы в этой компании - 5 лет, он знает всё о продукте и потребностях клиентов и при этом просит от разработчиков (которые устоились месяц назад) написание тестов, то да. Такого тестировщика можно увольнять.
Но если, этот же опытный тестировщик, отправляет план тестирования (высокоуровневое описание) и проект тестов (низкоуровневое описание) разработкам ради помощи им же, для выявления дефектов на ранних стадиях. То он им помогает.

Автор темы, новый человек в компании. И ему просто необходимо узнать как можно больше о продукте. Когдя я устроился на работу, мне все разработчики говорили, что они заняты. И что я могу "придумать" требования сам, исходя из здравого смысла. Я придумать сам не мог. Поэтому брал за основу поведение популярных продуктов: Microsoft Office Word, Mozilla FireFox, ... и потом писал замечания - вот там так, а у нас не так, значит надо сделать как у них. После первого же десятка таких замечаний, меня стали обучать. Я узнал про всю архитектуру, про все тонкости продукта, излазил все его настройки, и вычитал все руководства. Только потом, стал разбираться, что действительно нужно ожидать от продукта, а что ожидать не стоит.

По поводу посылки документов/задач по почте или другим способом разработчикам. Тут я уверен - лучше лично сходить с тетрадкой и ручкой к разработчику. При этом услышишь ответы на свои вопросы, увидишь прототип, узнаешь то, чего и ты не и знал и не собирался спрашивать.

Всё написанное выше справедливо для каскадной модели разработки.

Если же используется Scrum (Agile), то как правило нет принудительных согласований документов, нет занятых людей, ... вы - команда, сбалансированная, быстрая, где все обо всём знают.

...Нужно протестировать скрипт без GUI который работает с базой данных и по определённой логике выполняет какие-то преобразования с данными.

Как тестировать, формируем набор входных данных по какой-то логике, запускаем скрипт/сервис, проверяем результат выополнения. Результат выполнения нужно смотреть на первых этапах человеку, потому что автоматизированных тестов ещё нет и на основе составленных вручную тестовых случаев впоследствии (хотелось бы верить) будет делатся автоматизация.

Скрипт/сервис предоствален в виде откомпилированного файла. К сожалению из документации по нему есть "тех. задание"= , в котором в общих чертах описано что должен делать скрипт.

Так получилось что разработчик - опытный дядька, который с полуслова понимает, что нужно сделать. Вопрос заключается в том, как определить степень покрытия тестами функциональности сревиса скрипта, если нет полной информации о всех зависимостях и возможных "ветках работы скрипта".

При составлении тескейсов стараешся более полно покрыть все возможные положительные и негативные ветки. Однако уверенности в том, что не осталась какая-то важная ветка "не покрытой" нет.

Как это проверить - показать список из кейсов разработчику и придти и обсудить с ним, каким образом будет тестироваться скрипт, и "не забыл-ли тестировщик включить кейсы на какое-то поведение, о котором он забыл/не догадался".

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

Мне кажется, что то решение возникшей у вас проблемы, которое напрашивается - это не совсем ваша уже область отвественности, а того, кто у вас отвественнен за организацию процессов и за это получает деньги.
В чем главный прокол организации. Очевидно, что у вас принят командный образ работы (это видно из ваших слов про то, что премии лишают всех). Точнее, вас даже мотивируют так работать с помощью бонусов. Так вот, прокол в том, что "вечно занятые" разработчики не воспринимают вас как часть команды, не хотят делиться знаниями, объяснять и т.п. в то время как (из вашего рассказа следует) эти самые разработчики и являются хранителями знаний. И если им так не нравится терять премии то они должны бы по идее быть заинтересованы в том, чтобы у вас было все необходимое от них зависящее для вашей нормальной работы. И наладить этот момент не только, и как мне кажется, не столько ваша работа, сколько работа менеджера проекта, если он у вас есть конечно. Менеджер должен обеспечить ваш доступ к информации. И Вам нужно обсудить это с человеком, которому вы непосредственно подчиняетесь, вместе с ним продумать как сделать так, чтобы вы могли получать информацию и ваша работа не блокировалась от отсутствия информации.
При отсуствии желания кого-либо идти вам навстречу, вы можете попробовать самостоятельно расшибить лбом непробиваемую стенку. Например, продумывать вопросы еще более тщательно. Спрашивать так, чтобы на вопрос было интересно отвечать. Полученную инфу как-то фиксировать, чтобы не пришлось переспрашивать. Ну и... если разработчики не хотят идти на контакт то можно прибегнуть к методу "лучше перебдеть, чем недобдеть", т.е. в ситуции, когда вы не уверены, что то поведение системы, которое вы видите, является дефектом,(т.к. чтобы была уверенность, вам нужна дополнительная информация, а ее у вас нет), и вам кажется что это может быть дефектом, всё равно, несмотря на отсутствие уверенности, заводите дефект. Еще есть совет - многие вещи, несмотря на кажущуюся специфичность, можно нагуглить.

Если у вас не open-space офис, и вы сидите в разных комнатах с разработчиками, то.. попроситесь сесть в одну комнату с разработчиками. Если сидеть с ними рядом, то вы становитесь как бы своим и получить все ответы станет легче. : ) Ну и к тому же вам будет виднее когда вопрос уместнее задавать, а когда не очень.

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