Перейти к содержимому

Фотография

Переход из каскадной модели в Agile для QA


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 19

#1 alekslynx

alekslynx

    Новый участник

  • Members
  • Pip
  • 33 сообщений
  • ФИО:Александр Юрьевич
  • Город:Москва


Отправлено 10 июля 2014 - 10:33

Коллеги, добрый день.

 

Недавно решил заняться очень интересной темой, а именно как организовать процесс перехода от классической модели тестирования к гибкой.

И у меня возникли следующие вопросы, на которые я пока не смог найти ответ:

 

1. При классическом подходе есть функциональное тестирование новой доработки, после того как разработчик передает задачу на тестирование. Тестирование, к примеру, направлено на тестирование бизнес процесса через интерфейс системы. (Т.е. как все привыкли клацать мышкой по всему процессу в интерфейсе)

При переходе на гибкое тестирование как происходит процесс тестирования новых доработок? 

Только на уровне кода? интерфейс вообще не проверяется?


  • 0
Ломайте стереотипы и смотрите на тестирование иначе. Только так Вы сможете сделать что-то стоящее.

#2 alekslynx

alekslynx

    Новый участник

  • Members
  • Pip
  • 33 сообщений
  • ФИО:Александр Юрьевич
  • Город:Москва


Отправлено 10 июля 2014 - 11:03

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


  • 0
Ломайте стереотипы и смотрите на тестирование иначе. Только так Вы сможете сделать что-то стоящее.

#3 Julia Atlygina

Julia Atlygina

    Активный участник

  • Members
  • PipPip
  • 149 сообщений
  • ФИО:Юлия


Отправлено 10 июля 2014 - 12:29

Можно почитать книжку "Agile Testing" by Lisa Crispin and Janet Gregory

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

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

 

При переходе на гибкое тестирование как происходит процесс тестирования новых доработок? 

Только на уровне кода? интерфейс вообще не проверяется?

В идеале конечно чем больше покрыто автотестами тем лучше, тем быстрее сможем релизить, меньше времени на тестирование тратить, чаще его проводить. И если эти автотесты еще и заранее пишутся, типо BDD на каком-нить jbehave - еще лучше. Но это совсем не отменяет ручное тестирование. Юзеры так-то ручками будут тыкать (если у вас в приложении есть куда, конечно)

 

Не знаю, ответила ли и на то ли ответила:)


  • 0

#4 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 14:08

Ответ на ваш вопрос прост, в аджайл команде нет тестировщиков в классическом понимании. (по крайней мере именно такое моё представление об аджайл команде).

 

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

 

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


  • 0

#5 Julia Atlygina

Julia Atlygina

    Активный участник

  • Members
  • PipPip
  • 149 сообщений
  • ФИО:Юлия


Отправлено 10 июля 2014 - 15:38

Ответ на ваш вопрос прост, в аджайл команде нет тестировщиков в классическом понимании. (по крайней мере именно такое моё представление об аджайл команде).

Это неправда:) Уже вроде давно поняли и в куче докладов про аджайл рассказывали: команда должна быть универсальной - это не значит, что все делают все, это значит что вся команда может все ;)


  • 0

#6 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 16:28

 

Ответ на ваш вопрос прост, в аджайл команде нет тестировщиков в классическом понимании. (по крайней мере именно такое моё представление об аджайл команде).

Это неправда:) Уже вроде давно поняли и в куче докладов про аджайл рассказывали: команда должна быть универсальной - это не значит, что все делают все, это значит что вся команда может все ;)

 

 

ну по моему мнению это не аджайл, как можно сдать фитчу в срок спринта, если в начале спринта тестировщик вообще не в курсе как будет реализован функционал? 

Я так понял у вас аджайл? Расскажите как у вас процесс разработки поставлен? Как, вы, тестировщик участвуете в спринтах разработчиков? насколько часто у вас срываются планы на спринт и тд и тп.


  • 0

#7 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 16:32

Сколько времени у вас занимает планирование?

Как точно вы выставляете сложность задачи?

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


  • 0

#8 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 16:33

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


  • 0

#9 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 16:34

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


  • 0

#10 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 16:40

 

Ответ на ваш вопрос прост, в аджайл команде нет тестировщиков в классическом понимании. (по крайней мере именно такое моё представление об аджайл команде).

Это неправда:) Уже вроде давно поняли и в куче докладов про аджайл рассказывали: команда должна быть универсальной - это не значит, что все делают все, это значит что вся команда может все ;)

 

ну и в дополнение я наверное слушал другие доклады, потому что у меня то какраз мнение из докладов и из полугодового неудачного аджайл опыта. В Люксофте был на семинаре по аджайлу, там чётко и ясно говорили о том что каждый участник должен быть достаточно квалифицирован чтобы занять место другого (более или менее, понятно, что сложно найти команду с идиально идентичными навыками, но стремиться стоит).

 

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


  • 0

