Сообщений в теме: 40

[Guriy]

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

Если я не ошибаюсь - то пора делать ноги.

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

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

[Yarilo]

Если я не ошибаюсь - то пора делать ноги.

Отказ от обеспечения качества для своих программных продуктов говорит о кризисе в компании.

Ну, скажем, стресс, мы переходим из инкубаторного состояния на рынок :rolleyes:
Мы (тестировщики) сейчас пробуем переквалифицироваться, получится (я надеюсь!) - будем девелоперы на все руки, не получится - сделаем ноги :D

[barancev]

Мы (тестировщики) сейчас пробуем переквалифицироваться, получится (я надеюсь!) - будем девелоперы на все руки, не получится - сделаем ноги :D

Всё. С вопросами актуальности автоматизации тестирования покончено, дискуссия сконцентрироваласть на вопросе - как выжить вообще без тестирования. :P

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

Бесплатная (пока ;)) конультация по тому, как выжить в такой ситуации. Для успешного выполнения проекта я предлагаю Вам некоторые рекомендации, которые позволят в какой-то мере компенсировать те ошибки, которые делает Ваше руководство.

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

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

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

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

Распределите роли в команде разработчиков так, чтобы кому-то доставались роли "отладчиков" (то есть на самом деле тестировщиков). Не обязательно это должна быть 100% занятость. Пусть в остальное время "отладчики" занимаются программированием.

Сократите разработку и снизьте качество тех систем, которые не являются критическими по отношению к выявленным рискам. Займите освободившиеся ресурсы тестированием для снижения крупных рисков. Недоделки в некритических подсистемах вы сможете устранить на более поздних этапах - при бета-тестировании или даже на этапе эксплуатации (Вы сами сказали, что доработки практикуются).

Но всё это, конечно не поможет, потому что в следующий раз всё повторится. Как же изменить ситуацию?

Проведите два похожих проекта, один с тестированием (если не удаётся сделать это по-человечески - попробуйте по предложенной выше схеме), а другой без. После того, как оба проекта завершатся, проанализируйте их оба. Если тестирование оказало положительный эффект (надеюсь, что так и будет, хотя бывает и не так) - доложите руководству. Надеюсь, что после предложенного обоснования оно не будет продолжать упорствовать и не замечать тестирования. Если будет - либо нужно действительно уходить, либо терпеть. Как известно, власть - от Бога, и противиться - грех :).

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

Надеюсь, Вы будете держать нас в курсе того, как в компании будут развиваться дела. Лично мне это очень интересно и как менеджеру, и как консультанту.

Не теряйте присутствия духа!

[Undi]

Бесплатная (пока ;)) конультация по тому, как выжить в такой ситуации. Для успешного выполнения проекта я предлагаю Вам некоторые рекомендации, которые позволят в какой-то мере компенсировать те ошибки, которые делает Ваше руководство.

Исходя из моего опыта, Вы не затронули еще один фактор.
Анализ рисков и тестирование (вне зависимости от названия) - это очень хорошо и правильно, но в подобных компаниях "стрессы" характеризуются еще и урезанием времени на проект. Правильно Вы написали, "надо снизить затраты". И тут менеджеры начинают играть по типу "я угадаю эту мелодию с четырех нот. А я с трех!" :D т.е. если конкуренты говорят, что сделают проект за 8 месяцев, то менеджер берется сделать его за 7 или даже за 6.
В таких условиях фактически не остается времени на нормальное тестирование. Особенно если разработчик, тестировщик, тех.писатель в одном лице...

[barancev]

Совершенно верно, таковы реалии. Но ещё раз повторю - не теряйте присутствия духа.

Именно в таких условиях сокращения затрат, когда нет возможности протестировать "всё, что движется", нужно особенно тщательно анализировать риски и нацеливаться на снижение наиболее крупных из них.

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

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

А почему, собственно, все роли заключены в одном лице? У Вас в компании, уважаемый Undi, всего один человек? Если есть по крайней мере три - эти роли можно распределить между ними. Или может быть оставшиеся двое - менеджеры? :D

[Green]

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

С опытом моей работы в АйТи сфере я немного трансформировал "треугольник" и сейчас он выглядит следующим образом.

В вершинах треугольника расположены ключевые характеристики проекта: высокое качество разработки, короткие сроки реализации проекта, низкая стоимость. Сокращенно, КАЧЕСТВЕННО-БЫСТРО-ДЕШЕВО.

Так вот, фокус заключается в том, что возможно выбрать только одну грань! Если вы выбираете КАЧЕСТВЕННО и ДЕШЕВО, то вы должны быть готовы пожертвовать вершиной БЫСТРО. Если БЫСТРО и ДЕШЕВО, то страдает КАЧЕСТВО. И т.д.

Какой выход? Перейти на новый качественный уровень организации труда. Тогда "треугольник" будет актуален, но уже на более высоком уровне.
B)

[Yarilo]

Спасибо, уважаемый Barancev (даже как-то неудобно по фамилии называть :unsure: ) за совет, я так и настраиваюсь на борьбу за качество, теперь изнутри команды, а не снаружи :)

[Yarilo]

