Lesson 33

Сегодня вджобывал.
PMD помогло выяснить, что система тестирования старого проекта является тонко сбалансированной конструкцией из костылей.

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

Слово Канеру:

Используй подразумеваемые, скрытые спецификации точно так же как явные.


Не все ссылки, содержащие важную информацию для ваших тестов, могут быть явно представлены вам:
- Явная спецификация является полезным источником информации о требованиях, авторитет которого признан клиентами («Да, это спецификация. Это описание продукта»).
- Неявная спецификация является полезным источником информации о требованиях, авторитет которого не признан клиентами («Это не спецификация, но это имеет смысл»).

Авторитет неявной спецификации появляется из убедительности и достоверности содержащихся в ней сведений, а не волей клиентов. В большинстве случаев только часть неявной спецификации относится к продукту. Неявные спецификации могут принимать разные формы:
- Готовые продукты
- Релевантные продукты
- Старые версии продукта
- Дискуссии о продукте в почте
- Комментарии разработчиков
- Журнальные статьи (например обзор старых версий продукта)
- Книги по релевантным предметам (книга по учету может относиться к приложению по учету)
- Руководства по созданию пользовательского интерфейса
- Требования операционных систем
- Ваш личный основанный на фактах опыт

Когда продукт нарушает явные спецификации, вы получаете простую, легкозарепорчиваемую таску: «Продукт нарушает спецификацию, продукт, вероятно, сломан». Когда нарушена неявная спецификация, вам придется потрудиться больше: «В Microsoft Office, F4 забиндена на повторение команды. Если мы не будем делать так же, то мы можем запутать наших пользователей, они используют Office для повседневной работы.» И хотя никто не сказал бы, что MS Office это спецификация для вашего продукта, ваши клиенты могут согласиться, что выравнивание пользовательского интерфейса по нему может улучшить юзабилити продукта. В таком случае Office становится неявной спецификацией вашего продукта.

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