Комментарии 59
пользователи и есть тестировщики
НЛО прилетело и опубликовало эту надпись здесь
У нас программисты пишут модульные и интеграционные тесты, которые каждые полчаса прогоняются на сервере с помощью NUnit. Тестировщиков у нас нет, поэтому каждый разработчик и есть тестировщик.
И насколько эффективно это получается? Ведь разработчик умный, он будет вводить только правильные данные в свои формы, и кликать в нужные места, а тестер он глупый, накликает всякого и багов насоздает, которые разработчику и неочевидны… Как минимум, свои тикеты тестировать стоит не только самому.
Согласен с Вами. Парочка тестеров нам бы не помешала. От описанной Вами проблемы нас частично спасает то, что каждый разработчик исправляет ошибки в коде, за который он в данный момент времени отвечает, независимо от того, кто эту ошибку нашел. То есть фактически не один разработчик тестирует код, а несколько. Кстати говоря, иногда начальник (неучавствующий в разработке) запускает прогу и начинает ее ломать.
Лучше чем вообще отсутствие тестирования. Да и создание тестов провоцирует к вводу неправильных данных даже разработчиков. Только у тестировщиков фантазия богаче, про реальных пользователей вообще молчу :)
Скорее так)
разработчики ↔ тестировщики → пользователи
разработчики ↔ тестировщики → пользователи
У нас еще используется Parasoft SOAtest, в качестве автоматизации. А так ручное тестирование пока преобладает. Слишкомя сложная система и много компонентов, трудно подобрать подход и инструмент для тестирования хотя бы 70% всем кейсов.
Если описать более подробно, то начальники отделов составляют план заданий, передают моему непосредственному руководителю. После чего распределятся работа по программистом.
Приступаем к разработке, либо на тестовом сервере, либо, если изменения не требуют каких то сложных телодвижений, то можно сразу на рабочем сервере сделать.
По окончанию работы, отсылается уведомление начальнику отдела, он или же определенные подчиненные его тестируют.
Ну а далее или перенос с тестовой на рабочую или доработки
Приступаем к разработке, либо на тестовом сервере, либо, если изменения не требуют каких то сложных телодвижений, то можно сразу на рабочем сервере сделать.
По окончанию работы, отсылается уведомление начальнику отдела, он или же определенные подчиненные его тестируют.
Ну а далее или перенос с тестовой на рабочую или доработки
Наверное, это стандартный процесс разработки ПО в далёких в своей основной деятельности от ИТ компаниях.
Бухгалтерам нужна новая фича? Получайте, но тестируйте сами. Тем более, что и никакого строгого ТЗ обычно нет, требования меняются по ходу разработки, бизнеслогику допиливаем по ходу тестирования.
Бухгалтерам нужна новая фича? Получайте, но тестируйте сами. Тем более, что и никакого строгого ТЗ обычно нет, требования меняются по ходу разработки, бизнеслогику допиливаем по ходу тестирования.
Процесс тестирования поставлен. Тестировщиков очень много.
Видимо оттого, что сводим заказчиков и тестировщиков.
Видимо оттого, что сводим заказчиков и тестировщиков.
НЛО прилетело и опубликовало эту надпись здесь
TDD/BDD -> Functional Tests on Selenium RC -> manual (installation, cross browsering, etc) -> performance testing -> пользователи free (пару суток) –> платные пользователи
Мощно. Сколько занимает по времени промежуток между закрытием версии (передачей тестировщикам) и окончанием тестирования?
Мы когда-то добились, что процесс приёмочного тестирования занимал 4 часа (2000 функциональных тестов ранились 40 мин + вся команда тестировщиков ранила мануальные тесты паралельно. Юнит тесты занимают 10 мин).
Но сейчас, где-то сутки занимает. Вся разработка идёт через TDD/BDD, и сами же разработчики пишут функциональные тесты (C#, Selenium RC). Говорят что разработка через TDD/BDD ведёт к удорожанию разработки на 30%. Но мы продуктовая компания (www.targetprocess.com), и в долгосрочной перспективе выгодней максимально автоматизировать. Перформанс тесты мы раним на Visual Studio, идут паралельно, занимает 3 часа + 15 мин для анализа специально выделенному человеку.
Но сейчас, где-то сутки занимает. Вся разработка идёт через TDD/BDD, и сами же разработчики пишут функциональные тесты (C#, Selenium RC). Говорят что разработка через TDD/BDD ведёт к удорожанию разработки на 30%. Но мы продуктовая компания (www.targetprocess.com), и в долгосрочной перспективе выгодней максимально автоматизировать. Перформанс тесты мы раним на Visual Studio, идут паралельно, занимает 3 часа + 15 мин для анализа специально выделенному человеку.
Разработчик-тестеровщик → пользователи+тестировщик
В том смысле что первичные тесты проводятся на dev сервере разработчиками, потом все вываливается в продакшен где тестировщица смотрит все наравне с обычными пользователями.
И все потому что тестер у меня далеко, а дев сервер на ноутбуке.
В том смысле что первичные тесты проводятся на dev сервере разработчиками, потом все вываливается в продакшен где тестировщица смотрит все наравне с обычными пользователями.
И все потому что тестер у меня далеко, а дев сервер на ноутбуке.
Очень печально, что на покрытие функционала тестами время как правило не выделяется.
Результаты опроса печалят.
А может если такие результаты, то и не всегда надо тестировать? Я понимаю, что тестирование полезно, но может оно не так сильно необходимо.
Скорее всего просто характеризует тип проектов, над которым трудится типичный хабраюзер.
Все-таки, начиная с определенного размера продукта без QA — никуда. Даже при наличии замечательных юнит-тестов.
Все-таки, начиная с определенного размера продукта без QA — никуда. Даже при наличии замечательных юнит-тестов.
У нас получается так:
— разработчики пишут UT, пишут некоторые интеграционные тесты, и пишут тулы для нагрузочного тестирования
— тестировщики проводят ручное тестирование и методом свободного поиска и по тест-кейсам, перед выпуском проводят регрессионное тестирование
— отдел IT на стороне заказчика (у нас заказная разработка) проводит ручное тестирование
— разработчики пишут UT, пишут некоторые интеграционные тесты, и пишут тулы для нагрузочного тестирования
— тестировщики проводят ручное тестирование и методом свободного поиска и по тест-кейсам, перед выпуском проводят регрессионное тестирование
— отдел IT на стороне заказчика (у нас заказная разработка) проводит ручное тестирование
55% вообще не имеют в штате тестировщиков
83% не используют автоматические тесты
Жесть. А мы еще с индусов смеемся…
83% не используют автоматические тесты
Жесть. А мы еще с индусов смеемся…
Давно не писал в больших командах, раньше был отдельный штат тестеров (опыт работы был как за одну команду так и за другую) а сейчас пишу маленькие вещи в одиночку, по этому сам и разработчик, сам и тестер…
У нас в конторе вот как устроено.
Разработчики после кодирования нового функционала пишут юнит тесты и гоняют их перед коммитом. Уровень тестов неглубок — основная задача на данном этапе в том, чтобы убедиться, что солюшн собирается и написанный код работает. Код не отгружается, пока модульный тестировщик не поставит печать качества.
Далее новый функционал уходит модульному тестировщику, который по архитектуре и юзкейсам тестирует написанный код и пишет модульные автотесты. Основная его задача проверить логику нового кода и то, что старые тесты не сломаны.
Далее тестировщик коммитит тесты и они попадают в проект автотестирования (в нашем случае проект с тестами запускается каждый день в 6 утра, результаты прогона тестов рассылаются в команду по почте для мониторинга).
Далее тестировщик ставит на доработку ту самую печать качества, и код отгружается на тестирование в отдел функционального тестирования.
Когда итерация разработки заканчивается и код протестирован функционально, он попадает в регрессионное тестирование. По общим результатам тестирования, если есть какие-либо замечания по поводу производительности кода, могут также ставиться задачи на нагрузочное тестирование.
Инструменты: MSVS2010+MS TFS (код), MSTest (юнит тесты), MSBuild + шедулер (ежедневный прогон всех тестов), MS Test Manager для ручного функционального и регрессионного тестирования.
Разработчики после кодирования нового функционала пишут юнит тесты и гоняют их перед коммитом. Уровень тестов неглубок — основная задача на данном этапе в том, чтобы убедиться, что солюшн собирается и написанный код работает. Код не отгружается, пока модульный тестировщик не поставит печать качества.
Далее новый функционал уходит модульному тестировщику, который по архитектуре и юзкейсам тестирует написанный код и пишет модульные автотесты. Основная его задача проверить логику нового кода и то, что старые тесты не сломаны.
Далее тестировщик коммитит тесты и они попадают в проект автотестирования (в нашем случае проект с тестами запускается каждый день в 6 утра, результаты прогона тестов рассылаются в команду по почте для мониторинга).
Далее тестировщик ставит на доработку ту самую печать качества, и код отгружается на тестирование в отдел функционального тестирования.
Когда итерация разработки заканчивается и код протестирован функционально, он попадает в регрессионное тестирование. По общим результатам тестирования, если есть какие-либо замечания по поводу производительности кода, могут также ставиться задачи на нагрузочное тестирование.
Инструменты: MSVS2010+MS TFS (код), MSTest (юнит тесты), MSBuild + шедулер (ежедневный прогон всех тестов), MS Test Manager для ручного функционального и регрессионного тестирования.
Мне кажется первые два варианта — одно и то же
Используем TDD, тесты, соответственно, пишем сами
Интересно было бы провести сопутствующее голосование — кто использует рефакторинг в своих проектах?
Рефакторинг нужно использовать лишь тогда, и только тогда, когда его нужно использовать, и никогда иначе. Рефакторинг — не процесс написания кода, это процесс исправления ошибок, и есть все шансы что опытные программисты реже делают рефакторинг.
Ну если Рефакторинг — это процесс исправления ошибок, то опытные программисты может и делают его реже…
Но все же рефакторинг — это процесс улучшения существующего кода с целью сделать его более понятным. Без периодически повторяющегося рефакторинга проект развалится из-за слишком быстро растущей сложности. При этом рефакторинг МОЖЕТ внести новые ошибки, если нет наборов модульных регрессионных тестов, которые должны прогоняться каждый раз при внесении очередных изменений. С учетом результатов голосования и возник вопрос — сколько же человек из проголосовавших используют в процессе разработки программ рефакторинг при такой низкой доле использования регрессионных тестов
Но все же рефакторинг — это процесс улучшения существующего кода с целью сделать его более понятным. Без периодически повторяющегося рефакторинга проект развалится из-за слишком быстро растущей сложности. При этом рефакторинг МОЖЕТ внести новые ошибки, если нет наборов модульных регрессионных тестов, которые должны прогоняться каждый раз при внесении очередных изменений. С учетом результатов голосования и возник вопрос — сколько же человек из проголосовавших используют в процессе разработки программ рефакторинг при такой низкой доле использования регрессионных тестов
Данная статья дает знания которые улучшают понимание инструмента (Mysql), либо части его (JOIN). Рефакторинг же — «процесс улучшения существующего кода с целью сделать его более понятным».
Это разные русла, разные действия, и, мне кажется, не стоит их даже рядом ставить.
Кстати, на мой взгляд «более понятный код» после рефакторинга — побочный эффект.
Это разные русла, разные действия, и, мне кажется, не стоит их даже рядом ставить.
Кстати, на мой взгляд «более понятный код» после рефакторинга — побочный эффект.
НЛО прилетело и опубликовало эту надпись здесь
Тестировать должны все, но каждый в своей части, это многоаспектная задача:
- Несомненно, разработчик должен выдавать продукт только тогда, когда он сам не может его сломать, но всем ясно, что продукт после этого еще не стабилен.
- Потом продукт тестируется тимлидом, постановщиком задачи или аналитиком кратко и по основным вопросам самым важным.
- После этого только опционально может тестировщик включиться для ручного или автоматического тестирования, но тут тоже всем ясно, что автоматизируются только четкие логические вещи и математика в виде юниттестов, это очень узкий класс задач, а сложные задачи и пользовательские интерфейсы могут быть только вручную протестированы, при чем, у тестировщиков еще и глаз замыливается и после нескольких итераций нужно менять тестировщика, т.к. он будет ходить вокруг ошибки кругами, проверено многолетними опытами.
- Еще хочу отметить, что даже после самых тщательных тестов, пока программа пару месяцев в боевом режиме не обкатается, то ничего нельзя сказать еще, только проверка «в бою» покажет стабильность.
- Ну и ни какие гарбедж коллекторы в Джаве и C# не дадут 100% гарантии от утечек памяти, практика показала, что если программист очень постарается, то он везде напишет утечку, как и любую другую ошибку, даже если это Джава, то всего предусмотреть на уровне платформы просто невозможно.
- Есть еще ошибки юзабилити и эргономики — тут всем ясно, что их ни как кроме ручного режима не отловить и найдет только аналитик или клиент.
люди рассказывают об использовании BDD как о сексуальных похождениях прям. На словах у всех полное покрытие что клиент что модели, а в реале наверно лень?) Ну по чесноку давайте
На самом деле TDD и BDD используются сейчас не по назначению, вместо технологий разработки они стали маркетинговыми мловечками при напаривании своих ресурсов в аутсорс и при укатывании клиентов на большие заказы — нагнать пафоса — это то, для чего они применяются, а на самом деле TDD, это очень узко специализированная штука, пригодные для тестирования системных библиотек, фреймворков, внутренних API, например при разработке СУБД или в веб-сервера или браузера — тут да, нужно бы написать тесты, т.к. результат парсинга или построение индекса — это процессы, имеющие четкую матможели и известные результаты, ее можно протестировать, а вот что делать с пользовательскими интерфейсами и огромным количеством прикладной логики, жестко связанной с этими интерфейсами — все замалчивают. А мой знакомый и, с недавних времен, наш сохабровец itadapter говорит еще и так: «TDD — WTF? How do you guys test your tests? or do you TDD your tests?».
интересно было бы связать результаты опроса с размерами проектов (численностью команды и средним временем одного проекта).
Думаю, в более менее крупных проектах ситуация выглядит получше
Думаю, в более менее крупных проектах ситуация выглядит получше
Специалист в предметной области, который отвечает за постановку задачи, работает в паре с ведущим программистом, в процессе написания программы постоянно выступает в роли тестера. Таким образом программа как бы эволюционирует. Появляется то, что при постановке задачи и придумать было невозможно. Но так программа никогда не будет готовой. В определенный момент (зависит от сроков, и от интуиции руководителя) останавливаем этот процесс. Вводим тестировщика и ограничиваем возможность первому специалисту и ведущему программисту вводить новые фичи, если придумываются, то только записываются. На этом этапе важно разобраться со всеми багами и навести карасоту. Заказчик получает релиз, после тестирования. Процесс эволюции можно продолжить и получить новую версию, опять в определенный момент остановив его с вводом тестировщика и ограничением развития функционала.
У нас так считается, что это лучший вариант. На практике далеко не всегда получается.
У нас так считается, что это лучший вариант. На практике далеко не всегда получается.
… И никто не разу не упомянул, что для составления тестов используются какие-либо документы типа «Сценарии использования продукта», которые Аналитик или Маркетинг Менеджер (называйте как хотите) подготовил предварительно перед составлением ТЗ.
А ведь если «Сценарии...» готовятся в самом начале, то подобных комментариев просто не может быть:
А ведь если «Сценарии...» готовятся в самом начале, то подобных комментариев просто не может быть:
Есть еще ошибки юзабилити и эргономики — тут всем ясно, что их ни как кроме ручного режима не отловить и найдет только аналитик или клиент.
Если ТЗ готовится изначально на базе маркетиновых документов типа «Сценариев...» (а по своей сути Сценарии подразумевают некую приоритезацию), то и на этапе реализации кода, и на этапе тестирования есть чёткая картина того, какие фрагменты программы являются критически важными для Продукта (имеют High приоритет), а какие можно для первого релиза и отложить (имеющие Low priority). Понятна и степень готовности юзабилити — если приоритетные сценарии исполняются через ж..., то о какой готовности продукта вообще может идти речь?
у Вас это работает? Подробное составление ТЗ до этапа разработки и отсутствие изменений в требованиях во время разработки?
А почему вас это удивляет? Работает, именно…
Разумеется, в процессе разработки появляются изменения, но они опять-таки рассматриваются через призму тех же Сценариев. Если изменение необходимо внести для корректного выполнения сценария высшего приоритета — оно будет внесено обязательно. А если это касается какого-то сценария LowPriority — никакого смысла во внесении нет. Всё просто.
Разумеется, в процессе разработки появляются изменения, но они опять-таки рассматриваются через призму тех же Сценариев. Если изменение необходимо внести для корректного выполнения сценария высшего приоритета — оно будет внесено обязательно. А если это касается какого-то сценария LowPriority — никакого смысла во внесении нет. Всё просто.
Тестировщики ? — От куда такая роскошь.
У нас программист, тестировщик, инженер, менеджер проекта все в одном. Всего 4 человека 1 инженер 2 прогера и начальник далекий от программирования.
Все тестирование происходит рандомными кликами в тестовом режиме и потом сразу на суд пользователей где все и накрывается и на ходу дорабатывается и самое интересное, что все руководство считает, что все так и должно быть и в России по другому не делается, лучше тестеров, чем пользователи не найти.
У нас программист, тестировщик, инженер, менеджер проекта все в одном. Всего 4 человека 1 инженер 2 прогера и начальник далекий от программирования.
Все тестирование происходит рандомными кликами в тестовом режиме и потом сразу на суд пользователей где все и накрывается и на ходу дорабатывается и самое интересное, что все руководство считает, что все так и должно быть и в России по другому не делается, лучше тестеров, чем пользователи не найти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как у вас устроен процесс тестирования?