Как объять необъятное, или советы по тестированию
Я хочу рассказать про особенности тестирования больших решений. Почему речь пойдет именно об этом? Дело в том, что наша команда работала с фирмой 1С, и мы помогали им налаживать тестирование типовых конфигураций. Поэтому я прекрасно понимаю, что тем, кто поддерживает продукты фирмы 1С, помимо своих ошибок и проблем постоянно приходится сталкиваться также и со всеми ошибками и проблемами платформы, которых, как вы знаете, пока еще достаточно много.
В любом случае, когда речь идет про качество какого-то конечного продукта, который мы предоставляем пользователю, потенциальных проблем и рисковых зон у нас всегда хватает.
В любом случае, когда речь идет про качество какого-то конечного продукта, который мы предоставляем пользователю, потенциальных проблем и рисковых зон у нас всегда хватает.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Следующее решение – не самое правильное, но на него от отчаянья соглашаются очень многие: «давайте пользователю отдадим, и там посмотрим, что получится».
А разве в самой фирме 1С не так тестируют? Вся страна в бэта тестерах сидит....
И тому, кто заведет наибольшее количество полезных ошибок, пообещали в рамках этой бета-компании приз – iPhone.
Всё тестирование в 1С в одном предложении.... Может тогда конкурсы сделать разнообразными? С разными призами? Дело может лучше пойдёт.
Был такой опыт - привлекали аутсорсеров. Столкнулся с тем, что за ними потом еще нужно хорошенько все проверять. Да и глубина тестирования оставляет желать лучшего. Эти ребята классно отыскали все места, где наши доработки внешне отличаются от типовых (например, не хватало кнопки Структура подчиненности). Но ошибки в рассчетах себестоимости мы ловили сами
А расскажите кто-нить про опыт организации регресс-тестирования для 1С конфигураций. При постоянной команде разработки, скажем, 3-5 человек и примерно 30-40 пользователях системы. С постоянным выпуском релизов раз в месяц, например.
Имхо вода. Как насчет конкретных практик? Для сравнения рекомендую посмотреть на статьи/проекты silverbullets.
А тем кто просто процессом тестирования в компании 1С интересуется , очень рекомендую прочитать соответствующую статью (только там про платформу речь) в официальном блоге 1С на хабре.
А тем кто просто процессом тестирования в компании 1С интересуется , очень рекомендую прочитать соответствующую статью (только там про платформу речь) в официальном блоге 1С на хабре.
Забавно, сначала написано, что автоматизированное тестирование не катит. А в следующих абзацах про документирование через (авто-)тестирование, регрессионное тестирование и т.д.. Как всегда 1С идёт своим путём, чтобы в конце-концов окольным путём выйти к общемировым практикам (с 10 летним отставанием).
Многие вещи в статье на мой взгляд притянуты за уши с определенным уклоном. Тестирование само по себе не решит вопроса повышения качества, этого можно добиться только в комплексном подходе к разработке. И не всегда есть возможность передавать тестирование на аутсорс. Скажите сколько по времени аутсерсеры будут разбираться в существующих процессах, которые надо проверить? А будут ли?
Не соглашусь с утверждением, что стремление автоматизировать процесс тестирования при разработке ПО это неправильно. Наоборот стремление к автоматизации это один из ключей к успеху. "Вручную" покрыть тестами сложный проект это утопия.
Довольно забавно приведены примеры с читерством, за картинки однозначный плюс ) С другой стороны озвучены частые проблемы процесса разработки продукта, которые можно решить изменением подхода к его созданию, а не увеличением количества рук. К примеру, задействовав Канбан доски можно относительно равномерно разбить процесс решения задач (пулл задач, в работе, в тесте, готово к релизу), чтобы избежать пика в конце.
А вот практические вопросы по созданию сценариев тестирования не озвучены.
Не соглашусь с утверждением, что стремление автоматизировать процесс тестирования при разработке ПО это неправильно. Наоборот стремление к автоматизации это один из ключей к успеху. "Вручную" покрыть тестами сложный проект это утопия.
Довольно забавно приведены примеры с читерством, за картинки однозначный плюс ) С другой стороны озвучены частые проблемы процесса разработки продукта, которые можно решить изменением подхода к его созданию, а не увеличением количества рук. К примеру, задействовав Канбан доски можно относительно равномерно разбить процесс решения задач (пулл задач, в работе, в тесте, готово к релизу), чтобы избежать пика в конце.
А вот практические вопросы по созданию сценариев тестирования не озвучены.
"Дело в том, что наша команда работала с фирмой 1С, и мы помогали им налаживать тестирование типовых конфигураций". Ну расскажите же наконец-то КАК В 1С тестируются типовые! В блоге на habr 1Ски рассказали как тестируют платформу. Для меня было открытием, что они знают про TDD/BDD/unit- тесты и т.п. На вопрос "а почему всего этого нет в типовых" ответа так и не последовало. Ну и собственно мы все знаем, что автоматическое тестирование для типовых 1С делают люди не из 1С (Знаем кто и огромное им за это спасибо). Так как же тестируют типовые в 1С?