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

[alekslynx]

 

О, позовите в эту тему Алименкова Николая :)
Он разработчик и у них нет тестировщиков. При этом релизятся хоть в тот же день, что Заказчик фичу захотел, все на автотестах от разработки!

 

В этом случае подход б) очень эффективен. Он просто чудеса позволяет делать.

 

 

Тут все зависит от маштаба ежедневной фичи.

 

Если маленькая, то разработчик сам может и разработать и протестировать.

 

А если ежедневные обновляния, фичи для OS или браузера? Вы успеете за 8 часов написать обновление (на которое и надо 6-8 часов), прогнать полностью регрессионное тестирование всего OS или браузера (автотестами), успевать следить за багами, которые вываливаются на автотестах, их править и заново прогонять? А завтра Вам уже нужно писать новый код, т.к. завтра новое обновление.

 

Да и Вы видимо никогда не делали Ревью кода.

 

При том, что кроме Вас больше разработчиков на проекте нету, которые бы тоже занимались этой фичей.

 

Я при при таких условия не нагружал бы еще разработчиков такой работой.

 

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

[SALar]

 

Тут все зависит от маштаба ежедневной фичи.

 

Если маленькая, то разработчик сам может и разработать и протестировать.

 

А если ежедневные обновляния, фичи для OS или браузера? Вы успеете за 8 часов написать обновление (на которое и надо 6-8 часов), прогнать полностью регрессионное тестирование всего OS или браузера (автотестами), успевать следить за багами, которые вываливаются на автотестах, их править и заново прогонять? А завтра Вам уже нужно писать новый код, т.к. завтра новое обновление.

 

Да и Вы видимо никогда не делали Ревью кода.

 

При том, что кроме Вас больше разработчиков на проекте нету, которые бы тоже занимались этой фичей.

 

Я при при таких условия не нагружал бы еще разработчиков такой работой.

 

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

 

Давайте так. На SQADays-15 я делаю доклад о стратегиях тестирования. В частности, там будет рассмотрена стратегия б), и показано почему, если вам нужна очень высокая скорость релизов, то тестирование программистом является очень эффективным. Как вариант, можно посмотреть мой доклад с осенней конфетки, но там сложность высоковата. 

 

PS. И ревью и рефакторинг кода я, естественно, делал. Хотя непонятно причем тут это.

[ch_ip]

Тема и обсуждение непередаваемо прекрасны. Давненько таких не было. Слежу за обсуждением с самого начала и несколько офигеваю от реакции сообщества.
Собственно, что имеем на старте?
ТС озвучил проблему: есть мобильная версия, которую надо тестировать на 12 выбранных устройствах 1 раз в 2 месяца. Тестирование на одном устройстве занимает 1 час. Чтобы протестировать полностью необходимо 12 раз пройти тест-комплект, но тестировщик один, времени, которое есть чтобы протестировать - 1 день. Сейчас в качестве решения проблемы используется привлечение программистов к тестированию, но это не всем нравится, поэтому ТС ищет другие варианты решения проблемы.
 
Совершенно нормальная ситуация, особенно учитывая дополнение ТС о том, что раньше с ресурсами на  тестирование было лучше (3 человека), а сейчас пока так, как описано.
Итого, у команды, которая выпускает продукт, есть проблема (продукт выпускается командой, поэтому проблемы одного из участников команды в плане выполнения части работ, на самом  деле являются проблемами всей команды).
Какие проблемы есть:
выполнение 12 циклов тестирования по одному плану - это просто убийственно
1) с точки зрения мотивации человека, который этим занимается. Допускаю, что есть маньяки, готовые и 20 раз подряд проходить по одному сценарию, но обычно люди  начинают испытывать раздражение после трех одинаковых сценариев подряд.
2) следствием 1 является все меньшая концентрация и способность обнаружить ошибки при повторном прохождении сценария, причем снижение этой способности идет по нарастающей, и 10 цикл почти бесполезен с точки зрения вероятности найти ошибку, которая не совсем краш посередине сценария.
 
