- - - - - - - -
Собеседование Тестировщика - как тестировать карандаш
- - - - - - - - -

Типичное задание на собеседовании тестировщика - запрос протестировать карандаш, кружку, лифт или любой другой предмет.

В этом видео автор рассказывает, как следует строить ответ на такие вопросы и приводит примеры типичных ошибок многих кандидатов.

https://www.youtube.com/watch?v=RCkXBY6W2XY&list=WL&index=10

https://www.youtube.com/watch?v=RCkXBY6W2XY

Вопрос №26

Q: Расскажите про основные недостатки Agile подхода к разработке ПО
A: С Agile легко потерять чувство равновесия. В разработке программного обеспечения нет волшебной пилюли или бесплатного сыра. Если вы хотите принять гибкие принципы, вы должны быть уверены, что менеджмент и команда понимают все правила. Также нужно признать, что требования заказчика могут быстро стать подводными камнями:

1. Меньше предсказуемости
Для некоторых программных продуктов разработчики не могут в полной мере количественно оценить требуемые усилия, особенно в начале жизненного цикла разработки крупных продуктов. Команды, не имеющие опыта гибкой разработки, боятся этих неизвестных. Этот страх приводит к разочарованию, плохим практикам и часто к плохим решениям. Более регламентированный каскадный процесс (Waterfall model) позволяет легко определить количество усилий, времени и стоимости поставки конечного продукта.

2. Больше времени и приверженности
Тестировщики, клиенты и разработчики должны постоянно взаимодействовать друг с другом. Потребуются многочисленные беседы лицом к лицу, так как они являются лучшей формой общения. Все участвующие в проекте люди должны тесно сотрудничать. Ежедневно клиенты должны быть доступны для оперативного тестирования и утверждения на каждом этапе, так чтобы разработчики смогли отметить его как выполненный, прежде чем перейти к следующей функции. Благодаря этому продукт лучше соответствует ожиданиям пользователей, но процесс является обременительным и отнимает много времени. Он требует больше времени и энергии всех участников.

3. Повышенные требования к клиентам
Принципы Agile требуют тесного сотрудничества и активного участия пользователя. Хотя это интересная и полезная система, она требует большего участия клиентов для успешного завершения проекта. Клиенты должны пройти обучение, чтобы помочь в разработке продукта. Любой недостаток участия клиента будет влиять на качество программного обеспечения и конечный успех.

4. Отсутствие необходимой документации
Поскольку требования к программному обеспечению уточняются как раз во время разработки, документация не слишком подробна. Это означает, что если к команде присоединятся новые члены, они не будут знать подробностей, некоторых особенностей или как они должны действовать. Это создает недоразумения и трудности.

5. Проект легко сбивается с пути
Этот метод не требует подробного планирования для начала работы и предполагает, что потребности заказчика постоянно меняются. Такие недостаточные исходные данные могут ограничить использование Agile. Затем, если обратная связь заказчика не ясна, разработчик может сфокусироваться на разработке в неправильном направлении. Кроме того, имеется опасность неконтролируемого расширения границ проекта, и постоянно меняющийся продукт становится бесконечным.
Подводя итог:

Да, у Agile есть свои подводные камни. Да, не факт, что методология сразу начнет работать на вас, а не против. Но поверьте, при грамотном подходе и полном

понимании сути и всех нюансов Agile методологии Вы получите действительно рабочую и эффективную схему выстраивания рабочего процесса в Вашей команде.

- - - - - - - - -
Полезные статьи. Часть 6.
- - - - - - - - -

1. Тестирование на основе поведенческих моделей. Введение: https://www.womentesters.com/behaviour-driven-testing-an-introduction/
2. Что такое переходное тестирование в тестировании программного обеспечения: https://tryqa.com/what-is-state-transition-testing-in-software-testing/
3. Хороший пользовательский интерфейс: https://cmsmagazine.ru/journal/items-186846/

Вопрос №27

Q: Что такое SCRUM?
A: SCRUM - одна из методологий гибкой разработки.
SCRUM состоит из:
1. Скрам Команд (Scrum Teams), внутри которых распределены соответствующие роли (roles),
2. Мероприятий (events),
3. Артефактов (artifacts),
4. Правил (rules)

Каждый компонент SCRUM имеет свое предназначение и является ключевым для его успеха и использования. В последующих постах рассмотрим каждый из компонентов подробнее.

Вопрос №28

Q: Расскажите про роли участников SCRUM команды.
A: SCRUM команда состоит из:
1. Владельца Продукта (Product Owner);
2. Команды Разработчиков (сюда же включаем тестировщиков) (Development Team);
3. Скрам Мастера (Scrum Master).

