Comments 22
Хорошая история. А насчет того, что ждет дальше — задача моей группы на декабрь — «захватить мир». Вот только почему-то всегда находится что-то посрочнее, и приоритет уменьшают.
Работая тестописателем в западной компании, я быстро усвоил простую вещь: тестирование — это проверка соответствия реализации и спецификации. При отсутствии формальной спецификации хоть затестируйся, качественного кода не получишь — просто потому что спецификация-то есть, без нее ни код, ни тесты не пишутся — но она в голове у программиста, и в головах разных программистов (разработчиков кода и тестов) — она разная.
И кстати, начинать разработку тестов надо с вычитки спецификации на предмет ошибок, противоречий и недоговоренностей.
Спецификация — краеугольный камень разработки и тестирования. Видимо, усвоение этой аксиомы и есть то, что нас ждет завтра.
И кстати, начинать разработку тестов надо с вычитки спецификации на предмет ошибок, противоречий и недоговоренностей.
Спецификация — краеугольный камень разработки и тестирования. Видимо, усвоение этой аксиомы и есть то, что нас ждет завтра.
UFO just landed and posted this here
Дальше-больше;) Проекты без спецификации- вот диво дивное для тестировщика (и в тоже время обыденность, как ни странно). В моей собственной компании по аутсорсингу тестирования ко мне то и дело приходят заказчики с просьбой протестировать их продукт «as is», без спецификаций, аналитиков и т.д. Вот тогда начинается самый ад, когда используя опыт предыдущих проектов и собственные знания по предмету проекта начинаешь писать баги по «домыслам и догадкам».
Соглашусь, но лишь отчасти. Действительно, мы сейчас в работе проводим так называемое тестирование документации, где производим анализ спецификации на предмет логики, однозначности, функциональности и полноты. Но даже эта процедура не всегда дает 100% результата, т.е. баги на более поздних этапах все равно возникают. Становится проще, но не панацея.
Да и без спецификации можно делать грамотный код, зависит от слаженности работы в команде, когда понимание задачи не талмуд на 100500 листов А4 тех.документации, а некая эфемерная истина, которая воспринимается участниками на подсознательном уровне и не требует разъяснений и детализации.
Это как в отношениях двух влюбленных, когда один взгляд говорит много больше, чем тысяча слов. Посему хорошая команда- это эдакий вертеп мысленной синергии, когда и без спецификаций все и так ясно. Только вот эдакая «Рафаэлло-команда» (которая «вместо 1000 слов») — редкость, потому действительно анализ спецификации- крайне полезная процедура, но это скорее уже сегодня, чем завтра все-таки.
Да и без спецификации можно делать грамотный код, зависит от слаженности работы в команде, когда понимание задачи не талмуд на 100500 листов А4 тех.документации, а некая эфемерная истина, которая воспринимается участниками на подсознательном уровне и не требует разъяснений и детализации.
Это как в отношениях двух влюбленных, когда один взгляд говорит много больше, чем тысяча слов. Посему хорошая команда- это эдакий вертеп мысленной синергии, когда и без спецификаций все и так ясно. Только вот эдакая «Рафаэлло-команда» (которая «вместо 1000 слов») — редкость, потому действительно анализ спецификации- крайне полезная процедура, но это скорее уже сегодня, чем завтра все-таки.
Эфемерная истина, воспринимаемая на подсознательном уровне, может отражать лишь небольшие проекты — просто потому, что объем подсознания ограничен. А вот например реализация языка программирования или движка базы данных на подсознательном уровне невозможна, хотя некоторые и пытаются, по причине нелюбви к написанию документации.
Если говорить о таких масштабах, то безусловно да, без адекватной спецификации или употребления «расширителей сознания/подсознания» такое воплотить в жизнь крайне сложно. Как правило у таких проектов всегда есть переходный период ломки, когда писать еще не начали, но не писать уже нельзя. Вот в этот момент нередко попадал в компании тестировщиком, пожалуй именно такие случаи и подвигли в свое время заняться тестированием документации.
Сказанное верно для b2b — контрактной разработке. У нового продукта на массовом рынке спецификаций нет. По каким спекам писали твиттер? Есть реакция аудитории, попытки предсказать ее ожидания и жесткие сроки, которые и явились причиной появления процесса управления качеством, ведь это не только «у нас будет меньше багов», но и осознанное «релизим сейчас, поправим потом».
UFO just landed and posted this here
Надеюсь в будущем увидеть пост о критериях адекватности спецификации. Чтобы, как ты сам говоришь, и не «талмуд на 100500 листов», и понятно как работать и измерять результат.
Спасибо за идею! Постараюсьсделать, как только на наших проектах выведем эту процедуру на нормальный уровень, чтобы не пальцем в небо тыкать, а эмпирическим методом собрать наиболее кассовые правки и замечания к спецификациям в срезе хотя бы сотни протестированных документов:)
Критерий адекватности, кстати, существует.
У аналитика, разработчика и тестироващика в голове существует некий образ фичи. Этот образ по-умолчанию не совпадает (причем поначалу и вовсе отсутствует). Хорошая спецификация это такая, которая создаст одинаковый образ фичи в голове этих трех людей. Это основная задача документации при разработке. Потом уже идет хранение информации, передача опыта между поколениями разработчиков и т.д.
Соответственно любая бумажка (или ее отсутствие) которая решает эту задачу, удовлетворяет критерию адекватности. Звучит просто, но реализуется сложно. Больно уж по-разному мыслят люди. Вот учесть это и есть главная проблема для тех, кто пишет тексты фич.
У аналитика, разработчика и тестироващика в голове существует некий образ фичи. Этот образ по-умолчанию не совпадает (причем поначалу и вовсе отсутствует). Хорошая спецификация это такая, которая создаст одинаковый образ фичи в голове этих трех людей. Это основная задача документации при разработке. Потом уже идет хранение информации, передача опыта между поколениями разработчиков и т.д.
Соответственно любая бумажка (или ее отсутствие) которая решает эту задачу, удовлетворяет критерию адекватности. Звучит просто, но реализуется сложно. Больно уж по-разному мыслят люди. Вот учесть это и есть главная проблема для тех, кто пишет тексты фич.
Примерно тоже самое наблюдал с 2002-2003 гг с той лишь разницей, что ко всем годам в посте накинул бы парочку лет :)
Сильно радует когда смотрю на то что было и то, что сейчас :)
Ps. Спасибо за пост!
Сильно радует когда смотрю на то что было и то, что сейчас :)
Ps. Спасибо за пост!
Клевая статья)
Sign up to leave a comment.
Тестирование: из грязи в князи