Чудо-Программеры млин :)

3240 сообщений

#17 лет назад

Цитата ("SolNikolay"):

Я знаком с работой QA (проще писать тестера). И черный ящик используется в основном из-за экономии денег, а не для повышения качества.

Про черный ящик - Вы делаете очень спорное утверждение... Часто, к сожалению, это единственно возможный способ тестирования (тот же пример - сторонним тестерам присылают скомпиленный exe файл, и спецификацию - проверяйте). Но даже если и доступно все остальное, все равно тестирование методом черного ящика нельзя заменить чем-то еще. По сути, это составная часть последующего приемочного тестирования.

Цитата ("SolNikolay"):

Неправильная организация работы отдела тестирования. Вы сейчас говорите о первом уровне (из 5) модели тестирования.
"Уровень 1 ТММ. Начальный. Тестирование носит хаотический характер; оно плохо определено и не отличается от отладки. Тесты разрабатываются специальным образом после завершения кодирования. Тестирование и отладка сочетаются с целью устранения ошибок программного обеспечения. Целью тестирования является демонстрация того, что программное обеспечение работает. Программные продукты внедряются без обеспечения качества. Ресурсы, средства и надлежащим образом подготовленный персонал отсутствуют. На этом уровне не существует целей достижения зрелости."

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

Цитата ("SolNikolay"):

Я имею ввиду тест-case'ы как таковые.

Ну, это уже другой вопрос. Тест кейсы могут быть какие угодно, в том числе и такие тектовые, как я приводил "1. запускаем программу. 2. нажимаем кнопку . 3. .....". Я имел ввиду автоматические тесты, о чем и написал в предыдущем посте, что они пишутся редко в реальной жизни.

Цитата ("SolNikolay"):

Нет. Тестер, способный написать какой-нибудь тест на вес золота не ценится. При выборе тестера вы можете пользоваться теми же критериями, как и при составлении команды программистов.

Таки да, исправлю на "какой-нибудь полезный для повышения качества проекта тест". Хотя, повторюсь, имел ввиду тест для автоматического тестирования, который нужно "написать" в программерском понимании этого слова. А мануальные тесты может и человек без опыта делать.

710 сообщений

#17 лет назад

-IIIyT-, так мы вроде не мешаем вам работать

tvv,
Цитата:

Про черный ящик - Вы делаете очень спорное утверждение... Часто, к сожалению, это единственно возможный способ тестирования (тот же пример - сторонним тестерам присылают скомпиленный exe файл, и спецификацию - проверяйте).

Вы вспомните, когда используются сторонние тестеры:
1) когда нет своего - экономия

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

Цитата:

Ну, тестер обычно не залазит в код, обычно, в большинстве случаев, он тестирует программу как черный ящик, все работает как было затребовано по спецификации - и ладно. Максимум, если тестер продвинутый, - может тесты написать (рассматривая систему как белый ящик), но обычно тесты пишутся к программным интерфейсам, код не исследуется. Также могут быть тесты для нагрузочного тестирования, функциональные, интеграционные, и т.д. Иными словами, плохой код тестер может не посчитать дефектом, если система в целом работает. Это не дело QA (Quality Assurance), вне их компетенции. Да и не нужно - у QA другие задачи, инструменты, возможности, процессы.

Также тестеры обычно не являются специалистами в кодинге. Оно и понятно - сегодня они тестируют сайт на PHP, завтра - на Perl, послезавтра - на Java и т.д. Чаще всего, из практики, QA существенно больше работают с документацией, чем с разработанной тестируемой системой, и это правильно...

Кот ревьюить должен программист, это эффективнее... Причем желательно чтобы это делал не тот программист, который код писал, а другой. Такой процесс называется QC (Quality Control), когда программисты в команде перекрестно занимаются плановым ревьюингом/пересмотром кода друг друга, выявляют откровенное ламерство, некорректности, уязвимости, и т.д., и так же как и QA постят дефекты (но обычно в отдельном репозитории команды разработчиков).

Цитата:

Почему Вы решили что в нашем разговоре речь идет о "Неправильной организации работы отдела тестирования" ?

Во-первых, насчет того является тестер специалистом в коддинге или нет: зависит от организации работы. Тоже самое я могу сказать и о программистах - сегодня php, завтра Perl и т.д.
Во-вторых, насчет QC: опять же зависит от организации тестирования и от выбора способов тестирования. Тоже нагрузочное тестирование - при "черном ящике" тестер лишь занесет в бак-трак обнаружение факта утечки памяти, при белом - должен искать по коду и потом уже заносить.

Цитата:

Тест кейсы могут быть какие угодно, в том числе и такие тектовые, как я приводил "1. запускаем программу. 2. нажимаем кнопку . 3. .....". Я имел ввиду автоматические тесты, о чем и написал в предыдущем посте, что они пишутся редко в реальной жизни.

Цитата:

Автоматизирующие скрипты используются существенно реже, да они и не всегда возможны, особенно если QA идет параллельно с интенсивной разработкой.

Вот вам и неправильная организация работы. Вы привели ссылку какраз на уровни зрелости тестирования. Там все ответы на ваши вопросы

Какая разница - интенсивная разработка или нет. Если вы внедряете автооматизированное тестирование на поздней стадии, то оно врятли принесет вам существенные выгоды в сравнении с ручным (в зависимости от проекта и методов тестирования).

Цитата:

Таки да, исправлю на "какой-нибудь полезный для повышения качества проекта тест".

Опять же, зависит от проекта. Если вы будете использовать этот тест и дальше (например, при рекурсивном тестировании новых версий программы), то да - он снизит времязатраты и повысит качество. А если вы используете его один раз - то зачем он нужен, проще провести ручное.

Цитата:

А мануальные тесты может и человек без опыта делать.

Может. Но каков результат таких тестов? Тоже самое можно сказать и о проограммерах - человек без опыта может писать программы

3240 сообщений

#17 лет назад

Цитата ("SolNikolay"):

Вот вам и неправильная организация работы. Вы привели ссылку какраз на уровни зрелости тестирования. Там все ответы на ваши вопросы Какая разница - интенсивная разработка или нет. Если вы внедряете автооматизированное тестирование на поздней стадии, то оно врятли принесет вам существенные выгоды в сравнении с ручным (в зависимости от проекта и методов тестирования).

Автоматизированное тестирование на ранних стадиях - занятие дорогое, согласитесь. Особенно если учесть что в течении разработки скрипты тестов постоянно нуждаются в переделке. Что делать если заказчик отказывается оплачивать эти работы? Не будет же QA работать бесплатно. Я Вам говорю о реальной жизни, а Вы - о том что написано в "учебнике". Да я сам могу таких учебников десяток написать, дело нехитрое.

Мы с Вами сейчас находимся на фрилансерском сайте, поэтому, пожалуйста, в данный момент мыслите и оперируйте соответствующими категориями и масштабами проектов. И не спешите обвинять кого-то в неправильной организаци труда. Низкие "уровни зрелости" (кстати, весьма спорные и категоричные) можно было бы списать на ламерство менеджеров, но это не так, даже у очень опытной команды может быть кажущийся низкий "уровень". В реальности все зависит от бюджета проектов, сколько заказчик согласится выделить денег на QA.

710 сообщений

#17 лет назад

tvv, раз уж вы вернулись к фрилансерам - я пока не вижу проектов, в которых имело бы смысл вообще внедрять автоматизацию тестирования.

Цитата: