Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2019. Николай Мижигурский. Миссия /*не*/выполнима: гуманитарий собесе...QAFest
Случалось ли вам запускать автоматизацию на проекте? Испытывать непревзойденное удовольствие от необходимости собеседовать технического специалиста, когда сам не имеешь технического опыта? Если да, то этот доклад для вас.
Мы научимся анализировать сеньорность кандитата, его технический уровень и способность к организации команд. Но самое главное - все это мы сможем достичь без серьезного технического опыта. Будет интересно, заходи на огонек!
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
QA Fest 2015. Василий Сливка, Игорь Роздобудько. Кросплатформенное тестирован...QAFest
Хотите автоматизировать мобильные приложения? Хотите делать это быстро и безболезненно? И одновременно на двух платформах?
Эти и другие секреты откроют для вас гуру автоматизации мобильных приложений, которые стояли у первоисточников Calabash - Василий и Игорь
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2019. Николай Мижигурский. Миссия /*не*/выполнима: гуманитарий собесе...QAFest
Случалось ли вам запускать автоматизацию на проекте? Испытывать непревзойденное удовольствие от необходимости собеседовать технического специалиста, когда сам не имеешь технического опыта? Если да, то этот доклад для вас.
Мы научимся анализировать сеньорность кандитата, его технический уровень и способность к организации команд. Но самое главное - все это мы сможем достичь без серьезного технического опыта. Будет интересно, заходи на огонек!
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
QA Fest 2015. Василий Сливка, Игорь Роздобудько. Кросплатформенное тестирован...QAFest
Хотите автоматизировать мобильные приложения? Хотите делать это быстро и безболезненно? И одновременно на двух платформах?
Эти и другие секреты откроют для вас гуру автоматизации мобильных приложений, которые стояли у первоисточников Calabash - Василий и Игорь
Слайды к рассказу на SQAdays 12 в Минске (http://it-conf.ru/ru/content/524.htm#TOC-27)
Чтобы создавать по настоящему новые и качественные продукты, любой компании сначала необходимо измениться внутри. Это долгий и болезненный процесс с успехами и неудачами. 2,5 года назад Афиша объединилась с Рамблером. Сейчас мы перезапускаем Рамблер, разворачиваем его лицом к пользователю. Я расскажу несколько историй, как тестирование может участвовать и активно влиять на формирование настоящего и будущего компании.
Comaqa 2017 Presentation in Russian. Can we have some more quality? Who is responsible for QA on a project? Visionary talk on what direction testing (as a profession) should develop nowdays.
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
Тестирование — это способ узнать о разнообразных проблемах, которые могут возникнуть во время разработки вашего проекта. В лекции рассмотрены различные виды тестирования и различные практики, которые позволят вам узнавать о проблемах заранее.
лившиц владимир - независимое тестирование мифMagneta AI
Сюжет этой короткометражки рассказывает о том, как можно трансформировать «незавсимую» команду тестирования для обеспечения качества в нескольких Scrum командах (работающих в одном известном инвест-банке). Это почти что боевик о ломке устоявшихся принципов и небоязни меняться. Обсуждается вопрос: приносят тест-кейсы пользу? Тут есть немного философии: отношения тестировщиков и не совсем к тестированию и качеству в Agile командах.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
9. Реакция обычного тест-менеджера
1. Ищет отмазку для
Почему руководства
пропустил
и багу??! 2. Ищет виноватого и
%#@&!
даѐт ему в глаз
3. Наводит шухер
4. Сам перепроверяет
5. Заводит баг
6. Проверяет что баг
исправлен
10. Реакция просветлённого тест-менеджера
1.Анализирует
Почему
пропустил
причину пропуска
и багу??!
%#@&! 2.Ищет решение
для исправления
3.Корректирует
процесс
так, чтобы это
больше не
повторялось
11. Как проанализировать причину пропуска?
Почему пропустили багу?
Не было времени на проверку
Почему не было времени?
Задержали предыдущую задачу
Почему задержали предыдущую?
Не было вовремя необходимого оборудования
Почему не было оборудования?
Тест-менеджер забыл его вовремя заказать
Почему забыл заказать?
На проекте не ведѐтся планирование «железа»
12. Как проанализировать причину пропуска?
Причина Действие
Мы не знали, что какая-то • Анализ продукта
опция, настройка, условие • Анализ кода (white box и code coverage)
влияют на работу • Согласование тестов с разработчиками и
аналитиками
Не учли комбинацию • Анализ зависимостей
взаимозависимых • Pairwise
параметров
Баг появился за несколько • Повысить регулярность regression
сборок до релиза, не • Автоматизация
успели протестировать • Совместная с разработчиками приоритезация
тестов
Тест был отброшен / • Составление ментальной модели пользователя
отложен из-за низкого • Выяснение «Как используется наш продукт в
приоритета боевых условиях?»
Человеческий фактор, баг • Донести ответственность до сотрудников
просто пропустили • Узнать причину (квалификация / мотивация) и
работать над решением корня проблемы
15. Реакция просветлённого тест-менеджера
Условие Действие
Маленькая команда, • Настроить отправку писем по каждому новому
простой продукт дефекту всей команде
• Ввести теги, компоненты, области ПО в баг-
трекере – всѐ для удобства поиска
• Шаблон заголовка дефекта для удобства
нахождения
Большая команда, • Назначить ответственных модераторов за каждую
сложный продукт область функционала
• Ввести премодерацию дефектов, так чтобы все
баги по одной области проходили через одного
человека
Много подпроектов • Ответственные по проектам с премодерацией
17. Реакция обычного тест-менеджера
Ты почему опять завёл баг
через одно место??!
Сколько можно говорить что
их надо заводить правильно?
%#@&!
18. Реакция просветлённого тест-менеджера
Условие Действие
Простой продукт, • Совместный разбор спорных, сложных дефектов
маленькая команда
Сложный продукт • Анализ причин, влияющих на баги: настроек и
параметров
• Проведение внутренних тренингов по
локализации багов и по архитектуре продукта
• Шаблоны дефектов, правила «что должно быть в
баге обязательно»
• Наставники по заведению дефектов
Большая команда • Оценки в баг-трекере (проставляются
разработчиком в момент исправления)
• Анализ оценок, слабых мест, что нужно улучшать
• Внедрение роли «дефектный контроллѐр»
21. Реакция просветлённого тест-менеджера
1. Анализ причин 2. Учѐт результатов анализа
• С • Тестирование требований
аналитиком, внедрен • Обсуждение улучшений с
цем, РМ’ом проектной командой
• Самостоятельно – • Переход тестирования в
через QC
анкетирование, набл
юдение, опросники
25. Рабочий день просветлённого тест-менеджера
1. Ежедневный анализ: что важно, а
что нет?
2. Какие текущие приоритеты?
3. Что из моих задач можно
делегировать?
28. Выводы для ПТМ
1. По каждой проблеме –
анализ причин и
превентивные меры
2. По каждой цели –
выработка метрик для
своевременных изменений
3. Каждый день – вопрос: что
нужно улучшить
сегодня, чтобы не было
проблем завтра?