Скрам Команды являются самоуправляемыми и кроссфункциональными. Самоуправляемые команды сами выбирают, как наилучшим образом выполнить работу, и не ждут указаний от людей, не входящих в состав Команды. Кроссфункциональные команды имеют все необходимые навыки, чтобы выполнить работу и не зависеть от остальных, не являющихся частью их Команды. Командная модель Скрама создана для оптимизации гибкости, креативности и продуктивности.
Подробнее про составляющие команды:

1) Владелец Продукта
Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Он является единственным человеком в Команде, отвечающим за бэклог(он же Журнал Требований к Продукту или Product Backlog). Управление бэклогом включает в себя:
1. Четкое определение и упорядочивание элементов бэклога;
2. Ответственность за ценность работы, исполняемой Командой Разработчиков;
3. Обеспечение доступности, прозрачности и понятности бэклога, а также отображения тех требований, над которыми Скрам Команде предстоит работать в ближайшее время;
4. Ответственность за понимание Командой Разработчиков требований бэклога на надлежащем уровне.

Владелец Продукта может либо сам выполнять вышеперечисленные функции, либо предоставить их выполнение членам Команды Разработчиков. Однако, подотчетным считается именно Владелец Продукта. Владелец Продукта это только один человек, а не группа. Владелец Продукта может представлять интересы группы в бэклоге, но желающие изменить приоритетность требований бэклога должны в первую очередь убедить в этом Владельца Продукта. Для успешного выполнения Владельцем Продукта своих обязанностей все члены организации должны уважать его решение.

2) Команда Разработчиков
Команда Разработчиков состоит из профессионалов, выполняющих работу по разработке потенциально “готового” к выпуску Инкремента продукта в конце каждого Спринта. Инкремент создают только члены Команды Разработчиков. Команды Разработчиков являются структурированными и уполномоченными самим организовывать и управлять своей работой. Эта синергия усиливает продуктивность и эффективность работы Команды Разработчиков.
Командам Разработчиков присущи следующие характеристики:
1. Они самоуправляемы. Никто (и даже Скрам Мастер) не может указывать Команде, как правильно превращать Журнал Продукта в Инкременты работающей функциональности.
2. Команды Разработчиков кроссфункциональны, и обладают всеми навыками, необходимыми для разработки Инкремента продукта.
3. Скрам не признает никаких других должностей в Команде Разработчиков, кроме Разработчика, невзирая на вид работы, выполняемой человеком. У этого правила нет исключений.
4. Отдельные члены Команды Разработчиков могут владеть специализированны

ми знаниями в различных областях, однако ответственность лежит на всей Команде Разработчиков, подразумевающейся одним целым.
5. У Команды Разработчиков нет структурных подразделений, которые бы выполняли отдельные функции, как, к примеру, подразделение тестирования или бизнес-анализа.

3) Скрам Мастер
Скрам Мастер ответственен за то, чтобы Скрам был гарантированно понят всеми участниками и работал. Скрам Мастер достигает этого, следя за тем, чтобы все участники Команды придерживались теории, практик и правил Скрама. Скрам Мастер является слугой-лидером для Скрам Команды. Скрам Мастер также помогает людям, не входящим в состав Скрам Команды, понять, какие из их взаимодействий со Скрам Командой являются полезными, а какие нет. Скрам Мастер содействует изменению таких взаимодействий для увеличения ценности продукта, создаваемого Скрам Командой.
Скрам Мастер во многом помогает остальным членам команды.

Владельцу Продукта:
Обнаруживает методы эффективного управления Журналом Продукта.
Сообщает видение, цели и элементы Журнала Продукта Команде Разработчиков.
Учит Команду Разработчиков создавать лаконичные и понятные элементы Журнала Продукта.
Осуществляет долгосрочное планирование по продукту в эмпирической среде.
Понимает и практикует гибкие методы разработки и управления.
По требованию или необходимости может выступить ведущим мероприятий Скрама.

Команде Разработчиков:
1. Учит Команду Разработчиков самоуправлению и кроссфункциональности.
2. Учит и ведет за собой Команду Разработчиков при создании продуктов с высокой ценностью.
3. Устраняет помехи, которые возникают в процессе работы Команды Разработчиков.
4. При необходимости проводит мероприятия Скрама.
5. Проводит необходимые тренинги для Скрам Команды в тех организационных областях, в которых Скрам еще не до конца внедрен и понят.

