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

[Vestalka]

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

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

Зачем нужны тестировщики, если команда разработчиков уже использует автоматизированное тестирование (юнит-тесты)? Почему время для тестирования нужно выделять своевременно? Как тестировщики могут повлиять на работу agile-команды, которая сформировалась давно и не предполагала QA-отдела? Реально ли организовать полноценный отдел тестирования не в начале проекта? И — самое главное — как подстроиться под уже существующую методологию так, чтобы тестировщиков слушали и слышали, и в то же время не скатиться в печальное противостояние «мы» и «они»
Доступна Презентация"
Доступна Аудио запись "

[SALar]

Ох, уж эта вики. Ох, уж это копипаста

которыми руководствуются успешные команды.

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

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

Это в вики.

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

Это в слайдах.
Между этими двумя предложениями лежит огромная разница. Такая же как между фразами:
"Большинство программистов ошибается с оценкой сроков" <=> "Все программисты вруны"

Дополнение 1. Agile это название группы методологий. (Правда есть и собственно методология с таким названием).
Дополнение 2. Короткие циклы - это одна из практик. Иногда (часто) хорошая. Иногда очень плохая. Но важно не это. Во главу угла в Agile ставятся не практики, а люди. И здесь врет уже и вики.

К слову об 1-2 неделях. По утверждению Асхата SCRUM - ~ 50% рынка Agile. В SCRUM итерация 4 недели. Так что в большинстве случаев продолжительность итераций более 2-х недель. Это мелочь, но дьявол он именно в мелочах.
И что самое неприятное, определение длительности цикла у Agile основателей и российских инженеров резко расходится. Иногда в два - четыре раза. Но это так. К слову.

-- Слайд 2 --------------
Спринт - это не артефакт
Митинг - это не артефакт
Демо и ретро - это не артефакты

-- Слайд 3 -----------------
А что есть какие-то проблемы в том, что целый год не было тестировщиков?!
Я вот три года разрабатывал сложные бухгалтерские программы и не было у меня тестировщиков. Так после моего ухода еще лет пять аналогичную по качеству систему не могли на рынке подобрать. Или нереально дорого или недостаточная функциональная полнота.

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

==================================================================================
Можно еще запись послушать, может еще чего найду.
Но вот вопрос. Помогут ли мои комментарии? Нужны ли они?

PS. Я против реализации модели ПУТ (программирование - управление - тестирование). Неэффективная это модель.

[Vestalka]

Можно еще запись послушать, может еще чего найду.
Но вот вопрос. Помогут ли мои комментарии? Нужны ли они?

В споре рождается истина, как известно ))) Так что комментируйте не стесняясь )))
Копипаст - великая вещь, ага. И разница в предложениях - тоже великая. И что Аджайл - не собственно методология разработки, а "свод правил" - тоже правильно.
Вот только вопрос: как бы Вы объяснили людям, которые не знают, что такое Agile (а таких было почти половина зала), за 10-15 минут что же это такое, чтобы потом без проблем продвигаться в своем выступлении по намеченному плану? ;)
Согласитесь, отдельные определения - это большая, очень большая тема, говорить на которую можно часами. ))) Некоторые авторы, кстати, относят и спринт, и митинг к артефактам. Но цель-то выступления, согласитесь, была не в том, чтобы найти разницу и уловить нюансы. )))

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

А после моего ухода из одного учреждения на мое место хотели 2 человек брать, потому что один бы не справился (это раз уж мы тут "меряемся") )))
А еще мне знакомая программистка рассказывала, какая она молодец и как работает без тестировщиков. Тоже пишет программы бухгалтерам.
И когда они ей звонят и говорят, что что-то не работает, она идет чинить. Приходит, смотрит строгим взгядом, говорит пару умных слов и спрашивает: "Что именно не работает?" Нормально они ей, естественно, объяснить не могут как получилось, что система вылетела. На том и дело заканчивается. Перефразируя известное выражение: "Нет внятного объяснения - нет баги!"
Еще мне очень нравится ситуация, когда я прихожу в банки и там регулярно виснут программы: в кассе, на оформлении карточек и переводов и пр. Я уже настолько к этому привыкла, что даже научилась не обращать внимания на судорожно извиняющихся работников, яростно пытающихся хоть что-то сделать с программой или дозвониться до техподдержки. Я даже привыкла к потерям времени и если мне операционист говорит, что перевыпуск карточки займет 20 минут, я заранее настраиваюсь на 2 дня хождения в банк - и не ошибаюсь.
Я это к чему: когда мне кто-то говорит, что пишет программы, которые никто не тестирует, и эти программы замечательно работают - мне всегда хочется приложить к этим программам свои тестерские ручонки. ))))
Ничего личного, просто опыт )))

[Egor Eremeev]

Таня, здравствуй.
Какую литературу рекомендуешь для изучения по Agile ?

