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

Фотография

Процесс тестирования в маленькой команде.


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

#1 Teddy

Teddy

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

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

Отправлено 10 августа 2014 - 18:28

У нас на фирме мальнький отдел по разработке - 2 человека: программист и тестировщик. Я как раз занимаюсь там тестированием. Проект довольно сложный, но для него нет документации, то есть ее вообще нет. Программист занимается соответсвенно разработкой архитектуры и кодированием. Внутренние версии для тестирования выходят нерегулярно, когда-то по 3 раза в день, а когда-то раз в неделю, финальных релизов еще не было. Никакой документации по тестированию от меня не требуется.

 

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

 

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

 

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

 

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

 

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

 

Буду благодарен за любые советы.

 

 

 

 


  • 0

#2 wret

wret

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

  • Members
  • PipPip
  • 124 сообщений
  • Город:Москва

Отправлено 10 августа 2014 - 19:35

Митинги каждое утро

Хотите запись, купите диктофон)


  • 0

#3 Vasiliy

Vasiliy

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

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 10 августа 2014 - 19:55

Почему вы требуете документацию от программиста? Как ему попадают задачи на разработку? Может ставить задачу на другом уровне?

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


  • 0

#4 ryjii

ryjii

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

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 11 августа 2014 - 10:19

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

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

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

Я не понимаю, например, о какой регрессии может идти речь, если релиза ни одного ещё не было.


  • 0

#5 Julia Atlygina

Julia Atlygina

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

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


Отправлено 11 августа 2014 - 12:04

Если задачки пропадают - может их просто хоть как-то записывать? в trello.com например достаточно быстро, или в формате чеклистов в checkvist какой-нить. На гитхабе есть свой трекер, может он подойдет? Где сам код? Подобрать что-то очень простое и быстрое, может и липкие листики на физической доске или документы прям в коде где-то писать

 

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

 На это я бы сказала - если документация нужна тебе, ты ее и создавай :)

Программисту и так все ок, естественно он ничего делать не будет. Бери в свои руки. Откуда требования берутся, программист сам фичи придумывает? Учти, что он может придумал, а просто записать ему лень, и если ты станешь просто за ним записывать - все проблемы и решаться:)

 

 

Раз пять начинал состовлять тест кейсы

 

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

 

Я не понимаю, например, о какой регрессии может идти речь, если релиза ни одного ещё не было.

 

Странный комментарий, если были уже тестовые сборки и не одна - почему не может поломаться то, что уже работало в предыдущих? :) так разве только в релизных сборках происходит?;)


  • 1

#6 ryjii

ryjii

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

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 11 августа 2014 - 13:02

Странный комментарий, если были уже тестовые сборки и не одна - почему не может поломаться то, что уже работало в предыдущих? :) так разве только в релизных сборках происходит?;)

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


  • 1

#7 Julia Atlygina

Julia Atlygina

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

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


Отправлено 11 августа 2014 - 15:13

В моём понимании - регрессия есть проверка уже ранее работавшего функционала.

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

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


  • 0

#8 ryjii

ryjii

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

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 11 августа 2014 - 16:26

Юлия, если прочитать первый пост автора, в нём указано, что финальных релизов ещё не было. Если я понимаю это правильно, то пока ни о каком проде речи пока не идёт.

Только автор может прояснить, как на самом деле.

 

Что касается целей тестирования - полностью согласен, я тоже об этом говорил ранее.


  • 0

#9 Teddy

Teddy

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

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

Отправлено 12 августа 2014 - 04:01

Почему вы требуете документацию от программиста? Как ему попадают задачи на разработку? Может ставить задачу на другом уровне?

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

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

 

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

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

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

Я не понимаю, например, о какой регрессии может идти речь, если релиза ни одного ещё не было.

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

 

Если задачки пропадают - может их просто хоть как-то записывать? в trello.com например достаточно быстро, или в формате чеклистов в checkvist какой-нить. На гитхабе есть свой трекер, может он подойдет? Где сам код? Подобрать что-то очень простое и быстрое, может и липкие листики на физической доске или документы прям в коде где-то писать

 

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

 На это я бы сказала - если документация нужна тебе, ты ее и создавай :)

Программисту и так все ок, естественно он ничего делать не будет. Бери в свои руки. Откуда требования берутся, программист сам фичи придумывает? Учти, что он может придумал, а просто записать ему лень, и если ты станешь просто за ним записывать - все проблемы и решаться:)

 

 

Раз пять начинал состовлять тест кейсы

 

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

 

Я не понимаю, например, о какой регрессии может идти речь, если релиза ни одного ещё не было.

 

Странный комментарий, если были уже тестовые сборки и не одна - почему не может поломаться то, что уже работало в предыдущих? :) так разве только в релизных сборках происходит?;)

