it-книги
Б. Бейзер. "Тестирование чёрного ящика". (Издательство Питер)
К. Вигерс. "Разработка требований к ПО". (Издательство Майкрософт)
Над каждой книгой хочется плакать. Хотя бы потому, что чистота и ясность сформулированных в них мыслей зачастую напрочь игнорируется в реально существующем мире. И вовсе не потому, что там сказано что-то сложное или бесполезное. Отнюдь. Как это обычно и бывает, "дьявол кроется в мелочах". Надо хотя бы попытаться начать разбираться в деталях, и тогда многое прояснится, почему не достигается желаемый уровень эффективности.
Можно, безусловно, написать ещё что-нибудь. Повторить сказанное ранее, пересказать другими словами, но смысл от этого не изменится - надо учиться работать правильно. Иначе всегда будут диалоги вида:
developer: ты создаешь нам проблемы
qa-lead: кхм... позвольте!!! создаёте их вы, я на них лишь указываю
developer: ну кстати да. об этом я не подумал
(NB: почти уникальный случай, когда это признают)
Например, как правильно alll заметил в комментариях, "тестировать не по большим праздникам, а постоянно". Но, увы. Редко когда QA-активности начинаются одновременно с запуском проекта (у Creat Studio, слышал, правильно организованы процессы в данном вопросе). Обычно всё смещается под конец, ближе к финальному deadline-сроку. О вкусных и полезных методиках использования redline-сроков даже речи не идёт. Итак времени в обрез и команда загнана. Причин этому - множество, нечёткие требования и размытая проектная документация - в их числе.
Обобщённые цитаты по теме:
"Для меня одной из самых удручающих картин является образ человека, который вручную делает на клавиатуре то, что может быть сделано автоматически" (с) ББ
"Неясно сформулированные требования неизбежно приводят к неточным расчётам размера, затрат и графика" (с) КВ
К. Вигерс. "Разработка требований к ПО". (Издательство Майкрософт)
Над каждой книгой хочется плакать. Хотя бы потому, что чистота и ясность сформулированных в них мыслей зачастую напрочь игнорируется в реально существующем мире. И вовсе не потому, что там сказано что-то сложное или бесполезное. Отнюдь. Как это обычно и бывает, "дьявол кроется в мелочах". Надо хотя бы попытаться начать разбираться в деталях, и тогда многое прояснится, почему не достигается желаемый уровень эффективности.
Можно, безусловно, написать ещё что-нибудь. Повторить сказанное ранее, пересказать другими словами, но смысл от этого не изменится - надо учиться работать правильно. Иначе всегда будут диалоги вида:
developer: ты создаешь нам проблемы
qa-lead: кхм... позвольте!!! создаёте их вы, я на них лишь указываю
developer: ну кстати да. об этом я не подумал
(NB: почти уникальный случай, когда это признают)
Например, как правильно alll заметил в комментариях, "тестировать не по большим праздникам, а постоянно". Но, увы. Редко когда QA-активности начинаются одновременно с запуском проекта (у Creat Studio, слышал, правильно организованы процессы в данном вопросе). Обычно всё смещается под конец, ближе к финальному deadline-сроку. О вкусных и полезных методиках использования redline-сроков даже речи не идёт. Итак времени в обрез и команда загнана. Причин этому - множество, нечёткие требования и размытая проектная документация - в их числе.
Обобщённые цитаты по теме:
"Для меня одной из самых удручающих картин является образ человека, который вручную делает на клавиатуре то, что может быть сделано автоматически" (с) ББ
"Неясно сформулированные требования неизбежно приводят к неточным расчётам размера, затрат и графика" (с) КВ