[SALar]

В споре истина не рождается. В споре могут обрисоваться позиции.

Вот только вопрос: как бы Вы объяснили людям, которые не знают, что такое Agile (а таких было почти половина зала), за 10-15 минут что же это такое, чтобы потом без проблем продвигаться в своем выступлении по намеченному плану? ;)

Элементарно. 1-2 минут на это более чем достаточно.
=====================================

Некоторые авторы, кстати, относят и спринт, и митинг к артефактам.

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

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

А что есть какие-то проблемы в том, что целый год не было тестировщиков?!
...

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

Сосредоточимся на главном. Огромное число отличных программ были выпущены без тестировщиков в качестве выделенной роли. Программа не глючит, пользователи довольны, владелец бизнеса получает свой профит. Тестировщики то зачем?
Если эти программы замечательно работают - то зачем прикладывать к этим программам свои тестерские ручонки. )))) Заняться нечем? Денег как у дурака махорки?

То что в проекте год не было тестировщиков проблемой не является. Это нормальное, обыденное явление.

[Vestalka]

Таня, здравствуй.
Какую литературу рекомендуешь для изучения по Agile ?

Привет ))
На русском языке коротко и по-существу: "SCRUM и XP: записки с передовой" Хенрика Книберга.
Если этого уже мало, а уровень знаний английского нормальный, можно почитать "Agile Retrospectives" Esther Derby - очень хорошо написано про ретроспективы. В нашей команде очень сильно пригодилось, когда ретроспективы начали занимать по 2-3 часа (со всеми положенными холиварами и пр.)
Я обычно предпочитаю статьи книгам, т.к. там больше своевременной информации (зачастую книга пока к нам дойдет - уже становится неактуальной). Хорошую подборку, конечно, можно почитать на AgileRussia.
Если с английским вообще хорошо - можно послушать вебинары по Agile тут: www.rallydev.com.

[Vestalka]

В споре истина не рождается. В споре могут обрисоваться позиции.

...
Элементарно. 1-2 минут на это более чем достаточно.
...
Не мои проблемы.
...
Путать результат и действие - классическая ошибка слабых менеджеров. Менеджеры с запада не исключение. Но вам то зачем в тот лагерь?

...
Сосредоточимся на главном. Огромное число отличных программ были выпущены без тестировщиков в качестве выделенной роли. Программа не глючит, пользователи довольны, владелец бизнеса получает свой профит. Тестировщики то зачем?
Если эти программы замечательно работают - то зачем прикладывать к этим программам свои тестерские ручонки. )))) Заняться нечем? Денег как у дурака махорки?

То что в проекте год не было тестировщиков проблемой не является. Это нормальное, обыденное явление.

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

Отсутствие тестировщиков лично на нашем проекте целый год принесло свои "плоды". Если Вы слушали немного дальше, чем первые три слайда, то, наверное, заметили, что у нас релиз на полгода отложился в связи с тем, что багов было найдено немало. )) Опять же: смотря о какой программе идет речь. Мы, конечно, не гугл пишем, но и не программу на 20 бухгалтеров, которых можно припугнуть, а потом заверять начальство, что "пользователи довольны".

Ну и последнее. Я всегда не против (и даже ЗА) получения нового опыта и новых знаний, поэтому если Вы мне расскажите про Agile за 1-2 минуты - я буду Вам только благодарна. Если что - могу дать скайп, вдруг Вам войсом удобнее будет это делать? ;))

[SALar]

Об Agile в 105 слов: http://blog.shumoos.com/archives/233 . Если не ошибаюсь, это полминуты доклада.
Вызовет много вопросов - могу ответить в скайпе.

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

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

Мне близко определение RUP. Процесс не может быть артефактом. Но артефакт может появиться в результате процесса. Принято?

Отсутствие тестировщиков лично на нашем проекте целый год принесло свои "плоды". Если Вы слушали немного дальше, чем первые три слайда, то, наверное, заметили, что у нас релиз на полгода отложился в связи с тем, что багов было найдено немало. )) Опять же: смотря о какой программе идет речь. Мы, конечно, не гугл пишем, но и не программу на 20 бухгалтеров, которых можно припугнуть, а потом заверять начальство, что "пользователи довольны".

Ранее я написал, что анализировал только слайды. Запись не слушал.

> релиз на полгода отложился в связи с тем, что багов было найдено немало
Но это вовсе не означает, что проблема была исключительно из-за отсутствия тестировщиков на ранней стадии. И это вовсе не означает, что тестировщики вообще были нужны.
* Большая часть ошибок вносятся в программу до кодирования. Зачем отлавливать их на стадии тестирования?
* Часть проблем с качеством не ловится тестированием.

Много замечательных программ были написаны без выделенной роли тестировщиков.

[Vestalka]

Об Agile в 105 слов: http://blog.shumoos.com/archives/233 . Если не ошибаюсь, это полминуты доклада.
Вызовет много вопросов - могу ответить в скайпе.


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

Много замечательных программ были написаны без выделенной роли тестировщиков.

Об Agile в 105 слов....
Все хорошо. Но хорошо для меня - я УЖЕ знаю, что такое стендап митинг, парное программирование, "информационный радиатор", фильтры на вход и выход (и остальные умные слова :) ), а что делать, если человек их ни разу не слышал? Сколько еще слов (кроме этих 105) понадобится, чтобы донести до слушателя то, что хочется донести?
Кстати, в выступлении слышно, что вопрос про "артефакты это или нет?" задавался. И слышен мой ответ тоже )))

"Зачем нужны тестировщики?" - буду считать риторическим вопросом )))
У каждого - свое мнение. Вы считаете, что можно написать замечательную программу без тестировщиков. Я считаю, что еще более замечательную программу можно написать с участием тестировщиков. Каждый имеет право на свое ИМХО )))
Но вот у нас, допустим, еще ДО стадии кодирования тестировщик уже принимает участие в разработке. Например, проводя тестирование требований или анализируя (уже совместно с ПО и девелоперами) будущую фичу. У нас многие баги просто не доходят до кодирования. ))) Так что не стоит ограничивать тестировщика только участием его в "стадии тестирования" ))))

[samurai08]

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

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

Зачем нужны тестировщики, если команда разработчиков уже использует автоматизированное тестирование (юнит-тесты)? Почему время для тестирования нужно выделять своевременно? Как тестировщики могут повлиять на работу agile-команды, которая сформировалась давно и не предполагала QA-отдела? Реально ли организовать полноценный отдел тестирования не в начале проекта? И — самое главное — как подстроиться под уже существующую методологию так, чтобы тестировщиков слушали и слышали, и в то же время не скатиться в печальное противостояние «мы» и «они»
Доступна Презентация"
Доступна Аудио запись "

Понравилась ваша неформальная подача доклада.
Насколько эффективны юнит-тесты при наличии регрессионных тестов на Селениуме? (если я правильно понял, у вас именно так).

[Vestalka]

Понравилась ваша неформальная подача доклада.
Насколько эффективны юнит-тесты при наличии регрессионных тестов на Селениуме? (если я правильно понял, у вас именно так).

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

[samurai08]

Понравилась ваша неформальная подача доклада.
Насколько эффективны юнит-тесты при наличии регрессионных тестов на Селениуме? (если я правильно понял, у вас именно так).

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

Наверное, не так спросил. Хотелось бы узнать в количественных метриках нахождения ошибок(какой процент, приоритеты найденных багов, сколько процентов кода покрывается каждым видом тестов). Понимаю, что это "it depends", но было бы любопытно узнать.

[Vestalka]

Наверное, не так спросил. Хотелось бы узнать в количественных метриках нахождения ошибок(какой процент, приоритеты найденных багов, сколько процентов кода покрывается каждым видом тестов). Понимаю, что это "it depends", но было бы любопытно узнать.

Я уже говорила на докладе, что максимальный процент покрытия тестами (юнит-тестами), который я видела - это 98%. Но тут уже вопрос не в покрытии кода, а в правильности написания теста. Бывают такие случаи, когда тест покрывает код на 100%, а баги все равно появляются. Потому что тест написан, к примеру, только по позитивным сценариям и программист не предусмотрел того, что потом взбрело в светлую голову тестировщика ))) К тому же юнит-тесты не ищут баги как таковые. Они показывают, что какая-то часть системы была изменена и эти изменения затрагивают другую часть системы, на что не обратили внимания. У нас разработка ведется по TDD, т.е. существует тест и пока этот тест не "пройдет" - функционал не считается завершенным. Т.е. тесты не ищут баги: на основе тестов пишется код.
У нас ежедневный билд и если "упал" какой-то тест, то сразу видно, что кто-то закоммитил какой-то код, который задействуется не только в том месте, где он писался, но еще и в соседнем. Т.е. тестируется, в основном, бизнес-логика.
Тесты на Селениуме - только функциональные (те, которые кликают по интерфейсу). Количество найденных багов зависит от того, насколько сильно менялся функционал, а также от самого качества написания тестов. Это - только регрессионное тестирование, поэтому багов немного: к этому времени все обычно уже "вылизано" и "вычищено".
К тому же мы стремимся к тому, чтобы тестировщики не тестировали, а верифицировали функционал, поэтому много предусматривается еще на этапе анализа и проектирования фичи. Все это происходит с участием тестировщика, Project Owner и программистов. На этом этапе мы предупреждаем появление порядка 30% багов.
При мануальном тестировании львиную долю багов занимает верстка. Мы пока не придумали как это предупредить или автоматизировать с наименьшими затратами. ((((