QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Как оценить время на тестирование. Александр Зиновьев, Test Lead SoftengiSoftengi
Презентация Александра Зиновьева, Test Lead компании Softengi, на семинаре "Оценка в жизни тестировщика" от тренинговой центра QAS Training Center, который прошел 27 ноября в пространстве Циферблат, Киев.
QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Как оценить время на тестирование. Александр Зиновьев, Test Lead SoftengiSoftengi
Презентация Александра Зиновьева, Test Lead компании Softengi, на семинаре "Оценка в жизни тестировщика" от тренинговой центра QAS Training Center, который прошел 27 ноября в пространстве Циферблат, Киев.
This document discusses quality assurance (QA) practices in Agile teams. It emphasizes that quality is a team responsibility and outlines four levels of quality. It also stresses the importance of properly defining requirements, roles, and processes upfront in documents like the Statement of Work and during foundation sprints. Additionally, it recommends practices like grooming, planning, and demos to ensure common understanding and gather feedback from stakeholders throughout the development process. Regular retrospectives and direct customer involvement are also presented as important for building trust within Agile teams.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Презентация со встречи QA Club Minsk 11 декабря 2013 г., посвященная одному из поппулярнейших инструментов тест-менеджмента Test Link, автор Вадим Зубович
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...solit
Зубович Вадим, Минск. Опыт в IT более 5 лет, работает в компании ISSoft, специализация: разработка (.NET C# ASP\MVC, WPF, WinForm, Java) и автоматизация функционального тестирования програмного обеспечения (Web, Desktop, Mobile) и тестирования производительности (Web).
«Сравнительный анализ инструментов для автоматизации тестирования мобильных приложений». Development секция. Отделение тестирования.
Мобильные платформы уже набрали огромную популярность, и продолжают наращивать обороты. Ни один разработчик уже не обходит стороной мобильные приложения и автоматизация тестирования в этой сфере актуальна как никогда.
В настоящем докладе мы рассмотрим наиболее популярные и перспективные инструменты для автоматизации тестирования приложений для мобильных операционных систем iOS, Android и WindowsPhone, проведем анализ их особенностей и возможностей, основываясь на опыте их использования в рамках реальных проектов, а также подведем общий итог с рекоммендациями по выбору того или иного инструмента.
«Централизованное управление тестами с помощью TestLink». Development секция. Отделение тестирования.
Эффективное управление тестами это не только грамотный тим-менеджмент, это еще и правильный учет, контроль результатов и своевременное и централизованное обновление информации о тестах для всех участников процесса и силами всех участников процесса.
Достичь этого невозможно без системы управления тестами, позволяющей эффективно распределить права и обязанности участников и обеспечить постоянное поддержание информации о тестах в актуальном состоянии.
TestLink – бесплатный инструмент, предназначенный именно для выполнения этой задачи.
В рамках доклада мы рассмотрим:
1. Как устроен TestLink
2. Как построить работу с TestLink
3. Как создавать информативные отчеты в TestLink
4. Как наладить связь между автоматизацией и TestLink
The practical story telling how Devops changed the culture of quality in the Bank. Recently Devops became mainstream topic. But only few people have a deep understanding how to apply it to the process of software quality assurance. Some believe that the Devops kills manual testing.
I will talk about changes it makes to the role of QA engineers themself. The discussion main point is NOT about tools or technologies. It’s NOT about the “silver bullet” for your problems with the quality of products.
Instead, I will show you an integrated approach which we used for quality assurance. It allowed us to significantly reduce the cost of finding and fixing defects. This approach has also accelerated the development and delivery value to our customers and made the whole process more transparent and predictable.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
Практический доклад о том, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование.
В докладе рассмотрены основные проблемы, с которыми команда столкнулась при внедрении и способы их устранения.
Продемонстрированы результаты, которых смогли достичь в течении полугода.
Доклад содержит большое количество лайфхаков и обзоров инструментария, который использовался для достижения цели.
This document discusses continuous performance testing (CPT) and introduces the Jagger CPT solution. It provides an overview of why performance testing is important, outlines the principles and goals of CPT, and describes the key parts of the Jagger CPT platform including load generation, metrics collection, test data management, and environment management. It also provides an example customer success story where Jagger was used for continuous performance testing of a large ecommerce site.
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
This document provides an overview of the JDI (Java UI test automation framework). It discusses features of JDI including being UI element oriented, providing common UI elements and solutions to common problems. It provides examples of how to write tests using JDI annotations and page object pattern. The document also summarizes benefits of JDI such as reducing test code, improving test clarity, reuse across projects. Finally it outlines new features planned for JDI 2.0 including layout verification, page object generator, integration with Selenium and expanding JDI to other languages like Python.
The document discusses testing of geolocation systems. It provides an overview of geolocation, including definitions and importance. It then outlines the speaker's experience and work testing GIS systems. The rest of the document details approaches to testing geolocation, including simulating calls, checking responses and databases, and verifying accuracy. It also discusses common data formats, projections, tools like PostGIS and QGIS, and potential bugs to watch for like coordinate jumbling. The conclusion emphasizes starting simple, practicing to improve, and for tests to grow with knowledge as geolocation is important for future IT.
2. Обеспечение качества в
рамках компании
Quality
Assurance
Processes
Matured Processes
Iterative Testing Cycle
ISO 9001 & 27001
Technologies
E Business
Client/Server
CRM
Infrastructure
Test Management
Test Automation
Requirements
Management
Issue Tracking
Communication
People
Experienced Staff
ISTQB Certified
Automation Experts
Measurements
Code
Development Process
Testing Process
02/21
3. Проблемы
• Много найденных багов
• Нехватка времени
• Сдвиг даты релиза
• Нагрузка в конце итерации
• Низкое качество проекта
• Баги с продакшен-сервера
• Неудовлетворенность заказчика
03/21
4. Пути решения
• Много найденных багов - > Предотвращение типичных багов
• Нехватка времени - > Распараллеливание задач
• Сдвиг даты релиза - > Нахождение проблем на ранних этапах
• Нагрузка в конце итерации - > Мини-регрессии по ходу итерации
• Низкое качество проекта - > Обеспечение качества на всех этапах
• Баги с продакшен-сервера - > Анализ и предотвращение
• Неудовлетворенность заказчика - > Выполнять все пункты выше...
04/21
5. Спецификация
#1. Хранение: Единая точка (Confluence / SVN)
#2. Декомпозиция и именование каждого реквеста: Понятно,
лаконично, с наличием прямой ссылки на каждый реквест
#3. Обратная связь с заказчиком: Открытый доступ для review
#4. Заносятся ВСЕ требования, включая казалось бы мелкие
ПОЛЬЗА:
Требования в одном месте и каждый таск в Jira чётко на них ссылается;
обратная связь снижает риски ошибок в требованиях. ВРЕМЯ!
05/21
6. Планирование итерации
#5. Вдумчивый анализ и составление вопросов
#6. Участвуют ВСЕ
#7. Создание приёмочных тестов (DEV & QA)
#8. Переход к Test Design сразу после планирования итерации
#9. Декомпозиция задач
ПОЛЬЗА: Все в курсе что будет делаться; многосторонняя точка
зрения и разнообразные вопросы; обнаружение проблем на ранних
этапах. Четкое понимание что нужно делать. ВРЕМЯ!
06/21
7. Работа с тест кейсами
#10. Тесты описывают только то, что они должны проверять
ПОЛЬЗА: Исключение избыточности, легкость в поддержке
#11. Создаваемый тест кейс рассчитан на незнающего проект человека
ПОЛЬЗА: Обучение проекту; привлечение специалиста со стороны,
включая программистов на проекте (agile). ВРЕМЯ!
#12. Введение дополнительных параметров тест кейса
ПОЛЬЗА: Удобство при формировании и запуске тест сета. ВРЕМЯ!
#13. Unit-test по запросу
ПОЛЬЗА: Вынос проверки на уровень сборки. РИСКИ!
#14. Проведение рефакторингов тестовых сценариев
07/21
8. Оптимизация тест кейсов
#15. Используем тестовые данные (sample data, полу-автоматизация)
Иструмент: Apache ant (db-load, db-export)
ПОЛЬЗА:
- Единая терминология в рамках команды
- Компактные тест кейсы и баги
- Ускорение запуска тест кейсов и устранение человеческого фактора
08/21
9. Различные виды тестов на
все случаи жизни
#16. Различные виды тестов на все случаи жизни
• Sanity - поверхностные тесты
• Urgent – основной функционал
• Functional – детализированное описание фичи
• Cross – связь между различными функциональностями
• Comprehensive – ключевые функциональности в рамках схожего
поведения (Пример: Email sending - Entry points)
• Bugs list – список багов по функциональности
• Checklists – список ключевых аспектов функциональности
• Must haves – тест кейсы, которые выполняются в каждой итерации
• Автоматические функциональные скрипты
• Автоматические нагрузочные скрипты
• Проверка безопасности
09/21
10. Верификация тасков
#17. Code-review (Tech Lead) РАННЕЕ ОБНАРУЖЕНИЕ!
#18. Доступность билдов и умение работать с ними автономно ВРЕМЯ!
#19. Верификация тасков в параллели
ПОЛЬЗА: Более ранняя загрузка программиста, нахождение критичных
проблем на ранних стадиях. ВРЕМЯ! РИСКИ!
#20. Постоянное общение с программистом после любого фикса
ПОЛЬЗА: Всеобъемлющая проверка на ранней стадии. РИСКИ!
10/21
11. Работа с багами
#21. Заносим всё, что находим (используем контейнеры)
#22. Не полагаемся на память программиста
#23. Создаем покрытие на любой баг
#24. Указываем номер бага в тест кейсе
#25. Анализируем баг глубже
#26. Помечаем баги с продакшен-сервера и анализируем их
11/21
12. Детализация багов
#27. Детализируем заносимые баги
Keywords:
- Воспроизводимость
- Cсылка на требования
- Точная версия билда (старый баг?)
- Точный список окружения / компонент в приложении
- Минимизация шагов / лаконичный скриншот
- Log-файл с ошибкой
- Приоритет / итерация для фикса / исполнитель по-умолчанию
- Дополнительная информация: проблемный коммит / workaround /
покрытие / возможный фикс / места невоспроизводимости
ПОЛЬЗА: Предотвращение занесения невоспроизводимых багов;
экономия времени программиста; понятное, наглядное и
локализованное обнаружение проблемы. ВРЕМЯ!
12/21
13. Формирование тест сетов
• Features verification
#28. Выполнение теста по частям; обязательная финализация фичи
• Bug-fixing / verification
#29. Проведение мини-регрессий
• Release candidate testing
#30. Детальный и вдумчивый анализ всех изменений итерации
#31. Знание о доступном времени
#32. Привлечение PM’a к составлению тест сета
#33. Балансирование между КОЛИЧЕСТВО - ВРЕМЯ - КАЧЕСТВО
• Sanity check на продакшен-сервере
#34. Проверка сервер-ориентированных и новых функциональностей
13/21
14. Артефакты тестирования
#35. Наличие собственного тестового сервера (аналог продакшена)
#36. Создание словаря терминов, опросников, диаграмм зависимостей,
различная документация по настройке и автономной работе с проектом
Примеры:
- Single feature опросник - “New format”
- Connection and deploy on the test server
- Setting up test PC for Automation
14/21
15. Обеспечение качества
процесса
#37. Слежение за выполнением регламентированных процессов:
Milestones (Features Complete, Code Freeze), Commit программиста,
Закрытие сущности в Jira
#38. Создание и постоянный апдейт таких документов как Test Plan,
Known Issues, Main functionality and features list, Releases and hot-fixes
#39. Анализ unresolved сущностей в баг-трекинг системе
Keywords: актуальность; новые детали; соответствие приоритету
#40. Периодический анализ логов на продакшен сервере
#41. Своевременное “бранчевание”
#42. Распределение браузеров между командой
#43. Инициирование своевременных demo для заказчика
#44. Создание “Cписка улучшений” для review заказчику
15/21
16. Автоматизация
#45. Автоматизируем только важные и стабильные фичи
#46. Создаем кросс-функциональные скрипты на основе
Regions.Compare (TestComplete 7)
#47. Создаем скрипты для тестирования Web Services (soapUI)
#48. Включаем всю автоматизацию в Continuous Integration процесс с
ежедневным отчетом
ПОЛЬЗА: Нахождение проблем на ранних этапах; уменьшение
времени на регрессию; уменьшение времени на update.
#49. Используем вспомогательные приложения: SnagIT, AutoIT,
BCompare, Araxis Merge, SeleniumIDE
ПОЛЬЗА: Простой уровень вхождения; требуют мало времени на
освоение, но дают хороший эффект на выходе
16/21
17. Производительность
#50. Создание скриптов, позволяющих создать нагрузку (LoadRunner,
JMeter) / поиск нагружаемых функциональностей в проекте (Search)
#51. Проверка возможной просадки производительности перед
релизом на идентичных продакшен-серверу мощностях (load / no load)
#52. Периодический анализ sqlslow лога на продакшен-сервере
17/21
18. Безопасность
#53. Написание и выполнение инструкции по SQL injections
#54. Создание Must have тест кейса по авторизации пользователя и
проверке доступа к данным
#55. Периодический анализ используемых 3'd party компонентов
(exim4, proftpd, etc) на предмет актуальности версии, проблем с
безопасностью, инициирование апгрейда в случае нахождения
потенциальных угроз (http://www.cvedetails.com)
18/21
19. Сохранность данных и
поддержка
#56. Инкрементальный бекап (binlogs)
#57. Репликация данных (резервный сервер базы данных)
#58. Маскирование данных в продакшен-дампах, используемых
локально (email address, passwords, skype, phones, etc)
#59. Настройка уведомлений команде в случае непредвиденных
ошибок с детальным логом ошибки (email, sms)
#60. Pingability – слежение за доступностью сервера из разных мест
#61. Анализ данных из Google Analytics (используемые браузеры,
время наибольшей активности, нагрузки)
19/21
20. Активности после релиза
#62. Ретроспектива
• Приведение статистики по состоявщемуся релизу проекта
• Озвучивание новых или старых проблем; поиск путей решения
• Улучшения в процессе: выработка лучшего решения
• Cоздание и занесение протокола в Confluence
#63. Дополнительные активности после релиза
• Хранение релизного билда и всей отчетности по релизу
• Добавление новых функциональностей в опросники
• Обновление приемочных тестов
• Анализ невыполненных QA-тасков
• Поиск потенциальных целей для автоматизации
20/21