Если начальство перевело всех тестировщиков в разработчики - ещё не всё потеряно. Можно жить и так. Оттого, что тестировщики не называются тестировщиками, они хуже не становятся и могут с успехом осуществлять свою профессиональную деятельность.

Я бы добавила, что если посмотреть на ситуацию из отдаленного будущего, то не только не все не потеряно, но даже такая ситуация полезна:

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

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

3)разработчики должны будут изменить подход к разработке, чтобы предупреждать ошибки;

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

[Green]

To Yarilo
Разрешите не согласиться.

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

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

Что же касается рутины, так это есть в любой профессии, даже у программистов. :P

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

Совершенно другой вопрос, это проблема привыкания к проекту, что характерно как для тестировщиков, так и для программистов.

Если работа над одним и тем же проектом продолжается в течение года и больше. Притупляется чувство актуальности. Иссякает криативность, пик которой обычно приходиться на начало проекта. Люди просто устают решать однотипные проблемы. Выход - периодическая ротация персонала между проектами или задачами.

B)

[Guriy]

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

С опытом моей работы в АйТи сфере я немного трансформировал "треугольник" и сейчас он выглядит следующим образом.

В вершинах треугольника расположены ключевые характеристики проекта: высокое качество разработки, короткие сроки реализации проекта, низкая стоимость. Сокращенно, КАЧЕСТВЕННО-БЫСТРО-ДЕШЕВО.

Так вот, фокус заключается в том, что возможно выбрать только одну грань! Если вы выбираете КАЧЕСТВЕННО и ДЕШЕВО, то вы должны быть готовы пожертвовать вершиной БЫСТРО. Если БЫСТРО и ДЕШЕВО, то страдает КАЧЕСТВО. И т.д.

Какой выход? Перейти на новый качественный уровень организации труда. Тогда "треугольник" будет актуален, но уже на более высоком уровне.
B)

CMM чистой воды.
Когда не удается избежать константного значения в цене/качестве/времени необходимо изменять процессы.

[Undi]

А почему, собственно, все роли заключены в одном лице? У Вас в компании, уважаемый Undi, всего один человек? Если есть по крайней мере три - эти роли можно распределить между ними. Или может быть оставшиеся двое - менеджеры? :D

Я имела ввиду ситуацию, описанную выше Yarilo, когда проекты длятся порядка трех месяцев. И команда на проекте состоит из трех-четырех человек (которые анализируют, пишут код, тестируют, пишут документацию, общаются с заказчиком и т.д.).

[Darkus]

To Green

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

Романтика да и только :)
Пока тестирование разрабатывается и придумываются новые и новые пути исправления багов - то да, всё очень увлекательно.
А теперь представим, что у нас уже почти всё запланированное сделано и есть готовая документация.
Вот садимся и начинаем изо дня в день ручками прогонять одно и то же... до галюликов :)
Ужасно монотонное занятие и динамика в нём только та, чтобы побыстрее закончить работу, а творчество всё в том, чтобы не промазать по мышке или клавише :)
...
Извините за сарказм, но ручное тестирование это только в начале проекта удобно. Конечно это только IMHO.

[van]

Действительно, достаточно увлекательная тема получилась. Правда, как правильно заметил Грин, очень трудно уследить за всей линией дискуссии.

Я тоже занялся внедрением в наши проекты автоматизированного тестирования (ручным занимаемся примерно 3 - 4 месяца), поэтому сразу возникает куча связаных с этим вопросов.

1. Какое средство автоматизации выбрать?
Все усилия по выбору сосредочились сейчас между продуктами Rational и Mercury. Тестировать необходимо продукты, написанные на C# c использованием Java для web.

2. С каких тестов начать автоматизацию? С функциональных или навигационных (проверка работоспособноси всех ссылок и т.п.)

3. Как организовать процесс в свете возможной смены персонала каждые 4 - 5 месяцев (это касается и ручного тестирования)?

Помогите пожалуйста во всем этом разобраться!!!

[Mike]

Ответ на п.3: не автоматизировать ;) , а ручные тесты писать с подробнейшим разбиением по степам, и со снэпшотами, причём важно иметь чёткие стандарты на написание тест-планов, и вообще, подробную и толковую Test Strategy.

IMHO, автоматизация это процесс на который очень плохо влияет текучка кадров. Вы можете себе представить, что Ваши программисты будут менятся каждые 4-5 месяцев? А в случае с автоматизацией тестирования, есть ещё такая проблема как отсутствие guidlines - почти каждый "автоматизатор" пишет по-своему, а стандартов нет. Кроме того, за 4-5 месяцев это как раз то время, за которое вы успеете обучить тестировщика инструменту (ну, то есть через месяц он будет конечно писать какие-то тесты, но именно какие-то... а если ещё за ним его тесты прийдётся править такому-же новичку...).

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

Что касается выбора тула, то это вопрос вкуса, хотя стоит оценивать перспективу развития тула. У TestComplete и QTP такая перспектива есть, у Robot и WinRunner - нет. Про XDE Tester ничего не скажу- не видел, но тул, судя по всему, довольно современный.

[barancev]

