То есть тестировщики должны разрабатывать, а разработчики - тестировать?
Тестировщики подготавливают разработчикам чек-листы для самостоятельной проверки своей работы. И разработчики тестируют, да, в чём проблема? Они и так должны проверять свою работу самостоятельно, прежде чем отдать в тестирование. А тут им тестировщики предоставят кейсы, для более подробной проверки.
Если тестировщик умеет писать код, то он может разрабатывать авто-тесты, помогая разработчику ускорить закрытие задачи.
Все при деле, работают вместе, и задача разработана и протестирована.
Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Точнее, задача решаемая, но у команды (Dev+QA) должно быть время довести до ума начатые задачи: исправить баги в новых фичах, починить регрессию.
Для этого надо выделять время в конце итерации. То есть разработчики не должны начинать новые задачи задолго (примерно за 1/3) до окончания итерации, чтобы дать команде время на поиск, починку и проверку багов.
P.S.
И отказаться от попытки впихнуть в итерацию побольше задач - если они всё равно не доделываются, то смысла в этом нет
вы понимаете неправильно, и это показано на первой и второй схемах спринта
В статье нет ни одной схемы, где все взятые задачи закрываются с тестированием по окончании спринта.
"У тебя неправильно распланированы спринты. Необходимо, чтобы задачи выходили из спринта уже протестированные и с исправленными багами, иначе мы не сможем их закрывать!"
Вот эта цель же не достигнута.
И основная проблема здесь - жесткое разделение ответственности разработчиков и тестировщиков. Тестировщики у вас занимаются контролем качества, а не обеспечением.
Я деталей не знаю, но предполагаю, что как и у многих, такое жёсткое разделение Dev и QA у вас заложено даже на организационном уровне: есть отдельные команды Dev и QA, участники которых общаются через очереди (бэклоги). Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Если хочется, чтобы по завершению спринта все взятые задачи были закрыты, с честно выполненным DoD, то необходимо использовать принцип "вытягивающего" производства: stop starting, start finishing, то есть не брать новую задачу, пока не доделана начатая. И работать над задачей QA и Dev должны одновременно с самого начала и до самого завершения, помогая друг другу её завершить.
Кстати, чуда не бывает, и планировать на итерацию придётся меньше. Зато всё будет честно закрыто.
В заголовке про принципы тестирования, но статья про цели... разные вещи.
В целом направление правильное, конечно, так и надо делать.
А дальше надо смотреть ещё левее: не только заводить баги и предложения по улучшению того, что плохо сделано. Но и помогать команде не делать плохо сразу :)
Обычно аргументом против такого подхода выступает сложность понимания какой из ассертов упал
Нет, аргументом против этого выступает сложность понимания почему упал тест. Хороший тест падает по одной единственной причине, ради проверки которой он и создан.
Автоматизатор тестирования — это тупиковая ветвь развития в нашей отрасли. Эта ветвь выросла по причине высокого спроса на автоматизацию тестирования и отсутствия четкого понимания кто её должен делать.
В итоге появилась целая специализация, и к сожалению к ней часто себя относят те, кто научился как-то готовить селениум, но при этом сам не тестировщик и не разработчик. Об этом в статье правильно написано.
Сейчас понимание как делать автоматизацию постепенно приходит. И мы "с удивлением" обнаруживаем, что привлечение разработчика к этому процессу на всех этапах даёт наилучший эффект.
О чем Анастасия и написала в статье. Статья — огонь!
Прикольная идея и воплощение. Кому-то действительно пригодится.
P.S. принцип работы можно было описать и понятнее — пока видео не посмотрел ничего из прочитанного не понял
слов нет нормальных. Первая космическая держава не может в космос вылететь — фейлов больше, чем успешных запусков. Позорище же! Американцы Марс исследуют, а мы тут спутник на орбиту вывести не можем…
И как теперь устрашать недругов-злопыхателей? Не поверят, что у нас ракеты летать умеют :(
Спасибо за пост, очень интересная тулза, где-то может оказаться полезной. Но мне кажется, увлекаться такими тулзами не стоит. Надо понимать, что писать тестируемый (и поддерживаемый, ликвидный) код они не помогают, а скорее наоборот. Вот этот мануал (State of the Art Testability) можно покурить на досуге (я это делаю периодически), объясняет основные принципы на конкретном примере
как я понял идею этой разработки (собственно, она прозвучала в последние 20-10 секунд ролика): дать инструмент для визуализации больших объёмов данных.
Собственно различные Pivot Tables именно для этой цели и служат. Ничего нового тут нет, только хорошо забытое старое, реализованное по последнему слову техники (тут уж Майкрософт оторвались в своей лаборатории). Крышу у меня снесло в основном от требований к системе. Ну не для людей делают всё-таки…
System Requirements
Recommended System Configuration: Windows 7 with Aero enabled, 2-GHz 32-bit (x86) processor, 2 gigabytes of random access memory.
Graphics Card Requirements: at least 256 megabytes of video memory. Pivot does not support Intel integrated video chipsets without additional acceleration hardware.
Пока что это выглядит как красивая игрушка, очевидно ролик рассчитан именно на привлекательность визуальных эффектов. C красивой игрушкой и играть приятнее :o)
Итого. На мой взгляд идея хорошая и полезная. Но реализована по-майкрософтовски пальцато. Пока хардварный парк широкой аудитории пользователей дорастёт до этих требований, конкуренты подтянутся… :o)
если я правильно понимаю, Вы сможете использовать аккаунт с GAE для входа на Google Wave. Но для этого он должен быть привязан к аккаунту на GW, который можно получить через инвайт.
думаю в этом есть некоторая прелесть. И смысл. Да, действительно, понять что человек хочет сказать, можно не дожидаясь, пока он «отладит» свой комментарий… для делового общения — это плюс.
А вот для личного порой несколько раз подумаешь, прежде чем отослать написанное (сгоряча, например). Пока пишешь, обдумываешь. И совсем не обязательно собеседнику видеть в таком случае, как рождается очередной опус :o) А-то может и обидеться…
не-не… из похожих фич скайп позволяет только отредактировать своё сообщение в чате. Но волна — это не чат. Больше похоже на share-point документ, к которому доступ на редактирование имеют одновременно все пользователи, которым он разрешён
Тестировщики подготавливают разработчикам чек-листы для самостоятельной проверки своей работы. И разработчики тестируют, да, в чём проблема? Они и так должны проверять свою работу самостоятельно, прежде чем отдать в тестирование. А тут им тестировщики предоставят кейсы, для более подробной проверки.
Если тестировщик умеет писать код, то он может разрабатывать авто-тесты, помогая разработчику ускорить закрытие задачи.
Все при деле, работают вместе, и задача разработана и протестирована.
Точнее, задача решаемая, но у команды (Dev+QA) должно быть время довести до ума начатые задачи: исправить баги в новых фичах, починить регрессию.
Для этого надо выделять время в конце итерации. То есть разработчики не должны начинать новые задачи задолго (примерно за 1/3) до окончания итерации, чтобы дать команде время на поиск, починку и проверку багов.
P.S.
И отказаться от попытки впихнуть в итерацию побольше задач - если они всё равно не доделываются, то смысла в этом нет
В статье нет ни одной схемы, где все взятые задачи закрываются с тестированием по окончании спринта.
Вот эта цель же не достигнута.
И основная проблема здесь - жесткое разделение ответственности разработчиков и тестировщиков. Тестировщики у вас занимаются контролем качества, а не обеспечением.
Я деталей не знаю, но предполагаю, что как и у многих, такое жёсткое разделение Dev и QA у вас заложено даже на организационном уровне: есть отдельные команды Dev и QA, участники которых общаются через очереди (бэклоги). Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Если хочется, чтобы по завершению спринта все взятые задачи были закрыты, с честно выполненным DoD, то необходимо использовать принцип "вытягивающего" производства: stop starting, start finishing, то есть не брать новую задачу, пока не доделана начатая. И работать над задачей QA и Dev должны одновременно с самого начала и до самого завершения, помогая друг другу её завершить.
Кстати, чуда не бывает, и планировать на итерацию придётся меньше. Зато всё будет честно закрыто.
В заголовке про принципы тестирования, но статья про цели... разные вещи.
В целом направление правильное, конечно, так и надо делать.
А дальше надо смотреть ещё левее: не только заводить баги и предложения по улучшению того, что плохо сделано. Но и помогать команде не делать плохо сразу :)
Нет, аргументом против этого выступает сложность понимания почему упал тест. Хороший тест падает по одной единственной причине, ради проверки которой он и создан.
Автоматизатор тестирования — это тупиковая ветвь развития в нашей отрасли. Эта ветвь выросла по причине высокого спроса на автоматизацию тестирования и отсутствия четкого понимания кто её должен делать.
В итоге появилась целая специализация, и к сожалению к ней часто себя относят те, кто научился как-то готовить селениум, но при этом сам не тестировщик и не разработчик. Об этом в статье правильно написано.
Сейчас понимание как делать автоматизацию постепенно приходит. И мы "с удивлением" обнаруживаем, что привлечение разработчика к этому процессу на всех этапах даёт наилучший эффект.
О чем Анастасия и написала в статье. Статья — огонь!
Спасибо за статью и публикацию фреймворка.
Про укрупнение шагов можете пояснить?
Как, например, на базе шагов
"ввести значение admin в поле login"
"ввести значение admin в поле password"
"нажать кнопку login"
сделать укрупненный шаг
"войти с логином admin и паролем admin"?
Есть примеры?
P.S. принцип работы можно было описать и понятнее — пока видео не посмотрел ничего из прочитанного не понял
Там нет информации об успешных запусках, но количество неуспехов достаточно высоко, чтобы было от чего расстраиваться
И как теперь устрашать недругов-злопыхателей? Не поверят, что у нас ракеты летать умеют :(
Собственно различные Pivot Tables именно для этой цели и служат. Ничего нового тут нет, только хорошо забытое старое, реализованное по последнему слову техники (тут уж Майкрософт оторвались в своей лаборатории). Крышу у меня снесло в основном от требований к системе. Ну не для людей делают всё-таки…
System Requirements
Recommended System Configuration: Windows 7 with Aero enabled, 2-GHz 32-bit (x86) processor, 2 gigabytes of random access memory.
Graphics Card Requirements: at least 256 megabytes of video memory. Pivot does not support Intel integrated video chipsets without additional acceleration hardware.
Пока что это выглядит как красивая игрушка, очевидно ролик рассчитан именно на привлекательность визуальных эффектов. C красивой игрушкой и играть приятнее :o)
Итого. На мой взгляд идея хорошая и полезная. Но реализована по-майкрософтовски пальцато. Пока хардварный парк широкой аудитории пользователей дорастёт до этих требований, конкуренты подтянутся… :o)
А вот для личного порой несколько раз подумаешь, прежде чем отослать написанное (сгоряча, например). Пока пишешь, обдумываешь. И совсем не обязательно собеседнику видеть в таком случае, как рождается очередной опус :o) А-то может и обидеться…