Agile testing

 Юля
 7 лет как тестировщик
 QA @ ALMWorks
 QALead @ Jtalks Open Source
 email: atlygina_julia[собака]inbox.ru

 Имя
 Тестировщикменеджерразработчиксочувствующий?
 Знаете ли что-то об agile?
 Чего ждете от тренинга?
 Слово на первую букву имени
 Повторяем всех предыдущих ораторов 

 In the late 1990’s several methodologies began to get increasing public attention.
Each had a different combination of old ideas, new ideas, and transmuted old
ideas. But they all emphasized close collaboration between the programmer team
and business experts; face-to-face communication (as more efficient than written
documentation); frequent delivery of new deployable business value; tight, self-
organizing teams; and ways to craft the code and the team such that the
inevitable requirements churn was not a crisis.

http://agilemanifesto.org/
Agile-манифест разработки программного
обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного
обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря
проделанной работе мы смогли осознать, что:
Люди и взаимодействиеважнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

 Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
 Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
 Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
 На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
 Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
 Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
 Работающий продукт — основной показатель прогресса.
 Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
 Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
 Простота — искусство минимизации лишней работы — крайне необходима.
 Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
 Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
Agile Alliance,
http://www.agilealliance.org/

 3 слова для каждого принципа
 Картинка
 На все – 10 минут

- Scrum
- Kanban/Lean
- Xtreme Programming
- Crystal
- DSDM (Dymanic System
Development Met.)
- Feature Driven Development

1962, Toyota
“Кан” - видимый, визуальный, и “бан” - карточка
или доска.
1. Визуализируйте производство (visualize
workflow)
— Разделите работу на задачи, каждую задачу
напишите на карточке и поместите на стену или
доску.
— Используйте названные столбцы, чтобы
показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу,
выполняемую одновременно) на каждом этапе
производства. (limit work-in-progress)
3. Измеряйте время цикла (среднее время на
выполнение одной задачи) и оптимизируйте
постоянно процесс, чтобы уменьшить это время.
(monitor, adapt, improve)
Tools:
Trello 
Jira Agile
Kanbanflow
Kanbanize
Visual Wip

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

Водопад – когда нужна
формализация, четкий набор задач,
«можно» менять время и цену
Agile – нет четкого набора задач,
постоянные изменения, но
выпускаем всегда в одно и тоже
время, одной и той же командой

http://www.implementingscrum.com
/2006/09/11/the-classic-story-of-the-
pig-and-chicken/
Product Owner
Scrum Master
Team: BA, programmers, testers, etc.
Pigs are individuals who have
ownership over tasks;
everyone else is known as a
chicken.
Users
Stakeholders (clients)
Managers
Consulting Experts

Product Owner:
 Представляет интересы конечных пользователей и
других заинтересованных в продукте сторон (может
быть не один человек)
 Несет ответственность за значимость продукта для
пользователей
 Собирает все требования в бэклог и расставляет
приоритеты
 Поддерживает бэклог продукта
 Участвует в демо и «подтверждает» готовность историй
Scrum Master:
 Выделенный человек, ответственный за следвоании
командой процессу
 Поддерживает бэклог итерации
 Не менеджер, но организует все митинги, назначает
задачи
 Отвечает за то, чтобы команде ничего не мешало
доставить работающий продукт продакшен качества в
срок

 Группа мотивированных людей, которые работают друг с
