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

[natavmor]

Приветствую всех форумчан!

 

Наша компания занимается разработкой продукта, частью которого является мобильная версия (дефолтный браузер на мобильном устройстве), прошу не путать с приложением. Как все понимают мобильных устройств много, особенно Android. Автоматизировать данный функционал не представляется возможным, т.к.  все баги в основном связаны с анимацией. Т.е. тестировать должен человек. На данный момент в компании только 1 тестировщик, это я. Протестировать все устройства конечно можно, но глаз замыливается и терпения не хватает на это. Я предложила такую систему, при которой весь поддерживаемый функционал был поделен на 6 тест сьютов, т.е. для полной проверки мне нужны 5 разработчика и я. Такая система обеспечивает полное покрытие и занимает по времени 1-2 часа.

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

 

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

[BadMF]

ещё бы вас не устраивал подход при котором наиболее рутинная часть работы перекладывается на других персонажей =)

[220v]

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

За 12 (24) часов Вы сами не успеваете протестировать? как часто у функционал обновляется?

 

 

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

 

 

У тестера должно быть много терпения :)
 

 

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

 

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

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

 

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

[Dalay_LAMO]

Мы поддерживаем не только все desktop-ые браузеры, но и мобильные устройства (не путать с приложениями) . Как все понимают мобильных устройств много, особенно Android. Поддерживаемый функционал огромен и зависит от множества факторов (качество pdf, количество страниц и прочее).

Какой у вас парк устройств?

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

Попробуйте Хабр.

Я предложила такую систему, при которой весь поддерживаемый функционал был поделен на 6 тест сьютов, т.е. для полной проверки мне нужны 5 разработчика и я. Такая система обеспечивает полное покрытие и занимает по времени 1-2 часа.
Такой подход меня устраивает полностью, но вот разработчики недовольны и утверждают, что ни принимать участие в ручном тестировании не должны.

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

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

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

[natavmor]

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

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

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

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

 

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

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

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

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

[BadMF]

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

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

 

по вопросам:

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

2) по кейсам, так как всегда важно знать что конкретно было проверено.

3) нет

[220v]

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

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

[vuchenka]

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

и почему не реально, за дня 2-3 все реально.

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

[VinnieJohns]

"Тестировать одной это нереально, получается, что нужно проверить 12 раз одно и тоже"

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

 

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

-> А за что отвечает тестировщик?

 

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

 

 

Ну и по вопросам:

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

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

 

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

-> Так и так.

 

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

-> Нет.

 

[natavmor]

Спасибо всем, кто ответил  Мне понравилась идея про провинившихся разработчиков   

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

Мобильная версия это только маленькая часть всего функционала, который приходится тестировать. 2-3 дня на тестирование у меня нет, есть только 1 день. Раньше  в команде нас было больше (трое) и мы тестировали сами, но теперь я одна  и приходится искать выход из этой ситуации. Итак, что я уже сделала:

1. Была собрана статистика (именно по нашим клиентам) по использованию мобильных устройств (устройства с популярностью <1 не входят в список поддерживаемых)

2. Проанализированы все заведенные ранее баги. Оказалось, что баг зависит в большей степени от версии ОС, а не от самого устройства. Конечно есть тормозные устройства, но мы их не поддерживаем. 

Эти 2 пункта позволили сократить кол-во устройств до 12, раньше их было больше.

3. Были разработаны тест сьюты, которые позволяют покрыть весь поддерживаемый функционал

4. Обратилась с просьбой к начальству "выпускать мобильную версию реже, но более функциональной"

 

Что планирую сделать после текущего релиза:

 - Т.к. разработчики свирепствуют и не хотят принимать участие в ручном тестировании, я предложу вариант с провинившимися разработчиками (спасибо за идею BadMF). Такие как раз есть 

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

 

Какие плюсы того, что тестируют разработчики я увидела:

1. Отчет по результатам тестирования был просто фантастическим. Разработчик не только нашел и локализовал баги, но предложил кучу вариантов на доработку (как будет удобнее, что бы он изменил). Есть конечно такие тестировщики, но их еще поискать надо, мне бы такого в команду, я бы вообще плакать перестала 

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

3. Появилось много идей о том, как лучше построить тестирование, улучшить тесты и т.д. 

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

 

После релиза у нас планируется совещание на котором мы будем думать как быть дальше. Я обязательно поделюсь всеми идеями и отпишусь. Все спасибо!

[VinnieJohns]

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

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

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

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

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

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

[vuchenka]

Ищите еще тестировщика, то что разработчиков заставляют тестировать это неправильно.

Как  правильно сказали, они на это не подписывались...

Незнаю, как руководство ваше на это согласилось.

[vmaximv]

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

[natavmor]

VinnieJohns, а какие у вас в компании методы воспитания? 

Вот, например, есть разработчик, который выполнил задачу не только как написано и без багов, но даже лучше, так сказать выделился, а есть такой, который даже не удосужился посмотреть, что сделал и породил кучу багов. Как вы с таким боретесь? В некоторых компаниях бывают системы премирования с анкетами и прочим. Если несколько релизов подряд человек получает 0 баллов, то его либо увольняют, либо переводят на должность пониже.

У нас на данный момент никакой системы нет.

 

По поводу аутсорса надо прикинуть. Все-таки у меня получается не неделя разработчика, а всего 9 часов в релиз (по крайней мере в этот), это 1 рабочий день разработчика + мое время, пусть будет 1,5 дня разработчика. 

[VinnieJohns]

natavmor, мое мнение в том, что воспитывать - поздно в таком возрасте. = )
А работа с такими случаями - это задача менеджера: поговорить, выяснить причины (может, не умеет, или не считает нужным, или считает это ниже своего достоинства - всякое может быть), быть может замотивировать (денег дать, на другой проект перевести, в должности повысить - де юре или де факто - кому-то достаточно и просто называться круто), нарисовать дальнейший план, или принять нелёгкое решение о расставании с человеком. Имхо, для небольшого коллектива система с анкетами (как вы упомянули), KPI и прочим фаршем может быть даже вредна. На мой взгляд, нет ничего старого доброго регулярного фидбека от умного и понимающего менеджера - "чувак, ты классно поработал" или "чувак, ты сделал гадость, что мы можем предпринять, чтобы в будущем это не повторилось?"
Более вышесказанного, я даже не возьмусь гадать по форуму, да и не менеджер я ;)

Что, как мне кажется, вы можете предложить - так это написать и принять какой-то регламент (процесс/конвеншнз), в котором четко бы было сказано, к примеру, что разработчик обязан перед коммитом в общий транк, провести ряд функциональных позитивных тестов и задокументировать их.
Кому-то это может показаться излишней бюрократизацией процесса, но в некоторых случаях это может помочь решить эту проблему. (Ещё, кстати, помогает новичкам влиться в работу) У наших разработчиков был когда-то коммит-чеклист на 100500 пунктов - что нужно проверить и в чем убедиться перед коммитом и что задокументиовать после. В своё время это было полезно, сейчас отменили. Когда-то разработчики писали в багтрекер короткое "пофикшено в ревизии №чччч", сейчас (по процессу) пишут ноту на страничку A4 с кучей инфы - в нашем случае это всё было нужно. Плюсы такого подхода в том, что все знают что и как нужно делать и исключается момент с "я забыл, я не знал, я не думал, что это важно etc"

Можете предложить ещё каких-нибудь активностей добавить, типа код ревью, для особо отличившихся.

[BadMF]

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

[Drag]

Такие споры, интересно читать :)

Но ответ на вопрос тс может уже был озвучен: нужно больше тестировщиков. Где их искать уже другая задача, можете бета тестеров найти, можете на клиентах проверять (что плохо, но иногда вариант), можете разработчиков разжаловать (что еще более плохой вариант), можетет что то еще исключить из тестирования. Но вы уже оптимизровали что могли. А после предела оптимизации начинает работать закон впихивания: «при попытке впихнуть невпихуемое выпихивается ранее впихнутое». И почему кстати из троих тестеров остался всего один человек?

[Julia Atlygina]

Еще на тему тестирования разработчиками: http://blogs.atlassi...ira-qa-process/

[Molechka]

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

А Вы читали книжку "Как тестируют в Google" ? :)

[VinnieJohns]

Ольга, спасибо, хорошо подкололи = )

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

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