QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
by Yuri Vedenin
Автор: Юрий Веденин
Мини-доклад для апрельской встречи белорсского сообщества специалистов по обеспечению качества и тестированию belqa.by
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
Держим дизайн системы под контролем, используя изолированное юнит-тестировани...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2637.html
Код наших систем со временем загнивает из-за низкого качества обратной связи, которую дают интегрированные тесты.
Под интегрированными тестами я подразумеваю юнит-тесты, прохождение или падение которых зависит более чем от одной единицы нетривиального поведения. Очень часто в индустрии мы вместо быстрых и изолированных юнит-тестов пишем тесты, которые запускают на исполнение большие объемы кода или общаются с базой данных через ActiveRecord.
...
by Yuri Vedenin
Автор: Юрий Веденин
Мини-доклад для апрельской встречи белорсского сообщества специалистов по обеспечению качества и тестированию belqa.by
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
Держим дизайн системы под контролем, используя изолированное юнит-тестировани...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2637.html
Код наших систем со временем загнивает из-за низкого качества обратной связи, которую дают интегрированные тесты.
Под интегрированными тестами я подразумеваю юнит-тесты, прохождение или падение которых зависит более чем от одной единицы нетривиального поведения. Очень часто в индустрии мы вместо быстрых и изолированных юнит-тестов пишем тесты, которые запускают на исполнение большие объемы кода или общаются с базой данных через ActiveRecord.
...
Standard Provenance Reporting and Scientific Software Management in Virtual L...njcar
The Virtual Hazards Impact & Risk Laboratory (VHIRL) is a scientific workflow portal that provides researchers with access to a cloud computing environment for natural hazards eResearch tools. It allows researchers to construct experiments with data from a variety of sources and execute cloud computing processes for rapid and remote simulation and analysis. The service currently includes tools for the simulation of three major hazards affecting the Asia-Pacific region: earthquakes, tsunamis and tropical cyclones.
For scientific results, the establishment of provenance is key to reproducibility and trust. Thus the need for any virtual laboratory to provide provenance information for the tasks it manages is obvious, but the appropriate way to report and manage provenance information is not always so straightforward. Many virtual laboratories and workflow systems provide bespoke provenance management with a focus on internal system use. This has clear benefits for reproducibility within the system, but it limits the interoperability of systems. For VHIRL, a provenance solution was required that was as
interoperable with other, external, provenance systems as possible.
A related common issue facing workflow tools and virtual laboratories is the need to manage software code. With this comes well-known issues associated with code sharing: licensing, source code management, version management and dependency resolution. There are a wide selection of commonly used tools to help solve these problems, for example Git and Subversion.
A key goal of VHIRL was to externalise as much information management as was reasonable. VHIRL is a virtual laboratory: it is not designed to be a data store, software repository, or records management system. A solution was required that could hand off the management of provenance records and code to external services, with links between them, other data services and VHIRL jobs where appropriate.
Scientific software can be quite complicated and systems for managing dependencies and source vary from system to system. In order to provide the least friction for authors of software, we designed a system called the Scientific Software Solution Centre (SSSC) to manage solutions to scientific problems and deliver the solution templates, code and dependencies that enable them for use in VHIRL and other Virtual Laboratories and applications.
Executing Provenance-Enabled Queries over Web DataeXascale Infolab
The proliferation of heterogeneous Linked Data on the Web poses new challenges to database systems. In particular, because of this heterogeneity, the capacity to store, track, and query provenance data is becoming a pivotal feature of modern triple stores. In this paper, we tackle the problem of efficiently executing provenance-enabled queries over RDF data. We propose, implement and empirically evaluate five different query execution strategies for RDF queries that incorporate knowledge of provenance. The evaluation is conducted on Web Data obtained from two different Web crawls (The Billion Triple Challenge, and the Web Data Commons). Our evaluation shows that using an adaptive query materialization execution strategy performs best in our context. Interestingly, we find that because provenance is prevalent within Web Data and is highly selective, it can be used to improve query processing performance. This is a counterintuitive result as provenance is often associated with additional overhead.
Когда код «убивает», или зачем нам тестировать наши продуктыОлег Стрекаловский
Доклад посвящен теме тестирования и надёжности ПО. Что вы получаете, когда забываете о качестве разрабатываемого продукта и "куда копать", если вы вдруг решите начать проверять то, что у вас разрабатывается.
Ольга Лужецька - Exploratory testing: Love it or Leave it?DataArt
Є думка, що exploratory testing - це хаотичний процес, яким важко керувати. Ми розберемось, чи можна організувати exploratory testing так, щоб продукт був крутим та якісним, ризики більш передбачувані, а тестувальники отримували задоволення.
A presentation I've made for Computer Science students of St. Petersburg State University to talk about the professions within IT sphere. Contains several screenshots from Futurama
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Как улучшить удобство продукта минимальными затратами?Oleg Karapuzov
Эта презентация рассчитана на людей связанных с IT , которые занимаются разными проектами. Презентация поможет людям задуматься над тем что они делают и для кого. Думаю просмотрев презентацию вы сможете сделать свои проекты лучше!
2. Жизненный цикл ПО
• Каждая вещь в этом мире проживает свою жизнь. Мы стараемся продлить жизнь
разработанным нами приложениям, поэтому я хочу познакомить тебя с понятием
жизненного цикла ПО.
• А так же его моделями, их 4. Там есть водопад и итеративная модель. Найди
остальные и запиши определения.
• И не забудь про плюсы и минусы каждого вида ;).
3. Тестирование.
• Работа тестировщика заключается в том, чтобы предоставить актуальную картину
работы системы. А так же, локализовать проблемы в работе системы.
• Сегодня тебе нужно записать основные понятия: кто такой тестировщик, тест кейс,
тест план, тестовый сценарий, чек лист, баг и баг репорт.
4. Откуда же берется ПО?
• И как оно появляется?
• Подумать и выяснить откуда оно берется, как формируется, каким мы ( команда
разработчиков) его получаем.
5. Требования к ПО.
• Анализ требований – что это такое?
• Найти и узнать, что такое: Decigion table, State transition testing, Варианты
использования.
• Плюсы и минуса каждого вида.
6. Самостоятельная работа
• Для каждого вида анализа требования составить план по примеру работе почтовой
системы Mail.ru, Gmail, Яндекс.Почта.
• На бумаге, руками.
7. ТЗ.
• Ответить на вопросы:
Что такое ТЗ и как его тестировать?
Кто заказчик?
Что делает софт?
Зачем нам его делать?
Какой результат работы?
• Подумать: Какими свойствами должно обладать ТЗ для того или иного проекта.
8. Работа с ТЗ.
• Разобрать готовый пример ТЗ.
• Какие свойства должны быть у ТЗ?
9. Документация по проекту.
• Ответить на вопросы:
• Какая может быть документация по проекту?
• Где она хранится?
• Как ее тестировать?
• Разобрать на примере диска c MS Office.
10. Виды тестирования.
• Записать определения и свойства.
• Определить какой вид тестирования для какой части приложения нужен.
11. Более близкое знакомство с понятиями.
• Записать определения: тест кейс и чек лист.
• Ответить на вопросы:
• Что это такое?
• Для чего?
• Что с ними делать?
• Составить 5 штук тест кейсов по загрузке видео на Youtube и чек лист для заполнения
формы регистрации.
12. Варианты анализа
• Составить варианты анализа для приложения Ulect, по примеру видов от 19
ноября.
• По 1 варианту на каждый вид.
13. Баг.
• Записать определение.
• Какие отличительные черты?
• Привести примеры.
• Ответить на вопрос:
• А почему именно это баг, а вот это нет?
14. Баг репорт.
• Найти определение и примеры.
• Если не найдешь, попроси у Оли пример.
• Составить 5 баг репортов.
