Еще одно яркое событие этого лета!
Помимо тренингов 20 августа в 19.00 в отеле "Московская горка" состоится открытая лекция Алексея Баранцева, главного редактора портала Software-Testing.Ru, тренера и консультанта в области тестирования ПО.

Почему тестирование занимает так много времени? Почему тестировщики не успевают протестировать всё, что было запланировано? Почему производительность труда тестировщиков так сильно варьируется от компании к компании и даже от проекта к проекту? Эти вопросы задают себе многие менеджеры, они находят ответы в статьях и книгах, предпринимают новые усилия по улучшению тестирования - и снова возвращаются к тем же самым вопросам. Почему?

На лекции Алексей расскажет о том, что скорость тестирования и эффективность тестировщиков зависит совсем не от правильной организации процесса, как могли подумать некоторые, а от решений, принятых на этапе разработки. Но как именно и почему эффективность тестирования зависит от того, что происходило на предыдущем этапе? Именно об этом пойдет речь.

"Парадоксально, но факт - чем больше багов нашли тестировщики, тем хуже! Вы думали иначе? Приходите, я объясню, почему это так" - Алексей Баранцев.

Зарегистрироваться на лекцию можно здесь: http://spreadsheets.google.com/viewform?formkey=dGxKSkV0NGlLMjhFd2xjOUhNaUZZcnc6MQ

Хороший анонс, да. Город только забыли указать.

Екатеринбург?

Потому что:
1. до тестировщиков кто-то хорошо работать не умеет
2. да и сами тестировщики - те же люди
3. работу тестировщиков зачастую никто не считает за работу, либо считает что тестировщики должны работать 24 Х 7 и всегда давать ответ: хорошая у нас система или дерьмо? Хотя это ясно и по другим факторам, вовсе для этого не обязательно делать 24 Х 7, достаточно 1 дня

С 3 пунктом полностью согласен ибо решил немного поработать сам с тестировщиком, что бы на своей шкуре все это ощутить. Но это далеко не самая плачевная проблема, нет четких планов тестирования, часто приходится тестировать методом тыка, стратегии никакой нет.
К примеру стратегия могла бы быть такой: сначала проверяем стрессоустойчивость системы, на основе тех проблем, которые были заведены ранее, затем это основной функционал, потом перфоманс и только потом всякие финтефлюшечки. Даже в маленьких компашках нужно вводить нейминг конвенш, дабы не плодить дабл постинг одного и того же. В любом случае прежде чем что - то тестить, нужно четко понимать ЗАЧЕМ и КАК, все остальное детали.

нужно четко понимать ЗАЧЕМ и КАК, все остальное детали.

Зачем - понятно, чтобы обнаружить ошибки
Как - вопрос творческий

Да в том - то и проблема, что Как тестировать это и есть самая проблема. Откровенно говоря, мнение о том что в тестировании можно брать девочек - далеких от айти и создаёт мнение о ненужности и плохоквалифицированности данной профессии, а слово девелопер часто воспринимается как человек умный, хотя от некоторых девелоперов больше убытков, чем прибыли.

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

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

Что тестировать определяется разными входными потоками задач, как внешними, так и формируемые внутренними процессами.
Как тестировать решаем по контексту задачи: это может быть просто ручное тестирование, реализация автоматически выполняемого теста, даже вплоть до внесение некоторого проверяющего кода прямо в тестируемую систему (у нас есть спец. пакет Тестирование)
Не все идеально, но работаем

Вопрос "девочек", т.е. малопрофессиональной, но дешевой силы эффективен когда, есть сильные специалисты, которые готовят ЧТО и КАК тестировать, а "девочки" работают обезьянками. Но в нашем случае это не катит...

Конечно, качество кода определяется профессионализмом аналитиков, проектировщиков, программистов в первую очередь.

абсолютно с вами согласен! жаль только, что этого не понимаю большая часть руководителей.

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

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

Не обязательно. Test-driven development сейчас используется всё шире. Непрерывная интеграция с выполнением автотестов становится нормой. Или вы не считаете это тестированием?

Не обязательно...

я не вижу здесь противоречий, по-крупному, если Вы, конечно, не будете утверждать, что разработка ведется на основе автоматизированных тестов и именно ими драйвится

Автотесты можно провести далеко не всегда.

Может уже сказывается вечер и прочее, но LDV я правильно понимаю что вы рассматриваете такой порядок:
1) Дизайн и архитектура
2) кодирование и тестировка примерно одновременно.

Или я перегрелся, сидя за монитором.

Да, порядок такой.
+ параллель разработки и тестирования

можно еще уточнять, но это если потребуется