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

[Molechka]

Конечно, у них разработчики пишут только автотесты, но сколько! И какие!

Именно потому, что отвечают за качество. 

 

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

 

Кстати, наши разработчики иногда и с регрессией (ручной) нам помогают - когда "рук" не хватает.

Жалуются, но сами вызываются помочь )

[vmaximv]

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

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

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

 

ЗЫ: с гуглом пример не удачный - на ручное тестирование у них отдельная роль.

[VinnieJohns]

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

Ольга, честно признаться, я совсем не понял, что Вы тут имеете в виду. ((

 

Жалуются, но сами вызываются - это здорово и классно. Я спорю с тем, что у топикстартера их заставляют это делать.

 

Да, Вы не первая, кто в плюсы записал то, что разработчики таким образом познакомились с мобильной версией. А я никак в толк не возьму, какой в этом профит? (не, есть ощущение, конечно, что здорово, типа, что-то новенькое посмотрели, прониклись, но чтобы прям так это в "плюсы" писать?)

 

vmaximv - это как раз то, что я хотел написать, но ленился = ) подписываюсь!

[BadMF]

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

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

 

Да и юнит тестирование то же никак не связанно с данной темой.

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

[clipsa]

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

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

Да и студенту хорошо - какой-никакой опыт и немножко карманных денег :)

[alekslynx]

 

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

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

 

 

 

 

Разработчик должен разрабатывать функционал. Разработчик должен создавать продукт.

 

Кто говорит, что в Google разработчик тестирует, прошу читайте книгу внимательнее.

В GOOGLE тестирует не "разработчик", а "разработчик в тестировании".

Это 2 разные должности и разными обязанностями и не надо перекладывать их иерархию (разработчик, разработчик в тестировании, инженер по тестированию) на обычные компании, где (разработчик, инженер по тестированию).

 

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

Разработчик не тестирует!!! максимум, это что-то проверить на уровне кода!

 

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

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

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

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

 

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

 

http://slideshare.ne...oftware-testing

[Molechka]

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

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

А Вы, видимо, разработчик?)
Может быть, даже из Google, судя по оборотам речи в стиле "мне виднее"...

Но вообще-то, судя по книге (прошу, читайте ее внимательнее!), за качество продукта отвечают ВСЕ. Включая разработчиков. Разработчики редко пишут фреймворк, согласна. Но они часто пишут unit-тесты, не считая это какой-то ерундой, которой не должны заниматься разработчики.

а Вы навязываете что разработчик должен тестировать.

Кому и что я навязываю, простите? Вам? Вроде нет...
Автору? Да я, в целом, даже не автору отвечала тем сообщением...
Так что Ваша претензия непонятна и необоснованна :)

И кстати да, я работаю в компании, в которой разработки сами (о ужас!) пишут unit-тесты, сами пишут фреймворки для API-тестов (кошмар то какой!), а иногда даже помогают тестировщикам тестировать! На последнее они, правда, тоже бурчат =)
А вот первые 2 пункта делают сами, не крича при этом "я разработчик и это не моя обязанность"

[alekslynx]

 

 

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

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

 

А Вы, видимо, разработчик?)
Может быть, даже из Google, судя по оборотам речи в стиле "мне виднее"...

Но вообще-то, судя по книге (прошу, читайте ее внимательнее!), за качество продукта отвечают ВСЕ. Включая разработчиков. Разработчики редко пишут фреймворк, согласна. Но они часто пишут unit-тесты, не считая это какой-то ерундой, которой не должны заниматься разработчики.

 

Нет, я не разработчик. Я инженер по тестированию. Давайте не путать, отвечают за качество все, от разработчика до директора, а тестировать - это уже немного другое. Его главная обязанность - это разработка, писать код (имею ввиду конкретно разработчика). Если у него остается время или нету на проекте разработчика в тестировании, он может писать unit-тесты, но это только, если есть время. А так для этого есть разработчик в тестировании.

 

То что разработчик должен серьезно относиться к тестированию я согласен, но опять же, это не главная его обязанность.

 

 

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

[Molechka]

Нет, я не разработчик. Я инженер по тестированию. Давайте не путать, отвечают за качество все, от разработчика до директора, а тестировать - это уже немного другое. Его главная обязанность - это разработка, писать код (имею ввиду конкретно разработчика). Если у него остается время или нету на проекте разработчика в тестировании, он может писать unit-тесты, но это только, если есть время. А так для этого есть разработчик в тестировании.

Так мы про книгу или нет?
Давайте признаем, что в стандартной компании нет никакого разработчика в тестировании. Если разработчик и есть тестировщик.
А вот мнение 

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

Приводит к печальным результатам, которые я наблюдала на предыдущем месте работы.
Если разработчику сказать "пиши unit-тесты, если у тебя будет на это время", у него НИКОГДА не найдется времени. А была это, заметьте, не мобильная разработка
 

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

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

[alekslynx]

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

 

 

Ну все зависит от требования к качеству скажем так.

[SALar]

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

 

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

 

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

 

Что же касается разработки в гугл, я бы прислушался к Эльдару Мусаеву: http://www.eldar.com/node/190

PS. Блог у него весьма интересен. Рекомендую.

[SALar]

 

Разработчик должен разрабатывать функционал. Разработчик должен создавать продукт.

 

Кто говорит, что в Google разработчик тестирует, прошу читайте книгу внимательнее.

В GOOGLE тестирует не "разработчик", а "разработчик в тестировании".

Это 2 разные должности и разными обязанностями и не надо перекладывать их иерархию (разработчик, разработчик в тестировании, инженер по тестированию) на обычные компании, где (разработчик, инженер по тестированию).

 

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

Разработчик не тестирует!!! максимум, это что-то проверить на уровне кода!

 

Знаете, я много лет программировал. В том числе много лет программировал бухгалтерские системы. А это такая штука где за ошибки расчетов... [Не будем о грусном]. И после написания кода я занимался тестированием. Не только на уровне кода. А полноценным тестированием.

 

Что я делал не так?

 

PS. Есть куча фирм, выпускающих отменный софт, в которых нет тестировщиков. Это нормально

[alekslynx]

 

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

 

Да почему там тестирует разработчик?

 

Разработчик и разработчик в тестировании это разные специальности.

 

У них нету проектов под документацию. У них идеи. Разработчик делает наброски идеи, реализует это в код. Показывает руководству.

Если руководство одобряет, то их проекту дают разработчиков в тестировании и инженеров по тестированию.

 

Инженер по тестированию в Гугл это не привычный нам инженер по тестированию. 1 инженер по тестированию на 1 проект (типо youtube, Chrome и т.д.), а не с куча рук на одном проекте.

 

Инженер по тестированию в Гугл совмещает в себе бизнес-анализ пользовательских запросов, руководство группой разработчиков в тестировании, выпуск продукта, релиз менеджмент. Это очень объемный скоуп работ. Именно инженер по тестированию решает выпускать продукт или нет.

[alekslynx]

 

Знаете, я много лет программировал. В том числе много лет программировал бухгалтерские системы. А это такая штука где за ошибки расчетов... [Не будем о грусном]. И после написания кода я занимался тестированием. Не только на уровне кода. А полноценным тестированием.

 

Это очень круто и хороший опыт.

[Molechka]

Да почему там тестирует разработчик?
 
Разработчик и разработчик в тестировании это разные специальности.
 
У них нету проектов под документацию. У них идеи. Разработчик делает наброски идеи, реализует это в код. Показывает руководству.
Если руководство одобряет, то их проекту дают разработчиков в тестировании и инженеров по тестированию.
 
Инженер по тестированию в Гугл это не привычный нам инженер по тестированию. 1 инженер по тестированию на 1 проект (типо youtube, Chrome и т.д.), а не с куча рук на одном проекте.
 
Инженер по тестированию в Гугл совмещает в себе бизнес-анализ пользовательских запросов, руководство группой разработчиков в тестировании, выпуск продукта, релиз менеджмент. Это очень объемный скоуп работ. Именно инженер по тестированию решает выпускать продукт или нет.

Так Вы все-таки из Google, да?

[SALar]

 

 

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

 

Да почему там тестирует разработчик?

 

Разработчик и разработчик в тестировании это разные специальности.

 

У них нету проектов под документацию. У них идеи. Разработчик делает наброски идеи, реализует это в код. Показывает руководству.

Если руководство одобряет, то их проекту дают разработчиков в тестировании и инженеров по тестированию.

 

Инженер по тестированию в Гугл это не привычный нам инженер по тестированию. 1 инженер по тестированию на 1 проект (типо youtube, Chrome и т.д.), а не с куча рук на одном проекте.

 

Инженер по тестированию в Гугл совмещает в себе бизнес-анализ пользовательских запросов, руководство группой разработчиков в тестировании, выпуск продукта, релиз менеджмент. Это очень объемный скоуп работ. Именно инженер по тестированию решает выпускать продукт или нет.

 

Еще раз:

Тот программист, который пишет код он свой же код и тестирует.

 

Есть несколько  вариантов такого подхода:

а) Сотрудника проектирующего тесты просто нет. Такому подходу 70 лет. Масса хороших продуктов сделанных так показывает эффективность этого подхода.

б) Есть сотрудник, который проектирует тесты и пишет автотесты. Но сам их не гоняет, а передает тому, кто писал код и тот их гоняет. Я слышал, что такой подход применяется около четверти века. Вероятно, больше.

 

Где именно применяются эти подходы я не писал. Не в гугле.

[alekslynx]

Есть несколько  вариантов такого подхода:

а) Сотрудника проектирующего тесты просто нет. Такому подходу 70 лет. Масса хороших продуктов сделанных так показывает эффективность этого подхода.

б) Есть сотрудник, который проектирует тесты и пишет автотесты. Но сам их не гоняет, а передает тому, кто писал код и тот их гоняет. Я слышал, что такой подход применяется около четверти века. Вероятно, больше.

 

 

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

 

А если обновления выносятся на прод каждый день?

Вы успеете разработать и протестировать код?

[alekslynx]

Поэтому мы говорим с Вами о разных вещах и подходах.

 

Вы правы и я прав. Все зависит от ситуации.

[Molechka]

А если обновления выносятся на прод каждый день?
Вы успеете разработать и протестировать код?

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

[SALar]

 

Есть несколько  вариантов такого подхода:

а) Сотрудника проектирующего тесты просто нет. Такому подходу 70 лет. Масса хороших продуктов сделанных так показывает эффективность этого подхода.

б) Есть сотрудник, который проектирует тесты и пишет автотесты. Но сам их не гоняет, а передает тому, кто писал код и тот их гоняет. Я слышал, что такой подход применяется около четверти века. Вероятно, больше.

 

 

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

 

А если обновления выносятся на прод каждый день?

Вы успеете разработать и протестировать код?

 

 

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