QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...QAFest
Принципы «правильной» автоматизации всем хорошо известны, но почему-то даже опытные автоматизаторы не всегда им следуют. Допуская ошибки одну за другой, мы и не замечаем, как укорачиваем жизнь нашим авто-тестам. В результате, нередко случается так, что наши решения со временем забрасываются и не выживают, либо же превращаются в «чемодан без ручки» - когда нести тяжело, а выбросить жалко.
Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли.
Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.
Автоматизация тестирования как сервис, Павел Сташевский
Все мы хотим получать качественные сервисы. Мы хотим, чтобы обслуживание было быстрым, качественным и недорогим. Нам важно получить удовольствие от сервиса, будь то парикмахерская или бронирование авиабилетов. Автоматизация тестирования в этом плане практически не отличается от других сервисов, особенно, если она развивается в крупной компании. При этом нужно учесть стек технологий и уровень развития проекта и при этом не наступить на те грабли, что мы собрали при автоматизации тестирования других продуктов. Как строить такой сервис, как его адаптировать под различные команды и получать предсказуемый результат, именно про эти вопросы Павел расскажет в своем докладе. И все это на примерах из 2ГИС.
QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.QAFest
- История проекта (с чего началось внедрение SCRUM в QA команде, какая была команда и тп)
- Тестирование в идеальном Agilе (как происходит построение процесса в идеале и что мы можем получить)
- Советы тестировщику в Agile
- Показатели или что от нас хочет Product Owner
- Что мы добавили в обычное SCRUM тестирование и какой получили результат
Выводы что дал SCRUM команде и как поменялась
Автоматизация тестирования в highload проекте: практический опытRina Uzhevko
The document discusses automation testing for high-load projects, describing real-time bidding processes that must be completed in under 100ms. It outlines dividing tests and using metrics to test business logic and detect anomalies. The overall goals are to share practical experience with automation testing.
Выступление на встрече московского клуба тестировщиков.
Если почитать какую-нибудь книжку про разработку автотестов или просто погуглить по словам "successful test automation" -- можно найти множество разнообразных рекомендаций. Выбирайте правильно инструмент. Проектируйте и выстраивайте правильную архитектуру тестов. Уделяйте внимание тому, чтобы тесты было легко поддерживать. Не забывайте про планирование и управление (вообще-то это надо было бы поставить первым пунктом).
Но когда вы только приступаете к созданию автотестов -- вы ещё не знаете ничего ни про инструменты (насколько хорошо они вам подойдут), ни про архитектуру, да и управлять ещё нечем. Планировать в условиях такой неопределённости тоже сложно.
Что же делать?
Вы когда-нибудь выращивали цветы? Комнатные, или на клумбе, или может быть даже не цветы, а кусты или деревья?
Конечно, можно сначала нанять ландшафтных дизайнеров, распланировать и спроектировать большой-большой парк, потом нанять рабочих, которые всё посеют и посадят в соответствии с планом, сделают дорожки и выкопают декоративные прудики. А потом будут его поддерживать.
Но для этого нужно во-первых, иметь опыт таких работ, а во-вторых, иметь достаточно солидный бюджет.
Однако есть и другой путь -- "органический". Сначала посадить один цветочек. Если не приживётся -- посадить другой. Когда вы увидите, что он хорошо себя чувствует -- посадить побольше таких цветов. Оформить красиво клумбу. Подсадить что-нибудь ещё. Разбить рядом вторую клумбу, с другими цветами. Потом что-нибудь куда-нибудь пересадить, а что-нибудь вообще перестать сажать, потому что не понравились. И так постепенно создать ничуть н
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Atlassian Jira - не только тасктрекер / Анна Котова (Mail.Ru)Ontico
Jira всем и каждому, и пусть никто не уйдет обиженным.
Jira — простой в настройке, удобный и гибкий инструмент для автоматизации процессов.
- Почему Jira.
- Для каких проектов и процессов подходит Jira.
Планирование и автоматизация работы в Jira на примере контентного проекта.
- Настройка бизнес-процессов для ведения редакционного плана.
- Сбор и анализ статистики, оценка качества материалов и эффективности авторов.
- Наглядность: графики и отчеты.
- Автоматизация расчетов с авторами материалов и контроль бюджета проекта.
Плюсы внедрения Jira в проекты любого типа.
- Безопасность.
- Удобство и скорость формирования отчетов.
- Быстрый анализ эффективности команды и проекта.
- Экономия времени и порядок в финансовых расчетах.
Out-of-the-box WebDriver API provides two main classes: WebDriver and WebElement. Webium library helps you to extend it to whatever deep UI object structure you need. You can describe basic elements (e.g. Button, Input), construct complex elements (e.g. Calendar) from small pieces and at the end put it all together into your Page Objects. Webium is free and open-source. In my speech I’ll present your how to use it effectively if you want to write Selenium tests in Python.
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
Ольга Лужецька - Exploratory testing: Love it or Leave it?DataArt
Є думка, що exploratory testing - це хаотичний процес, яким важко керувати. Ми розберемось, чи можна організувати exploratory testing так, щоб продукт був крутим та якісним, ризики більш передбачувані, а тестувальники отримували задоволення.
Тестирование — это способ узнать о разнообразных проблемах, которые могут возникнуть во время разработки вашего проекта. В лекции рассмотрены различные виды тестирования и различные практики, которые позволят вам узнавать о проблемах заранее.
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html
Как мы помогаем тестировщикам делать их работу лучшеRoman Ivliev
Картинки к моему рассказу на QAMeetUp в нижегородском mail.ru про то, как мы помогаем тестировщикам и мешаем одновременно.
Тезисно: есть куча способов привлечь других членов команды (админов, саппорт, разработчиков) к тестированию и выявлению дефектов, но не всегда это здорово, потому что де-факто получается огромное количество наведённых эффектов, борьба с которыми перекрывает по затратам нормальный процесс тестирования. Доклад больше менеджерский, но и остальным он будет полезен имхо. Видео и аудио не снимали. В слайдах есть контакты - с удовольствием отвечу на вопросы и расскажу про то, как и что у нас.
3. • 10 лет в Интернете
• 570КК выручки за 2014 год
• 0,5КК уников в сутки
• 30+ сотрудников департамента
информационных технологий
• 70Тб трафика в месяц
• А ещё мы покупаем конкурентов ;)
О BANKI.RU
4. • Метрики, что это и что с ними делать
• Метрики - примеры
• Темная сторона метрик, как не надо
• Темная сторона метрик, как избежать
ПРО ЧТО Я БУДУ РАССКАЗЫВАТЬ
7. Метрики, что это?
• Метрика по ISO 14598 - это
количественный масштаб и метод,
который может использоваться для
измерения.
• Метрика - это мера, позволяющая получить
численное значение некоторого свойства
объекта
12. • Найденные дефекты/ исправленные
дефекты
• Процент выполненных тестов /процент
успешных тестов
• Метрика стилистики и понятности
(например, плотность комментариев)
Метрики, примеры (простые и один не простой)
13. Иллюстрация, как можно сломать мозг
• Major Defects Per Test Case Review
• Minor Defects Per Test Case Review
• Total Defects Per Test Case Review
• Ratio of Major to Minor Defects Per Test Case Review
• Total Defects Per Test Case Review Hour
• Major Defects Per Test Case Review Hour
• Ratio of Major to Minor Defects Per Test Case Review Hour
• Number of Open Defects Per Test Review
• Number of Closed Defects Per Test Case Review
• Ratio of Closed to Open Defects Per Test Case Review
• Number of Major Open Defects Per Test Case Review
• Number of Major Closed Defects Per Test Case Review
• Ratio of Major Closed to Open Defects Per Test Case
Review
• Number of Minor Open Defects Per Test Case Review
• Number of Minor Closed Defects Per Test Case Review
• Ratio of Minor Closed to Open Defects Per Test Case
Review
• Percent of Total Defects Captured Per Test Case Review
• Percent of Major Defects Captured Per Test Case Review
• Percent of Minor Defects Captured Per Test Case Review
• Ratio of Percent Major to Minor Defects Captured Per Test
Case Review
• Percent of Total Defects Captured Per Test Case Review
Hour
• Percent of Major Defects Captured Per Test Case Review
Hour
• Percent of Minor Defects Captured Per Test Case Review
Hour
• Ratio of Percent Major to Minor Defects Captured Per Test
Case Review Hour
• Percent of Total Defect Residual Per Test Case Review
• Percent of Major Defect Residual Per Test Case Review
• Percent of Minor Defect Residual Per Test Case Review
• Ratio of Percent Major to Minor Defect Residual Per Test
Case Review
• Percent of Total Defect Residual Per Test Case Review
Hour
• Percent of Major Defect Residual Per Test Case Review
Hour
• Percent of Minor Defect Residual Per Test Case Review
Hour
• Ratio of Percent Major to Minor Defect Residual Per Test
Case Review Hour
• Number of Planned Test Case Reviews
• Number of Held Test Case Reviews
• Ratio of Planned to Held Test Case Reviews
• Number of Reviewed Test Cases
• Number of Unreviewed Test Cases
• Ratio of Reviewed to Unreviewed Test Cases
• Number of Compliant Test Case Reviews
• Number of Non-Compliant Test Case Reviews
• Ratio of Compliant to Non-Compliant Test Case Reviews
• Compliance of Test Case Reviews
• Non-Compliance of Test Case Reviews
• Ratio of Compliance to Non-Compliance of Test Case
Reviews
14. Иллюстрация, как можно сломать мозг
• Major Defects Per Test Case Review
• Minor Defects Per Test Case Review
• Total Defects Per Test Case Review
• Ratio of Major to Minor Defects Per Test Case Review
• Total Defects Per Test Case Review Hour
• Major Defects Per Test Case Review Hour
• Ratio of Major to Minor Defects Per Test Case Review Hour
• Number of Open Defects Per Test Review
• Number of Closed Defects Per Test Case Review
• Ratio of Closed to Open Defects Per Test Case Review
• Number of Major Open Defects Per Test Case Review
• Number of Major Closed Defects Per Test Case Review
• Ratio of Major Closed to Open Defects Per Test Case
Review
• Number of Minor Open Defects Per Test Case Review
• Number of Minor Closed Defects Per Test Case Review
• Ratio of Minor Closed to Open Defects Per Test Case
Review
• Percent of Total Defects Captured Per Test Case Review
• Percent of Major Defects Captured Per Test Case Review
• Percent of Minor Defects Captured Per Test Case Review
• Ratio of Percent Major to Minor Defects Captured Per Test
Case Review
• Percent of Total Defects Captured Per Test Case
Review Hour
• Percent of Major Defects Captured Per Test Case Review
Hour
• Percent of Minor Defects Captured Per Test Case Review
Hour
• Ratio of Percent Major to Minor Defects Captured Per Test
Case Review Hour
• Percent of Total Defect Residual Per Test Case Review
• Percent of Major Defect Residual Per Test Case Review
• Percent of Minor Defect Residual Per Test Case Review
• Ratio of Percent Major to Minor Defect Residual Per Test
Case Review
• Percent of Total Defect Residual Per Test Case Review
Hour
• Percent of Major Defect Residual Per Test Case Review
Hour
• Percent of Minor Defect Residual Per Test Case Review
Hour
• Ratio of Percent Major to Minor Defect Residual Per Test
Case Review Hour
• Number of Planned Test Case Reviews
• Number of Held Test Case Reviews
• Ratio of Planned to Held Test Case Reviews
• Number of Reviewed Test Cases
• Number of Unreviewed Test Cases
• Ratio of Reviewed to Unreviewed Test Cases
• Number of Compliant Test Case Reviews
• Number of Non-Compliant Test Case Reviews
• Ratio of Compliant to Non-Compliant Test Case Reviews
• Compliance of Test Case Reviews
• Number Non-Compliance of Test Case Reviews
• Ratio of Compliance to Non-Compliance of Test Case
Reviews
16. • Счетчик новых и исправленных дефектов
• Счетчик удачных и неудачных тестов
• Число строк кода и число комментариев
Чем их мерять?
17. • Все дефекты найдены и
задокументированы
• Есть цель исправить все дефекты
• Если все известные дефекты исправлены
– продукт готов
• Есть разумное объяснение для всех
исправленных дефектов
Смеркалось Счетчики, предположения
18. Смеркалось Проценты, предположения
• Перед выполнением точно знаю,
сколько тестов будет выполнено
• Все четко понимают, что такое «тест»
• Все четко понимают, что такое
«выполненный»
• Выходом теста является либо
«Прошел», либо «Не прошел»
30. КЛАССИЧЕСКИЙ ЗАГОН УПРАВЛЕНЦА
• Взять цифры (их кто-то написал)
• Изучить внимательно (это важно!)
• Сделать выводы (ТОЛЬКО верные)
• Наказать виновных (и остальных)
31. КЛАССИЧЕСКИЙ ЗАГОН УПРАВЛЕНЦА
• Взять цифры (их кто-то написал)
• Изучить внимательно (это важно!)
• Сделать выводы (ТОЛЬКО верные)
• Наказать виновных (и остальных)
• Внести «коррективы»
32. КЛАССИЧЕСКИЙ ЗАГОН УПРАВЛЕНЦА
• Взять цифры (их кто-то написал)
• Изучить внимательно (это важно!)
• Сделать выводы (ТОЛЬКО верные)
• Наказать виновных (и остальных)
• Внести «коррективы» (а как иначе?)
33. КЛАССИЧЕСКИЙ ЗАГОН УПРАВЛЕНЦА
• Взять цифры (их кто-то написал)
• Изучить внимательно (это важно!)
• Сделать выводы (ТОЛЬКО верные)
• Наказать виновных (и остальных)
• Внести «коррективы» (а как иначе?)
• ПРОФИТ!
35. Методы «управления» Счетчики
• Объединение дефектов в один
• «Альтернативный» коллектор
дефектов
• Добавление дефекта, только после
того, как он был исправлен
• Самостоятельный поиск и
исправление дефектов разработчиком
36. Следствие Счетчики
• А как корректно учитывать дефекты?
• Как заставить отказаться от
альтернативных путей?
• Как считать сложные дефекты?
• И т.д.
37. Методы «управления» Проценты
• «Исправление» термина «тест» в
сторону увеличения гибкости
• Прогон только «хороших» тестов
• Исправление тестов по поведению
софта
38. Следствие Проценты
• Падает ли тест дважды, если он
находит два дефекта?
• Надо ли прогонять тест, который
наверняка упадет?
• Надо ли включать в отчет такой
дефект?
• Если функционал работает частично,
все тесты отклонять, или только те, что
реально упали?
44. Стратегия выбора метрик: измерения
• Понять назначение измерения. Какое
измерение для чего будет
использоваться
• Понять цель измерения. Как широко
будут использоваться измерения
• Найти объект измерения
• Определиться с масштабом
измерения.
47. Стратегия выбора метрик: инструмент
• Найти описание естественного
изменения объекта измерений, т.е.
некоторый алгоритм, по которому
изменяется объект измерения.
• Найти инструмент для измерения
свойств объекта. Например, счетчик
новых дефектов.
• Важно, чтобы инструмент был
исправен!
48. Стратегия выбора метрик: инструмент
• Понять как изменяются измерения,
сделанные с использованием
выбранного инструмента.
• Определиться с масштабом
инструмента для измерений.
49. Стратегия выбора метрик: инструмент
• Понять каким образом объект
измерения соотносится с
инструментом.
• Выяснить побочные эффекты, которые
могут возникнуть при измерениях
объекта выбранным инструментом.
52. ПРИМЕР
• Команда А: тех.долг - 11 задач .
• Команда Б: тех.долг - 110 задач .
• Команда В: тех.долг - 0 задач .
• Команда Д: тех.долг - 35 задач .
53. ПРИМЕР
• Команда А: тех.долг - 11 задач .
• Команда Б: тех.долг - 110 задач .
• Команда В: тех.долг - 0 задач .
• Команда Д: тех.долг - 35 задач .
• О чём нам говорят эти цифры?