Господа читающие, это полная бабуйня.
Ответ на пост «Тестировщики»
Тестировщик не просто срёт.
Давайте попробую объяснить, уж сорян за душноту, но чето пригорает уже от этого.
Если воспользоваться этой аналогией, то выглядит всё так.
Хозяин кота оборудовал квартиру так, чтобы в теории кот смог срать только в лоток, и только единоразово до момента уборки говна. Возможны вариации, но это уже опции.
Итак. Хозяин хаты организовал место сранья так, чтоб кот ходил срать именно в лоток. Но. Кот сильно не хочет срать именно туда. Он ищет угол, где его не видит, и гадит туда. Это баг. Кот может дважды насрать. Тоже баг. Хозяин фиксит, но кот упорный - он срет под ванной. Фикс. И тд....
А теперь реальность.
Работа кота заключается в поисках багов. И их документировании. Т.е. прям задокументированная последовательность воспроизведения. Мол в этом углу есть нитка, если за нее потянуть, то шторка, блокирующая проход, отодвигается на 1.6мм, что позволяет просунуть 3 когтя левой задней лапы, и это действие триггерит попугая который вообще сидит в дальнем углу комнаты. Попугай своими криками отвлекает хозяина, и он не видит проникновения кота в запретную зону. Кот проникает, и срет под ванну.
И таких ситуаций тысячи. И каждую нужно документировать... А еще кот должен писать тест-кейсы...
Так что хватит упрощать работу ИТшников, сайпали, чесслово.
Неделя 4. Теория тестирования. Часть 4
Доброго времени суток. Инфы опять не так много, а текста в конспекте получилось еще меньше, так как в техниках тест-дизайна много ссылок (потому что проще оставить ссылку на статью, чем просто копипастить текст оттуда, да и техники тест-дизайна лучше смотреть на примере). На следующей неделе планирую уместить git, junit, возможно Rest Assured или вместо всего этого будет git и Java (я пока еще не решил). Ну а теперь конспект:
Техники тест-дизайна:
Попарное тестирование
State & Transition Diagram (сокращенно S&T) — схема состояний и переходов
Вариант использования
Decision Table (таблица решений)
Исследовательское тестирование - это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки. Если в ходе проведения тестирования был обнаружен дефект, то следует задокументировать (тест-кейс), чтобы в последующем можно было проверять данный сценарий. Также желательно создать тест-кейсы на похожие сценарии, так как там могут находится похожие дефекты.
Гибкие методологии разработки:
Для начала определим кто такой менеджер?
Менеджер — это человек производящий и управляющий потоками, для оптимизации производственной деятельности и достижения поставленных целей и результатов.
С чем это связано?
Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrum, Kanban. Чтобы иметь представления как работать с командой.
Что такое Agile?
Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.
А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.
Подход к проектам по разработке ПО
Гибкая методология разработки,
Постоянное формирование требований на основе целевого видения продукта
Короткие горизонты планирования (1-2 мес.)
Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля
Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку
Agile Manifesto - основной документ, содержащий описание ценностей и принципов гибкой
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Особенность реализации проектов
Фиксированы срок и стоимость проекта.
Лучший контроль качества – контроль результата каждой итерации
Отсутствует конечный скоуп проекта - нет четко описанного результата
Что такое Scrum?
Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки
Scrum – самая популярная из гибких методологий разработки
Позволяет решать задачи
меньшими силами
в сжатые сроки
с минимальными затратами.
РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!
Процесс создания нового программного продукта ведется посредством создания спринтов - коротких рабочих сессий, как правило, продолжительностью 1–2 недели.
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.
Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.
ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.
По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.
Как максимизировать и выравнивать процессы?
На самом деле здесь уже все продумано, и придумать велосипед не нужно!
Используется всего четыре артефакта:
Product Backlog
Sprint Backlog
Sprint Goal
Sprint Burndown Chart.
Sprint backlog
Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.
Sprint Goal
Это краткое описание того, ради чего выполняется данный спринт, цель на спринт помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.
Sprint Burndown Chart
диаграмма сгорания
в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
диаграмма обновляется каждый раз, когда завершается какая-либо задача.
Ритуалы
Есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.
Ритуалы в скрам это:
Sprint Planning Meeting
Daily Meeting
Sprint Review
Retrospective
Sprint Planning Meeting (встреча по планированию спринта)
выполняется всей командой перед началом спринта
команда выбирает требования из Product Backlog и формирует Sprint Backlog
если требуется учесть взаимосвязи между операциями, то это делается здесь
команда декомпозирует требования на задачи (tasks)
каждая задача проходит оценку в трудозатратах или универсальных единицах
во время встречи Product Owner отвечает на вопросы команды.
Daily Meeting (ежедневная встреча команды).
Основные принципы:
проходит ежедневно и только в одно и то же время;
встречи не более 15 минут;
чтобы успеть каждый должен ответить всего на 3 вопроса: что я сделал вчера, чем я занимаюсь сегодня, какие есть проблемы?
Scrum Master следит за ходом встречи, побуждает участников высказываться полностью и слушать говорящего.
Sprint Review – сдача спринта Product Owner
По завершению каждого спринта команда обязана провести демонстрацию полученного результат.
Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.
Структура встречи:
команда зачитывает требования из Sprint Backlog
по каждому критерию приемки происходит демонстрация полученных результатов
каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.
Retrospective
Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.
Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:
какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
какие проблемы мешают команде выполнять взятые на себя обязательства?
как улучшить взаимодействие с Product Owner’ом?
какие ошибки совершает команда и почему.
Scrum Poker (Planning Poker):
Scrum Poker - суть не идеально точно установить срок выполнения задачи, а убедиться в том, что все участники процесса понимают задачу и алгоритм ее выполнения одинаково правильно.
Алгоритм таков: всем участникам дается набор карт и задачи, которые будут реализованы. Каждый из участников дает свою оценку. Берется самое минимальное и максимальное значение. Затем каждый участник, поставивший такую оценку, должен объяснить, почему именно так. После обсуждения начинается вторая фаза проставления оценок. Таких фаз проводится 3. Если на последней фазе расхождения остаются, то берется максимальная оценка.
Agile. Kanban:
Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.
Kanban — это метод для разработки продуктов, который помогает наладить текущие процессы и не перегрузить команду. Незавершенные задачи не простаивают и потоком движутся по цепочке создания продукта или его поддержки.
Kanban используют для реализации проектов.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с "передовой" и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.
В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи.
Карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, прикрепляются , к доске с расчерченными колонками:
Бэклог — задачи, которые надо выполнить
Задачи, которые в данный момент разрабатываются
Задачи, которые выполнены, но еще не переданные тестировщикам
Задачи, готовы к передаче отделу тестирования
Задачи, которые проходят проверку проект-менеджером (ПМ)
Выполненные задачи
Основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “узкие места” в системе и поработать с ними.
Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.
4 базовых принципа «Kanban»
1) Отталкивайтесь от того, что у вас есть сейчас
2) Стремиться к поэтапным, постоянным и эволюционным изменениям
3) Уважайте поточные процессы и роли
4) Поддерживать лидерство на всех уровнях
Почему важно визуализировать?
Kanban — это в первую очередь визуализация
- Визуальное отображение задач. Все задачи должны быть представлены в виде карточек и отражены на доске.
- Фокус на невыполненных задачах
- Постоянное улучшение
- Уделяйте внимание мелочам
Kanban на первом месте задачи. команда работает над задачей с самого начала и до завершения
Kanban имеет и недостатки:
Система плохо работает с командами численностью более 5 человек
Он не предназначен для долгосрочного планирования.
В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.
Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile
Если взять Scrum и Kanban они могут взаимодействовать вместе, если Scrum встал или имеет проблемы команды процессов, допустим Scrum это макароны а Kanban это кетчуп которые делает макароны вкуснее. Это делается для такого чтобы люди сфокусировались на потоке создания ценностей.
Откуда берутся тестировщики (QA) ?
Откуда берутся тестировщики? Все просто – судьба наделяет их всеми необходимыми скилами ещё в детстве
Программа QA Manual Engineer 2.0 - Освоение профессии тестировщика без СМС и регистрации
Привет! Представляю новую программу для освоения профессии QA Engineer (тестировщик) по направлению WEB. Собрана на базе бесплатных и общедоступных материалов, оформлена в программу, ориентированную примерно на 4 месяца.
Результатов!
Профессиональная паранойя
Тестировщик: Выпуск релиза надо отложить!
Разработчик: Почему, что случилось?
Тестировщик, озабоченно: Все тесты проходят успешно. Не могу понять, почему так происходит...
