tag:blogger.com,1999:blog-2915575209377183930.post3866688008436616423..comments2023-08-25T01:09:38.714-07:00Comments on Юля Нечаева: как Тестированию не задерживать Разработку: часть 2Julia Nechaevahttp://www.blogger.com/profile/10351585428833840273noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-2915575209377183930.post-52688653175173768672015-03-02T04:18:52.036-08:002015-03-02T04:18:52.036-08:00Где можно научится профессии мануального тестировщ...Где можно научится профессии мануального тестировщика?anluckhttps://www.blogger.com/profile/15270661545210934438noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-66636822908068929012011-04-16T11:28:14.607-07:002011-04-16T11:28:14.607-07:001. А все таки когда наступает конец одного квадрат...1. А все таки когда наступает конец одного квадратика и начало другого ? Конечно запрос на тестирование должен приходить несколько раньше чем девелопер коммитит последние изменения и закрывает таск - тут я согласен. некоторые процессы (как тест-дизайн) можно постараться сделать паралельно с девелопментом и даже - чем черт не шутит - анализом. Но вот когда задача закончена и переходит в тестирование - какой критерий чтобы сказать "все - первый красный квадрат закончился - перехожу к зеленому"? <br />2. По-моему это все можно упросить сказав тестерам -> "начинайте репортить баги как только нашли" девелоперам ->"фиксите баг как только он попал в багтрекер" CI инженеру -> "настрой среду на билд после каждого коммита и деплой раз в день" Это на мой взгляд вполне стандартный и работающий подход и если иметь ответ на вопрос 1 то можно считать оптимальный путь найден --- или тут речь немного о другом ? (и значит я не понял идеи статьи:)) )<br />3. Юля - кажется упоминали о работе с несколькими девелопмент командами и в тоже время задачами которые не имеют бизнес вэлью одна без другой - как это так получилось? Мне кажется каждая дев команда должна работать над вполне себе самодостаточной и полноценной задачей - иначе ничего не выйдетshkeeperhttps://www.blogger.com/profile/14477239728537298529noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-69391047281982090892011-03-10T08:49:33.540-08:002011-03-10T08:49:33.540-08:002Alexei Zheglov
Вы мне вообще не противоречите =...2Alexei Zheglov <br /><br />Вы мне вообще не противоречите =) Ничего не мешает в такой схеме тестировщикам подключаться к обсуждению фичей на уровне идеи, и на уровне реализации. <br /><br />Здесь речь о том, когда команда тестирования работает на НЕСКОЛЬКО команд разработки. <br /><br />Что же касается "впечатления, что отдел тестирования расположился "вниз по течению" - то про это просто ни слова не было сказано ни в статье, ни в докладе. Описана конкретная проблема: работа с несколькими командами по разным процессам. КАК сделать так, чтоб все были довольны. Вот вам методы.<br /><br />Что до проповедников Lean - то не они со мной работают, а конкретные люди, которым нам нужно сделать удобный сервис, а не слепо следовать методологиям.Julia Nechaevahttps://www.blogger.com/profile/10351585428833840273noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-54571916841823544432011-03-09T14:49:07.931-08:002011-03-09T14:49:07.931-08:00Было бы интересно узнать, как ваша система сочетае...Было бы интересно узнать, как ваша система сочетается со <a href="http://gojko.net/" rel="nofollow">specification by example</a>. Мне кажется следующим логическим шагом привлекать тестировщиков на ещё более раннем этапе и тем самым, во-первых, получить более чёткое определение "готово" (definition of done) и, во-вторых, число циклов "тест-фикс-ретест" минимизировать или вообще занулить.<br /><br />Но такое раннее подключение тестировщиков подразумевает их подключение к задаче, которая пошла в разработку, и сотрудничество с разработчиками (и бизнес-аналитиками) по этой конкретной задаче, а не свободу "выбирать задачи из пула". Как бы вы разрешили это противоречие?<br /><br />Создаётся также впечатление, что отдел тестирования, который вы описываете, расположился "вниз по течению", и что вы боретесь там с проблемами, которые создаются отделом "в верхем течении", вместо того, чтобы ТАМ их устранять - например, вы пишете, что тестировщики могут принимать рещения на основании того "какой разработчик чище пишет код". Это как раз то, что проповедники Lean склонны ругать, называя это локальной оптимизацией. Как бы вы на это ответили?Alexei Zheglovhttps://www.blogger.com/profile/08427391130759567987noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-71234074289663729752011-03-09T10:39:45.532-08:002011-03-09T10:39:45.532-08:002CaMypau:
1) это моя классификация, я её ввожу в п...2CaMypau:<br />1) это моя классификация, я её ввожу в первой части статьи<br /><br />2) Не быстрее. Я как раз всю статью и рассказываю, в каком случае можно пожертвовать последовательностью. И ограничения подхода привожу.<br /><br />3) Опять же в первой части я определяю заказчика, как постановщика задачи. Это команда разработки, чаще всего. А не сторонний заказчик. Этап приемочного тестирования может быть в первом квадратике времени на тестирование. А может проводиться разработчиками. Зависит от процессов.Julia Nechaevahttps://www.blogger.com/profile/10351585428833840273noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-36063731636437414172011-03-09T02:08:51.415-08:002011-03-09T02:08:51.415-08:00спасибо, интересный доклад и подход к оценке време...спасибо, интересный доклад и подход к оценке времени. <br />Но:<br />1) откуда такая классификация времени. <br /><br />2) почему параллелизация процессов быстрее последовательных? <br /><br />3) если все делается для заказчика, то где то должен быть этап приемочного тестирования, только пока не очень понял гдеCaMypauhttps://www.blogger.com/profile/15743753045438573393noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-73407512693029041552011-03-08T09:13:54.989-08:002011-03-08T09:13:54.989-08:001 - Выравнивать поток входящих задач могут только ...1 - Выравнивать поток входящих задач могут только те, кто эти задачи генерит. Опять же, я не ставила себе задачей найти общее решение, я решила свою конкретную задачу, руководствуясь определенными принципами.<br /><br />2 - И это можно. И можно отдать разработчикам доступ к тестам, чтоб они сами их прогоняли перед тем, как отдать задачу на тестирование. И можно вместе с менеджером сесть посмотреть, что получилось на уровне интерфейсов, чтоб он срочно убежал к проектировщикам менять кнопки местами =)<br />Все по ситуации.<br />Тут пойнт в том, чтобы максимально подстраиваться под процессы, которые существуют в командах-заказчиках. чтоб на них влиять, но чтобы они не ломались о тестирование.Julia Nechaevahttps://www.blogger.com/profile/10351585428833840273noreply@blogger.comtag:blogger.com,1999:blog-2915575209377183930.post-25033119785907852552011-03-08T07:27:10.965-08:002011-03-08T07:27:10.965-08:00По поводу кол-ва людей в команде: надо выравнивать...По поводу кол-ва людей в команде: надо выравнивать поток задач, тогда эту практику можно распространить и на большие команды. <br />А можно базовые тесты прогонять сразу с разработчиком, чтобы он без отрыва, если необходимо внес исправления?Борис Вольфсонhttps://www.blogger.com/profile/10226714542131469659noreply@blogger.com