#11 Julia Atlygina

Julia Atlygina

    Активный участник

  • Members
  • PipPip
  • 149 сообщений
  • ФИО:Юлия


Отправлено 10 июля 2014 - 18:51

ну по моему мнению это не аджайл, как можно сдать фитчу в срок спринта, если в начале спринта тестировщик вообще не в курсе как будет реализован функционал? 

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

 

 

Я так понял у вас аджайл? Расскажите как у вас процесс разработки поставлен? Как, вы, тестировщик участвуете в спринтах разработчиков? насколько часто у вас срываются планы на спринт и тд и тп.

ну скажем так, сам аджайл - это манифест и 12 принципов. Я бы лучше конкретные методологии называла; работала по скраму и канбану, в разных командах и несколько лет :) По-честному, если уж мы говорим о гибкой методологии, то нужно и понимать, что здесь главное - готовность меняться быстро, адаптироваться. А значит каких-то четких правил нет, аджайл у каждого свой :)

 

Что именно про процесс рассказать? Я наверно про какое-то одно место работы расскажу, где было подобие скрама и скрам мастер имел кучу сертификатов :) Итерации были по 3 недели, был  выделенный продакт овнер, он писал общее понимание истории и юзкейсы, зачем все это нужно. Он же писал аксептанс критерии к историям (по сути критерии приемки), я их ревьюила, со временем выработалось доверие и писать я их стала сама, наоборот, на ревью отдавала продакт овнеру. Были ежедневные митинги, где мы обсуждали кто что делает, нет ли у него проблем. Никаких долгих обсуждений проблем сразу на митинге! они интересны далеко не всем:) лучше обсуждать после и с заинтересованными людьми, иначе в 15 минут вы укладываться не будете и народ все сложнее будет на эти митинги зазывать. Пока девелоперы делают истории, я пишу тесты, истории на следующую итерацию, если есть что-то, что уверена, что не изменится - скрипты. Как только фича приходит на тестирование - гляжу на нее одну, и закрываю, когда все фичи на спринт готовы - перепроверяю их все и провожу приемочные тесты, обычно по сценариям длинным, типо бизнесс процессов основных. В это время у девелоперов код фриз, они подчищают хвосты и смотрят чего собираемся делать в след итерации. Автотестов там не было, не успевались, зато девелоперы исправно писали юнит тесты, было очень хорошее покрытие именно юнит тестами и на каждую задачу обязательное парное код ревью (в среднем час-два на каждое уходило),  я больше в бизнесс анализ была вовлечена, в само написание и продумывание фич, подготовку прототипов, приемочных критериев для историй, чтобы на момент планирования уже было что обсуждать. Не профукивали итерацию ни разу, тот конкретный проект длился месяцев 7, заказчик был доволен и присылал цветы :) 

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

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

 

 

Сколько времени у вас занимает планирование?

 

На проекте, о котором рассказывала выше, занимало 1 день в каждой итерации + мое время и время продакт овнера на подготовку историй. 

 

 

Как точно вы выставляете сложность задачи?

Опять же на том проекте оценивали в часах, но потому что все участники проекта в прошлых местах оценивали в часах и так было проще, чем в попугаях + нам нужно было репортить шведским коллегам именно в часах

 

 

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

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

 

 

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

Ну так наверно тоже можно, если у тебя такой выбор как у Люксофта и текучка. У нас ни того, ни другого не было, постоянная команда, очень самоорганизованная. Было круто, что мы могли сами многие решения принимать, без вовлечения менеджеров и отчетов + сидели все рядом. Грубо говоря, я могла и рядом с девелопером сесть, показать ему чего не так, вместе обсудить за 5 минут, прежде чем в багтрекер записывать, приоритезировать и с менеджерами обсуждать. Так же и баги некоторые первую верификацию проходили "парно" с девелоперами. И да, у нас не было никаких "скрам оф скрам", везде были сравнительно небольшие команды, максимум 15 человек. Проект, о котором выше рассказывала - 7 девелоперов+ 1 продакт овнер + 1 тестировщик в лице меня + скрам мастер + иногда приходящий дизайнер-фрилансер, который иконки рисовал.

 

Если на что-то не ответила  или ответила не на то - пишите:)


  • 0

#12 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 10 июля 2014 - 20:12

1 тестировщик на 7 разработчиков говорит о том, что тестировщиками были все, что подтверждается вашими словами о том, что разработчики писали много юнит тестов. Вы ещё и в роли бизнес оунера выступали. Как мне видится, ваша роль скорее была в перепроверке проверенного.

 

Про люкс и текучку:

- текучка в скрам команде это фэйл, сразу и бесповоротно. 

