Все же зависит от предметной области :)
Наша тестовая инфраструктура уже в амазоне и там да, свою нюансы и спецэффекты. В то же время проекты команды напрямую связаны с шаред хостингом, в котором проблемы 2005 года все ещё могут быть актуальны для конечных пользователей и которые мы, в том числе, решаем в своих проектах за счет автоматизации взаимодействия между пользователем и системой, где расположен хостинг.
В данном случае считаю, что конкретный пример не имеет значения, намеренно избегал любого контекста. Пример из области настройки системы — показался мне наиболее общим для широкой общественности, который удобно будет разложить на простые и понятные этапы.
Но идея интересная, можно на досуге подумать, какой бы показательный пример можно было выбрать для оценки знаний в области инфраструктуры амазона.
Отличный пример, спасибо!
Полностью согласен с таким подходом, особенно с фазой рассказа о проекте. Почему-то собеседование принято рассмаривать, как что-то одностороннее — подходит кандидат или нет. Не принимается во внимание то, что кандидат точно так же должен оценить проект и людей, с которыми предстоит работать.
Важность оценки софт скилов тем выше, чем выше предполагаемая ответственность. Например, кандидат на лидерскую позицию может отлично пройти тех собес, но по результатам HR интервью могут появиться вопросы, подходит ли он на должность, например из-за того, что позиция предполагает пипл менеджмент, активное взаимодействие с командой, развитие, ресурсное состояние и вот это все, а его личный запрос ближе к работе скилового инженера — самостоятельно решать сложные технические задачи, а управление командой постольку поскольку.
Мне важно, например, понимать, будет человек готов работать автономно или ему комфортнее, когда ставят четкие задачи «от забор и до обеда». Это не значит, что что-то из этого — плохо. Вопрос в том, какая в данный момент открыта позиция, какой круг задач придется решать новому сотруднику.
Не могу говорить за всю компанию. Каждая команда вольна строить свою процедуру найма и собседований. У меня ярких неудач небыло, чтобы говорить о том, что раньше было так, а теперь стало совсем по-другому. В целом, на уровне компании, на софт скилы стали обращать сильно больше внимания именно из-за нескольких промахов при оценке личностых качеств ещё на этапе найма. Фатального ничего не случилось, просто оказалось, что от кандидата были одно ожидания, а у самого кандидата они были прямо противоположны.
Не могу назвать описанный подход именно креативным, для меня это всего лишь структура, каким образом выстраивать диалог. Так или иначе подобные вопросы задаются, только делается это неосознанно. Алгоритм позволяет упорядочить это и получать больший выхлоп при тех же условиях :)
У меня есть предварительное задание, которое кандидату высылается до тех собеса. И там да, есть возможность потрогать руками. Суть задания не починить что-то, а именно поисследовать и составить план тестирования (наша специфика). Но тем не менее пример довольно показательный, т.к. можно получить представление о том, как человек привык работать, какими навыками и знаниями обладает. Ну и плюсом кандидат может примерить на себя то, чем ему в действительности предстоит заниматься.
Очень интересное мнение! ИМХО, исповедь преследует немного другие цели. На собеседовании нет желания именно завалить кандидата, цель наоборот — раскрыть человека, что невозможно сделать, задавая закрытые вопросы. С этим справится и тех. опросник. Установив комфортное и доверительное общение мы разговариваем с человеком, а не с набором технических знаний. Для меня это важно, т.к. с командой в первую очередь будет взаимодействовать человек, а не знания операционных систем, умение тестировать или что-либо подобное. У активного, обучаемого и болеющего за общее дело человека, но обладающего недостаточными техническими навыками, больше шансов оказаться в команде, чем у самого скилового специалиста, но который не сможет выстроить общение. Наша специфика такова, что командная работа крайне важна. И если подтянуть человека в предметной области я могу, то научить его взаимодействовать с другими или быть нетоксичным — выходит за рамки моих компетенций.
Если в данном контексте исповедь — это разговор о косяках из предыдущего опыта, то даже из косяков и ошибок можно извлечь пользу и сделать правильные выводы. в этом смысле негативные кейсы не менее важны, чем позитивные.
Порядок собеседований- дело вкуса и конкретной специфики. Каждая команда вольна сама выбирать процедуру, поэтому могу говорить только за свою. В нашем случае до технического собеса есть ещё и «домашнее задание». В итоге кандидатов не так много, поэтому сначала идет тех собес, плюс я смотрю интересующие меня софт скилы, что за человек и как он впишется в команду. После этого я могу обратить внимание HRов в дополнение к тому, что оценивают они, глубже посмотреть моменты, которые могут меня смущать и моих компетенций недостаточно, чтобы оценить их самостоятельно.
Значит всего 2 в 4 степени = 16 комбинаций этих условий. Вы будете писать сценарии на все 16? А там ведь еще геолокация, язык, cookies. Уж про то, что нужно тестировать как минимум на двух-трех десктопных веб-движках плюс на паре мобильных.
Все эти альтернативные сценарии можно расписывать отдельными кейсами. А можно комбинировать техники. Диаграмма состояний-переходов, например, позволяет наглядно увидеть возможности обратных переходов и не забыть про них. Разные языки интерфейса, операционных систем и браузеров — по сути отдельные конфигурации, на которых тоже нужно проходить полный тест план. Чтобы не потонуть под количеством тест кейсов от их взрывного роста, применяется комбинаторика, позволяющая получить приемлемое покрытие для различных конфигураций и окружений.
И весь этот «аналитический подход» может вылиться в разнообразное тестирование идеального пути.
Позвольте не согласиться. По моим наблюдениям как раз тестирование по наитию или «опытом и здравым смыслом» — это тестирование идеального пути с кучей допущений и пробелов. Аналитический подход и применение различных техник тест анализа позволяет существенным образом расширить и углубить покрытие. Итоговый результат от аналитики все-таки зависит от совести и опыта того, кто этой аналитикой занимается :)
Emelian
Очень интересный и развернутый комментарий! Т.к. я в контексте самой техники, того, как она применяется и какую пользу наносит, хотел бы поподробнее пообщаться с вами и уточнить, чего нехватило для понимания применимости техники в вашей ситуации и с точки зрения вашего опыта.
Даже в школе учат считать яблоками и апельсинами. Т.е., на конкретных примерах. Поэтому, при всем уважении к изложенной «технике по работе с требованиями» совершенно непонятно, как она реально работает.
Можете уточнить, какого именно примера оказалось недостаточно? В статье рассматривается приложение для сервиса заказа и доставки еды. Что стоило бы добавить, чтобы более полно продемонстрировать работу изложенной техники?
Если мы хотим расширить возможности мастера, сделать что-то типа универсального генератора интерфейсов для бизнес приложений, то, что нам по этому поводу может сказать наука «по требованиям» и «фичам»?
Вы сами дали ответ на свой вопрос: «Другими словами, мы садимся и разрабатываем алгоритм нашего супер мастера.» — техника помогает в разработке алгоритмов того, как работает проектируемая фича, взглянуть на неё с точки зрения взаимодействия участвующих систем. Позволяет структурировать и визуализировать эти алгоритмы, поможет из неоформившихся пожеланий «сделать что-то типа универсального генератора интерфейсов» вычленить сценарии того, как планируемая фича должна себя вести в разных ситуациях. Какие будут входные и выходные данные. Например, на основании чего мы планируем генерировать универсальный имнтерфейс, будет ли это всегда стандартный набор вроде: одно поле ввода и две кнопки — «Ок» и «Отмена», или будет возможность кастомизации типа элементов и их количества на этапе до генерации шаблона? Ответ на этот вопрос дает нам две разные задачи с соответствующими трудозатратами на их реализацию. Подобные вопросы, сценарии и функциональные возможности стоит уточнять до того, как задача, собственно, попадает в разработку. Таким образом мы говорим не о тестировании готового приложения, а об обеспечении качества посредством тестирования требований на раннем этапе работы над задачей. При этом «качество» нужно понимать не как исключительно функциональую часть приложения, что кнопки нажимаются и все работает без неожиданных ошибок, а, в том числе, и качество с точки зрения UX для конечного пользователя — корректную обработку едж кейсов, отсутствие тупиковых сценариев, в конце концов убедиться, что проектируемая функциональность будет решать проблему заказчика.
Мы вот программируем свои программы без тестирования и живем.
Прелесть техники в том, что её может использовать не только человек с выделенной ролью тестировщика. Инструмент универсальный и может использоваться РМом, аналитиком, QA специалистом, в том числе и разработчиком. Грубо говоря, тем, на кого в данный момент ложится роль уточнения и согласования требований к проектируемой функциональности. По сути это универсальный язык для описания требований, понятный для всех, кто работает над задачей. При этом не важно, есть на проекте тестирование или нет. По большому счету даже масштаб проекта не имеет значения.
Наша тестовая инфраструктура уже в амазоне и там да, свою нюансы и спецэффекты. В то же время проекты команды напрямую связаны с шаред хостингом, в котором проблемы 2005 года все ещё могут быть актуальны для конечных пользователей и которые мы, в том числе, решаем в своих проектах за счет автоматизации взаимодействия между пользователем и системой, где расположен хостинг.
В данном случае считаю, что конкретный пример не имеет значения, намеренно избегал любого контекста. Пример из области настройки системы — показался мне наиболее общим для широкой общественности, который удобно будет разложить на простые и понятные этапы.
Но идея интересная, можно на досуге подумать, какой бы показательный пример можно было выбрать для оценки знаний в области инфраструктуры амазона.
Полностью согласен с таким подходом, особенно с фазой рассказа о проекте. Почему-то собеседование принято рассмаривать, как что-то одностороннее — подходит кандидат или нет. Не принимается во внимание то, что кандидат точно так же должен оценить проект и людей, с которыми предстоит работать.
Мне важно, например, понимать, будет человек готов работать автономно или ему комфортнее, когда ставят четкие задачи «от забор и до обеда». Это не значит, что что-то из этого — плохо. Вопрос в том, какая в данный момент открыта позиция, какой круг задач придется решать новому сотруднику.
Не могу назвать описанный подход именно креативным, для меня это всего лишь структура, каким образом выстраивать диалог. Так или иначе подобные вопросы задаются, только делается это неосознанно. Алгоритм позволяет упорядочить это и получать больший выхлоп при тех же условиях :)
Если в данном контексте исповедь — это разговор о косяках из предыдущего опыта, то даже из косяков и ошибок можно извлечь пользу и сделать правильные выводы. в этом смысле негативные кейсы не менее важны, чем позитивные.
Все эти альтернативные сценарии можно расписывать отдельными кейсами. А можно комбинировать техники. Диаграмма состояний-переходов, например, позволяет наглядно увидеть возможности обратных переходов и не забыть про них. Разные языки интерфейса, операционных систем и браузеров — по сути отдельные конфигурации, на которых тоже нужно проходить полный тест план. Чтобы не потонуть под количеством тест кейсов от их взрывного роста, применяется комбинаторика, позволяющая получить приемлемое покрытие для различных конфигураций и окружений.
Позвольте не согласиться. По моим наблюдениям как раз тестирование по наитию или «опытом и здравым смыслом» — это тестирование идеального пути с кучей допущений и пробелов. Аналитический подход и применение различных техник тест анализа позволяет существенным образом расширить и углубить покрытие. Итоговый результат от аналитики все-таки зависит от совести и опыта того, кто этой аналитикой занимается :)
Очень интересный и развернутый комментарий! Т.к. я в контексте самой техники, того, как она применяется и какую пользу наносит, хотел бы поподробнее пообщаться с вами и уточнить, чего нехватило для понимания применимости техники в вашей ситуации и с точки зрения вашего опыта.
Можете уточнить, какого именно примера оказалось недостаточно? В статье рассматривается приложение для сервиса заказа и доставки еды. Что стоило бы добавить, чтобы более полно продемонстрировать работу изложенной техники?
Вы сами дали ответ на свой вопрос: «Другими словами, мы садимся и разрабатываем алгоритм нашего супер мастера.» — техника помогает в разработке алгоритмов того, как работает проектируемая фича, взглянуть на неё с точки зрения взаимодействия участвующих систем. Позволяет структурировать и визуализировать эти алгоритмы, поможет из неоформившихся пожеланий «сделать что-то типа универсального генератора интерфейсов» вычленить сценарии того, как планируемая фича должна себя вести в разных ситуациях. Какие будут входные и выходные данные. Например, на основании чего мы планируем генерировать универсальный имнтерфейс, будет ли это всегда стандартный набор вроде: одно поле ввода и две кнопки — «Ок» и «Отмена», или будет возможность кастомизации типа элементов и их количества на этапе до генерации шаблона? Ответ на этот вопрос дает нам две разные задачи с соответствующими трудозатратами на их реализацию. Подобные вопросы, сценарии и функциональные возможности стоит уточнять до того, как задача, собственно, попадает в разработку. Таким образом мы говорим не о тестировании готового приложения, а об обеспечении качества посредством тестирования требований на раннем этапе работы над задачей. При этом «качество» нужно понимать не как исключительно функциональую часть приложения, что кнопки нажимаются и все работает без неожиданных ошибок, а, в том числе, и качество с точки зрения UX для конечного пользователя — корректную обработку едж кейсов, отсутствие тупиковых сценариев, в конце концов убедиться, что проектируемая функциональность будет решать проблему заказчика.
Прелесть техники в том, что её может использовать не только человек с выделенной ролью тестировщика. Инструмент универсальный и может использоваться РМом, аналитиком, QA специалистом, в том числе и разработчиком. Грубо говоря, тем, на кого в данный момент ложится роль уточнения и согласования требований к проектируемой функциональности. По сути это универсальный язык для описания требований, понятный для всех, кто работает над задачей. При этом не важно, есть на проекте тестирование или нет. По большому счету даже масштаб проекта не имеет значения.