http://rutube.ru/tracks/2921945.html — предлагаю прослушать идею о распределение ответственности между командой разработки и командой тестирования. Да конечно в Аджайл командах это сложно выделить, но существует множество команд и проектов, где Аджайл почему-то не внедряют. И чтобы расставить точки над и, я решил поделиться своим видением, что должен делать тестировщик в таких командах.
Здравствуйте, denis miller, Вы писали:
DM>http://rutube.ru/tracks/2921945.html — предлагаю прослушать идею о распределение ответственности между командой разработки и командой тестирования. Да конечно в Аджайл командах это сложно выделить, но существует множество команд и проектов, где Аджайл почему-то не внедряют. И чтобы расставить точки над и, я решил поделиться своим видением, что должен делать тестировщик в таких командах.
"Вы собираетесь просмотреть видео, которое может содержать материалы эротического характера, нецензурную лексику или сцены насилия."
ЗачОтный, наверное, ролик про программистов и тестеров
Здравствуйте, vmpire, Вы писали:
V>"Вы собираетесь просмотреть видео, которое может содержать материалы эротического характера, нецензурную лексику или сцены насилия."
V>ЗачОтный, наверное, ролик про программистов и тестеров
черт, теперь обязательно посмотрю
Здравствуйте, denis miller, Вы писали:
DM>http://rutube.ru/tracks/2921945.html — предлагаю прослушать идею о распределение ответственности между командой разработки и командой тестирования. Да конечно в Аджайл командах это сложно выделить, но существует множество команд и проектов, где Аджайл почему-то не внедряют. И чтобы расставить точки над и, я решил поделиться своим видением, что должен делать тестировщик в таких командах.
мудацкое видео, мудацкий текст, мудацкий перевод. Про автора не знаю, но скорее всего и автор тоже...
Если кто не согласен с этим комментарием — сначала посмотрите видео. Выдержите ли вы более 15 секунд?
K>мудацкое видео, мудацкий текст, мудацкий перевод. Про автора не знаю, но скорее всего и автор тоже...
K>Если кто не согласен с этим комментарием — сначала посмотрите видео. Выдержите ли вы более 15 секунд?
ну я
в рог сразу дать или сам об стенку?
Здравствуйте, Аноним, Вы писали:
А>ну я
А>в рог сразу дать или сам об стенку?
Дай угадаю. Ты denis miller?
Перевести ролик конечно начинание хорошее, но зачем так гнусавить?
P.S. Больше 15 секунд я не выдержал.
Здравствуйте, denis miller, Вы писали:
DM>http://rutube.ru/tracks/2921945.html — предлагаю прослушать идею о распределение ответственности между командой разработки и командой тестирования. Да конечно в Аджайл командах это сложно выделить, но существует множество команд и проектов, где Аджайл почему-то не внедряют. И чтобы расставить точки над и, я решил поделиться своим видением, что должен делать тестировщик в таких командах.
Посмотрел видео. Сразу хотелось бы отметить, что перевод лучше все-таки сделать нормальным или же записать версию, полностью дублированную на русском. То есть отдельно версия на английском и отдельно версия на русском. Как минимум, английская версия мне понятна и без перевода.
Думаю, так было бы лучше, а так больше похоже, что автор прикалывается, причем не очень удачно. Но это мнение по поводу "обложки".
Теперь по содержанию. Сразу скажу, что оно заметно лучше "обложки", так как есть подведение под модель, при которой и разработчики и тестировщики (в данном случае подразумеваются тестировщики-автоматизаторы) обеспечивают некоторую инфраструктуру, которая сама бы все баги находила и сама бы всё регистрировала. А люди работали бы просто над поддержанием данной инфраструктуры.
Технически это реализуемо. Связка "версионка — автосборщик — интерфейс внешнего доступа к трекинговой системе" рулит. В частности в ту же Jira, TestLink, Mantis есть возможность постить баги через XML-RPC, SOAP (у кого как).
Но проблема в другом. Если еще code-level тесты можно сделать более-менее стабильными, то вот с более высокоуровневыми тестами (вплоть до уровня UI) уже проблематичнее. Основные источники проблем:
1) Выбрыки используемого инструментария. Если это всякие фитнесы, ватиры, то это еще ничего. Подобные средства уже по форме своей хорошо интегрированы в инфраструктуру разработки. Но если пойдет какой-нибудь тяжеловес, типа QTP, RFT и прочая (а пока что не на всех направлениях можно найти полноправный легковесный аналог), то готовьтесь к секасу с допиливанием своего решения + разного рода кастомизациям. Это я уже не говорю, что на определенном этапе (когда тестов будет очень много), такие тяжеловесы могут преподносить неприятные сюрпризы с зависанием, вылетом без выдачи логов и т.п.
2) Кривые руки тестировщиков-автоматизаторов. Хоть это корень всех зол изначально, но я поставил это вторым пунктом, так как данный недуг все-таки лечится правильной мотивацией + с приходом опыта после серии набитых шишек.
И вот пока вот эти недуги не устранены или не минимизированы, то об автоматической регистрации дефектов лучше позабыть на время. Практика показывает, что подобное стоит применять после того, как всё автоматизационное решение выдает не менее 90% корректных результатов (то есть тесты либо прошли успешно, либо упали на известной проблеме). Иначе трекер погрязнет в куче ложных багов.
Но сама идея имеет право на жизнь.
Другая сложность состоит в том, что вот эту вся эта система рассматривается в контексте Agile. А это зачастую означает, что продукт развивается очень динамично и всё решение надо постоянно латать. Да и если временные рамки достаточно тесные, то часть кода пишется наспех и появляются разные артефакты, наподобие того связывания, что рассматривалось в ролике.
Также, подобные "артефакты" еще связаны с проблемами проектирования. То есть сам дизайн изначально не до конца проработан, вот уже на этом уровне проблемы.
В целом, описанная система подходит не только для Agile. От Agile ( точнее XP ) явно указывается практика TDD. Да и сама идея покрывать тестами свежий код. Просто, скорее всего, подобная система более жизненно необходима для гибких процессов.
Здравствуйте, karkadil, Вы писали:
k> мудацкое видео, мудацкий текст, мудацкий перевод. Про автора не знаю, но скорее всего и автор тоже...
k> Если кто не согласен с этим комментарием — сначала посмотрите видео. Выдержите ли вы более 15 секунд?
+1. 17 секунд (5 секунд потрачено на поиск таймера).
Ytz>Дай угадаю. Ты denis miller?
Верно.
Ytz>Перевести ролик конечно начинание хорошее, но зачем так гнусавить?
Ytz>P.S. Больше 15 секунд я не выдержал.
Это специально сделано. Это задумка. Аналог начала 90-х, когда гнусявый переводчик переводил все буржуйские фильмы.
Чуть позже оригинал могу выложить, но там я на английском рассказываю
Marduk, жму руку! Ты пошёл дальше задумки! Спасибо за развёрнутое сообщение.
В этом ролике был ещё один посыл — "программисты должны писать код качественно". Встречается ситуаций, которые можно описать такими анти-паттернами
— ну на моей машине запускается ведь (пример не очень хорошего отношения к командным усилям)
— вот тебе код — тести (специализация и изоляция команд разрабоки и качества)
— откладывания багов на потом (очень много регрессионых багов обнаруженных на стадии тестирования могут быть Won't Fix, то есть время нет на это, пусть живут)
— отношение разработчиков к команде тестировщиков
— отношение к процессу. когда творческий позыв разработчиков не ограничивается качеством.
В общем, между строк очень интересные топики подняты. Если цепочку раскрутить, то в конце цепочки обнаружится интересное слово... Lean