- Люкс Люксу рознь =) всё от проекта сильно зависит там. Бывают и вполне себе ничего.


  • 0

#13 Llanie

Llanie

    Новый участник

  • Members
  • Pip
  • 53 сообщений

Отправлено 11 июля 2014 - 06:07

1 тестировщик на 7 разработчиков говорит о том, что тестировщиками были все, что подтверждается вашими словами о том, что разработчики писали много юнит тестов.

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

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


  • 0

#14 alekslynx

alekslynx

    Новый участник

  • Members
  • Pip
  • 33 сообщений
  • ФИО:Александр Юрьевич
  • Город:Москва


Отправлено 11 июля 2014 - 06:28

 

Юля, спасибо за хороший ответ.

 

 

 

1 тестировщик на 7 разработчиков говорит о том, что тестировщиками были все, что подтверждается вашими словами о том, что разработчики писали много юнит тестов. Вы ещё и в роли бизнес оунера выступали. Как мне видится, ваша роль скорее была в перепроверке проверенного.

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

 

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

 

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

 

 

Юля, то есть без автотестов, как я понимаю, смысла переходить на аджайл нету? Т.е. время выноса задачи на бой не сократиться, если нету автоматизации, т.к. по прежнему придется делать приемку руками?


  • 0
Ломайте стереотипы и смотрите на тестирование иначе. Только так Вы сможете сделать что-то стоящее.

#15 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 11 июля 2014 - 09:26

@alekslynx

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


  • 1

#16 Julia Atlygina

Julia Atlygina

    Активный участник

  • Members
  • PipPip
  • 149 сообщений
  • ФИО:Юлия


Отправлено 11 июля 2014 - 10:15

1 тестировщик на 7 разработчиков говорит о том, что тестировщиками были все, что подтверждается вашими словами о том, что разработчики писали много юнит тестов. Вы ещё и в роли бизнес оунера выступали. Как мне видится, ваша роль скорее была в перепроверке проверенного.

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

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

 

Юля, то есть без автотестов, как я понимаю, смысла переходить на аджайл нету? Т.е. время выноса задачи на бой не сократиться, если нету автоматизации, т.к. по прежнему придется делать приемку руками?

Ну от много зависит, от размера команды, размера проекта.. Если большой - вы конечно за 2 недели не успеете все, нужны автотесты. Опять же не сказала бы, что тут в аджайле дело: чем чаще будете тесты запускать, тем меньше неожиданностей перед релизом)  Другой вопрос, что автотесты не обязательно же системные, модульных и интеграционных может быть достаточно, а систему уже посмотреть ручками в конце, картинки с пирамидкой тестов наверно все видели (такую например). Работайте командой, как вариант - те же автотесты могут и девелоперы в конце итерации каждой писать, пока вы приемку делаете, за пару итераций уже будет какой-то набор, который ваше время на приемку сократит. Ну то есть работайте командой не в том смысле, что тоже код пишите и заставляйте девелоперов ручками тестировать, а не делите проблемы на свои и чужие, общайтесь, решайте проблемы вместе, ставьте себе задачу не "протестировать", а сделать проект с хорошим качеством.


  • 0

#17 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 14 июля 2014 - 08:21

А у вас в вотерфольных проектах девелоперы не пишут юнит тестов и не делают код ревью?

 

К сожалению, далеко не всегда и далеко не на всё.

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


  • 0

#18 FestiveGrape

FestiveGrape

    Новый участник

  • Members
  • Pip
  • 69 сообщений
  • ФИО:Андреевич


Отправлено 30 октября 2014 - 19:14

Ку

 

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

 

То есть если я правильно понял, то всё упирается в то, как работает отдел разработки? И если он сначала пишет продукт до конца, а потом отдает его в тестирование (Waterfall), то тут отделу тестирования уже ничего не поделать, кроме того как работать в таком каскадном режиме? Или всё-таки отдел тестирования может как-то повлиять на этот процесс?

 

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

 

Возможно ли это как-то изменить и если да, то как и чего требовать/просить у/от раздела разработки?


  • 0

#19 clipsa

clipsa

    Специалист

  • Members
  • PipPipPipPipPip
  • 527 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


Отправлено 31 октября 2014 - 12:43

Попробуйте поговорить с начальником разработки и/или главным программистом и/или ПМом (если таковой имеется) о том, чтобы разбивать большие задачи на более мелкие тестируемые подзадачи, т.о. программисты будут выполнять мелкие задачки, а вы их будете "подхватывать" по мере готовности и тестировать.


  • 0

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


#20 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 04 ноября 2014 - 15:47

Можно почитать книжку "Agile Testing" by Lisa Crispin and Janet Gregory

Внимание, халтура!

http://software-test...e-testirovanie/


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных