Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
Работа с бизнес-требованиями на стадии выхода продуктаSQALab
The document discusses user stories in user acceptance testing (UAT) time. It covers why changes to user stories during UAT need to be discussed, provides examples of common types of changes like changing a story's size or adding support, and examines what those changes mean for tasks like code, design, and testing updates. It poses the question of whether such changes can be prevented.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
Работа с бизнес-требованиями на стадии выхода продуктаSQALab
The document discusses user stories in user acceptance testing (UAT) time. It covers why changes to user stories during UAT need to be discussed, provides examples of common types of changes like changing a story's size or adding support, and examines what those changes mean for tasks like code, design, and testing updates. It poses the question of whether such changes can be prevented.
Пирамида Тестирования через призму ROI калькулятора и прочая геометрияSQALab
This document provides information about test automation strategies and calculating return on investment (ROI) for test automation. It discusses the test pyramid approach, with unit tests at the base comprising the largest percentage (around 70-80%) and user interface tests at the top comprising the smallest percentage (around 1-5%). It also discusses factors to consider for ROI calculations, such as effort required for manual vs automated testing, and when the investment in automation will pay off. Sources of information on these topics are provided. The document aims to help understand how to apply test automation strategies and ROI calculations for a specific project context.
This document discusses various topics related to psychology, testing, and introducing change. It addresses resistance to change and how people can get stuck playing psychological games and drama triangles. It emphasizes that knowing you are playing a game can help change your perspective, and provides tips for refusing to play expected roles and making games less attractive or harder to engage in. The overall content suggests that understanding psychology, human behavior, and group dynamics is important for successfully introducing things like structured testing or other changes.
The document discusses pairwise testing as a technique for reducing the number of test cases needed to cover all combinations of parameters. It shows that using pairwise testing on a problem with 10 parameters, each with multiple values, reduces the number of test cases from over 36 million to just 97 test cases, cutting the estimated testing time from over 2016 man years to just 1 man day. Pairwise testing provides nearly 100% coverage of defects using far fewer tests than exhaustive testing of all combinations.
- The speaker proposes 16 "test axioms" that are intended to provide a framework for testing approaches and represent principles that are context-insensitive and self-evidently true.
- The axioms are grouped into three categories: stakeholders, design, and delivery. The speaker argues the axioms can help testers think critically about testing and identify flaws in arguments.
- It is argued that process improvement models are not effective for improving testing because there is no consensus on best practices and processes must be tailored to context. True improvement requires understanding why current approaches are used given the context.
This document provides an overview of approaches to achieving zero defects in software development. It discusses how adopting a "zero defects" attitude can reduce defects by 50% overnight. It emphasizes defect prevention through proper root cause analysis and design reviews over testing. Iterative design, implementation, and review cycles are recommended to find and address issues early. The goal of quality assurance is to help developers produce fewer defects by focusing on prevention rather than finding defects after the fact. The ultimate goal is to deliver working software to customers with "no questions and no issues."
This document discusses why checklists are better than test cases for documentation in quality assurance. It argues that test cases become overcrowded and focus too much on documentation rather than core functions. Checklists are more time-saving and easy to update. An example compares a test case to a checklist for login/registration flows. The author's company Hipo uses a test pad and robot framework integrated with checklists to share with clients and team members.
Процесс тестирования в условиях неявных требований COMAQA.BY
В условиях изучения и кастомизации ПО с открытым кодом, бизнес-аналитики формируют высоко-уровневые требования, детализация появляется в ходе разрабтки девелоперами или после отзывов заказчика. Тестировщики в этой ситуации имеют не четкие требования и недовольство девелоперов отвлекающихся на разъяснения "как это сделано". Как мы решили эту задачу - будет рассказано на живом примере в моём докладе.
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...Tech Talks @NSU
http://techtalks.nsu.ru
5 апреля 2012. Организация тестирования в IT-компаниях Академгородка. Карьерный путь тестировщика (Мария Колчинская, AcademSoft)
«Мария Колчинская (AcademSoft) рассказывает о процессах тестирования и карьере тестировщика»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Эффективное мобильное решение, разработанное Mobile Dimension, для проведения аудита торговых точек для супервайзеров, торговых аудиторов и сотрудников отделов маркетинга ритейл-сетей
Новый процесс тестирования на "старом" проектеCOMAQA.BY
Как часто вам приходилось сталкиваться с построением процессов на проекте, который существует десятки лет, но заказчик только начал с вами сотрудничество и хочет начать всё с чистого листа?
В своем докладе Александр расскажет:
- с чего начать при старте нового процесса на уже существующем проекте
- как не повторять ошибок прошлых команд
- рассмотрю с какими сложностями можно столкнуться при построении процессов
- как использовать те инструменты, которые предоставил заказчик и выжать из них максимум
- как внедрить бесплатные решения и доказать, что они тоже эффективны и применимы на практике
- как автоматизировать отчетность тестирования
Новый процесс тестирования на "старом" проектеCOMAQA.BY
Как часто вам приходилось сталкиваться с построением процессов на проекте, который существует десятки лет, но заказчик только начал с вами сотрудничество и хочет начать всё с чистого листа?
В своем докладе я расскажу:
с чего начать при старте нового процесса на уже существующем проекте
как не повторять ошибок прошлых команд
рассмотрю с какими сложностями можно столкнуться при построении процессов
как использовать те инструменты, которые предоставил заказчик и выжать из них максимум
как внедрить бесплатные решения и доказать, что они тоже эффективны и применимы на практике
как автоматизировать отчетность тестирования
Особенности внедрения оперативного учета на автосервисных предприятияхКлуб черного 1С-ника
Презентация к видео с шестой встречи клуба: http://club-1c.zfilin.org.ua/2013/10/blog-post_25.html
Анонс встречи: http://club-1c.zfilin.org.ua/2013/10/blog-post_9.html
Количественно - качественные бережливые показатели (операционные, мощности, финансов) оценки эффективности мероприятий по переводу предприятий с традиционных систем "массового" производства на системы "бережливого" производства
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.
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
Процесс тестирования в условиях неявных требований
1. Software quality assurance days
20 Международная конференция
по вопросам качества ПО
sqadays.com
Минск. 24–26 ноября 2016
Егор Сосковец
ООО Лаборатории Инвенто. Минск, Беларусь
Процесс тестирования в условиях неявных
требований
2. Процесс тестирования в условиях неявных требований
О себе
• Более 20 лет опыта в IT
• Прошел путь от функционального
тестировщика, через WEB Developer,
Test Manager, Lead Developer и до
Delivery Manager
• Основная специализация: комплексная постановка
процессов разработки, тестирования и доставки
продукта как в рамках отдельного проекта, так и в
компании в целом
3. Процесс тестирования в условиях неявных требований
Зачем этот доклад?
1.продемонстрировать, что отсутствие четких
требований не является блокирующим моментом в
достижении качества продукта, поставляемого
заказчику
2.доказать, что в условиях неявных требований – тест-
документация становится единственным артефактом,
на который можно “опереться”
3.внушить уверенность: тестовая документация может
быть любого формата, именно такого, что-бы
требовать минимального обслуживания и давать
максимальную отдачу, уточняя собой неявные
требования
4. Процесс тестирования в условиях неявных требований
О проекте
• Ранее клиент работал с двумя разрозненными,
которые было необходимо объединить с полным
сохранением исторических и текущих данных
• Принято решение произвести кастомизацию системы
CRM+ERP на основе приложения с открытым кодом
(Odoo) в соответствии с требованиями заказчика
• Помимо внедрения нового приложения требовалось
внести изменения в бизнес-процесс предприятия в
целом
5. Процесс тестирования в условиях неявных требований
Пользовательский интерфейс: было - стало
10. Процесс тестирования в условиях неявных требований
Пример тест-кейса:
Title: CRM / Обработка Клиента: форма "Регистрация платежа“
Description:
Precondition
Пользователи: Администратор КО(ko_admin), Вася Пупкин (vpu)
Steps
1.Войти в систему как Администратор КО -> нажать кнопку Администратор КО -> в выпадающем
списке нажать О программе -> нажать кнопку Активировать режим разработчика -> Главное
меню настройки -> Пользователи -> выбрать пользователя Администратор КО -> Изменить ->
ЮрСпектр Горячая линия поставить роль Сотрудник
2.Главное меню Горячая линия -> Все заявки -> Создать -> Заполнить поля Сохранить -
> Отправить в обработку
3.Expected results: В списке заявок появилась заявка, автор которой Администратор КО
4.Войти в систему как Вася Пупкин -> Главное меню Горячая линия -> Все заявки -> Создать ->
Заполнить поля -> Ответственным указать Администратор КО -> Сохранить -> Отправить в
обработку
5.Войти в систему как Администратор КО -> Главное меню Горячая линия -> Все заявки
6.Expected results: В списке заявок появилась заявка, ответственным на которую назначен
Администратор КО.
11. Процесс тестирования в условиях неявных требований
Столкновение с реальностью: выход в «PROD»
14. Процесс тестирования в условиях неявных требований
Пример чеклиста
Title: Клиенты / Клиенты / Заявки на счета: проверка позиций заявки типа
«Актуализация»
Description:
1.Создать заявку типа "Актуализация"
2.Добавить позиции заказа(проверить, что в поле "Система" доступны только
необслуживаемые системы, у которых дата окончания подписки не позже 1-ого числа
предыдущего месяца)
3.Проверить, что в поле "Программа" указывается вид услуг:
актуализация,обслуживание,понижение и/или переход
4.Проверить, что программа любого вида услуг соответствует выбранной системе, в
зависимости от текущей системы или ее перехода/понижения
5.Проверить, что в списке программ присутствуют необходимые актуализация и
обслуживание в зависимости от перехода/понижения системы
6.Проверить, что в поле "Количество" значение ограничено 60-ю месяцами
7.Проверить, что при указании начала подписки указывается окончание подписки(начало
подписки+значение поля "Количество")
8.Проверить, что в поле "Величина скидки (%)" тянется скидка, указанная в системе
15. Процесс тестирования в условиях неявных требований
Вывод
Вы можете не иметь четких требований к системе как на
страте проекта, так и при выходе в продакшен.
Ваши заказчики могут менять требования изо дня в день.
В такой ситуации требованиями к системе становится
тестовая документация – это единственный артефакт,
который позволит вам чётко отследить внесенные
изменения в систему и обеспечить её качество.
16. Процесс тестирования в условиях неявных требований
Спасибо за внимание
Вопросы?
Mail: esoskovets@mail.ru
Skype: net-ego.net