Тестирование: из грязи в князи

[@Wolonter]

Хорошая история. А насчет того, что ждет дальше — задача моей группы на декабрь — «захватить мир». Вот только почему-то всегда находится что-то посрочнее, и приоритет уменьшают.

[@pifagor_mc]

Спасибо! Но боюсь помешаю Вам в декабре вторжением своей армады с Нибиру, в моем личном бэклоге релиз проекта по захвату мира имеет блокирующий приоритет:)

[@Alanir]

[@rfq]

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

[@pifagor_mc]

Дальше-больше;) Проекты без спецификации- вот диво дивное для тестировщика (и в тоже время обыденность, как ни странно). В моей собственной компании по аутсорсингу тестирования ко мне то и дело приходят заказчики с просьбой протестировать их продукт «as is», без спецификаций, аналитиков и т.д. Вот тогда начинается самый ад, когда используя опыт предыдущих проектов и собственные знания по предмету проекта начинаешь писать баги по «домыслам и догадкам».

[@rfq]

За такую работу надо брать вдвойне, приплюсовывая восстановление спецификации.

[@pifagor_mc]

Дык я так и делаю по сути, спеку конечно не восстанавливаю, но ПМИ/тест-план в наследство оставляю:)

[@pifagor_mc]

Соглашусь, но лишь отчасти. Действительно, мы сейчас в работе проводим так называемое тестирование документации, где производим анализ спецификации на предмет логики, однозначности, функциональности и полноты. Но даже эта процедура не всегда дает 100% результата, т.е. баги на более поздних этапах все равно возникают. Становится проще, но не панацея.

Да и без спецификации можно делать грамотный код, зависит от слаженности работы в команде, когда понимание задачи не талмуд на 100500 листов А4 тех.документации, а некая эфемерная истина, которая воспринимается участниками на подсознательном уровне и не требует разъяснений и детализации.

Это как в отношениях двух влюбленных, когда один взгляд говорит много больше, чем тысяча слов. Посему хорошая команда- это эдакий вертеп мысленной синергии, когда и без спецификаций все и так ясно. Только вот эдакая «Рафаэлло-команда» (которая «вместо 1000 слов») — редкость, потому действительно анализ спецификации- крайне полезная процедура, но это скорее уже сегодня, чем завтра все-таки.

[@rfq]

Эфемерная истина, воспринимаемая на подсознательном уровне, может отражать лишь небольшие проекты — просто потому, что объем подсознания ограничен. А вот например реализация языка программирования или движка базы данных на подсознательном уровне невозможна, хотя некоторые и пытаются, по причине нелюбви к написанию документации.

[@pifagor_mc]

Если говорить о таких масштабах, то безусловно да, без адекватной спецификации или употребления «расширителей сознания/подсознания» такое воплотить в жизнь крайне сложно. Как правило у таких проектов всегда есть переходный период ломки, когда писать еще не начали, но не писать уже нельзя. Вот в этот момент нередко попадал в компании тестировщиком, пожалуй именно такие случаи и подвигли в свое время заняться тестированием документации.

[@Wolonter]

Сказанное верно для b2b — контрактной разработке. У нового продукта на массовом рынке спецификаций нет. По каким спекам писали твиттер? Есть реакция аудитории, попытки предсказать ее ожидания и жесткие сроки, которые и явились причиной появления процесса управления качеством, ведь это не только «у нас будет меньше багов», но и осознанное «релизим сейчас, поправим потом».

[@rfq]

Ну это смотря какой продукт. Когда выпускали Андроид, спецификации были. Сейчас Гугл выпускает Дарт, спецификация была с самого начала, но неокончательная, в процессе разработки постоянно меняется. Тем не менее это спецификация, и ее существование позволяет вести тестирование.

[@aradan]

Вот поэтому на некоторых проектах отказывались от аналитиков, а использовали тест-аналитиков и agile принципы :)

[@romanshamin]

Надеюсь в будущем увидеть пост о критериях адекватности спецификации. Чтобы, как ты сам говоришь, и не «талмуд на 100500 листов», и понятно как работать и измерять результат.

[@pifagor_mc]

Спасибо за идею! Постараюсьсделать, как только на наших проектах выведем эту процедуру на нормальный уровень, чтобы не пальцем в небо тыкать, а эмпирическим методом собрать наиболее кассовые правки и замечания к спецификациям в срезе хотя бы сотни протестированных документов:)

[@gleb_kudr]

Критерий адекватности, кстати, существует.

У аналитика, разработчика и тестироващика в голове существует некий образ фичи. Этот образ по-умолчанию не совпадает (причем поначалу и вовсе отсутствует). Хорошая спецификация это такая, которая создаст одинаковый образ фичи в голове этих трех людей. Это основная задача документации при разработке. Потом уже идет хранение информации, передача опыта между поколениями разработчиков и т.д.

Соответственно любая бумажка (или ее отсутствие) которая решает эту задачу, удовлетворяет критерию адекватности. Звучит просто, но реализуется сложно. Больно уж по-разному мыслят люди. Вот учесть это и есть главная проблема для тех, кто пишет тексты фич.

[@aradan]

Примерно тоже самое наблюдал с 2002-2003 гг с той лишь разницей, что ко всем годам в посте накинул бы парочку лет :)

Сильно радует когда смотрю на то что было и то, что сейчас :)

Ps. Спасибо за пост!

[@pifagor_mc]

Ностальжи:) Ну там действительно плюс-минус, от компании зависело еще слегка. А так да, небо и земля прогресс за десятилетие! Дальше-больше, все в наших руках и головах ;)

[@Fisik]

Клевая статья)

[@pifagor_mc]

благодарю покорно, рад, что мои мысли пришлись Вам по нраву:)