Тестирование – процесс, имеющий огромное количество сложных ограничений. У тестировщиков есть бесконечность потенциальных тестов и в то же время весьма ограниченное время для того, чтобы придумать, создать, задокументировать, и оценить результаты некоторых из этой бесконечности прогнанных тестов.
Время, потраченное на создание, согласование, доработку... документации – это время, которое отнимается у разработки тестов, инвестигейта тест тулов, выполнения и оценки тестирования...
В идеале конечно оценить соотношение стоимость/ польза для каждого случая. Если какой-либо тип документа является настолько ценным для текущего проекта, что целесообразнее написать документ, чем закончить задачу (по девелопменту, тестированию,...), то – создавайте (пишите) документ.
Если вы всё же решили, что документ стоит писать, то я бы посоветовал писать его не «залпом», накануне срока сдачи, выискивыя необходимые данные, тратя тем самым ещё больше времени, а постепенно и непрерывно. Таким образом, к моменту, когда документ должен быть готов, его останется только просмотреть и обновить какую-то минимальную информацию.
На последок хочу сказать, что тестировщик всегда должен чётко осознавать смысл своей работы. Это поможет правильно приотизировать события и не погрязнуть в бумажной работе.
Подписаться на:
Комментарии к сообщению (Atom)
40% работы - это документация, иногда - больше. Исправление баги на раннем этапе стоит условный $1, на каждом последующем этапе - много больше - всё это понимают. Хорошо, когда используют тот же RUP - риски не попасть или попасть снижаются, да и UML в наборе с тулами делает жизнь проще.
ОтветитьУдалитьНо добавлю к твоим прекрасным рекомендациям: подружитесь со стандартами и методологиями, выбросьте всё лишнее и пользуйтесь!
Давай по порядку:
ОтветитьУдалить1) речь идёт о документации, сопровождающей тестирование (i.e. тест план, тест сценарий, тест кейс и т.п.) - роль таковой зачастую преувеличена, поэтому (в гибких процессах) целесообразно отказаться от максимального количества таких артефактов
2) да, я полностью согласен с тем, что чем позже найден дефект, тем выше стоимость исправления самого дефекта и его последствий. Это очень широко описано в различных книгах по тестированию (график такой - http://bit.ly/a2CNCC)
3) последнее предложение твоего комментария очень точно отражает мысль о своевременности использования описанных мной рекомендаций - сначала надо с чем-то "подружиться" (разобраться, оценить), а уж только потом начинать оптимизировать и тем более отказываться или выбрасывать.