А мне нравится поиск яндекса. Жаль что поиск по картинкам сделали гугло-стайл, всё испортили. А вообще я предпочитаю сервисы яндекса: и поиск, и пробки, и народ, и много других мелких приятных фишек.
Тем обиднее, что яндекс выпускает такое фуфло. «полностью переработанный браузер с табло», бар который попробуй не поставь (недавно порадовала инсталляшка торрент клиента, в которой галочка с инсталляции бара НЕ снималась физически).
Ребята, делайте хорошие сервисы, делайте их лучше, не копируйте гугл, у вас свои наработки были лучше (я картинки много ищу, для меня изменения в них — отдельная больная тема). Тогда клиент к вам потянется потому, что сервис лучше, а не потому что все эти бары и защитники ставятся без спроса при первой же возможности.
На студентов никто не наезжает, все начинают работу без опыта.
НО! Многие берут студентов в условия, где этих самых опытных наставников просто нет. А когда человеку не у кого учиться, развитие идёт в разы медленннее, это плохо и для него, и для компании.
Ну я всегда даю задачки по тестированию :) И сразу вижу, делит ли человек продукт на составные части, декомпозирует ли функционал, как приоритизирует тесты и т.д. Тестирование чашек и карандашей показывает, как человек умеет ломать продукт. Знание терминологии — лишь его заинтересованность и готовность полистать статьи или книжки перед собеседованием.
А вот тестирование маленького продукта (на бумаге) показывает очень много: умение задавать вопросы для выяснения требований, определение граничных значений, приоритизация, вспомнит ли человек про нефункциональные тесты и т.д.
Теоретические вопросы «а что такое вот это?» и «а как делать вот то?» плохи тем, что на них человек отвечает «как написано в книжке/статье». А в реальной жизни он зачастую будет делать по-другому.
«Модули» — это хорошо, но обычно нет ничего настолько удалённого друг от друга. Когда разработчик исправляет ошибку, которая относится с точки зрения пользователя (и чаще всего тестировщика) к функционалу Х, логично проверять работу фичи Х. Только исправление могло вноситься в какую-то системную библиотеку, и проверить на самом-то деле важно сквозные моменты использования этого кода во всех фичах.
Поэтому я всегда стараюсь вместе с разработчиками, архитекторами, нарисовать карту взаимосвязей в продукте. Тогда после слов разработчика «я правил это здесь» я сразу по карте вижу, что могло быть затронуто и что нужно проверять. Постепенно эта карта расширяется и становится ОЧЕНЬ полезной: мы экономим время, не тестируем лишнее, быстрее находим свежие дефекты.
К счастью, не всегда. Практика «не выпускать релиз с больше чем N некритичных багов на KLOC» достаточно популярна. Но естественно всё зависит от проекта и его текущих приоритетов.
Ну к программистам вменяемые требования значительно чаще предъявляются. А в тестировщики я лично видела как берут людей, которые на вопрос «что такое тестирование?» отвечают «а вот прийду работать к вам тестировщиком и заодно узнаю».
Код-ревью — это хорошо, особенно когда есть ответственный за модуль, и он делает ревью всех коммитов, и всегда в курсе что в его модуле происходит и не допускает бардака.
И да, ошибок на этапе код-ревью тоже много отлавливается, если проводить его не для галочки.
Только не хватает ПЕРВОГО пункта — «а что если всё хорошо?» :)
То есть и эти 10 прогнать надо, и самый основной. И НАЧАТЬ нужно с ОСНОВНОГО, когда всё хорошо. Но ведь основное редко ломается, поэтому тестировщики часто начинают сразу с негативных сценариев. А критичность негативного в разы меньше, чем самой стандартной ситуации.
Об этом же в статье написано… Мы сократили сроки в 2-м и 3-м случае, и по разработке фичи, и по выпускам итераций. В 1-й же истории временные затраты врядли изменились.
Мы стали находить больше багов, но сроки выпуска итераций фиксированные, просто мы стали исправлять в итоге более приоритетные дефекты, а сроки выпусков и ресурсы на тестирование остались неизменными.
Т.е. истории №1 и №2 — про сокращение сроков без ущерба качеству, №3 — про повышение качества без замедления разработки.
Спасибо! Хорошая статья и хорошая модель. Согласна, что GTD «привязывает» к задачам, в итоге в какой-то момент понимаешь, что за деревьями уже не видно леса.
Поэтому я бы не рассматривала GTD как самодостаточную модель, ей всегда нужна помощь на более высоком уровне стратегического целеполагания.
Недавно у меня был необычный опыт, я очень удивилась.
Мы предоставляем услуги по аутсорсу тестирования. Я на проект выделяю ведущего тестировщика, прошу добавить его в чат разработчиков на проекте. Нас добавляют с комментарием «познакомьтесь, это наши тестеры». Мой тестировщик мне лично пишет: «Наташа, а тебе не обидно, что тебя назвали тестером?».
ОБИДНО??? Вот так я невзначай узнала у ТЕСТИРОВЩИКА, что его это оказывается может задеть. Да я горжусь что меня тестером назвали, я ж тестер как-никак! А многие бодаются, стесняются, не любят таких слов.
И вот что я вам точно скажу: в том небольшом количестве компаний, где работают правильные тестировщики и где к качеству относятся тоже правильно, слова «тестер» и «тестировщик» — это очень хорошие слова :)))
Про «отсутствие трекеров и волокиты» — сталкивалась с таким, но редко. Обычно всё-таки нужны баги, которые и через месяц не грех исправить, но прямо сейчас времени нет.
Опять же, всё зависит от контекста, тестирование везде разное и цели у него разные. Возможно, в вашем случае именно так и должно быть, именно это — самое подходящее тестирование. Каждый второй шаблонизированный тестировщик будет пускать ахи и охи, говоря, что «баги надо заносить все!». Но умение подстраиваться под нужды конкретного проекта — искусство.
Про тесты на миллион строк кода как-нибудь напишу, а про b2b и b2c врядли. Опыт большой и там и там, но магических отличий я не вижу. Между 2-мя проектами b2b или 2-мя b2c зачастую отличия больше, чем между b2b и b2c. Это как отличия в ДНК: между мужчиной и женщиной их больше, чем между мужчиной и обезьяной-самцом или женщиной и обезьяной-самкой :)))
Ну всё зависит от ваших целей и что от тестирования нужно. Если такие результаты не устраивают — очевидно, что нужно что-то менять. Либо мышление этого тестера, либо самого тестера.
1) тестирование это не только предоставление информации, но и предоставление её в правильной последовательности, в нужные сроки, требуемом объёме и подходящем формате
2) информация «мы нашли такие-то баги» и формирование 25-ти разных диаграм из баг-трекера не принесёт много пользы, если в этом самом баг-трекере нет половины критичных багов.
Не поняла, с чем Вы спорите.
Тем обиднее, что яндекс выпускает такое фуфло. «полностью переработанный браузер с табло», бар который попробуй не поставь (недавно порадовала инсталляшка торрент клиента, в которой галочка с инсталляции бара НЕ снималась физически).
Ребята, делайте хорошие сервисы, делайте их лучше, не копируйте гугл, у вас свои наработки были лучше (я картинки много ищу, для меня изменения в них — отдельная больная тема). Тогда клиент к вам потянется потому, что сервис лучше, а не потому что все эти бары и защитники ставятся без спроса при первой же возможности.
НО! Многие берут студентов в условия, где этих самых опытных наставников просто нет. А когда человеку не у кого учиться, развитие идёт в разы медленннее, это плохо и для него, и для компании.
Я на ней планирую как раз об этом рассказать. Участие абсолютно бесплатное, так что регистрируйтесь :)
А вот тестирование маленького продукта (на бумаге) показывает очень много: умение задавать вопросы для выяснения требований, определение граничных значений, приоритизация, вспомнит ли человек про нефункциональные тесты и т.д.
Теоретические вопросы «а что такое вот это?» и «а как делать вот то?» плохи тем, что на них человек отвечает «как написано в книжке/статье». А в реальной жизни он зачастую будет делать по-другому.
Поэтому я всегда стараюсь вместе с разработчиками, архитекторами, нарисовать карту взаимосвязей в продукте. Тогда после слов разработчика «я правил это здесь» я сразу по карте вижу, что могло быть затронуто и что нужно проверять. Постепенно эта карта расширяется и становится ОЧЕНЬ полезной: мы экономим время, не тестируем лишнее, быстрее находим свежие дефекты.
И да, ошибок на этапе код-ревью тоже много отлавливается, если проводить его не для галочки.
Только не хватает ПЕРВОГО пункта — «а что если всё хорошо?» :)
То есть и эти 10 прогнать надо, и самый основной. И НАЧАТЬ нужно с ОСНОВНОГО, когда всё хорошо. Но ведь основное редко ломается, поэтому тестировщики часто начинают сразу с негативных сценариев. А критичность негативного в разы меньше, чем самой стандартной ситуации.
Т.е. истории №2 и №3 — про сокращение сроков без ущерба качеству, №1 — про повышение качества без замедления разработки.
Мы стали находить больше багов, но сроки выпуска итераций фиксированные, просто мы стали исправлять в итоге более приоритетные дефекты, а сроки выпусков и ресурсы на тестирование остались неизменными.
Т.е. истории №1 и №2 — про сокращение сроков без ущерба качеству, №3 — про повышение качества без замедления разработки.
Поэтому я бы не рассматривала GTD как самодостаточную модель, ей всегда нужна помощь на более высоком уровне стратегического целеполагания.
Мы предоставляем услуги по аутсорсу тестирования. Я на проект выделяю ведущего тестировщика, прошу добавить его в чат разработчиков на проекте. Нас добавляют с комментарием «познакомьтесь, это наши тестеры». Мой тестировщик мне лично пишет: «Наташа, а тебе не обидно, что тебя назвали тестером?».
ОБИДНО??? Вот так я невзначай узнала у ТЕСТИРОВЩИКА, что его это оказывается может задеть. Да я горжусь что меня тестером назвали, я ж тестер как-никак! А многие бодаются, стесняются, не любят таких слов.
И вот что я вам точно скажу: в том небольшом количестве компаний, где работают правильные тестировщики и где к качеству относятся тоже правильно, слова «тестер» и «тестировщик» — это очень хорошие слова :)))
Опять же, всё зависит от контекста, тестирование везде разное и цели у него разные. Возможно, в вашем случае именно так и должно быть, именно это — самое подходящее тестирование. Каждый второй шаблонизированный тестировщик будет пускать ахи и охи, говоря, что «баги надо заносить все!». Но умение подстраиваться под нужды конкретного проекта — искусство.
Про тесты на миллион строк кода как-нибудь напишу, а про b2b и b2c врядли. Опыт большой и там и там, но магических отличий я не вижу. Между 2-мя проектами b2b или 2-мя b2c зачастую отличия больше, чем между b2b и b2c. Это как отличия в ДНК: между мужчиной и женщиной их больше, чем между мужчиной и обезьяной-самцом или женщиной и обезьяной-самкой :)))
1) тестирование это не только предоставление информации, но и предоставление её в правильной последовательности, в нужные сроки, требуемом объёме и подходящем формате
2) информация «мы нашли такие-то баги» и формирование 25-ти разных диаграм из баг-трекера не принесёт много пользы, если в этом самом баг-трекере нет половины критичных багов.