Итого, на старте скорее всего (полностью ситуации не знаю, поэтому предполагаю) имеем следующее:
можно или не проводить часть тестирования, или проводить его неэффективно, или в качестве временной меры привлечь разработчиков.
Плюсы привлечения прекрасно расписаны ТС тут

[ch_ip]

Тестировать версию надо 1 раз в 2 месяца. Тестировать одной это нереально, получается, что нужно проверить 12 раз одно и тоже (на данный момент мы выбрали 12 устройств по собственной статистике), нанимать для этого кучу тестировщиков тоже нецелесообразно, объясню почему:

1. такая работа требуется не часто (1 раз в 2 месяца)

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

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

 

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

 - а) это делают только тестировщики?

 - б) они тестируют по тест кейсам или как пользователи?

 - в) есть ли группа бета тестирования?

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

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

б) не очень ясно, что значит как пользователи. Скорее всего тестируем мы "как пользователи", потому что по тест-кейсам - это не тестирование, а верификация (checking в англоязычной литературе)

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

[ch_ip]

А руководство как отнеслось к вашему "рац.предложению"? Мы ведь все понимаем, что час разработчика обычно стоит несколько дороже, чем час тестировщика.

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

[ch_ip]

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

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

2 220v и vuchenka. Вы сами пробовали 12 раз прогнать одно и то же за один-два дня?
Оптимизировать рутину - это совершенно нормальное желание.
И N раз проверять одно и то же - это работа робота, а не тестировщика. Квалифицированный специалист будет стараться уйти от такого всеми силами.

[ch_ip]

"Тестировать одной это нереально, получается, что нужно проверить 12 раз одно и тоже"
-> Вы не думали о смене профессии? Такой подход очень сильно "дискриминирует" тестировщиков в глазах общественности, задумайтесь.

такой ответ дискриминирует профессию гораздо больше

"не надо сваливать свои недоработки и безответственность на плечи тестировщиков", у нас за качество функционала отвечает в первую очередь разработчик, а не тестировщик"
-> А за что отвечает тестировщик?

Тестировщик за качество не отвечает. См. выше мои комментарии + почитайте статьи на тему, почему он не может отвечать за качество. 
 

Разработчик не должен тестировать (точка!)

 
Это заблуждение. Разработчики тестируют создаваемое ПО уже более 50 лет, и нельзя сказать, что это провальная затея :)

[ch_ip]

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

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

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

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

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

[ch_ip]

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

Это правильно!
Вообще нехватка ресурсов - это хорошо! Позволяет оценить приоритеты в задачах и способы оптимизации работы (см, например, http://okiseleva.blo.../blog-post.html)

[ch_ip]

Разработчики при прохождении ручных ТК будут всегда смотреть на приложение со стороны "кода", а не со стороны "пользователя". Это примерно тоже самое, как сдавать экзамен где ты и экзаменатор и экзаменующийся.
Если первые несколько раз от этого и можно получить отдачу - людям свойственно интересоваться новым, пусть даже это новое не очень приятное.
То потом эта отдача будет уменьшаться как качественно так и количественно: "Я знаю, что тут в коде я ничего не трогал => все должно работать как и раньше => passed", "Ой. Какой то конфирмейшен выскочил, а в ТК его нет - но ведь все работает => passed", "Чойта кнопка какая-то сильно большая - но ведь работает => passed", "Блин эксепшен. А... Да мой косяк. Cейчас быстро поправлю будет работать сто пудово. *Записывает на бумажке - бумажка падает под стол* => passed", "Хм. Фейлится. Ниче не понятно. *Перегружает телефон*. О. Норм. Наверное просто тел сглючил => passed" и т.д.

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

[ch_ip]

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

Что можно в итоге предложить:
1) еще раз посмотреть на баги, найти общие моменты и попытаться еще раз приоритизировать список конфигураций, чтобы можно было, например, всегда проверять на трех, а еще на трех дополнительно. В следующий релиз опять проверять на трех обязательных и трех других дополнительных и т.д. То есть покрывать все устройства не каждый раз, а в течение нескольких релизов
2) отдать на аутсорс - но велик риск, что качество будет не таким, как вы ожидаете
3) посоветоваться с разными программистами, которые видели приложение, и еще раз подумать, что из списка проверок можно автоматизировать. На симуляторах совсем никак нельзя проверять, обязательно на живых устройствах надо?
Может быть можно автоматизировать не всю проверку, а часть каких-то сценариев или шагов, которые являются подготовительными к проверке, чтобы уменьшить время, необходимое на прохождение сценария
4) попробовать использовать биржи типа fixber или oDesk, где есть много тестировщиков с разными устройствами. Сразу решает и проблему рутины и проблемы покрытия.
5) выпускать релизы часто и проверять новые релизы на одном устройстве каждый раз. Все равно же пользователи не будут обновлять приложение каждую неделю. А процент тех, кто будет, - мал, что позволит провести фактически бесплатное бета-тестирование.О критичных ошибках вам сразу сообщат ;-)