другом для достижения общей цели (создания продукта), могут
участвовать в дискуссиях, должны быть готовы к изменениям
Могут брать задачи самостоятельно, им не нужен менеджер,
который назначит работу. Высокая степень ответственности за
свой выбор и результат
 Управляем своими задачами как единая группа (назначить,
оценить, переоценить, переделать, доставить,..)
Команде нужен «тренер», но не нужен человек для контроля
(They still require mentoring and coaching, but they don't
require "command and control.«)
 Вся команда понимает требования, никто не боится задавать
вопросы чтобы развеять сомнения
 Команда постоянно развивается, улучшать свои навыки,
пробудет новые технологии, идеи, улучшения
Competency. Collaboration. Motivation. Trust and Respect.
Continuity. Do Agile Right: team structure

 Синие и красные бумажечки. Синие – должны,
красные – часто бывает
 3 столбика: Product Owner, Scrum Master, Team
 Раскладываем карточки за 10 минут

 Под «сделано» каждый может подразумевать что-то
свое. И под «хорошо сделано», тоже
 Нужны критерии, что продукт «готов»
1. Договор между заказчиком и командой
2. Чеклист нужных активностей
3. Могут быть на требование (есть критерии, есть
приоритет,..), задачу (код ревью, автотесты, ручные
тесты, все тесты прошли,..), итерацию (есть нужные
документы, все задачи прошли все стадии,
регрессионные тесты прошли,..)
4. Должен разрабатываться ВСЕЙ командой
http://vimeo.com/21529305

- Story Card
- Acceptance
Criteria
- Communications!
Do Agile Right: Specifications

INVEST theory:
Independent – Don’t mix user stories together, each
should be independent in and of itself.
Negotiable – User stories, up until they are part of an
iteration, can always be changed and rewritten.
Valuable – A user story must deliver value to the end
user
Estimable – User stories may have to be prioritized.
Small – Keep them short, user stories are not novels.
Testable – Make sure the user story actually offers
something you can analyze or test.

MoSCoW:
 Must have
 Should have
 Could have
 Would like
Developers will initially try to deliver all the M, S and C requirements but
the S and C requirements will be the first to go if the delivery timescale
looks threatened.

http://www.slideshare.net/krivitsky/
estimations-stop-asking-when
 Planning Poker
 Size/Story Points
Do Agile right

 15 минут
- Что делал вчера,
- Что собираюсь делать сегодня
- Есть ли вопросы?
15 минут
- Что делал вчера,
- Что собираюсь делать сегодня
- Есть ли вопросы?

Она же канбан доска 

X- time
Y – Story Points/Hours/ etc.

 Показываем заинтересованным лицам что сделали за
итерацию
 Обычно сценарии берем из приемочных критериев
 Тыкаем «вживую»
 Отвечаем на вопросы
Цель: показать, что сделали и узнать,
то ли вообще сделали?

- Нужна для того, чтобы улучшать процесс, инструменты, результаты по ходу разработки

 За качество отвечает ВСЯ команда (вместе планируем,
вместе проводим ретро, вместе демонстрируем
заказчикам, вместе огребаем проблем)
 Стараемся не находить ошибки, а предвосхищать их
появление (больше к девелоперам, но мы можем быть
рядом с ними в эти моменты: во время код ревью,
планирования)
 Тестируем документацию и мокапы/прототипы!
 Требования все время меняются, частые доставки ( на
кейсы обычно времени нет)
 Приоритезируем еще лучше, чем в других процессах)
 Больше исследований! Exploratory, Ad-hoc, Session
based

- UAT
- Automation
- Exploratory
- Less documented
- Use tools!

 прежде чем писать - подумайте для кого пишем
 Неофициальный: чеклист, майн-карта, записи на вики :)
 стандартные разделы:
- Что тестируем? Описание системы, оборудования,..
- Какую часть тестируем? Scope тестируемых функций
- Что не тестируем
- Как тестируем? Стратегия, типы тестов, техники, уровни
- Кто тестирует? роли, команды, конкретные имена :)
- Когда тестируем? Расписание / estimation
- На чем тестируем? Описание тестового стенда, необходимых систем (нужны ли внешние
системы?), железо, инструменты (багткерер, хранение кейсов,..)
- Критерии конца: метрики (открытые/закрытые баги, покрытие кода, etc), время, etc.
- Риски
- Где искать другие документы "ленивый" тест план

 Набор идей для тестирования
http://jira.jtalks.org/secure/StructureBoard.jspa?s=134

Исследование продукта, разработка и выполнения
тестов в одно и то же время.
 Это тестирование без тест-кейзов,
исследовательское, совмещённое с изучением
продукта. Используется при отсутствии
документации и/или времени на составление тест-
дизайна. Может быть измеримым,
менеджебельным и контролируемым, в отличие от
ad hoc © Natalya Rukol

 Бизнес район – места, где делаются дела
 Исторический район – старые районы, достались нам от прошлый хозяев (legacy
code)
 Туристический район – места, где бывают новые пользователи и не бывают
горожане
 Федекс тур – тестируем, фокусируясь на тестовых данных

 Способ управления исследовательским тестированием

 Садимся парами и тестируем
 Практика! 10 минут путешествия по туристическому району