Организации:
1. Ведет и тренирует организацию на ее пути внедрения Скрама.
2. Планирует этапы внедрения Скрама в пределах организации.
3. Помогает сотрудникам компании и заинтересованным лицам понять и внедрить Скрам и принципы эмпирической разработки продукта.
4. Выступает инициатором изменений, усиливающих продуктивность Скрам Команды.
5. Работает совместно с другими Скрам Мастерами для более эффективного использования Скрама в пределах организации.

- - - - - - - - -
Виртуализация. Виртуальные машины. Гипервизоры. Контейнеры.
- - - - - - - - -

Важность и применение виртуализации простирается далеко за пределы виртуальных машин. Ни одно из достижений в области информационных технологий не имело столь огромной ценности как виртуализация. Многие IT-специалисты думают о виртуализации с точки зрения виртуальных машин (VM) и связанных с ними гипервизоров и операционных систем, но это только вершина айсберга. Все более широкий спектр технологий, стратегий и возможностей виртуализации переопределяет основные элементы IT в организациях по всему миру.

https://smartiqa.ru/blog/virtualization

 - - - - - - - - -
Как войти в IT. Кем быть: тестировщиком или аналитиком?
- - - - - - - - -

Сфера IT стремительно развивается. Это, пожалуй, одна из сфер бизнеса, которая за последние год-полтора не только не потеряла в доходе, а наоборот выросла. Хотели бы начать работать в IT сфере?
В этом видео автор расскажет о двух профессиях, с которых проще всего начать свой путь в мире IT.

Сравнит профессии тестировщиков и аналитиков, посмотрит требования к начинающим специалистам на примере вакансий крупных компаний, рассмотрим потенциальный карьерный рост в каждой из этих профессий.

https://www.youtube.com/watch?v=WfjHcgdaMzs&list=WL&index=66

https://www.youtube.com/watch?v=WfjHcgdaMzs

 Вопрос №29

Q: Какие SCRUM мероприятия вы знаете?
A: Четко установленные мероприятия используются в Скраме для того, чтобы придать процессу разработки регулярность и минимизировать потребность в совещаниях, не предписанных Скрамом. Скрам использует ограниченные по времени мероприятия, поэтому каждое мероприятие имеет свой верхний предел продолжительности. Это гарантирует, что планирование будет проводиться в предназначенное время, не позволяя потерь времени в процессе планирования.

Кроме главного мероприятия, собственно самого Спринта, который включает все остальные мероприятия, каждое мероприятие Скрама является возможностью что-то проверить и провести адаптацию чего-нибудь. Такие мероприятия являются специально разработанными для обеспечения необходимой прозрачности и контроля.
И все-таки что же такое Спринт?

Спринт является сердцем Скрама. Это промежуток времени длиной в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта.

Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.

Во время Спринта:
1. Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal).
2. Состав Команды Разработчиков и цели по качеству продукта остаются неизменными.
3. Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.

В течение Спринта регулярно проводятся следующие мероприятия(Meetings):
1. Планирования Спринта(Sprint Planning);
2. Ежедневные Скрамы(Standups);
3. Обзоры Спринта(Sprint Review);
4. Ретроспективы Спринта(Sprint Retrospective).

Вопрос №30

Q: Что такое качество(Quality)?

A: Это когда клиент доволен. Да, такое определение верно, но это субъективная оценка. И зависит от того, кто является клиентом. Так как у каждого клиента своё понимание качества (а так же у тестера, у менеджера, у покупателя продукта). Для тестера, качество — это соответствие требованиям.

- - - - - - - - -
Полезные статьи. Часть 7.
- - - - - - - - -

1. Ссылки для UX-специалистов: https://habr.com/ru/post/247493/
2. Как не надо проводить нагрузочное тестирование: https://xwizard-test.blogspot.com/2015/01/blog-post_30.html
3. Регрессионное тестирование: https://33testers.blogspot.com/2015/06/blog-post_17.html

 - - - - - - - - -
Что делает тестировщик? Тестирование на примере
- - - - - - - - -

Видео для тех, кто не знает, что делает тестировщик. Автор видео показал: как выглядит тестирование на примере, поиск багов и составление баг репорта.

https://www.youtube.com/watch?v=bxcvLJf19bQ

https://www.youtube.com/watch?v=bxcvLJf19bQ

Вопрос №31

Q: Что такое обеспечение качества продукта (Software Quality Assurance)?

A: Это процесс отслеживания и совершенствования всех видов деятельности, связанных с разработкой программного обеспечения. Этот процесс включает в себя всё: начиная со сбора требований, дизайна, код-ревью, тестирования, имплементирования и заканчивая обслуживанием (технической поддержкой на стороне клиента).