[uga]

ch_ip, всё ты правильно пишешь... только почему никто не заметил:

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

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

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

[220v]

 

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

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

2 220v и vuchenka. Вы сами пробовали 12 раз прогнать одно и то же за один-два дня?
Оптимизировать рутину - это совершенно нормальное желание.
И N раз проверять одно и то же - это работа робота, а не тестировщика. Квалифицированный специалист будет стараться уйти от такого всеми силами.

 

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

[vmaximv]

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

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

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

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

Для опытного автоматизатора - это 1,5-2 месяца. А если ТК простые или однотипные - и того меньше. А теперь представьте профит от автоматизации, если эти 300 тестов надо гонять на 12 конфигурациях

[220v]

 

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

Для опытного автоматизатора - это 1,5-2 месяца. А если ТК простые или однотипные - и того меньше. А теперь представьте профит от автоматизации, если эти 300 тестов надо гонять на 12 конфигурациях

 

Связать веб с десктопным не так уж и просто (очень специфичные места...за 2 месяца веб был написан - проблема в связке с десктопным), гоняем на 8 конфигурациях + mobile. Тесты совершенно не однотипные

[uga]

Коллеги, все вы что-то пишете, как-бы правильно... только никто не заметил:

Предложенное мной решение было принято начальством.

т.е. что рыба-то гниёт с головы!

Благодаря руководству уволились 2 тестировщика (если, конечно это не было первой частью плана natavmor).

Теперь начнут увольняться разработчики (из-за тойже natavmor), благодаря руководству.

Судя по всему, чтобы вкрутить в той компании лампочку: руководство встаёт на стул и держит её, natavmor читает кейс, а 5 разработчиков вращают стул.

Может хватит обсуждать с умным видом глупость!

[ch_ip]

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

Я, конечно, контекст не знаю и могу промахнуться, но, когда я читаю про "нет времени для улучшений", мне сразу вспоминается картинка: https://twitter.com/...9864960/photo/1

[ch_ip]

ch_ip, всё ты правильно пишешь... только почему никто не заметил:

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

1. Не беспокоит, что только один разработчик занимается реализацией на множестве кроссплатформенных вариаций (из которых natavmor выделила лишь часть - 12 инвариантов, как/почему - только ей ведомо - но уже и этого объёма ей выше крыши)?
2. Очевидно, в обсуждениях много "слепых зон", из-за которых советы, мягко говоря однобоки, не ведут точно к цели (которая здесь также ясно не сформулирована).

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

P.S. Троллинг в такой форме здесь не приветствуется. Правила форума

[uga]

1. Один разработчик - вполне нормально. У нас веб-приложением занимается один разработчик, например. А основным приложением - два разработчика. Количество разработчиков - это не показатель вообще.

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