Задачки как раз не пропадают, баг трекер нормально функционирует, а вот с майндкартами надо попробовать, спасибо за идею.

 


  • 0

#10 Teddy

Teddy

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

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

Отправлено 12 августа 2014 - 04:26

 

В моём понимании - регрессия есть проверка уже ранее работавшего функционала.

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

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

 

Как я вижу цель тестирования:

1) Удостовериться, что новые фичи работают

2) Удостовериться, что старая функциональность не поломалась и очередным релизом, а так как изменения в архитектуре случаются постоянно, такие поломки уже на раз происходили

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

4) В итоге должен быть создан продукт, который работает 24/7, справляется с указанной нагрузкой, и по качеству просто безупречен (вот тут и кроется основная сложность).


  • 0

#11 ryjii

ryjii

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

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 12 августа 2014 - 10:00

Ну вот, теперь становится несколько яснее. Проясните, пожалуйста, ещё пару вещей:

1. Кто спускает набор новых фичей?

2. Как часто это происходит?

3. Как быстро вам нужно реализовывать эти фичи?

4. Как часто обновляется "продакшен"?

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

Главное, не стараться соблюдать её до буквы, а брать оттуда только то, что вам подходит.


  • 0

#12 Vasiliy

Vasiliy

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

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 12 августа 2014 - 11:00

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

Может смотреть не только со стороны тестирования?


  • 3

#13 Teddy

Teddy

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

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

Отправлено 13 августа 2014 - 04:00

Ну вот, теперь становится несколько яснее. Проясните, пожалуйста, ещё пару вещей:

1. Кто спускает набор новых фичей?

2. Как часто это происходит?

3. Как быстро вам нужно реализовывать эти фичи?

4. Как часто обновляется "продакшен"?

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

Главное, не стараться соблюдать её до буквы, а брать оттуда только то, что вам подходит.

1. Фичи придумывает программист

2. Практически в каждой сборке, т.е. сборки, в которых исправляются только баги, редко происходят. Сами сборки нерегулярны - бывает, что по несколько в день, бывает, что одна сборка в течение 1-1.5 недель.

3. Жестких сроков нет

4. Еще не обновляли

 

Как вы считаете, если добавить в процесс регулярность сборки, скажем, сборка для тестирования делается по среда, от этого процесс выиграет или нет?

 

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

Может смотреть не только со стороны тестирования?

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

 

 

kacheli.jpg


  • 0

#14 ryjii

ryjii

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

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 13 августа 2014 - 08:05

На основании 1 и 4 у меня остался последний вопрос: а кто будет пользоваться этим софтом?

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

 

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


  • 0

#15 Vasiliy

Vasiliy

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

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 13 августа 2014 - 12:33

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

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

Я не говорю, что вы не правы и требуете чего-то странного! Просто есть подозрение, что требование ваши надо переложить на уровень выше.
У вас есть багтрекер - какие вещи туда записывают? Только баги? Программист может записать туда все фичи новой версии и повесить их на вас?
  • 0

#16 lurk

lurk

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

  • Members
  • PipPipPip
  • 180 сообщений


Отправлено 13 августа 2014 - 15:26

У нас на фирме мальнький отдел по разработке - 2 человека: программист и тестировщик. Я как раз занимаюсь там тестированием. Проект довольно сложный, но для него нет документации, то есть ее вообще нет. Программист занимается соответсвенно разработкой архитектуры и кодированием. Внутренние версии для тестирования выходят нерегулярно, когда-то по 3 раза в день, а когда-то раз в неделю, финальных релизов еще не было. Никакой документации по тестированию от меня не требуется.

 

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

 

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

 

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

 

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

 

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

 

Буду благодарен за любые советы.

От программиста вам нужна история изменений. Её он вполне может написать. 

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


  • 0

#17 Teddy

Teddy

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

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

Отправлено 15 августа 2014 - 16:06

 

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

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

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

 

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

 

Как-то не хочется мне привлекать руководство к этому вопросу. Думаете, без этого не обойтись?


  • 0

#18 Vasiliy

Vasiliy

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

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 15 августа 2014 - 16:46

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

#19 ryjii

ryjii

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

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 15 августа 2014 - 19:00

Я за человеческий подход. Выспросите у него, как ему будет удобнее. Хоть в багтрекер писать, хоть по утрам за чашкой кофе пересказывать.

Всё-таки пока человек не чувствует собственную заинтересованность в этой затее - даже желание вам помочь разбивается об лень.

А через руководство давить - портить отношения, имхо. В таком мега-маленьком коллективе это непростительно.


  • 1

#20 Vasiliy

Vasiliy

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

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 16 августа 2014 - 11:34

А через руководство давить - портить отношения, имхо. В таком мега-маленьком коллективе это непростительно.

Не портить, но ухудшать. Поддерживаю.
  • 0


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

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