Звук записывали, но выкладывать его без видео смысла нет: часть мастер-класса выступающий на глазах у публики писал тесты, что-то из затронутых тем уже докладывалось на SQA Days 7 в Харькове.
Презентацию и отчет о прошедшем мероприятии позже выложим, следите за публикациями на нашем сайте!
Транслировать не планируем, даже не задумывались о таком варианте, если честно. Видео писать не будем, ибо не на что, звук запишем, если он будет иметь смысл без видео и докладчик не будет против — выложим.
Если же найдутся желающие записать мастер-класс на видео и конвертировать его в файлы, мы будем только рады. Пишите нам на org@sqagroup.spb.ru, обсудим детали.
> Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
Ну, модуль условно. Например, в моей личной практике часто бывало, что разработчик ведет пяток компонентов в течение нескольких лет, а тестировщик за это время успевает поучаствовать в нескольких больших проектах.
> Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
Судя по спецификации проблемы могут быть в одном месте, а по реализации — совершенно в другом) Да, ошибки неуникальны в принципе, но ведь согласитесь, что надо еще уметь их найти, а это уже другое дело. Кроме того, хороший тестировщик должен не только найти багу, но и описать условия возникновения, возможные причины и влияние на работу с продуктом, возможные последствия. Тоже не тривиально и требует аналитических способностей.
> Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
80% тестировщиков в принципе, во всем мире, в России, в какой-то области, в Вашей компании? Уточните, пожалуйста, и пруфлинк тоже не помешал бы. Да, я согласен, что есть такая профессиональная болезнь у некоторых тестировщиков, которые считают, что им не надо понимать принципов разработки и уметь программировать, но это скорее проблема квалификации отдельных людей, молодости профессии и весьма специфического к ней подхода. Набирайте тестировщиков исходя из того, что они должны уметь программировать, или хотя бы учиться этому, и соотношение будет меняться как вокруг Вас, так и в целом :)
> Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Тестировщики должны проверять качество программного продукта, а не его реакцию на действия пользователя, а это немного разные вещи. Многие программные продукты с пользователем напрямую вообще никогда не взаимодействуют, и с чьей квалификацией тогда сравнивать квалификацию тестировщика?) Для эффективной работы тестировщик должен знать особенности платформы, технологии реализации, специфику окружений и условий работы, архитектуру продукта и принципы взаимодействия системных компонентов. Для прощелкивания кнопок на формах есть специальные фреймворки и инструменты.
Если бы система производства ПО работала идеально, то работа была бы у всех скучная: программисту говорят: какие технологии использовать, какова должна быть логика работы, какие должны быть интерфейсы полученного продукта. Тестировщик должен, кстати, подключаться раньше, начиная тестирование еще со спецификаций и технического задания. Затем тестировщик берет те же входные документы, что были у программиста и сверяет то, что должно было с тем, что получилось, и насколько стабильно работает продукт. Затем он собирает из компонентов систему и проверяет, чтобы все вместе работало как надо. Все рутинно и скучно, так и ведь деньги платят не за развлечения.
В реальной жизни ведь все совсем не так. И у кого еще скучная работа: у программиста, который зажат в рамках одного модуля, или у тестировщика, который зачастую работает с полной системой, изучая ее вдоль и поперек? Всегда забавляли подобные сентенции.
Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи. Кроме тривиальных исключений бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях, которые порой вылезают только в продуктиве. Поэтому и нужно конфигурационное и нагрузочное тестирование. Вообще, в распределенных системах бывает много такого, что обычно программистами почему-то не учитывается. К тому же, у программистов другое мышление, им интереснее создавать, чем искать уязвимости. В данном случае поговорка «ломать — не строить» имеет совсем другой акцент.
К тому же, тестировщики должны знать, как будет эксплуатироваться разрабатываемая система (степень востребованности и приоритет функционала, профили нагрузки и т. д.), чтобы искать не все ошибки подряд, а наиболее важные. Сроки всегда сжатые, что у разработчиков, что у тестировщиков, поэтому всегда будут дефекты ПО, и время на тестирование и исправление сильно ограничено. Тоже вполне творческая и ответственная работа.
Насчет монотонности — плох тот тестировщик, который не умеет программировать ;) Автоматизация помогает справляться с рутиной, ведь монотонно проверяя одно и то же, можно легко проглядеть дефект.
Насчет соотношения зарплат: почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат? По-моему, квалификация проверяющего должна быть не ниже квалификации автора, иначе просто нет смысла в таких проверках.
Мотивация как раз примерно одинаковая, по определению в краудсорсинге люди работают в основном ради интереса и признания, в случае uTest получается некоторая смесь крауд и аутсорсинга, денежное вознаграждение вторично. В качестве примера могу привести бета-тестирование игр или веб-сервисов, придумывание названий разным объектам, наполнение баз данных.
Отличается только постановка задачи. В случае краудсорсинга пользователи делают то, что заведомо кому-то нужно, а в случае ugc сами придумывают что-то такое, что должно заинтересовать окружающих.
Мне кажется, что этого отличий хватает, чтобы все-таки разделять эти вещи, это скорее два схожих пути из разных отправных пунктов в разные пункты назначения, но устраивать терминологический спор не вижу смысла, ибо практического результата мы не достигнем, не важно, к какому решению придем. Тем более, что дискуссия эта к теме самой заметки имеет отношение весьма косвенное :)
В UGC ключевым моментом является самоорганизация, в краудсорсинге — наличие заказчика, который ставит и принимает задачу. А что общего видите Вы между этими двумя явлениями?
> Сервис отладки программного обеспечения.
Отладка и тестирование — разные вещи, нет?
> Поиск ошибок за деньги.
А еще там можно выполнять тестирование по сценариям и получать деньги, не находя ошибок. Или заниматься автоматизацией тестирования, вычиткой документации.
> Найм отладчиков программного обеспечения.
Про отладку см. выше, к тому же тогда чем это отличается от аутсорса (или отдачу работ под договору подряда, если по-русски) или найму внештатных сотрудников?
> Массовое тестирование вашего продукта.
Это скорее про альфа- или бета-тестирование
Есть вполне определенное явление, есть сервис, который это явление использует, об этом и речь в топике. Предложенные Вами заменители описывают слишком широкие области и вполне могут ввести читателей в заблуждение, чего мне бы не хотелось.
Все же под краудсорсингом подразумевалось другое, не самоорганизация и не контент, генерируемый пользователями. Специально в начале привел определение. Так, например, создатели википедии утверждают, что она к краудсорсингу отношения не имеет.
я же написал как минимум. Сколько реально было проектов я не знаю. Написано, что в сообществе более 25 000 тестировщиков, однако процент «мертвых душ» неизвестен. Количество тестировщиков на проекте варьируется и зависит от бюджета заказчика — где-то бывает по 5-10, где-то по 200-300.
К тому же, распределение неравномерно и зависит от доступного оборудования, места проживания, рейтинга в системе. Например, у меня в профиле указан мобильный телефон Siemens S65, который никого не интересует, может, будь у меня iPhone или телефон на базе Android или WM, мне были бы доступны 10 проектов за май, кто же знает )
На форуме некоторые товарищи писали, что им так много проектов доступно, что им физически некогда тестировать, в то время как другим вообще ничего не было доступно.
В данном случае это транслитерация. Русскоязычного термина я не нашел (разве что «толпирование», так понятнее?), а сам изобретать не хочу. Ваш вариант, раз уже это «вполне заменяемое словечко»?
У каждого свой частный случай, ведь и приниматься решение будет не для какого-то идеального продукта, а для вполне конкретного со своей спецификой. Я вот тоже, например, не представляю, как бы мы свои серверные продукты (телеком) отдавали в краудсорс. Да у нас только чтобы человек детально разобрался в том, как все это работает, занимает обычно от месяца и больше + знание специфических протоколов и т.д. и т.п.
Собственно, топик для того и создавался, чтобы те, кто не особо не размышлял на тему отдавать в краудсорс или нет, получили некоторые общие выводы, сделанные по результатам работы в конкретных проектах, на блюдечке и им было проще решать, стоит в это влезать или себе дороже выйдет. Если кому-то поможет сэкономить время и/или деньги — буду только рад.
Насчет идеального приложения для тестирования в краудсорсе — веб-сервисы, настольные и особенно мобильные приложения, рассчитанные на неподготовленного пользователя, который скорее всего не будет читать никакие мануалы, а будет пользоваться, разбираясь по ходу дела.
1) stand alone приложения также тестируются — сборка выкладывается на фтп, тестировщикам выдаются данные для подключения
2) На мой взгляд uTest скорее предназначен для поимки багов в продукте, нежели для проверки его качества. С тестовыми сценариями, хоть такая возможность и предлагается заказчикам, много мороки: надо составить тестовые сценарии, описать ожидаемые результаты, придумать, как проверять, что сценарий действительно пройден полностью (в основном просят прикладывать скриншоты чуть ли не для каждого шага, что крайне утомительно для проверки) и, соответственно, проверить результаты. В качестве документации можно выдавать инструкцию для пользователя, если таковая имеется.
3) Конечно, подготовка окружения и управление заказов нужны, куда ж деваться?
4) Вам же проверить надо, а не переводить. Я думаю, носитель языка с формулировками разберется, ведь баги будут заноситься на явные ошибки, а не на все, что непонятно или не понравилось.
5) Никак, точно так же никто не может гарантировать, что, например, на сайте ICQ пользователь укажет свой телефон для того, чтобы ему СМкой скинули ссылку на мобильный клиент, а не будет спамить друзей. К тому же, есть достаточно бесплатных способов отправлять СМки на чужие номера, так что не думаю, что тестировщики будут этим заниматься, им деньги надо зарабатывать, а не шалить)
Вообще-то запрещено разглашать о том, в каких проектах принимаешь участие. У меня было несколько веб-сервисов, и клиентов для обмена мгновенными сообщениями. В принципе, Вы можете написать письмо со всеми вопросами их менеджерам по работе с клиентами, они довольно оперативно отвечают.
Это не активных проектов, а тех проектов, которые Вам видно ;) Так, например, только в этом мае было три проекта, в которых присуждали звание MVT (Most Valuable Tester), значит, самих проектов за это время было как минимум в два раза больше. Да, согласен, начинать там трудно, но некоторые коллеги из России и Украины трудятся весьма успешно не покладая рук.
Презентацию и отчет о прошедшем мероприятии позже выложим, следите за публикациями на нашем сайте!
Если же найдутся желающие записать мастер-класс на видео и конвертировать его в файлы, мы будем только рады. Пишите нам на org@sqagroup.spb.ru, обсудим детали.
Это просто плохой пример организации работы программистов.
Ну, модуль условно. Например, в моей личной практике часто бывало, что разработчик ведет пяток компонентов в течение нескольких лет, а тестировщик за это время успевает поучаствовать в нескольких больших проектах.
> Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
Судя по спецификации проблемы могут быть в одном месте, а по реализации — совершенно в другом) Да, ошибки неуникальны в принципе, но ведь согласитесь, что надо еще уметь их найти, а это уже другое дело. Кроме того, хороший тестировщик должен не только найти багу, но и описать условия возникновения, возможные причины и влияние на работу с продуктом, возможные последствия. Тоже не тривиально и требует аналитических способностей.
> Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
80% тестировщиков в принципе, во всем мире, в России, в какой-то области, в Вашей компании? Уточните, пожалуйста, и пруфлинк тоже не помешал бы. Да, я согласен, что есть такая профессиональная болезнь у некоторых тестировщиков, которые считают, что им не надо понимать принципов разработки и уметь программировать, но это скорее проблема квалификации отдельных людей, молодости профессии и весьма специфического к ней подхода. Набирайте тестировщиков исходя из того, что они должны уметь программировать, или хотя бы учиться этому, и соотношение будет меняться как вокруг Вас, так и в целом :)
> Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Тестировщики должны проверять качество программного продукта, а не его реакцию на действия пользователя, а это немного разные вещи. Многие программные продукты с пользователем напрямую вообще никогда не взаимодействуют, и с чьей квалификацией тогда сравнивать квалификацию тестировщика?) Для эффективной работы тестировщик должен знать особенности платформы, технологии реализации, специфику окружений и условий работы, архитектуру продукта и принципы взаимодействия системных компонентов. Для прощелкивания кнопок на формах есть специальные фреймворки и инструменты.
В реальной жизни ведь все совсем не так. И у кого еще скучная работа: у программиста, который зажат в рамках одного модуля, или у тестировщика, который зачастую работает с полной системой, изучая ее вдоль и поперек? Всегда забавляли подобные сентенции.
Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи. Кроме тривиальных исключений бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях, которые порой вылезают только в продуктиве. Поэтому и нужно конфигурационное и нагрузочное тестирование. Вообще, в распределенных системах бывает много такого, что обычно программистами почему-то не учитывается. К тому же, у программистов другое мышление, им интереснее создавать, чем искать уязвимости. В данном случае поговорка «ломать — не строить» имеет совсем другой акцент.
К тому же, тестировщики должны знать, как будет эксплуатироваться разрабатываемая система (степень востребованности и приоритет функционала, профили нагрузки и т. д.), чтобы искать не все ошибки подряд, а наиболее важные. Сроки всегда сжатые, что у разработчиков, что у тестировщиков, поэтому всегда будут дефекты ПО, и время на тестирование и исправление сильно ограничено. Тоже вполне творческая и ответственная работа.
Насчет монотонности — плох тот тестировщик, который не умеет программировать ;) Автоматизация помогает справляться с рутиной, ведь монотонно проверяя одно и то же, можно легко проглядеть дефект.
Насчет соотношения зарплат: почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат? По-моему, квалификация проверяющего должна быть не ниже квалификации автора, иначе просто нет смысла в таких проверках.
Отличается только постановка задачи. В случае краудсорсинга пользователи делают то, что заведомо кому-то нужно, а в случае ugc сами придумывают что-то такое, что должно заинтересовать окружающих.
Мне кажется, что этого отличий хватает, чтобы все-таки разделять эти вещи, это скорее два схожих пути из разных отправных пунктов в разные пункты назначения, но устраивать терминологический спор не вижу смысла, ибо практического результата мы не достигнем, не важно, к какому решению придем. Тем более, что дискуссия эта к теме самой заметки имеет отношение весьма косвенное :)
Отладка и тестирование — разные вещи, нет?
> Поиск ошибок за деньги.
А еще там можно выполнять тестирование по сценариям и получать деньги, не находя ошибок. Или заниматься автоматизацией тестирования, вычиткой документации.
> Найм отладчиков программного обеспечения.
Про отладку см. выше, к тому же тогда чем это отличается от аутсорса (или отдачу работ под договору подряда, если по-русски) или найму внештатных сотрудников?
> Массовое тестирование вашего продукта.
Это скорее про альфа- или бета-тестирование
Есть вполне определенное явление, есть сервис, который это явление использует, об этом и речь в топике. Предложенные Вами заменители описывают слишком широкие области и вполне могут ввести читателей в заблуждение, чего мне бы не хотелось.
К тому же, распределение неравномерно и зависит от доступного оборудования, места проживания, рейтинга в системе. Например, у меня в профиле указан мобильный телефон Siemens S65, который никого не интересует, может, будь у меня iPhone или телефон на базе Android или WM, мне были бы доступны 10 проектов за май, кто же знает )
На форуме некоторые товарищи писали, что им так много проектов доступно, что им физически некогда тестировать, в то время как другим вообще ничего не было доступно.
Собственно, топик для того и создавался, чтобы те, кто не особо не размышлял на тему отдавать в краудсорс или нет, получили некоторые общие выводы, сделанные по результатам работы в конкретных проектах, на блюдечке и им было проще решать, стоит в это влезать или себе дороже выйдет. Если кому-то поможет сэкономить время и/или деньги — буду только рад.
Насчет идеального приложения для тестирования в краудсорсе — веб-сервисы, настольные и особенно мобильные приложения, рассчитанные на неподготовленного пользователя, который скорее всего не будет читать никакие мануалы, а будет пользоваться, разбираясь по ходу дела.
2) На мой взгляд uTest скорее предназначен для поимки багов в продукте, нежели для проверки его качества. С тестовыми сценариями, хоть такая возможность и предлагается заказчикам, много мороки: надо составить тестовые сценарии, описать ожидаемые результаты, придумать, как проверять, что сценарий действительно пройден полностью (в основном просят прикладывать скриншоты чуть ли не для каждого шага, что крайне утомительно для проверки) и, соответственно, проверить результаты. В качестве документации можно выдавать инструкцию для пользователя, если таковая имеется.
3) Конечно, подготовка окружения и управление заказов нужны, куда ж деваться?
4) Вам же проверить надо, а не переводить. Я думаю, носитель языка с формулировками разберется, ведь баги будут заноситься на явные ошибки, а не на все, что непонятно или не понравилось.
5) Никак, точно так же никто не может гарантировать, что, например, на сайте ICQ пользователь укажет свой телефон для того, чтобы ему СМкой скинули ссылку на мобильный клиент, а не будет спамить друзей. К тому же, есть достаточно бесплатных способов отправлять СМки на чужие номера, так что не думаю, что тестировщики будут этим заниматься, им деньги надо зарабатывать, а не шалить)
Вообще-то запрещено разглашать о том, в каких проектах принимаешь участие. У меня было несколько веб-сервисов, и клиентов для обмена мгновенными сообщениями. В принципе, Вы можете написать письмо со всеми вопросами их менеджерам по работе с клиентами, они довольно оперативно отвечают.