Тестировать необходимо продукты, написанные на C# c использованием Java для web.

Ух ты!!! Занятная комбинация. Это как? Типа на сервере Java, а клиент реализован на C#?

[van]

Вобщем, приклад написан на С#, а Java скрипты используются на клиенте для всяких проверок и т.п. вещей.

[barancev]

Вобщем, приклад написан на С#, а Java скрипты используются на клиенте для всяких проверок и т.п. вещей.

Ах, JavaScript... Понятно. Так бы сразу и надо писать. Ни в коем случае не путать с Java!!!

По существу вопроса:

1. Если Вам всё равно, что покупать -- начните с поиска человека-тестировщика, а потом купите то, что он попросит. Человека найти труднее, чем инструмент купить. Или это у Вас человек мучается таким выбором? Тогда я могу добавить ему сомнений: RadView WebFT+WebLOAD, Empirix e-TEST Suite, AutomatedQA TestComplete, Compuware QARun, Segue SilkTest, а также менее известные Quality Forge TestSmith, AdventNet QEngine, eValid, Solex (бесплатный, с открытым кодом, но весьма любопытный и перспективный), а если не заклинило на Record-n-Play и не брезгуете ручным кодированием, то actiWATE тоже неплох (тоже бесплатный, но с закрытым кодом).

2. Автоматизировать проверку битых ссылок -- вообще дело нехитрое, если ссылки обычные, а не JavaScript-ом сделанные. Возьмите, например, Xenu. А если JavaScript-овые -- это уже не навигационное, а самое что ни наесть функциональное тестирование получится. Почти все упомянутые выше инструменты понимают JS, а некоторые даже Flash и ActiveX.

3. Какой именно персонал меняется по три раза в год? Руководители проектов? Архитекторы? Программисты? Тестировщики? А сколько остаётся постоянного персонала? (неужели весь меняется? тогда Вам осталось работать всего несколько месяцев и чего вообще сыр-бор разводить :)) А какова средняя продолжительность проекта?

[van]

1. Относительно текучести кадров:
Предполагается, что в группе тестирования есть постоянное ядро, в лице руководителя группы тестирования (т.е. меня), а остальные тестировщики, как ручные, так и автоматизированные, могут меняться с периодичностью от 4 - 5 месяцев до года.

2. Проект длится уже больше года и завершаться не планируется пока (группа тестирования работает только 4 месяца :) )

3. Алексей, у меня есть еще парочка вопросов относительно продуктов UniTesK
1) Можно ли провести какие - либо параллели этих продуктов с продуктами Purify, Quantify, PureCoverage фирмы Rational?
2) Тесты какого плана автоматически генерируют Ваши продукты?

[barancev]

1. Относительно текучести кадров:
Предполагается, что в группе тестирования есть постоянное ядро, в лице руководителя  группы тестирования (т.е. меня), а остальные тестировщики, как ручные, так и автоматизированные, могут меняться с периодичностью от 4 - 5 месяцев до года.

Ну, тогда прислушайтесь к совету Майка. Действительно, за 4-5 месяцев тестировщки только-только научатся как следует пользоваться инструментом, а тут и уходить пора :) Вряд ли опытные и грамотные пойдут работать на таких условиях, они уж поищут место постабильнее. Поэтому нужно из имеющихся постараться выжать за этот короткий срок как можно больше. А обучать их за счёт компании -- перебьются :) Но если всё-таки приходят уже обученные (возможно, смена обусловлена ротацией кадров внутри компании) -- тогда имеет смысл подумать об автоматизации. За полгода они много хорошего сделают, а когда уйдут, от них останутся хорошие готовые тесты и не надо "обезьянок" нанимать кнопки тыкать. То, что стиль разный -- это ничего, у программистов тоже разный, с этим вполне можно жить.

2. Проект длится уже больше года и завершаться не планируется пока (группа тестирования работает только 4 месяца :) )

Пожалуй, не очень удачно я вопрос задал. Лучше так: какова продолжительность цикла разработки (периодичность выпуска версий) и сколько версий выпущено/планируется выпустить? Чем больше итераций, тем выгоднее заниматься автоматизацией (см. любую книгу, например, Дастин приводит такие цифры: внедрение автоматизации может увеличить объём работ на первом цикле на 150%, то есть в два с половиной раза, а сокращение проявляется только на последующих циклах, да и то при условии, что тесты разработаны так, что большую из часть их удаётся переиспользовать). С другой стороны, слишком короткие циклы (хоть и много их) тоже не очень хороши -- времени не хватает, всё происходит по принципу "давай-давай!". Даже XP с их сверхкороткими циклами не рекомендует слишком часто заниматься приёмочным тестированием, для него нужно пропустить несколько циклов разработки.

3. Алексей, у меня есть еще парочка вопросов относительно продуктов UniTesK
1) Можно ли провести какие - либо параллели этих продуктов с продуктами Purify, Quantify, PureCoverage фирмы Rational?
2) Тесты какого плана автоматически генерируют Ваши продукты?

Это пошло в приват. Если, конечно, нет ещё желающих слушать рекламу в моём исполнении :) Да и в этом случае -- есть специализированный форум.

[van]

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