О, спасибо! Надеюсь работа впечатляет в хорошем смысле :)
Про генераторы не думала… этот чит-лист, по сути, список структурированных рекомендаций, на что обращать внимание. Какие-то из рекомендаций применимы в каждом конкретном случае, какие-то нет. Некоторые применимы всегда.
Возьмем, например, сброс авторизационной сессии на всех устройствах. При сбросе пароля критично, чтобы пользователя разлогинивало со всех устройств, это вопрос безопасности. При принудительном разлогине (пользователь нажал "Выход" на одном из клиентов) вопрос дискуссионный, в некоторых системах нужно, чтобы разлогинивало везде, в некоторых наоборот не надо.
Даже не знаю, как их можно автоматизировать, но было бы очень интересно узнать, как Вы это видите, на уровне идеи
Замечу однако, что проходя по перечисленным проверкам в диалоге с разработчиком, я часто нахожу критичные недоработки задолго до начала тестирования. Может быть, его можно было бы как-то адаптировать для разработчиков?..
Кроме того, картинка иллюстрирует «к пуговицам претензии есть?» Жванецкого и без подписи :)
похоже так и есть, по Жванецкому :) Однако с другой коннотацией. Жванецкий говорил о безразличии и непрофессионализме. Я попыталась раскрыть условия, в которых профессиональный тестировщик необходим команде. По моему опыту, мисс коммуникации, человеческий фактор, VUCA-world, постоянные спутники IT-проектов, у кого-то больше, у кого-то меньше. В сложных условиях их влияние возрастает и становится фатальным. Но если есть процессы контроля качества, выполняемые специальными людьми, риски качества значительно уменьшаются.
Касательно аутсорсинга тестирования продуктов — здесь все совсем неоднозначно.
абсолютно с вами согласна :) С аутсорсинг-тестированием всё неоднозначно. Неоднозначно, также, как с конкретными видами инструментов и процессов. Думаю, золотых пуль не существует, нет решения, которое бы подошло каждому проекту, на любом этапе зрелости, на любом рынке. Давайте посмотрим, когда аутсорсинг может быть полезен:
— к примеру компания набирает первых тестировщиков, ни у кого в ней нет компетенций, чтобы достоверно оценить потенциальных кандидатов и понимания, как настраивать QA/QC процессы. А, как я писала ранее, профессионализм в работе тестировщика крайне важен. В этом случае мы можем прийти, настроить процессы и передать наработки компании.
— или компания готовит MVP нового продукта, никто в ней не может гарантировать, что проект «взлетит». Как поступить в этом случае, нанимать тестировщиков с риском увольнения или привлечь аутсорсеров?
— или компании понадобился определенный вид тестирования и срочно, а на кадровом рынке нужного специалиста с огнем не сыскать. Почему бы в этом случае не привлечь нас, если у нас такой специалист есть ;)
если подумать, примеров куда больше. Мы договариваемся о результатах заранее, легко подключаемся и отключаемся. И нам выгодно иметь хорошую репутацию, поэтому уделяем развитию своего сервиса и компетенций достаточно внимания.
Я могу представить внешнюю контору как некоего аудитора, доказывающего заказчику продукта, что, будучи выполненным компанией X, он соответствует заявленному качеству.
Мы можем выполнять аудиты, и это, пожалуй, самое независимое тестирование. Но, как вы заметили, оно не всегда эффективно. И я с этим согласна :), хотя и у аудитов есть свое место в истории
Также мы умеем работать в команде заказчика, в этом случае производственный процесс тестировщика совсем не отличается от работы штатного сотрудника, отличается зона ответственности
Благодарю за проявленный интерес! В публикации использовалось уже готовое изображение. А сделанные, по моему мнению, ошибки автора носят преднамеренный характер и составляют всю «соль» данного демотиватора.
лично мне очень импонирует Ваш подход :) Однако охота подискутировать, так рождается истина
У меня не получилось рассмотреть за текстом процессов — не ясны контрольные точки и коммуникации на каждом этапе. А это значит, непонятно
— какие условия нужно было выстроить, чтобы все перечисленное работало, как положено. К примеру, не при всяких условиях можно узнать, что хочет заказчик и не в любой момент выяснить из каких компонентов состоит продукт.
— как именно вы понимаете, сделаны ли эти работы хорошо. Как сами тестировщики это понимают?
Или перечисленное скорее best practices отдела?
В деталях:
— Про требования. Мне кажется тут не хватает проверки на согласованность требований… с целями заказчика. Если проект живет дольше одного релиза, с архитектурой проекта, уже существующими в нем другими функциональностями, данными.
— Про риски. Есть такое убеждение, что риски могут быть не только регрессионными.
Для примера, вы разрабатываете новую функциональность, ммм… статус-кнопку, которая горит красным на ответ false от внешнего сервера и зеленым в случае true. Кнопка должна работать в режиме реального времени. Какие риски? Приложение может заспамить, а в худшем случае положить внешний сервер. Надо анализировать. Допустим риск оправдан. Очевидное решение — нужно кэшировать показатель кнопки, или реализовать очереди. Но тогда кнопка перестает работать в режиме реального времени — тоже риск, да такой, что надо обсуждать с заказчиком.
Другой пример, вы разрабатываете какую-то внутреннюю механику, положим выгрузчик. На каждом этапе, он может не обработать данные, не выгрузить их, не суметь сохранить в БД. В чем риск? Все это нельзя будет достоверно проверить, если не будет соответствующих ручек и логов. Это уже дополнительная активность, чтобы в тестирование передали тестопригодный продукт. Ничто из перечисленного не является регрессией, но вроде является работой с рисками.
Довольно платное решение, не каждому по карману, но действительно удобное — подробнее чек-листов и тем более чит-листов, легковеснее тест-кейсов, чтобы использовать в быстрой разработке, интегрированное с таскменеджером, да и прогоны можно прикрутить при желании, причем бесплатно.
Только не закидывайте меня помидорами. В чем все таки уязвимость?
Юридически нельзя, что за закон? Как можно навредить абоненту (даже потенциально), узнав его ФИО через телефон?
Или обсуждается нравственный аспект. Т.е. навредить нельзя, просто нехорошо это. К слову про нравственный аспект, не так давно была возмущена сайтом поиска ФИО по телефону. Возмутило то, что писк выдает список личных социальных аккаунтов, номер телефона в которых заведен, НО скрыт для всех. Тем не менее, сайт, как видите, жив здоров.
— само собой интересен инструмент. Что за инструмент, возможен ли совместный доступ, как помечаются приоритеты кейсов, можно ли фильтровать кейсы по типам, например, для прогона регрессии или части сценариев?
— как Вы тестируете, только черным ящиком или серым тоже. Если и серым, то где фиксируете описание и связи компонент, относящиеся ко все фиче, а не отдельным use case
— используете ли систему управления тестами. Если да, то какую — интересно, как Вы помечаете прогоны тестов в древовидной структуре.
— и наконец, какой у Вас жизненный цикл разработки продуктов, в которых используется древовидная документация. Сколько времени длится релиз, какую часть из него занимает тестирование
все это необходимо для понимания, насколько Ваша практика применима
Вот как раз содержание мне и показалось урезанной версией предыдущей статьи, обернутой в другой фантик, но если это Ваш авторский контент, то любые вопросы отпадают автоматически.
С содержанием согласна на 100%, и удержание и возвращение окупается, проверено опытом. Само собой оба решения надо принимать осмысленно. И отдельное спасибо за предыдущую статью, я ее помню, потому что нашла в тексте поддержку своих решений, которые на то время выглядели адиозно внутри компании.
не читала. Порекомендуйте, почему ее стоит прочитать, по комментарию это не ясно. Я здесь пишу о вполне конкретных вещах и хочу понять, как ваш отклик к относится к содержанию.
Статья очень похожа на краткое изложение книги «Как тестируют в Google». Я даже удивлена что там нет прямой ссылки. Очень рекомендую ее к прочтению, там куда больше занимательного. Тем более, что книга уже несколько лет выпускается в русском переводе.
И все таки, она не про качество, а про процессы контроля и обеспечения качества. Попробую объяснить разницу
Качество определяется метриками проекта. А влиять на него при росте проекта нужно путем автоматизации процессов релизного цикла.
метрики сами по себе не определяются, их должен кто-то определить. Кто? Допустим вы QA и взяли на себя эту задачу. Как это сделать, чтобы не строить башню из слоновой кости и не занизить планку? Структурировать эту задачу и определить для каждого пункта границы между «качественно» и «некачетсвенно». Как? Попыталась описать в своей статье.
А процессы… Они же не перенимаются по шаблону, их выстраивают на основе многих условий, первые из которых Ваш потребитель и Ваш продукт. Тему процессов попробую раскрыть в следующей статье.
в соответствии со статьей от ассоциации Деминга император Хирохито вручил ученому «Орден священного сокровища второй степени» в 1960г. Полагаю этот год можно считать официальным признанием его работы.
Итак, с годом, вы правы, я борщенула. Сбил с толку год публикации книги, нужно было проверить.
Ублажение потребителя — это емкое словосочетание, которое в его риторике действительно не фигурирует. Но его 14 принципов направлены именно на это. В долгосрочной перспективе вы сэкономите время и сделаете ваш продукт более успешным, если научитесь слышать своего «потребителя» (внутреннего и конечного). И сильно облегчите себе жизнь, если научите этому своего «поставщика».
В статье я хочу рассказать не о Деминге, хотя не скрою, его книга «Выход из кризиса. Новая парадигма управления людьми, системами и процессами», сильно утвердила лично мои взгляды. Я хочу сказать, что «качество» начинается с определения своего потребителя и понимания, что именно вы ему даете и каким образом. Поставщика, что хотите от него получать, в каком виде.
Я отвечаю за тестирование, поэтому пример про тестирование. Что производят ручные тестировщики? На низком уровне, для внутренних потребителей они не производят ничего, кроме отчетов (о дефектах, о состоянии релиза, о рисках). Очевидно, эти отчеты, должны быть понятными, достоверными и своевременными. Для кого? Для разработчиков, руководителей проекта, саппорта. А если нет? В лучшем случае они будут приходить за уточнением и тем самым тратить время (и ваше и свое), которое могли бы не тратить. В худшем принимать неправильные решения, которые негативно повлияют на конечно потребителя.
Конечному потребителю нужен хороший продукт. Основная сложность в том, чтобы понять, что именно он идентифицирует, как «хороший». Декомпозировать такую крупную задачу мне помог стандарт ISO.
Он не работал непосредственно на заводах Тойоты, тем более в 80 годах
ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.
Мерси :) буду рада узнать, как полет, удобно ли пользоваться и чего не достает
Мерси :) буду рада узнать, как полет, удобно ли пользоваться и чего не достает
Спасибо за обратную связь :)
Спасибо за обратную связь :)
Большое спасибо! Буду рада, если чит-лист будет реально полезен и распространится, особенно со ссылкой на первоисточник ;)
С большим вниманием обработаю обратную связь, что удобно — не удобно, хватает — не хватает. Обратная связь может навести на идеи его масштабирования.
Спасибо за редактуру, поправила. Мне и правда не хватает редактора :) И это не сарказм, автоматический, как я вижу, не справился.
О, спасибо! Надеюсь работа впечатляет в хорошем смысле :)
Про генераторы не думала… этот чит-лист, по сути, список структурированных рекомендаций, на что обращать внимание. Какие-то из рекомендаций применимы в каждом конкретном случае, какие-то нет. Некоторые применимы всегда.
Возьмем, например, сброс авторизационной сессии на всех устройствах. При сбросе пароля критично, чтобы пользователя разлогинивало со всех устройств, это вопрос безопасности. При принудительном разлогине (пользователь нажал "Выход" на одном из клиентов) вопрос дискуссионный, в некоторых системах нужно, чтобы разлогинивало везде, в некоторых наоборот не надо.
Даже не знаю, как их можно автоматизировать, но было бы очень интересно узнать, как Вы это видите, на уровне идеи
Замечу однако, что проходя по перечисленным проверкам в диалоге с разработчиком, я часто нахожу критичные недоработки задолго до начала тестирования. Может быть, его можно было бы как-то адаптировать для разработчиков?..
похоже так и есть, по Жванецкому :) Однако с другой коннотацией. Жванецкий говорил о безразличии и непрофессионализме. Я попыталась раскрыть условия, в которых профессиональный тестировщик необходим команде. По моему опыту, мисс коммуникации, человеческий фактор, VUCA-world, постоянные спутники IT-проектов, у кого-то больше, у кого-то меньше. В сложных условиях их влияние возрастает и становится фатальным. Но если есть процессы контроля качества, выполняемые специальными людьми, риски качества значительно уменьшаются.
абсолютно с вами согласна :) С аутсорсинг-тестированием всё неоднозначно. Неоднозначно, также, как с конкретными видами инструментов и процессов. Думаю, золотых пуль не существует, нет решения, которое бы подошло каждому проекту, на любом этапе зрелости, на любом рынке. Давайте посмотрим, когда аутсорсинг может быть полезен:
— к примеру компания набирает первых тестировщиков, ни у кого в ней нет компетенций, чтобы достоверно оценить потенциальных кандидатов и понимания, как настраивать QA/QC процессы. А, как я писала ранее, профессионализм в работе тестировщика крайне важен. В этом случае мы можем прийти, настроить процессы и передать наработки компании.
— или компания готовит MVP нового продукта, никто в ней не может гарантировать, что проект «взлетит». Как поступить в этом случае, нанимать тестировщиков с риском увольнения или привлечь аутсорсеров?
— или компании понадобился определенный вид тестирования и срочно, а на кадровом рынке нужного специалиста с огнем не сыскать. Почему бы в этом случае не привлечь нас, если у нас такой специалист есть ;)
если подумать, примеров куда больше. Мы договариваемся о результатах заранее, легко подключаемся и отключаемся. И нам выгодно иметь хорошую репутацию, поэтому уделяем развитию своего сервиса и компетенций достаточно внимания.
Мы можем выполнять аудиты, и это, пожалуй, самое независимое тестирование. Но, как вы заметили, оно не всегда эффективно. И я с этим согласна :), хотя и у аудитов есть свое место в истории
Также мы умеем работать в команде заказчика, в этом случае производственный процесс тестировщика совсем не отличается от работы штатного сотрудника, отличается зона ответственности
У меня не получилось рассмотреть за текстом процессов — не ясны контрольные точки и коммуникации на каждом этапе. А это значит, непонятно
— какие условия нужно было выстроить, чтобы все перечисленное работало, как положено. К примеру, не при всяких условиях можно узнать, что хочет заказчик и не в любой момент выяснить из каких компонентов состоит продукт.
— как именно вы понимаете, сделаны ли эти работы хорошо. Как сами тестировщики это понимают?
Или перечисленное скорее best practices отдела?
В деталях:
— Про требования. Мне кажется тут не хватает проверки на согласованность требований… с целями заказчика. Если проект живет дольше одного релиза, с архитектурой проекта, уже существующими в нем другими функциональностями, данными.
— Про риски. Есть такое убеждение, что риски могут быть не только регрессионными.
Для примера, вы разрабатываете новую функциональность, ммм… статус-кнопку, которая горит красным на ответ false от внешнего сервера и зеленым в случае true. Кнопка должна работать в режиме реального времени. Какие риски? Приложение может заспамить, а в худшем случае положить внешний сервер. Надо анализировать. Допустим риск оправдан. Очевидное решение — нужно кэшировать показатель кнопки, или реализовать очереди. Но тогда кнопка перестает работать в режиме реального времени — тоже риск, да такой, что надо обсуждать с заказчиком.
Другой пример, вы разрабатываете какую-то внутреннюю механику, положим выгрузчик. На каждом этапе, он может не обработать данные, не выгрузить их, не суметь сохранить в БД. В чем риск? Все это нельзя будет достоверно проверить, если не будет соответствующих ручек и логов. Это уже дополнительная активность, чтобы в тестирование передали тестопригодный продукт. Ничто из перечисленного не является регрессией, но вроде является работой с рисками.
Довольно платное решение, не каждому по карману, но действительно удобное — подробнее чек-листов и тем более чит-листов, легковеснее тест-кейсов, чтобы использовать в быстрой разработке, интегрированное с таскменеджером, да и прогоны можно прикрутить при желании, причем бесплатно.
Юридически нельзя, что за закон? Как можно навредить абоненту (даже потенциально), узнав его ФИО через телефон?
Или обсуждается нравственный аспект. Т.е. навредить нельзя, просто нехорошо это. К слову про нравственный аспект, не так давно была возмущена сайтом поиска ФИО по телефону. Возмутило то, что писк выдает список личных социальных аккаунтов, номер телефона в которых заведен, НО скрыт для всех. Тем не менее, сайт, как видите, жив здоров.
— само собой интересен инструмент. Что за инструмент, возможен ли совместный доступ, как помечаются приоритеты кейсов, можно ли фильтровать кейсы по типам, например, для прогона регрессии или части сценариев?
— как Вы тестируете, только черным ящиком или серым тоже. Если и серым, то где фиксируете описание и связи компонент, относящиеся ко все фиче, а не отдельным use case
— используете ли систему управления тестами. Если да, то какую — интересно, как Вы помечаете прогоны тестов в древовидной структуре.
— и наконец, какой у Вас жизненный цикл разработки продуктов, в которых используется древовидная документация. Сколько времени длится релиз, какую часть из него занимает тестирование
все это необходимо для понимания, насколько Ваша практика применима
С содержанием согласна на 100%, и удержание и возвращение окупается, проверено опытом. Само собой оба решения надо принимать осмысленно. И отдельное спасибо за предыдущую статью, я ее помню, потому что нашла в тексте поддержку своих решений, которые на то время выглядели адиозно внутри компании.
Ее тоже публиковали Вы, parallels?
И все таки, она не про качество, а про процессы контроля и обеспечения качества. Попробую объяснить разницу
метрики сами по себе не определяются, их должен кто-то определить. Кто? Допустим вы QA и взяли на себя эту задачу. Как это сделать, чтобы не строить башню из слоновой кости и не занизить планку? Структурировать эту задачу и определить для каждого пункта границы между «качественно» и «некачетсвенно». Как? Попыталась описать в своей статье.
А процессы… Они же не перенимаются по шаблону, их выстраивают на основе многих условий, первые из которых Ваш потребитель и Ваш продукт. Тему процессов попробую раскрыть в следующей статье.
в соответствии со статьей от центра сертификации и лицензирования прорыв заводов Toyota был назван Японским чудом и случилось оно на основе трудов Деминга.
в соответствии со статьей от ассоциации Деминга император Хирохито вручил ученому «Орден священного сокровища второй степени» в 1960г. Полагаю этот год можно считать официальным признанием его работы.
Итак, с годом, вы правы, я борщенула. Сбил с толку год публикации книги, нужно было проверить.
В статье я хочу рассказать не о Деминге, хотя не скрою, его книга «Выход из кризиса. Новая парадигма управления людьми, системами и процессами», сильно утвердила лично мои взгляды. Я хочу сказать, что «качество» начинается с определения своего потребителя и понимания, что именно вы ему даете и каким образом. Поставщика, что хотите от него получать, в каком виде.
Я отвечаю за тестирование, поэтому пример про тестирование. Что производят ручные тестировщики? На низком уровне, для внутренних потребителей они не производят ничего, кроме отчетов (о дефектах, о состоянии релиза, о рисках). Очевидно, эти отчеты, должны быть понятными, достоверными и своевременными. Для кого? Для разработчиков, руководителей проекта, саппорта. А если нет? В лучшем случае они будут приходить за уточнением и тем самым тратить время (и ваше и свое), которое могли бы не тратить. В худшем принимать неправильные решения, которые негативно повлияют на конечно потребителя.
Конечному потребителю нужен хороший продукт. Основная сложность в том, чтобы понять, что именно он идентифицирует, как «хороший». Декомпозировать такую крупную задачу мне помог стандарт ISO.
ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.