Суммарный вывод не увидел :( Фактически ставили четкую цель. По результатам замеров получили разрозненные (по агрегатам) результаты, как это поможет сделать выбор? В сухом итоге: Здесь А2 круче, Здесь А3 такой же, здесь VPS ничего… Наверное не хватает, что — то типа, но для нашего приложения важнее Проц и Память, поэтому Выбираем А2, но делаем себе отметку, что если будет провал там-то, то это нормально и надо искать другое решение… Возможно не понял посыл статьи.
Ну собственно да! О том и речь, что это нужно НАМ, чтобы лучше видеть стек и прогресс работ и корректировать собственные действия. Я в своей практике это называю «стабилизация» :) Ну плюс можно давать пищу химере :) Если она просит «цыфирь».
Наташа, спасибо! Поправьте меня, если я ошибаюсь, посыл следующий:
1. Мы работаем в тех условиях, что есть, т.е. в реальном мире.
2. Для прозрачности и поддержания процесса реализации в актуальном состоянии нам приходится модифицировать внутренние процессы тестирования таким образом, чтобы не особо задеть внешние процессы реализации (аналитика, разработка, менеджмент).
3. Мы структурируем информацию о прямых требованиях, каталогизируем ее и генерализуем (собираем в некоторые категории/направления/группы).
4. Обеспечиваем стабильное покрытие каждого «каталога» требований проверками необходимыми и достаточными для анализа этих проверок (соответствует/не соответствует, работает/не работает).
5. Живем с этим и поддерживаем в актуальном состоянии.
Т.е. стандартный подход к работе с требованиями в тестировании, хоть TDD хоть ad hoc…
Не совсем понимаю, как это противоречит точке зрения powerman… Как бы не были поставлены процессы, все равно рано или поздно объем проверок и требований превысит память выполняющей проверки команды и потребуется либо заново генерировать и отбирать ТС либо условно принимать, что то что не меняли — работает.
В сущности наверное стоит озаглавить не как оценить покрытие, а как его стабилизировать согласно требованиям. Ведь мы знаем, что оценка покрытия — это то, что нужно ПМу для собственного успокоения, т.к. адекватность этой оценки может понимать только тестировщик.
В целом хорошая статья с правильными практиками, обязательно читаю нечто подобное в каждой организации, куда прихожу ТМ работать и для подчиненных и для коллег по реализации. Теперь смогу ссылку давать :)
Еще раз спасибо, Наташа.
Эффективность — отношение затрат к полученному результату. В случае с разработкой ПО — получение максимально ожидаемого и предсказуемого результат с наименьшими затратами — высокая эффективность. В случае, который я привел, как пример, «без бюрократии» затраты во много раз превысят затраты «с бюрократией», соответственно эффективность процесса будет ниже в разы. Но про эффективность как таковую я не писал, я просто привел пример, почему методологии/методики/принципы и т.п. стоит применять и подчиняться правилам. Когда все идет как должно идти пользу методологии вы не увидите, она будет казаться вам чем то лишним и ненужным, а вот когда случится какая-нибудь *опа… Снизить риски и потери как компании так и сотрудников (в том числе и имиджевые) может только грамотно настроенная и соблюдаемая методология производства… А *опа случится обязательно рано или поздно… «Просто писать код» — это круто, но не надо тогда удивляться, когда однажды вместо зп получите кукиш, просто потому что сочетание различных обстоятельств привело к тому, что контора не получила доход, а вы (или ваше начальство и коллеги) никак не поучаствовали в том, чтобы хотя бы часть из этих обстоятельств отработать хотя бы методологией…
Хмм, а потом вы заболеете, умрете, уйдете в другой проект… то что вы «наговорили» с заказчиком уйдет вместе с вами… А оставшиеся, через полтора месяца, будут ломать голову, как должен был работать вот именно тот кусок кода, который вы тогда написали, и работает ли он правильно сейчас… В конечном итоге — переписанный за вами функционал, который возможно и правильно работал и его потом еще раз перепишут, протестируют, интегрируют… потратят 100500 часов, вместо одного-двух часов «бюрократии»… В конечном итоге методология — инструмент не только разработки, но и общения и сохранения знаний о проекте. При нормальных или близких к нормальным условиях.
Вот сценарий: движется автомобиль по горной узкой дороге.
1. Формируем ложное препятствие параллельно дорожному полотну, в плоскости дорожного плотна над пропастью (например слева).
2. Формируем ложную стену за метр перед капотом.
3. Система, если она не дура, понимает, что остановиться не успеет, справа отвесная скала, слева — ложная твердая поверхность (см. пункт 1.).
4. Машина сворачивает, т.к. там риск меньше, чем столкновение со стеной.
Profit: пассажиры мертвы (при падении с обрыва), техника покорежена или уничтожена (при падении с обрыва).
И это только один сценарий. А ведь можно просто мародерствовать на трассах, симулируя препятствия и т.д. и т.п. Поэтому уязвимость действительно серьезная.
Человек выйдет и указку в глотку светившему вобьет… возможно ногами. А здесь будет работать принцип безнаказанности, ведь пассажиры скорее всего даже не поймут сразу причину странного поведения автопилота.
В нескольких командах пробовал SCRUM… Где-то пришел — он уже был, где-то хотели, чтобы поставил… Собственно, что могу сказать…
1. Скрам должны ХОТЕТЬ все участники команды. Иначе все это превращается в обычный цирк, только вместо менеджера несколько скрам активистов.
2. Команда должна ЗНАТЬ о своей заинтересованности в выпуске продукта. Знает она это от руководителя (функционального или проектного), который так же решает проблемы исполнителей с зп/отпуском/мат. обеспечением и прочим… А это значит, что его (руководителя) видение всегда будет влиять на варианты решения задач сильнее, чем обсуждение команды.
3. Кроссфункциональность команды это прекрасно, пока тестирование не пишет требования, аналитики не пишут код, а программисты не проводят ручное регрессионное тестирование… Понимать, чем занимаются другие и выполнять задачи других ролей (что проповедует Скрам) — все же разные вещи…
4…
В общем можно много говорить на тему скрама… в принципе, как идея — вещь прекрасная, но всегда ВСЕГДА требует серьезных «допилов» под конкретную команду и проект (в принципе и методология -то «гибкая»), к сожалению, в нынешних реалиях России большинство берет «труевый» скрам, ничего не обдумывая и не меняя, начинает его использовать, потому что он — модный и крутой, а так же дает иллюзию контроля процесса. Причины разочарования осознают не все и склонны обвинять других участников процесса в некомпетентности, чем признать, что процесс просто требует доработки и отступления от некоторых правил и принципов скрама.
Какой посыл от комментария?
Можно использовать любую методологию, ведь это всего лишь инструмент производства, ДУМАТЬ и РЕШАТЬ придется все равно… Ну и надо быть готовым к тому, что когда ваша команда достигнет хорошей эффективности это уже будет не совсем та или совсем не та методология, которую вы пытались внедрить изначально.
Думайте, решайте, пробуйте и верьте фактам, а не тому, что похоже на факты (см. предыдущий комментарий...ServPonomarev`а).
ИМХО В любом случае автоматизированное тестирование — лишь инструмент, который используется или не используется в рамках процесса тестирования. Контекст данной статьи звучит для меня приблизительно как: «Скоро все откажутся от лопат в пользу экскаваторов...» Полностью заменить ручное тестирование на что-то возможно лишь в полностью автоматических системах или системах, где роль «пользователь» почти и не нужна. Да и экономический и технический профит должен быть колоссальный от автоматизации, чтобы она «выстрелила». Хотя бы потому что ее надо:
1. Создать.
2. Описать.
3. Регламентировать.
4. Поддерживать.
5. Обновлять.
6. Анализировать результаты ее работы.
Собственно я всегда за, когда количество ручного труда, переложенного на плечи автоматизации, растет, но не питаю иллюзий, что когда-нибудь смогу заниматься только автоматизацией… совсем без ручного тестирования. :)
Кратко: сценарий проверяет набор идей и содержит много ожидаемых результатов, каждый из которых критичен для реализации одного завершенного БП пользователя (например ЖЦ учетной записи пользователя).
Тестовый случай — проверяет только одну идею и содержит один ожидаемый результат, т.к. проверяет только одну функцию продукта (например работу валидатора на поле в форме).
По сути — верно. Только вот и статья-то написана о том, чего именно мне и нужно. А по факту: тот же ISQTB — сам себе противоречит в терминах и является, по сути своей, просто компиляцией всех терминов и их определений, сводкой методологий. Я же пытаюсь предложить то, что построено самим на основе опыта работы в данной профессии и применимо к 95% проектов, как по тестированию ПО, так и по тестированию любой предметной области, в том числе бизнес- процессов. Для меня в итоге важно, чтобы человек понимал куда пришел — для этого беседа и вопросы. Важно, чтобы я понимал насколько мы с человеком будем говорить на одном языке и одними терминами. Как-то так.
Разница только в том, что я практикую :)
И должность руководителя получил не за то, что сын директора. Вообще не родственник (ни на прошлом месте, ни на этом). Более того руководителя первый раз увидел на собеседовании. И он (мой непосредственный руководитель) вырос из разработчиков и неплохих, так как его софтом для внутреннего назначения вовсю пользуются до сих пор. А начинал в одиночку. Более того, можно много высказываться в общем смысле, но мой отдел из 4 человек (включая меня) справляется с 9 проектами разного направления, без задержек сроков и срыва метрик по уровням качества. В то время, как многие компании вынуждены нанимать по 7-9 человек на один такой проект. Так что позволю все таки себе заметить, что ЧСВ у меня обосновано. А людей я на собеседованиях не унижаю, а пытаюсь вытянуть до нужного уровня. И даже те, кого я не взял к себе работать, в конечном итоге говорят: «спасибо».
Доброго дня!
Возможно Вы невнимательно читали статью. Я поясню:
• Человек может волноваться, особенно в условиях ограниченного времени.
Время никто не ограничивает, более того полтора часа — это лично моя метрика. Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился. Хотя знал о том, что пойдет на собеседование не с HR, а с будущим руководителем. И у него есть зп ожидания, которые надо оправдать.
• Человек может плохо владеть речью, плохо излагать свои мысли. Некоторые хорошо делают, но плохо объясняют.
Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование. Я денег за обучение юниоров, опытных и прочих не беру. Я набираю людей, которые с первого дня работы начинают получать зарплату, в том числе и юниоры — среднюю по СПб, а то и выше.
• Области его и ваших знаний могут плохо пересекаться.
Это абсолютно точно так, но я и не требую от него четкого знания буква в букву. Тоже писал об этом. Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера. Поэтому я жду, что они проведут хотя бы минимальную подготовку по той области, в которой собираются работать.
• Вы одни и те же вопросы постоянно спрашиваете, что означает, что вы их хорошо разобрали и хорошо помните данную часть предметной области, но это не значит, что другие сделали акцент на этом.
Хм, по моему все вопросы относятся к весьма и весьма базовым по тестированию. Я не спрашиваю устройство сетей, особенности картографических проекций, знания API google карт или еще какую-то специфику… Я спрашиваю, а чем Вы, собственно, пришли сюда заниматься?
• Как давно человек работал с технологией, о которой вы его спрашиваете. Может он когда-то был в ней экспертом, но забыл ее, так как не приходилось ей пользоваться последние несколько лет.
Что мешало освежить свои знания и навыки перед собеседованием?
Вообще, я благодарен за Ваш ответ, он действительно конструктивен и вопросы, которые Вы в нем поднимаете — бич собеседований в IT. Отвечая на Ваше утверждение: я каждые полгода обязательно хожу на пару — тройку собеседований — это хорошо дает понять в какую сторону развивается рынок труда, что интересует работодателей. И стараюсь избегать общих ошибок, которые вижу на этих собеседованиях. И форма собеседования именно поэтому и построена в форме беседы, а не экзамена. Именно поэтому я стараюсь объяснять свою точку зрения и слежу за «откликом» на нее. А самое главное — я не считаю, что те, кто не прошел собеседование — плохие или ничего не знают, я считаю, что мы не сработаемся, вот и все. «Нет плохих специалистов, есть не на своем месте» (с) Вот и я стараюсь избежать людей не на своем месте, так как это принесет проблемы не только мне, но и им самим.
Где? Где тот злодей, что хочет придумывать требования? Выявлять! Батенька, и только выявлять. Грань действительно очень тонкая, но ведь в этом и заключается квалификация — выявить существенное и отбросить несущественное. Хороший пример: есть движок карт ArcGis. Там по умолчанию настройка на работу с роликом мыши «реверсивная» (от себя — отдаление от подложки, на себя — приближение). Если Вы откроете публичные ресурсы с картами (Yandex, Google и пр.), то увидите, что «средний» пользователь в РФ «привык» к обратному. Ни одно ТЗ (кроме написанного военным в пятом поколении) не будет содержать прямого требования о направлении вращения ролика мыши и соотносить его с изменением масштаба. Что получается? Требование косвенное. Ухудшит отношение пользователей к приложению на этом движке, если вовремя не выявить и не исправить? Да. получается, что никто ничего не «придумал», а профит хороший.
Ну и есть такие люди, которые говорят — «пользователь привыкнет»… Думаю, что не надо объяснять почему это неправильно.
Если перефразировать «проект» -> «задача» (task), то вопрос собственно каждодневный:
приходит две задачи по одному проекту — реализованный функционал передали в тестирование. Приоритеты, критичность, сроки и прочая одинаковые, пометок ПМ в комментариях о срочности нет. Какую делать?
1. Спросить у тест лида.
2. Я сам тест лид. Спросить у ПМ.
3. Я тест лид. ПМу фиолетово. Любую.
4. Я тест лид. ПМу не фиолетово, он обозначает. Вставить ему «люлей» за то, что тратит чужое время.
5. Я тест лид. Решаю сам, ибо никаких отметок о срочности нет.
6. Я тест лид. Отдаю команде тестирования в разработку обе одновременно, разным людям.
Я так думаю, что холивары можно прекратить?
1. Мы работаем в тех условиях, что есть, т.е. в реальном мире.
2. Для прозрачности и поддержания процесса реализации в актуальном состоянии нам приходится модифицировать внутренние процессы тестирования таким образом, чтобы не особо задеть внешние процессы реализации (аналитика, разработка, менеджмент).
3. Мы структурируем информацию о прямых требованиях, каталогизируем ее и генерализуем (собираем в некоторые категории/направления/группы).
4. Обеспечиваем стабильное покрытие каждого «каталога» требований проверками необходимыми и достаточными для анализа этих проверок (соответствует/не соответствует, работает/не работает).
5. Живем с этим и поддерживаем в актуальном состоянии.
Т.е. стандартный подход к работе с требованиями в тестировании, хоть TDD хоть ad hoc…
Не совсем понимаю, как это противоречит точке зрения powerman… Как бы не были поставлены процессы, все равно рано или поздно объем проверок и требований превысит память выполняющей проверки команды и потребуется либо заново генерировать и отбирать ТС либо условно принимать, что то что не меняли — работает.
В сущности наверное стоит озаглавить не как оценить покрытие, а как его стабилизировать согласно требованиям. Ведь мы знаем, что оценка покрытия — это то, что нужно ПМу для собственного успокоения, т.к. адекватность этой оценки может понимать только тестировщик.
В целом хорошая статья с правильными практиками, обязательно читаю нечто подобное в каждой организации, куда прихожу ТМ работать и для подчиненных и для коллег по реализации. Теперь смогу ссылку давать :)
Еще раз спасибо, Наташа.
1. Формируем ложное препятствие параллельно дорожному полотну, в плоскости дорожного плотна над пропастью (например слева).
2. Формируем ложную стену за метр перед капотом.
3. Система, если она не дура, понимает, что остановиться не успеет, справа отвесная скала, слева — ложная твердая поверхность (см. пункт 1.).
4. Машина сворачивает, т.к. там риск меньше, чем столкновение со стеной.
Profit: пассажиры мертвы (при падении с обрыва), техника покорежена или уничтожена (при падении с обрыва).
И это только один сценарий. А ведь можно просто мародерствовать на трассах, симулируя препятствия и т.д. и т.п. Поэтому уязвимость действительно серьезная.
1. Скрам должны ХОТЕТЬ все участники команды. Иначе все это превращается в обычный цирк, только вместо менеджера несколько скрам активистов.
2. Команда должна ЗНАТЬ о своей заинтересованности в выпуске продукта. Знает она это от руководителя (функционального или проектного), который так же решает проблемы исполнителей с зп/отпуском/мат. обеспечением и прочим… А это значит, что его (руководителя) видение всегда будет влиять на варианты решения задач сильнее, чем обсуждение команды.
3. Кроссфункциональность команды это прекрасно, пока тестирование не пишет требования, аналитики не пишут код, а программисты не проводят ручное регрессионное тестирование… Понимать, чем занимаются другие и выполнять задачи других ролей (что проповедует Скрам) — все же разные вещи…
4…
В общем можно много говорить на тему скрама… в принципе, как идея — вещь прекрасная, но всегда ВСЕГДА требует серьезных «допилов» под конкретную команду и проект (в принципе и методология -то «гибкая»), к сожалению, в нынешних реалиях России большинство берет «труевый» скрам, ничего не обдумывая и не меняя, начинает его использовать, потому что он — модный и крутой, а так же дает иллюзию контроля процесса. Причины разочарования осознают не все и склонны обвинять других участников процесса в некомпетентности, чем признать, что процесс просто требует доработки и отступления от некоторых правил и принципов скрама.
Какой посыл от комментария?
Можно использовать любую методологию, ведь это всего лишь инструмент производства, ДУМАТЬ и РЕШАТЬ придется все равно… Ну и надо быть готовым к тому, что когда ваша команда достигнет хорошей эффективности это уже будет не совсем та или совсем не та методология, которую вы пытались внедрить изначально.
Думайте, решайте, пробуйте и верьте фактам, а не тому, что похоже на факты (см. предыдущий комментарий...ServPonomarev`а).
1. Создать.
2. Описать.
3. Регламентировать.
4. Поддерживать.
5. Обновлять.
6. Анализировать результаты ее работы.
Собственно я всегда за, когда количество ручного труда, переложенного на плечи автоматизации, растет, но не питаю иллюзий, что когда-нибудь смогу заниматься только автоматизацией… совсем без ручного тестирования. :)
Тестовый случай — проверяет только одну идею и содержит один ожидаемый результат, т.к. проверяет только одну функцию продукта (например работу валидатора на поле в форме).
И должность руководителя получил не за то, что сын директора. Вообще не родственник (ни на прошлом месте, ни на этом). Более того руководителя первый раз увидел на собеседовании. И он (мой непосредственный руководитель) вырос из разработчиков и неплохих, так как его софтом для внутреннего назначения вовсю пользуются до сих пор. А начинал в одиночку. Более того, можно много высказываться в общем смысле, но мой отдел из 4 человек (включая меня) справляется с 9 проектами разного направления, без задержек сроков и срыва метрик по уровням качества. В то время, как многие компании вынуждены нанимать по 7-9 человек на один такой проект. Так что позволю все таки себе заметить, что ЧСВ у меня обосновано. А людей я на собеседованиях не унижаю, а пытаюсь вытянуть до нужного уровня. И даже те, кого я не взял к себе работать, в конечном итоге говорят: «спасибо».
Возможно Вы невнимательно читали статью. Я поясню:
Время никто не ограничивает, более того полтора часа — это лично моя метрика. Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился. Хотя знал о том, что пойдет на собеседование не с HR, а с будущим руководителем. И у него есть зп ожидания, которые надо оправдать.
Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование. Я денег за обучение юниоров, опытных и прочих не беру. Я набираю людей, которые с первого дня работы начинают получать зарплату, в том числе и юниоры — среднюю по СПб, а то и выше.
Это абсолютно точно так, но я и не требую от него четкого знания буква в букву. Тоже писал об этом. Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера. Поэтому я жду, что они проведут хотя бы минимальную подготовку по той области, в которой собираются работать.
Хм, по моему все вопросы относятся к весьма и весьма базовым по тестированию. Я не спрашиваю устройство сетей, особенности картографических проекций, знания API google карт или еще какую-то специфику… Я спрашиваю, а чем Вы, собственно, пришли сюда заниматься?
Что мешало освежить свои знания и навыки перед собеседованием?
Вообще, я благодарен за Ваш ответ, он действительно конструктивен и вопросы, которые Вы в нем поднимаете — бич собеседований в IT. Отвечая на Ваше утверждение: я каждые полгода обязательно хожу на пару — тройку собеседований — это хорошо дает понять в какую сторону развивается рынок труда, что интересует работодателей. И стараюсь избегать общих ошибок, которые вижу на этих собеседованиях. И форма собеседования именно поэтому и построена в форме беседы, а не экзамена. Именно поэтому я стараюсь объяснять свою точку зрения и слежу за «откликом» на нее. А самое главное — я не считаю, что те, кто не прошел собеседование — плохие или ничего не знают, я считаю, что мы не сработаемся, вот и все. «Нет плохих специалистов, есть не на своем месте» (с) Вот и я стараюсь избежать людей не на своем месте, так как это принесет проблемы не только мне, но и им самим.
Ну и есть такие люди, которые говорят — «пользователь привыкнет»… Думаю, что не надо объяснять почему это неправильно.
приходит две задачи по одному проекту — реализованный функционал передали в тестирование. Приоритеты, критичность, сроки и прочая одинаковые, пометок ПМ в комментариях о срочности нет. Какую делать?
1. Спросить у тест лида.
2. Я сам тест лид. Спросить у ПМ.
3. Я тест лид. ПМу фиолетово. Любую.
4. Я тест лид. ПМу не фиолетово, он обозначает. Вставить ему «люлей» за то, что тратит чужое время.
5. Я тест лид. Решаю сам, ибо никаких отметок о срочности нет.
6. Я тест лид. Отдаю команде тестирования в разработку обе одновременно, разным людям.
Я так думаю, что холивары можно прекратить?