Comments 55
Эта простая идея помогает сэкономить на крупных проектах значительно больше, чем 25.000$!
Звучит как в этих тоненьких книжечках про то, как разбогатеть за три месяца.
История не понравилась. Она говорит, что надо жить только в синхронном стиле, хотя очень часто асинхронный позволяет увеличить производительность. Например, если у нас есть, на которое мы посылаем подчиненного и для его окончания необходимо дождатся возвращения подчиненного, мы можем на просто висеть в его ожидании, а повесить колбек на его приход, а сами заниматься остальными делами.
Плюс еще один момент для оптимизации:
1 дело. В пункте А сделать 50% дела, в пункте Б сделать других 50% дела
2 дело. В пункте А сделать 50% дела, в пункте Б сделать других 50% дела
Мы можем сделать первое и второе дело на 50% в пункте А, потом перейти в пункт Б, в котором закончить эти два проекта, чем сэкономим время лишнего перемещения между А и Б.
С другой стороны я согласен с идеей статьи, что не стоит вешать на людей сразу невероятную кучу дел, или одно огромное дело. И надеятся, что к релизу багов не будет. Это невозможно.
Думаю, ошибка в статье, что она совместила две разных идеи:
1. Надо делать только одно дело в один момент
2. Надо заканчивать сначала приоритетные дела, а потом переходить к мелочёвке, когда будет время.
С первой идеей — я не согласен, со второй — согласен.
Насчет первого пункта — все верно, при допущении того, что обе задачи — полностью независимы.
Обычно легче нанять еще одного человека (группу) для выполнения второй независимой задачи — тогда она принесет доход раньше. Другое дело, когда задача Б зависит от А, пусть даже на 20% — нужна синхронизация, которая тоже стоит денег и времени.
Так же не редкость увидеть 2-3 проекта одной компании, законченные на 70%-80% на момент окончания денег.
Обычно легче нанять еще одного человека (группу) для выполнения второй независимой задачи — тогда она принесет доход раньше. Другое дело, когда задача Б зависит от А, пусть даже на 20% — нужна синхронизация, которая тоже стоит денег и времени.
Так же не редкость увидеть 2-3 проекта одной компании, законченные на 70%-80% на момент окончания денег.
дело — это то что делаешь конкретно ты. а не проект вообще. так что когда ты послал подчинённого, то основное дело сделано и ты переходишь к следующему. если подчинённые прибегает, то возвращает себя в стэк ;-)
у тебя не 2 дела в пунктах А и Б, а 4. и когда ты находишься в пункте А все дела там являются более приоритетными чем дела в Б.
у тебя не 2 дела в пунктах А и Б, а 4. и когда ты находишься в пункте А все дела там являются более приоритетными чем дела в Б.
но дело может быть зависимо от результата дела подчиненного. к примеру, я пишу письмо к своим клиентам и прошу подчинённого принести мне последние цены, чтобы я могу их сориентировать. пока я про цены не говорю — я не зависим от результата. но когда я скажу все — я могу или ждать подчиненного с ценами, или занятся другим делом
Привет!
«Надо делать только одно дело в один момент» можно переформулировать:
1) При наличии задач разных уровней приоритета, надо всегда делать более приоритетную (при возможности и независимости)
2) При наличии возможности сделать одно дело, закончить и перейти к следующему — дела лучше делать по очереди. Потому что:
— так меньше overhead на переключении между задачами
— так раньше появляется результат хотя бы по одной задаче (а не имеется 10 задач, сделанных на 95%, которые таким образом пользы не приносят)
конечно, при взаимозависимостях задач положение дел меняется.
Что касается сравнения с «тоненькими книжками» — в этих книгах бывают очень умные мысли, которые можно и нужно внедрять :)
«Надо делать только одно дело в один момент» можно переформулировать:
1) При наличии задач разных уровней приоритета, надо всегда делать более приоритетную (при возможности и независимости)
2) При наличии возможности сделать одно дело, закончить и перейти к следующему — дела лучше делать по очереди. Потому что:
— так меньше overhead на переключении между задачами
— так раньше появляется результат хотя бы по одной задаче (а не имеется 10 задач, сделанных на 95%, которые таким образом пользы не приносят)
конечно, при взаимозависимостях задач положение дел меняется.
Что касается сравнения с «тоненькими книжками» — в этих книгах бывают очень умные мысли, которые можно и нужно внедрять :)
Если таки есть процесс тестирования, может быть базовый функционал тестировать через регрессию?
Обьясните мне пожалуйста, неразумному, что такое регрессия? Много раз видел это слово употребленным, но нормального определения не видел.
ппц. гугл с википедией отменили что-ли уже?..
Мммм… Представь, что вместо того, чтобы гонять тестера каждый раз по известным маршрутам в программе или сайте ( например — добавить товар в корзину, зарегистрироваться на сайте, и т.д. ), их можно автоматизировать, то есть пишется программы, которые специально «проходят» все эти сценарии автоматически, и проверяет — получилось ли то, что надо.
То, что надо — может быть определенным содержимым в БД или определенным контентом DOM узла с указанным селектором — это уже тот, кто писал тесты решает.
То, что надо — может быть определенным содержимым в БД или определенным контентом DOM узла с указанным селектором — это уже тот, кто писал тесты решает.
Прогресс — движение вперед, развитие системы, стремление к росту (любой системы — город, программа, сообщество).
Регресс — движение назад, ухудшение работы системы, стремление к развалу.
Со временем любая сложная система может дать сбой в «неожиданных и труднодоступных» местах.
Вдруг выясняется, что не все хотят идти к светлому будущему.
Вдруг выясняется, что в районах не так поняли указание из центра.
ВНЕЗАПНО выясняется, что никто из разработчиков не трогал функционал регистрации на сайте, а он почему-то не работает.
Чтобы предупредить весьма вероятный, но сложнозаметный откат системы в преисподню, иногда следует проводить регрессионное тестирование — проверку того, что уже давно было сделано, и вроде бы, оно всё ещё должно корректно работать.
Со стороны это выглядит, как «Так, парни, давайте еще раз с энтузиазмом пройдемся по ВСЕМУ нашему приложению, и перекликаем всё, что можно перекликать».
Или, если есть приоритеты, не по всему приложению, а по определенным местам или логическим цепочкам, по сценариям.
Наилучшее предупреждение регрессии — юнит-тесты и полная, беспощадная автоматизация. «Наилучшая» не означает «единственно верная» — есть области, аспекты и места, которые автоматизация или пропустит, или не учтет, или посчитает корректным (картинки отсутствуют, но линки работают), а это не так.
Но быстрейший способ выловить регрессию — прогонять автотесты.
Регресс — движение назад, ухудшение работы системы, стремление к развалу.
Со временем любая сложная система может дать сбой в «неожиданных и труднодоступных» местах.
Вдруг выясняется, что не все хотят идти к светлому будущему.
Вдруг выясняется, что в районах не так поняли указание из центра.
ВНЕЗАПНО выясняется, что никто из разработчиков не трогал функционал регистрации на сайте, а он почему-то не работает.
Чтобы предупредить весьма вероятный, но сложнозаметный откат системы в преисподню, иногда следует проводить регрессионное тестирование — проверку того, что уже давно было сделано, и вроде бы, оно всё ещё должно корректно работать.
Со стороны это выглядит, как «Так, парни, давайте еще раз с энтузиазмом пройдемся по ВСЕМУ нашему приложению, и перекликаем всё, что можно перекликать».
Или, если есть приоритеты, не по всему приложению, а по определенным местам или логическим цепочкам, по сценариям.
Наилучшее предупреждение регрессии — юнит-тесты и полная, беспощадная автоматизация. «Наилучшая» не означает «единственно верная» — есть области, аспекты и места, которые автоматизация или пропустит, или не учтет, или посчитает корректным (картинки отсутствуют, но линки работают), а это не так.
Но быстрейший способ выловить регрессию — прогонять автотесты.
Регрессионное тестирование — это набор тестов, которые проводятся для того, чтобы убедиться, что новый функционал не нарушил работу старой системы.
Пример:
разработали фичи 1,2,3. покрыли тестами, проверили, вывели в продакшн.
разработали фичи 4,5. покрыли тестами и проверили их. они работают. но перед уходом в продакшн надо проверить, что работает вся система. поэтому берем те тесты, которые отобраны для регрессионки и проводим их перед выходом в продакшн.
Пример:
разработали фичи 1,2,3. покрыли тестами, проверили, вывели в продакшн.
разработали фичи 4,5. покрыли тестами и проверили их. они работают. но перед уходом в продакшн надо проверить, что работает вся система. поэтому берем те тесты, которые отобраны для регрессионки и проводим их перед выходом в продакшн.
Таким образом объясняется только «что такое регрессионное тестирование».
Товарищ bear11 же спросил о том, что такое «регрессия».
У вас приведено, пожалуй, самое правильное определение «регресионного тестрования», но не приведено толкование термина «регрессия».
Товарищ bear11 же спросил о том, что такое «регрессия».
У вас приведено, пожалуй, самое правильное определение «регресионного тестрования», но не приведено толкование термина «регрессия».
Я об этом говорю отдельно только потому, что на собеседованиях заметил печальное: народ знает, что такое регрессионное тестирование, а что такое регрессия itself — не знает.
В частности, хороший вопрос "В чем разница между регрессионным и регрессивным тестированием?" обычно путает даже матерых тест-манагеров, и порождает массу гипотез и попыток на полном серьезе понять и как-то сформулировать разницу между этим двумя видами тестирования.
В частности, хороший вопрос "В чем разница между регрессионным и регрессивным тестированием?" обычно путает даже матерых тест-манагеров, и порождает массу гипотез и попыток на полном серьезе понять и как-то сформулировать разницу между этим двумя видами тестирования.
а что такое регрессивное тестирование? о_0"
Ваши предположения?
тестирование создающее баги? х)
Еще какие-нибудь предположения?
В чем основная разница между «регрессионный» и «регрессивный»?
Насколько это применимо к тестированию?
В чем основная разница между «регрессионный» и «регрессивный»?
Насколько это применимо к тестированию?
тестирование старых версий? х)
это типа головоломка или что?
это типа головоломка или что?
Да, но она очень легко решается, если понимаешь сам термин «регрессия», а не только общее толкование термина «регрессионное тестирование».
Сдаемсу?
Сдаемсу?
которая? ru.wikipedia.org/wiki/Регрессия
Мне уже пять лет этот вопрос не даёт покоя. Сдаёмся! Скажите же уже, не мучайте!
Если приложение уже большое, то регрессию тоже надо делать выборочно, по приоритетам, или же последовательно, по итерациям.
Регрессионное тестирование — хорошо.
Когда оно оптимизировано под конкретные результаты: подтверждение статуса продукта, определение возможности релиза и т.д.
А часто регрессия — это поиск багов. Это не есть хорошо :)
Когда оно оптимизировано под конкретные результаты: подтверждение статуса продукта, определение возможности релиза и т.д.
А часто регрессия — это поиск багов. Это не есть хорошо :)
эти принципе применимы не только к тестированию
Недели тестирования на Хабре?
При правильной организации процесса Program Engineering тестеры вместе с кодом (а лучше за некоторое время ДО того) должны получить от Project Manager-а такие документы как User's Scenarios & Personas. Эти документы должны описывать то, как именно будет использоваться продукт, и кем. Второе не столь важно. Важнее, чтобы в перечне сценариев стояли приоритеты. Первыми должны проверяться именно сценарии главного приоритета, и только затем — все последующие.
Важно здесь то, что распределять приоритеты (и уж тем более — писать сами сценарии) должен ну никак не Testing Manager. Это не его специализация и не его забота. Он должен получить их готовыми от Project Manager. Еще хорошо получить общий документ с общим описанием взаимодействия пользователя и текущей версии продукта. Это более широкий и более детальный документ, описывающий не только конкретные сценарии использования, а весь процесс взаимодействия пользователя и продукта. По этому документы Interface Designer должен был перед этим рисовать интерфейсы, а Developer Manager распределять работы между программистами.
Как-то так…
Важно здесь то, что распределять приоритеты (и уж тем более — писать сами сценарии) должен ну никак не Testing Manager. Это не его специализация и не его забота. Он должен получить их готовыми от Project Manager. Еще хорошо получить общий документ с общим описанием взаимодействия пользователя и текущей версии продукта. Это более широкий и более детальный документ, описывающий не только конкретные сценарии использования, а весь процесс взаимодействия пользователя и продукта. По этому документы Interface Designer должен был перед этим рисовать интерфейсы, а Developer Manager распределять работы между программистами.
Как-то так…
По-моему, на написание сценариев у менеджера жизни не хватит. Это совершенно нормально — делегировать этот процесс на инженеров.
Этим должны заниматься аналитики, отдельные люди, которые передают доки Пму, чтобы он был в курсе.
Все верно, именно так. Я не стал тут раскрывать всю цепочку, ибо там еще есть и Marketing Manager-ы, которые позиционирование прорабатывают, и Competitors Analyze ведут. И много еще кого.
Моя главная мысль была в том, что Testing Manager не должен заниматься маркетиновыми документами, это дело отдела маркетинга и проектировщиков взаимодействия. А получает он все документы от Project Manager-а, который отслеживает всю работу по проекту и координирует работу всех отделов.
Моя главная мысль была в том, что Testing Manager не должен заниматься маркетиновыми документами, это дело отдела маркетинга и проектировщиков взаимодействия. А получает он все документы от Project Manager-а, который отслеживает всю работу по проекту и координирует работу всех отделов.
Привет!
User's Scenarios быть должны — факт. Кто их делает — в каждом процессе по-разному. В моём опыте этим обычно занимаются тест-аналитики и уже результаты согласуют с РМ и аналитиками.
User's Scenarios быть должны — факт. Кто их делает — в каждом процессе по-разному. В моём опыте этим обычно занимаются тест-аналитики и уже результаты согласуют с РМ и аналитиками.
Вопрос упирается, как всегда, в терминологию. Какую роль вы отводите «тест-аналитикам»? За что они отвечают?
Моё твёрдое убеждение, что пользовательские сценарии должны быть готовы еще ДО начала разработки продукта. Разумеется, если продукт уже имеет выпущенные ранее предыдущие версии, то User's Experience от предыдущих версий должен учитываться в обязательном порядке, но это никак не отменяет необходимости подготовки сценариев для новой версии.
Моё твёрдое убеждение, что пользовательские сценарии должны быть готовы еще ДО начала разработки продукта. Разумеется, если продукт уже имеет выпущенные ранее предыдущие версии, то User's Experience от предыдущих версий должен учитываться в обязательном порядке, но это никак не отменяет необходимости подготовки сценариев для новой версии.
Тест-аналитики в терминологии RUP'a — тестировщики, ответственные за создание тестовых наборов.
Хотя, если верить RUP'y, юз-кейсы они точно создавать не должны :)
> Моё твёрдое убеждение, что пользовательские сценарии должны быть готовы еще ДО начала разработки продукта
Звучит классно, поддерживаю двумя руками!!! работала в мировых производителях ПО, такого счастья встретить не довелось :( се ля ви.
Хотя, если верить RUP'y, юз-кейсы они точно создавать не должны :)
> Моё твёрдое убеждение, что пользовательские сценарии должны быть готовы еще ДО начала разработки продукта
Звучит классно, поддерживаю двумя руками!!! работала в мировых производителях ПО, такого счастья встретить не довелось :( се ля ви.
Тот факт, что даже у многих мировых лидеров такая практика не используется — виден хотя бы на примере WP7, когда даже в основных сценариях, которые позиционируются как Sales Point, есть просто «убийственные» пробелы. Если бы сценарии прорабатывались, то ничего подобного бы не было в принципе.
Тоже согласна на 100%
Но тест-менеджер в большинстве случаев не может повлиять на отсутствие сценариев и заставить их писать, да ещё и до начала разработки.
А чтобы компенсировать их нехватку, я лично организую их написание со стороны тестирования с последующим согласованием с маркет-лидерами.
Это хуже, чем «сценарии до начала разработки», но это значительно лучше чем их отсутствие вообще.
Но тест-менеджер в большинстве случаев не может повлиять на отсутствие сценариев и заставить их писать, да ещё и до начала разработки.
А чтобы компенсировать их нехватку, я лично организую их написание со стороны тестирования с последующим согласованием с маркет-лидерами.
Это хуже, чем «сценарии до начала разработки», но это значительно лучше чем их отсутствие вообще.
«Дохлая рыба». Спасибо, теперь я знаю, как называется паттерн тестирования наших заказчиков :-)
Я думал, что простую идею можно просто и кратко описать.
Надо бы подсчитать, сколько стоили 25.000$ в начале ХХ столетия.
Практически любая система управления тестами имеет систему приоритетов
Пост не понравился, как будто большинство тест менеджеров не понимают значения основного, критичного и остального.
Пост не понравился, как будто большинство тест менеджеров не понимают значения основного, критичного и остального.
Хотел написать комментарий, но вы уже выразили мою мысль. Согласен с вами.
Понимать и использовать — «две большие разницы».
Я выступаю в роли консультанта по построению процесса тестирования и вижу кучу «бардаков» изнутри. Приоритезировать работы почти никто не умеет, это не догадки, а наблюдения. В теории понимать — все понимают, и статьи не надо. В реале использовать — увы! Преобладает либо хаос и попустительство, либо приоритезация «в голове», которая нигде не документируется.
А мысли никто читать не умеет — приоритеты так и остаются в голове.
На вопрос «приоритезированы ли у вас тесты?» почти все отвечают «да». Прошу показать, где и как — пусто. «Устно». При аудите спрашиваю у разных участников тест-команды про приоритеты. У всех они есть, и у всех свои!
А ведь тестировщики почти всегда удалены от пользователя, и сами определить приоритеты не могут.
Техническое обеспечение (наличие поля в TMS) проблему не решает. В этом поле можно поставить что угодно, но без согласования с маркетерами, аналитиками и внедренцами это пустой звук.
Я выступаю в роли консультанта по построению процесса тестирования и вижу кучу «бардаков» изнутри. Приоритезировать работы почти никто не умеет, это не догадки, а наблюдения. В теории понимать — все понимают, и статьи не надо. В реале использовать — увы! Преобладает либо хаос и попустительство, либо приоритезация «в голове», которая нигде не документируется.
А мысли никто читать не умеет — приоритеты так и остаются в голове.
На вопрос «приоритезированы ли у вас тесты?» почти все отвечают «да». Прошу показать, где и как — пусто. «Устно». При аудите спрашиваю у разных участников тест-команды про приоритеты. У всех они есть, и у всех свои!
А ведь тестировщики почти всегда удалены от пользователя, и сами определить приоритеты не могут.
Техническое обеспечение (наличие поля в TMS) проблему не решает. В этом поле можно поставить что угодно, но без согласования с маркетерами, аналитиками и внедренцами это пустой звук.
А самое ужасное в тестировании а-ля дохлая рыба — это заведение сообщений об ошибках, которые выглядят как имеющие высокий приоритет, но на самом деле вовсе ошибками не являются, а происходят от того, что тестеры не читают спецификации. Вот так потратишь на эдакую прелесть пару часов, потом обнаруживаешь, что так и должно быть, и еще час это тестеру объясняешь…
Пользователю тоже объяснять будете?
Мы живём в век Usability, посмотрите на последние версии браузеров, офисных приложений, операционок. Нового функционала почти не появляется даже в системном ПО, все новые «фичи» — это по сути лишь повышение юзабилити.
А если продукт не понятен без внимательного чтения спецификаций, то у клиента возникнут те же вопросы. А продукт с вопросами лидером рынка уже не станет, пользователи балованные :-)
Мы живём в век Usability, посмотрите на последние версии браузеров, офисных приложений, операционок. Нового функционала почти не появляется даже в системном ПО, все новые «фичи» — это по сути лишь повышение юзабилити.
А если продукт не понятен без внимательного чтения спецификаций, то у клиента возникнут те же вопросы. А продукт с вопросами лидером рынка уже не станет, пользователи балованные :-)
Вот чтобы такой ситуации не было и нужен документ «Сценарии использования» с расставленным в нём приоритетами. И оценка приоритета ошибок тогда делается очень просто: если в основном сценарии не выполняется главная задача — это Epic fail и без вариантов. А если в сценарии с приоритетом Low где-то что-то работает не так, как нужно, на это в первой версии можно и забить.
А что такое паттерн «Дохлая рыба»?
1. Сначала делать высокоприоритетные дела, а потом к мелочёвке
Это лишь один из множества паттернов управления задачами. Есть куча других паттернов.
Например: «Задачу нельзя начинать ранее указанной даты». Отличный способ управления. Я бы даже сказал, один из лучших. И то, что при этом придется начать низкоприоритетную задачу с более ранней датой начала раньше высокоприоритетной с более поздней датой — никак не уменьшает ценность метода.
2. Надо делать только одно дело в один момент.
Для повышения производительности я регулярно переключаюсь с задачи на задачу. Существует несколько причин для этого:
а) короткие циклы «разработка» — «проверка»
б) снятие усталости
в) иногда чтобы решить задачу нужно на время ее отложить
— Так что есть варианты.
Я к тому, что очень часто в тестировании нужно начинать с низкоприоритетных тестов, потому что есть причина пройти их пораньше. Причина не связанная с приоритетом функционала и приоритетом тестов. Так бывает.
Есть множество причин по которым следует бросить тестирование незаконченным и переключиться на другую задачу / проект.
PS. Эти замечания никак не умаляют ценность статьи.
Это лишь один из множества паттернов управления задачами. Есть куча других паттернов.
Например: «Задачу нельзя начинать ранее указанной даты». Отличный способ управления. Я бы даже сказал, один из лучших. И то, что при этом придется начать низкоприоритетную задачу с более ранней датой начала раньше высокоприоритетной с более поздней датой — никак не уменьшает ценность метода.
2. Надо делать только одно дело в один момент.
Для повышения производительности я регулярно переключаюсь с задачи на задачу. Существует несколько причин для этого:
а) короткие циклы «разработка» — «проверка»
б) снятие усталости
в) иногда чтобы решить задачу нужно на время ее отложить
— Так что есть варианты.
Я к тому, что очень часто в тестировании нужно начинать с низкоприоритетных тестов, потому что есть причина пройти их пораньше. Причина не связанная с приоритетом функционала и приоритетом тестов. Так бывает.
Есть множество причин по которым следует бросить тестирование незаконченным и переключиться на другую задачу / проект.
PS. Эти замечания никак не умаляют ценность статьи.
Sign up to leave a comment.
Ну очень простая идея, которая повышает эффективность тестирования в разы