http://validator.w3.org/checklink
http://validator.w3.org/mobile/
http://jigsaw.w3.org/css-validator/
http://nibbler.silktide.com/en_US

http://achecker.ca/checker/index.php
http://wave.webaim.org/
http://www.w3.org/WAI/ER/tools/complete

 Developer tools in Chrome
(нажать F12 -> значок мобильного)
 http://responsivepx.com/
 http://www.responsinator.com/
 http://responsive.pixeltuner.de
http://mattkersley.com/responsive/
http://designmodo.com/responsive-test/
http://quirktools.com/screenfly/
 Видео от JTalks: http://www.youtube.com/watch?v=NsFi85QkFls&feature=youtu.be (презентация)

 https://userium.com/
гайдлайны:
 http://guidelines.usability.gov/
 http://www.vrange.ru/

 Jing http://www.techsmith.com/jing.html
 https://addons.mozilla.org/en-US/firefox/addon/fireshot/

 https://addons.mozilla.org/en-US/firefox/addon/pencil/
 https://balsamiq.com/
 http://creately.com/Online-UI-Mockups-and-Wireframes

http://bugscatcher.net/archives/3184
http://www.mockaroo.com/
http://www.generatedata.com/
http://testspicer.com/docs
http://www.lipsum.com/
http://gojko.github.io/bugmagnet/

https://checkvist.com/checklists/476089

STOPSU: Stress Time Operation Platform Security Usability

 Исследуем элементы
 Пробуем «портить» код
 Смотрим время загрузки
 Следим за http

 HAR (HTTP Archive)– стандарт для трейса http запросов. Цель – запись запросов
в браузере.
Как записать (Chrome):
- F12
- Rec, выполняем нужные действия
- Stop
- Right-click на запросах -> save as HAR
СпецификацияТестирование с HAR
Конвертация в jmx

 плагин к firefox, chrome
 http://chrispederick.com/work/web-developer/
Примеры:
 Forms->Меняем Get на Post
 Forms-> Convert Select elements to text input
 Miscellaneous->Display hidden elements
 Tools->Validators
16.3.15

 Прокси
 перехватываем, редактируем, посылаем запросы
 эмулируем плохую сеть, ошибки в ответах,..
 отправляем запросы одновременно Shift+R
 аналог для браузера: tamper data
 качаем тут http://www.telerik.com/download/fiddler
16.3.15

http://www.webpagetest.org/
http://developers.google.com/speed/pagespeed/insights/
http://loadimpact.com/
http://tools.pingdom.com/fpt/
http://webwait.com/
http://gtmetrix.com
YSlow(плагин) http://yslow.org/

 http://www.browserstack.com/list-of-browsers-and-platforms?product=live (платно)
 https://saucelabs.com/pricing (платно)
 виртуалки для IE: https://www.modern.ie/ru-ru/virtualization-tools#downloads
(бесплатно, но работает не бесконечно)

 Исследуем на уязвимости

Scenario: When a user adds a product to the shopping cart, the product
should be included in the user's shopping cart.
Given a user
Given a shopping cart
Given a product
When the user adds the product to the shopping cart
Then the product must be included in the list of the shoppingcart's
entries
public class AddProductToShoppingCart extends JUnitStory {
private User user;
private ShoppingCart shoppingCart;
private Product product;
@Given("a user")
public void aUser() {
user = new User();
}
@Given("a shopping cart")
public void aShoppingCart() {
shoppingCart = new ShoppingCart();
}
@Given("a product")
public void aProduct() {
product = new Product();
product.setName("Coffee");
}
@When("the user adds the product to the shopping cart")
public void userAddsProductToShoppingCart() {
shoppingCart.add(user, product);
}
@Then("the product must be included in the list of the shoppingcart's entries")
public void productMustBeListed() {
List<Product> entries = shoppingCart.getProductsByUser(user);
Assert.assertTrue(entries.contains(product));
}
}
Evolution of Automation Test Engineer
JBehave

Why
- Increase online conversions by 15% in the next
quarter
- Attract 20% more customers in the next financial
year
Who
- Students with a tablet device or smart phone in
the classroom
- Corporate employees with access to the secure
drive
How
- Get faster access to accurate information
- Have access to a wider network of colleagues to
collaborate with
What
- Online purchasing
- Registration form

 Что было хорошо?
 Что можно улучшить?

Agile testing

More Related Content

Agile testing