"просто", ага

О, а еще активно юзаем линки между задачами и спеками. И между задачами и задачами

хаха, конечно. 9dev, 3test, 1anal

Ну вот я работал в том же самом *3

3 аналитика, 10 тестеров, 15 девов в 1 команде и ещё 3 команды поменьше

У нас сильно больше разработчиков. Но они сами пишут юнит/системные тесты

Система видеонаблюдения для метро

А аналитики уже как-то сильно далеко оказались, это не есть хорошо если задуматься

А еще у нас каждый новый сотрудник начинает работу с чтения спеки и тыкания в проект. Видишь несоответствие - пишешь коммент к спеке

Руки доходят - правим

далеко где?

в смысле коммуникаций

меня посадили в центр кабинета около тестеров. Сложно не коммуницировать.

У нас распределенная команда

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

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

Но нет такого вот универсального и всеми применимого как кипячение воды.

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

Конфлюэнс неидеален конечно, и если чем и лучше других  wiki решений так это интеграцией с Джирой.

+ Контекстная школа полагает что без живого обучения и передачи знаний все равно не обойтись (и по моему опыту это тоже так).

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

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

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

Мы с коллегой набросали один чеклист "куда смотреть если обновление iOS или новая версия XCode" весной 2016-го года и он до сих пор используется — дополняется-редактируется, но используется.

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

Скорее это просте все ленятся обновлять/поддерживать