10 правил agile тестировщика IT-Brunch

•

2 likes•3,493 views

10 правил Agile тестировщика

Андрей Дзыня

Andrii Dzynia
Test Engineer/Consultant/Trainer

@adzynia

http://adzynia.com

Техники Тест Дизайна
Equivalence Class Domain Analysis
Testing Testing
Boundary Value Use Case Testing
Testing Control Flow Testing
Decision Table Testing Data Flow Testing
Pairwise Testing
State-Transition
Testing
“Practitioners Guide To Software Test Design” Lee Copeland

http://www.adzynia.com/2012/01/5.html

Но чаще всего

10. Постоянно улучшаться

9. Приносить ценность продукту

8. Заряжать духом тестирования

7. Смотреть по сторонам

6. Исследовать и экспериментировать

5. Знать все практики тест дизайна

4. Дружить с программистом

3. Обладать техническими знаниями

2. Задавать неудобные вопросы

1. Быть смелым и решительным

10 принципов Agile тестировщика
Быть смелым и решительным
Задавать неудобные вопросы
Обладать техническими знаниями
Дружить с программистом
Знать все практики тест дизайна
Исследовать и экспериментировать
Смотреть по сторонам
Заряжать духом тестирования
Приносить ценность продукту
Постоянно улучшаться

http://adzynia.com

@adzynia

me@adzynia.com

More Related Content

What's hot

KPI тестировщиков - особенности и проблемы

KPI тестировщиков - особенности и проблемы

KPI тестировщиков - особенности и проблемы

Great functional testing with WebDriver and Thucydides

Great functional testing with WebDriver and Thucydides

Great functional testing with WebDriver and Thucydides

Mikalai Alimenkou

Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

Улучшить KPI в два раза? Сделано!

Улучшить KPI в два раза? Сделано!

Улучшить KPI в два раза? Сделано!

Темная сторона метрик

Темная сторона метрик

Темная сторона метрик

- История проекта (с чего началось внедрение SCRUM в QA команде, какая была команда и тп) - Тестирование в идеальном Agilе (как происходит построение процесса в идеале и что мы можем получить) - Советы тестировщику в Agile - Показатели или что от нас хочет Product Owner - Что мы добавили в обычное SCRUM тестирование и какой получили результат Выводы что дал SCRUM команде и как поменялась

QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.

QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.

QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...

Автоматизация тестирования визуальных регрессий, как особый вид тестирования, может поставить в тупик даже опытных специалистов своей отрасли. Тем более, если речь идёт об адаптивном дизайне. Задача тестирования адаптивной верстки не является простой, хотя бы по той причине, что требует большого времени на проверку отображения визуального контента и покрытие всей требуемой матрицы платформ, браузеров и разрешений экрана. Тем не менее существуют способы эффективного использования таких инструментов как Galen Framework и Applitools Eyes и интеграции их в уже существующую среду тестирования. На наглядном примере сайта, имеющего адаптивный дизайн, я расскажу о том, как можно с лёгкостью применять вышеуказанные инструменты с целью избежать как можно больше разнообразных регрессионных визуальных ошибок. Также будут подробно рассмотрены варианты построения архитектуры тестов и организации работы с дизайном приложения в целом.

Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...

Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...

Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...

Start Agile 2007

Start Agile 2007

Start Agile 2007

Can we have some more quality - Russian version

Can we have some more quality - Russian version

Can we have some more quality - Russian version

Alexander Pushkarev

Доклад для ленивых тестировщиков, которые не хотят набивать свои шишки, а научится на чужом опыте: - полезные инструменты и решения для тестирования; - работа с сетью, внутренними и внешними сервисами; - процессы и культура тестирования в отделе разработки - silver bullet в конце доклада

QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...

QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...

QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...

Принципы «правильной» автоматизации всем хорошо известны, но почему-то даже опытные автоматизаторы не всегда им следуют. Допуская ошибки одну за другой, мы и не замечаем, как укорачиваем жизнь нашим авто-тестам. В результате, нередко случается так, что наши решения со временем забрасываются и не выживают, либо же превращаются в «чемодан без ручки» - когда нести тяжело, а выбросить жалко. Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли. Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.

QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...

QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...

QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...

Фокус тест

Agile Testing: вопросы и ответы

Agile Testing: вопросы и ответы

Agile Testing: вопросы и ответы

Промышленный подход к автоматизации тестирования или Keyword-driven testing в...

Промышленный подход к автоматизации тестирования или Keyword-driven testing в...

Промышленный подход к автоматизации тестирования или Keyword-driven testing в...

Continuous Integration для тестировщиков

Continuous Integration для тестировщиков

Continuous Integration для тестировщиков

Uladzimir Kryvenka

Continuous Integration для QA

Continuous Integration для QA

Continuous Integration для QA

Ivan Kolodyazhny

What's hot (18)

KPI тестировщиков - особенности и проблемы

KPI тестировщиков - особенности и проблемы

KPI тестировщиков - особенности и проблемы

Great functional testing with WebDriver and Thucydides

Great functional testing with WebDriver and Thucydides

Great functional testing with WebDriver and Thucydides

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

Улучшить KPI в два раза? Сделано!

Улучшить KPI в два раза? Сделано!

Улучшить KPI в два раза? Сделано!

Темная сторона метрик

Темная сторона метрик

Темная сторона метрик

QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.

QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.

QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...

Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...

Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...

Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...

Start Agile 2007

Start Agile 2007

Start Agile 2007

Can we have some more quality - Russian version

Can we have some more quality - Russian version

Can we have some more quality - Russian version

QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...

QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...

QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...

QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...

QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...

QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...

Фокус тест

Agile Testing: вопросы и ответы

Agile Testing: вопросы и ответы

Agile Testing: вопросы и ответы

Промышленный подход к автоматизации тестирования или Keyword-driven testing в...

Промышленный подход к автоматизации тестирования или Keyword-driven testing в...

Промышленный подход к автоматизации тестирования или Keyword-driven testing в...

Continuous Integration для тестировщиков

Continuous Integration для тестировщиков

Continuous Integration для тестировщиков

Continuous Integration для QA

Continuous Integration для QA

Continuous Integration для QA

Similar to 10 правил agile тестировщика IT-Brunch

Sef Streluk Agile

Sef Streluk Agile

Sef Streluk Agile

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

Роман Кокин «Организация тестирования в больших командах»

Роман Кокин «Организация тестирования в больших командах»

Роман Кокин «Организация тестирования в больших командах»

Виталий Стрелюк, Постановка процесса тестирования в Agile

Виталий Стрелюк, Постановка процесса тестирования в Agile

Виталий Стрелюк, Постановка процесса тестирования в Agile

SQADays_2009_Piter

RSTQB Presentation about ISTQB Agile Tester during TMPA-2014:

RSTQB Presentation about ISTQB Agile Tester during TMPA-2014:

RSTQB Presentation about ISTQB Agile Tester during TMPA-2014:

Методы управления проектами с коротким циклом - Agile от практиков_InnoTrain_...

Методы управления проектами с коротким циклом - Agile от практиков_InnoTrain_...

Методы управления проектами с коротким циклом - Agile от практиков_InnoTrain_...

Анастасия Виноградова

Тестирование как панацея для жизни и развития проекта

Тестирование как панацея для жизни и развития проекта

Тестирование как панацея для жизни и развития проекта

андрей дмитриев взгляд со стороны разработчика

андрей дмитриев взгляд со стороны разработчика

андрей дмитриев взгляд со стороны разработчика

How to estimate time for testing

How to estimate time for testing

How to estimate time for testing

Alexandr Zinovyev

Как оценить время на тестирование. Александр Зиновьев, Test Lead Softengi

Как оценить время на тестирование. Александр Зиновьев, Test Lead Softengi

Как оценить время на тестирование. Александр Зиновьев, Test Lead Softengi

Роли, в которые играют тестировщики

Роли, в которые играют тестировщики

Роли, в которые играют тестировщики

Agile.by - Agileee season 3 - Agile Testing by Elisabeth Hendrickson

Agile.by - Agileee season 3 - Agile Testing by Elisabeth Hendrickson

Agile.by - Agileee season 3 - Agile Testing by Elisabeth Hendrickson

Автоматизация визуального тестирования

Автоматизация визуального тестирования

Автоматизация визуального тестирования

Тестирование осень 2013 лекция 3

Тестирование осень 2013 лекция 3

Тестирование осень 2013 лекция 3

Тестирование весна 2014 смешанное занятие 1

Тестирование весна 2014 смешанное занятие 1

Тестирование весна 2014 смешанное занятие 1

Agile testing

Elena Korotchuk

вольфсон построение собственного Agile-фреймворка (шаблон)

вольфсон построение собственного Agile-фреймворка (шаблон)

вольфсон построение собственного Agile-фреймворка (шаблон)

Тестирование - это не просто тестирование, или Business Driven Testing

Тестирование - это не просто тестирование, или Business Driven Testing

Тестирование - это не просто тестирование, или Business Driven Testing

Роман Василенко. Continuous delivery или как упростить себе жизнь

Роман Василенко. Continuous delivery или как упростить себе жизнь

Роман Василенко. Continuous delivery или как упростить себе жизнь

Презентация была представлена в ходе вебинара "Scrum с нуля". Ведущая: Анна Чащина – разработчик 1С, руководитель отдела внедрения компании "Кодерлайн". Основная тема для обсуждения: почему IT - самая передовая отрасль во всем мире отдает предпочтение именно Scrum. http://www.koderline.ru/

Презентация "Scrum с нуля"

Презентация "Scrum с нуля"

Презентация "Scrum с нуля"

Елена Коптева

Similar to 10 правил agile тестировщика IT-Brunch (20)

Sef Streluk Agile

Sef Streluk Agile

Sef Streluk Agile

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

Внедрение тестирования в Scrum

Роман Кокин «Организация тестирования в больших командах»

Роман Кокин «Организация тестирования в больших командах»

Роман Кокин «Организация тестирования в больших командах»

Виталий Стрелюк, Постановка процесса тестирования в Agile

Виталий Стрелюк, Постановка процесса тестирования в Agile

Виталий Стрелюк, Постановка процесса тестирования в Agile

RSTQB Presentation about ISTQB Agile Tester during TMPA-2014:

RSTQB Presentation about ISTQB Agile Tester during TMPA-2014:

RSTQB Presentation about ISTQB Agile Tester during TMPA-2014:

Методы управления проектами с коротким циклом - Agile от практиков_InnoTrain_...

Методы управления проектами с коротким циклом - Agile от практиков_InnoTrain_...

Методы управления проектами с коротким циклом - Agile от практиков_InnoTrain_...

Тестирование как панацея для жизни и развития проекта

Тестирование как панацея для жизни и развития проекта

Тестирование как панацея для жизни и развития проекта

андрей дмитриев взгляд со стороны разработчика

андрей дмитриев взгляд со стороны разработчика

андрей дмитриев взгляд со стороны разработчика

How to estimate time for testing

How to estimate time for testing

How to estimate time for testing

Как оценить время на тестирование. Александр Зиновьев, Test Lead Softengi

Как оценить время на тестирование. Александр Зиновьев, Test Lead Softengi

Как оценить время на тестирование. Александр Зиновьев, Test Lead Softengi

Роли, в которые играют тестировщики

Роли, в которые играют тестировщики

Роли, в которые играют тестировщики

Agile.by - Agileee season 3 - Agile Testing by Elisabeth Hendrickson

Agile.by - Agileee season 3 - Agile Testing by Elisabeth Hendrickson

Agile.by - Agileee season 3 - Agile Testing by Elisabeth Hendrickson

Автоматизация визуального тестирования

Автоматизация визуального тестирования

Автоматизация визуального тестирования

Тестирование осень 2013 лекция 3

Тестирование осень 2013 лекция 3

Тестирование осень 2013 лекция 3

Тестирование весна 2014 смешанное занятие 1

Тестирование весна 2014 смешанное занятие 1

Тестирование весна 2014 смешанное занятие 1

Agile testing

вольфсон построение собственного Agile-фреймворка (шаблон)

вольфсон построение собственного Agile-фреймворка (шаблон)

вольфсон построение собственного Agile-фреймворка (шаблон)

Тестирование - это не просто тестирование, или Business Driven Testing

Тестирование - это не просто тестирование, или Business Driven Testing

Тестирование - это не просто тестирование, или Business Driven Testing

Роман Василенко. Continuous delivery или как упростить себе жизнь

Роман Василенко. Continuous delivery или как упростить себе жизнь

Роман Василенко. Continuous delivery или как упростить себе жизнь

Презентация "Scrum с нуля"

Презентация "Scrum с нуля"

Презентация "Scrum с нуля"

More from Andrii Dzynia

Continuous delivery makes an agenda for many engineering teams. When there are not that many unknowns in the web world, the embedded software domain is worth exploring. With such diversity of different partner integrations(speakers, consoles, tv’s, cars, etc) Spotify is not an exception. We set ourselves on a journey to reach a state when releases of Spotify’s eSDK is rather a routine and doesn't require anything more than a push of a button. The end goal is clear and sounds easy but challenges are all over the place and every single one needs to be addressed individually. This talk is about how we managed to setup releases of Spotify’s embedded SDK on a predictable schedule and keep improving towards being able releasing on-demand going forward. Our challenges and solutions. What worked, what did not. Pain, tears, joy, and smiles.

Continuous Delivery as you want it

Continuous Delivery as you want it

Continuous Delivery as you want it

Testing is probably the most misunderstood concept in software engineering. Many still believe that testing is simply a verification of actual and expected results in pre-defined set of test scenarios. I wish to know earlier how wrong this statement is. Conversations about testing can be seen wide, ambiguous, and hard to facilitate. But when done properly show prominent results. You start from quality. Addressing questions like. What does quality mean for us? Who owns it? Who is responsible for quality improvements? There is no single answer to every team. Each has to come up with their own definition, which works in their particular situation. Testing is not a measure for quality, but rather a set of activities and preparations to increase a level of confidence before releasing. You cannot simply state that after verifying 1000 test scenarios the whole product behaves as expected. During this presentation I will share key findings which I think are the most important ones to get almost any engineering team on the right track towards improving productivity and released product quality. There is no single rule to rule them all, but experience-based patterns.

Test coaching your agile team

Test coaching your agile team

Test coaching your agile team

Testing at Spotify

Testing at Spotify

Testing at Spotify

Test engineering is hard, even harder than software development. Being test engineer puts you in a wider context, with no clear boundaries. You have to find those by yourself. This requires courage. Courage to take action, courage to make mistakes. As a test engineer, you do mistakes every day. You do them so often that sometimes you feel you can predict the future. Scientific explanation to this phenomena is patterns recognition. It is an ability of our brain to match the information from a stimulus with information retrieved from memory. Defect prevention is hard. Together with technical skills one have to develop high social awareness. Working on safety nets never was so important, different types of checks on different levels to make sure software is reliable and serves its purpose to the variety of everyday use-cases. We know that life is so complex and sometimes complicated which makes it impossible to predict all possible outcomes and scenarios. But striving for excellence never was so important as nowadays in such an open, transparent and competitive environment. Goal of my talk will be to show you my everyday job as a test engineer. Not only how to look for defects, but how to prevent them from happening. Not only how to automate tests(noun), but how to build safety nets to minimize end-user impact. Not only how to inform testing status but how to influence quality on company level.

What does it mean to be a test engineer?

What does it mean to be a test engineer?

What does it mean to be a test engineer?

As a developer, most of the time, you are being focused on solving concrete problems. This process get’s all your attention on implementation details to make it just work. If time persists you might spend some time on writing tests for your code, but not going far into details on all the edge cases. It is very hard to verify your own creation in all possible ways. Stepping out of comfort zone and think like a consumer is what test engineers are good at, thinking from the end. During this session I’m going to share my daily tricks on how to help developers writing better tests which leads to less bugs and more testable architecture.

Exploring your unit tests

Exploring your unit tests

Exploring your unit tests

What are the most common problems with testing environments? - You are not the only one who is using it. - Test failures are not repeatable. - Test data can be easily messed up due to tests overlap. Those problems are introducing flakiness in your tests, increase frustration level and decrease confidence in quality of a product you are building. Forcing your development team to have a testing queue increases delivery time dramatically. Creating zillions of environments does not sound as cheapest solution either. At Spotify we experimented with different approaches on how testing environments can be configured: from shared environment to mocks, stubs and hermetic servers. During my presentation I will share the lessons we learned, what worked, what not and what is the direction we are pursuing in order to stabilise our testing suites.

Hermetic environment for your functional tests

Hermetic environment for your functional tests

Hermetic environment for your functional tests

Most of the people think that quality in software development is limited to manual testing on the latest stage before releasing a product. That might be true 20 years ago in the industrial era. But current world is much more dynamic than before. Time to market became the most crucial metric nowadays. Releasing code to production need to be done faster and faster. How to maintain quality on a sufficient level in this fast paced environment? How to find a time to work on quality improvements? Those are two main questions I want to answer during this talk. Do not expect a silver bullet or even receipt to success. But definitely expect a lot of information about continuous delivery/deployment/improvements with a case studies and lessons we learned at Spotify. Spotify Engineering Culture: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/ Scaling Agile @ Spotify http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify Scaled Agile @ Spotify http://vimeo.com/111131934

Quality Built In @ Spotify

Quality Built In @ Spotify

Quality Built In @ Spotify

Software Development is a creative activity that requires focus. During coding session you as a programmer tends to make so many decision that sometimes force you to neglect 'unimportant details' that might sounds like specific use cases, unclear statements or somethings that won't gonna happen. In most cases the system even so complex that is not that easy to step out and see the whole picture, even from user's point of view. Historically software developers used to trust other people called testers to verify those 'details' from user's perspective before deploying into production. In order to have proper alignment inside the team dedicated 'QA step' added to the process. That obvious solution have some quick-wins with outcome of found bugs before releasing the software. But there are some tradeoffs, such as: slower delivery cycle, extra test documentation and GUI automated tests that are not that easy to maintain. During my talk I would like to share some insight and lessons we learned @ Spotify that helps us improving team's development productivity without losing quality of the product. Hopefully that will help your team as well or at least show one of the directions you might want to follow. Spotify Engineering Culture: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

Applying testing mindset to software development

Applying testing mindset to software development

Applying testing mindset to software development

Appium Mobile Test Automation like WebDriver

Appium Mobile Test Automation like WebDriver

Appium Mobile Test Automation like WebDriver

How to Manage Testing in Dynamic World

How to Manage Testing in Dynamic World

How to Manage Testing in Dynamic World

ExtJS WebDriver

ExtJS WebDriver

ExtJS WebDriver

Не один десяток раз каждый из нас видео этот пункт Agile манифеста. Кто на официальном сайте Agile Manifesto, кто в книгах или статьях, кто на тренингах или конференциях. Звучит правильно очевидно и просто, но на практике возникают некие сложности с его реализацией. Как определить какие документы писать нужно, а какие не стоит? Как поддерживать документы с наименьшими усилиями? От каких документов нужно отказаться или заменить на более простые решения? Что стоит документировать тестировщику, разработчику, бизнес-аналитику в Agile проектах, для того чтобы презентовать результаты своей работы. На все эти вопросы я постараюсь ответить в своем докладе, закрепляя примерами которые вы сможете попытаться применить на своих проектах.

Working Software Over Comprehensive Documentation

Working Software Over Comprehensive Documentation

Working Software Over Comprehensive Documentation

«Возможно ли управлять временем? Спорный вопрос. Время идет и мы ничего не можем поделать. Но в наших силах научиться управлять собой, своими привычками, идеями. При этом, очень важно, чтобы мы управляли своими собственными идеями, а не теми которые кто-то придумал за нас. Учиться самоорганизации можно по-разному и каждый находит свой индивидуальный путь обучения. На докладе я расскажу о своем пути развития Self Management System(SMS), о тех практиках которые применял и продолжаю применять ежедневно».

«Самоорганизуй» себя, пока не «самоорганизовали» тебя

«Самоорганизуй» себя, пока не «самоорганизовали» тебя

«Самоорганизуй» себя, пока не «самоорганизовали» тебя

“Очень часто, внедряя Behavior Driven Development на проекте, думаешь только о быстрых выгодах и о краткосрочной перспективе. На первый взгляд нету ничего сложного в том, чтобы написать приемочный сценарий в стиле Given When Then, простым языком и дальше связывать эти конструкции с языком программирования. Но как показывает практика у многих возникают сложности с составлением непосредственного сценария. Если написать сценарий не правильно, это может повлиять на весь процесс разработки как приемочных тестов, так и на логику работы самого приложения. В докладе я расскажу о том с какими проблемами сталкивается каждый проект, внедряя практику Acceptance Test Driven Development используя Gherkin синтаксис для написания приемочных тестов. На примерах мы рассмотрим частые ошибки при написании приемочных сценариев и разберем основные правила, которые нужно использовать для того, чтобы Acceptance Test-ы помогали каждому члену команды. Доклад будет интересен как тестировщикам, так бизнес аналитикам и разработчикам.”.

Как не нужно писать Gherkin сценарии

Как не нужно писать Gherkin сценарии

Как не нужно писать Gherkin сценарии

Мир мобильных телефонов очень сильно изменил нашу жизнь. В наше время невозможно представить современного человека, без этого чудо устройства. На рынке появляется все больше устройств и приложений. И чтобы удобнее пользоваться этими приложениями пользователи выбирают “умные” телефоны, или как их еще принято называть смартфоны. В своем докладе я хочу поделиться своим опытом автоматизации приложений под Android и iOS. Я расскажу о том, какие инструменты автоматизации я использовал. Поговорим о недостатках этих инструментов и какие из них стоит использовать у себя на проекте.

iOS and Android Mobile Test Automation

iOS and Android Mobile Test Automation

iOS and Android Mobile Test Automation

Что такое Exploratory Testing?

Что такое Exploratory Testing?

Что такое Exploratory Testing?

Software testing 2.0

Software testing 2.0

Software testing 2.0

Тестировщики Vs Программисты

Тестировщики Vs Программисты

Тестировщики Vs Программисты

Testing Dojo Kyiv - Testing Heuristics

Testing Dojo Kyiv - Testing Heuristics

Testing Dojo Kyiv - Testing Heuristics

Основы Self Management v. 2

Основы Self Management v. 2

Основы Self Management v. 2

More from Andrii Dzynia (20)

Continuous Delivery as you want it

Continuous Delivery as you want it

Continuous Delivery as you want it

Test coaching your agile team

Test coaching your agile team

Test coaching your agile team

Testing at Spotify

Testing at Spotify

Testing at Spotify

What does it mean to be a test engineer?

What does it mean to be a test engineer?

What does it mean to be a test engineer?

Exploring your unit tests

Exploring your unit tests

Exploring your unit tests

Hermetic environment for your functional tests

Hermetic environment for your functional tests

Hermetic environment for your functional tests

Quality Built In @ Spotify

Quality Built In @ Spotify

Quality Built In @ Spotify

Applying testing mindset to software development

Applying testing mindset to software development

Applying testing mindset to software development

Appium Mobile Test Automation like WebDriver

Appium Mobile Test Automation like WebDriver

Appium Mobile Test Automation like WebDriver

How to Manage Testing in Dynamic World

How to Manage Testing in Dynamic World

How to Manage Testing in Dynamic World

ExtJS WebDriver

ExtJS WebDriver

ExtJS WebDriver

Working Software Over Comprehensive Documentation

Working Software Over Comprehensive Documentation

Working Software Over Comprehensive Documentation

«Самоорганизуй» себя, пока не «самоорганизовали» тебя

«Самоорганизуй» себя, пока не «самоорганизовали» тебя

«Самоорганизуй» себя, пока не «самоорганизовали» тебя

Как не нужно писать Gherkin сценарии

Как не нужно писать Gherkin сценарии

Как не нужно писать Gherkin сценарии

iOS and Android Mobile Test Automation

iOS and Android Mobile Test Automation

iOS and Android Mobile Test Automation

Что такое Exploratory Testing?

Что такое Exploratory Testing?

Что такое Exploratory Testing?

Software testing 2.0

Software testing 2.0

Software testing 2.0

Тестировщики Vs Программисты

Тестировщики Vs Программисты

Тестировщики Vs Программисты

Testing Dojo Kyiv - Testing Heuristics

Testing Dojo Kyiv - Testing Heuristics

Testing Dojo Kyiv - Testing Heuristics

Основы Self Management v. 2

Основы Self Management v. 2

Основы Self Management v. 2

Recently uploaded

DCRat, швейцарский армейский нож киберпреступного мира, истинное свидетельство предпринимательского духа, процветающего в темных уголках Интернета. С момента своего грандиозного дебюта в 2018 году DCRat стал незаменимым гаджетом для каждого начинающего злодея со склонностью к цифровым проказам. По очень низкой цене в 7 долларов можно приобрести двухмесячную подписку на это чудо современного вредоносного ПО, а для тех, кто действительно предан делу, доступна пожизненная лицензия за внушительную сумму в 40 долларов. DCRat служит напоминанием, что в эпоху цифровых технологий безопасность настолько сильна, насколько сильна способность не переходить по подозрительным ссылкам.

Malware. DCRAT (DARK CRYSTAL RAT) [RU].pdf

Malware. DCRAT (DARK CRYSTAL RAT) [RU].pdf

Malware. DCRAT (DARK CRYSTAL RAT) [RU].pdf

Хроники кибер-безопасника

LockBit 3.0 завоевал золото на хакерской олимпиаде, за ним последовали отважные новички Clop и ALPHV/BlackCat. По-видимому, 48% организаций почувствовали себя обделёнными вниманием и решили принять участие в кибератаках. Бизнес-сервисы получили награду в номинации "наиболее подверженные цифровому взлому", а образование и розничная торговля последовали за ними. Хакеры расширили свой репертуар, перейдя от скучного старого шифрования к гораздо более захватывающему миру вымогательства. Не бедные страны США, Великобритания и Канада заняли первое место в категории "страны, которые, скорее всего, заплатят". Биткоины были предпочтительной валютой, хотя некоторые стали поглядывать в сторону Monero. Некоторые организации пытались сэкономить на выкупе, заплатив только 37%. Тем, кто все-таки раскошелился, пришлось в среднем отдать $408 643. Кибер-преступность действительно окупается!

2023 Q4. The Ransomware report. [RU].pdf

2023 Q4. The Ransomware report. [RU].pdf

2023 Q4. The Ransomware report. [RU].pdf

Хроники кибер-безопасника

Действие очередной кибер-саги разворачивается в мистических землях Азиатско-Тихоокеанского региона, где главные герои (или антагонисты, в зависимости от вашего взгляда на конфиденциальность данных и необходимость доступа к ним) начали свое цифровую деятельность ещё в середине 2021 года и качественно усилили её в 2022 году. Вооружённый арсеналом инструментов и специально разработанного вредоносного программного обеспечения, предназначенного для кражи данных и шпионажа, Dark Pink был воплощением настойчивости. Их любимое оружие? Фишинговые электронные письма, содержащие сокращённый URL-адрес, который приводил жертв на бесплатный файлообменный сайт, где их ждал ISO-образ, конечно же вредоносный. Давайте углубимся в цели кибер-художников. Корпоративный шпионаж, кража документов, аудиозапись и утечка данных с платформ обмена сообщениями – все это было делом одного дня для Dark Pink. Их географическая направленность, возможно, начиналась в Азиатско-Тихоокеанском регионе, но их амбиции не знали границ, нацелившись на европейское правительственное министерство в смелом шаге по расширению своего портфолио. Их профиль жертв был таким же разнообразным, как совещание ООН, нацеливаясь на военные организации, правительственные учреждения и даже религиозную организацию. Потому что дискриминация это не модная повестка. В мире киберпреступности они служат напоминанием о том, что иногда самые серьёзные угрозы приходят в самых непритязательных упаковках с розовым бантиком.

Cyberprint. Dark Pink Apt Group [RU].pdf

Cyberprint. Dark Pink Apt Group [RU].pdf

Cyberprint. Dark Pink Apt Group [RU].pdf

Хроники кибер-безопасника

В постоянно развивающемся мире ИБ, где цифровая сфера устойчива, как карточный домик во время урагана, появился новаторский документ под названием "Доктрина киберзащиты, которая управляет рисками: полное прикладное руководство по организационной киберзащите", предположительно написанный израильским Сунь Цзы из эпохи цифровых технологий. Доктрина, являющаяся шедевром кибернетической мудрости, делит свои стратегии оценки рисков и управления ими на два направления, вероятно, потому что одно из них является слишком уже не модно. Эти направления изобретательно основаны на потенциальном ущербе для организации – новой концепции, для воплощения которой, должно быть, потребовалось как минимум несколько сеансов мозгового штурма за чашкой кофе. Как принято сегодня говорить, доктрина является ярким примером приверженности индустрии киберзащиты … к тому, чтобы как можно подробнее изложить очевидное. Она убеждает нас в том, что перед лицом киберугроз мы всегда можем положиться на объёмные документы, которые защитят нас.

Cyber Defense Doctrine Managing the Risk Full Applied Guide to Organizational...

Cyber Defense Doctrine Managing the Risk Full Applied Guide to Organizational...

Cyber Defense Doctrine Managing the Risk Full Applied Guide to Organizational...

Ирония безопасности

С 4368 жертвами, пойманными в их цифровые сети, киберпреступникам удалось превзойти самих себя по эффективности на 55,5% по сравнению с предыдущим годом, вот что значит KPI. Средняя сумма выкупа для предприятия выросла до более чем 100 000 долларов, при этом требования в среднем составляли крутые 5,3 миллиона долларов. 80% организаций придерживаются политики "Не платить", и все же в прошлом году 41% в итоге заплатили выкуп. И для тех, кто думает, что страховка может спасти положение, подумайте ещё раз. 77% организаций на собственном горьком опыте убедились, что программы-вымогатели – это далеко не то, за что страховая с лёгкостью заплатит, не проверив, а всё ли вы сделали для защиты.

Ransomware_Q3 2023. The report [RU].pdf

Ransomware_Q3 2023. The report [RU].pdf

Ransomware_Q3 2023. The report [RU].pdf

Хроники кибер-безопасника

Пристегнитесь, потому что мы собираемся отправиться в захватывающее путешествие по мистической стране инноваций Китая, где драконы прошлого превратились в единорогов мира технологий. Да, мы говорим о превращении Китая из любимой в мире машины Xerox в сияющий маяк инноваций. И как им удалось совершить этот удивительный подвиг? Ведь теперь Запад сидит в стороне, заламывая руки и задаваясь вопросом: "Должны ли мы вскочить в уходящий поезд или придерживаться другого плана действий?" Оказывается, Запад ещё не полностью перехитрили, и у него все ещё есть несколько козырей в рукаве. В статье проповедуется, что сидеть и смотреть не самый разумный выбор. Вместо этого Западу следует напрячь свои демократические мускулы и чутье свободного рынка, чтобы остаться в игре.

ИСТОЧНИКИ ИННОВАЦИОННОСТИ КИТАЯ (ПО ВЕРСИИ DGAP) | The Sources of China’s Inn...

ИСТОЧНИКИ ИННОВАЦИОННОСТИ КИТАЯ (ПО ВЕРСИИ DGAP) | The Sources of China’s Inn...

ИСТОЧНИКИ ИННОВАЦИОННОСТИ КИТАЯ (ПО ВЕРСИИ DGAP) | The Sources of China’s Inn...

Ирония безопасности

Мир кибербезопасности пополнился последней и самой совершенной версией общей системы оценки уязвимостей CVSS версии 4.0. Эта версия обещает произвести революцию в том, как мы оцениваем критичность и влияние уязвимостей ПО, ведь версия 3.1 была всего лишь разминкой. 📌 Более детализированные базовые показатели. если есть что-то, что любят профессионалы в области ИБ, так это детализация. Теперь мы не только можем оценить воздействие на уязвимую систему, но и потратить тысячу листов на детализацию, это уже серьёзный уровень профессионализма 📌 Группа угроз – критичность уязвимости может быть скорректирована в зависимости от того, мог ли кто-то где-то подумать о их использовании, и теперь паранойя всегда подкрепляется последними данными об угрозах. 📌 Метрики окружения позволяют адаптировать оценку к нашей конкретной вычислительной среде. ничто так не говорит о "индивидуальности", как корректировка оценок на основе множества мер по смягчению последствий. 📌 Показатели угроз были упрощены до уровня зрелости эксплойтов. если и есть что-то, что легко определить, так это то, насколько зрелым является эксплойт. 📌 Система подсчёта оценки стала проще и гибче и … больше. если и есть какое-то слово, которое ассоциируется с CVSS, так это простота, ведь теперь поддерживается несколько оценок для одной и той же уязвимости Итак, CVSS версии 4.0 призван спасти положение благодаря своей повышенной ясности, простоте и повышенному вниманию ко всем мелочам и деталям. Потому что, как мы все знаем, единственное, что доставляет больше удовольствия, чем оценка уязвимостей, — это делать это с помощью новой, более сложной системы.

СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS 4.0 / CVSS v4.0 [RU].pdf

СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS 4.0 / CVSS v4.0 [RU].pdf

СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS 4.0 / CVSS v4.0 [RU].pdf

Хроники кибер-безопасника

Документ содержит руководство по эффективной стратегии и тактике реагирования на инциденты (IR). Руководство, разработанное группой реагирования на инциденты Microsoft, призвано помочь избежать распространённых ошибок и предназначено не для замены комплексного планирования реагирования на инциденты, а скорее для того, чтобы служить тактическим руководством, помогающим как группам безопасности, так и старшим заинтересованным сторонам ориентироваться в расследовании реагирования на инциденты. В руководстве также подчёркивается важность управления и роли различных заинтересованных сторон в процессе реагирования на инциденты

MS Navigating Incident Response [RU].pdf

MS Navigating Incident Response [RU].pdf

MS Navigating Incident Response [RU].pdf

Ирония безопасности

CVE-2024-0204 как ключ под ковриком, для не прошедших проверку подлинности, и желающих создать своего собственного пользователя-администратора. Эта уязвимость может быть использована удалённо и является классическим примером CWE-425: "Принудительный доступ, когда веб-приложение просто слишком вежливое, чтобы обеспечить надлежащую авторизацию". Уязвимые версии 6.x начиная с 6.0.1 и версии 7.x до 7.4.1, которая была исправлена, а для уязвимых версией необходимо удалить файл /InitialAccountSetup.xhtml или заменить на пустой с перезапуском службы/ Последствия подобны альбому величайших хитов о кошмарах безопасности: 📌Создание неавторизованных пользователей-администраторов (акция «избавляемся от складских запасов аутентификационных ключей») 📌Потенциальная утечка данных (для повышения популярности компании) 📌Внедрение вредоносных программ (вместо традиционных схем распространения) 📌Риск вымогательства (минутка шантажа) 📌Сбои в работе (разнообразие от повелителя хаоса) 📌Комплаенс и юридические вопросы (ничто так не оживляет зал заседаний, как старый добрый скандал с комплаенсом и потенциальная юридическая драма) Планка "сложности атаки" установлена так низко, что даже малыш может споткнуться об неё. Отмечается простота, которая заставляет задуматься, не является ли "безопасность" просто модным словом, которым они пользуются, чтобы казаться важными

CVE. The Fortra's GoAnywhere MFT [RU].pdf

CVE. The Fortra's GoAnywhere MFT [RU].pdf

CVE. The Fortra's GoAnywhere MFT [RU].pdf

Хроники кибер-безопасника

Recently uploaded (9)

Malware. DCRAT (DARK CRYSTAL RAT) [RU].pdf

Malware. DCRAT (DARK CRYSTAL RAT) [RU].pdf

Malware. DCRAT (DARK CRYSTAL RAT) [RU].pdf

2023 Q4. The Ransomware report. [RU].pdf

2023 Q4. The Ransomware report. [RU].pdf

2023 Q4. The Ransomware report. [RU].pdf

Cyberprint. Dark Pink Apt Group [RU].pdf

Cyberprint. Dark Pink Apt Group [RU].pdf

Cyberprint. Dark Pink Apt Group [RU].pdf

Cyber Defense Doctrine Managing the Risk Full Applied Guide to Organizational...

Cyber Defense Doctrine Managing the Risk Full Applied Guide to Organizational...

Cyber Defense Doctrine Managing the Risk Full Applied Guide to Organizational...

Ransomware_Q3 2023. The report [RU].pdf

Ransomware_Q3 2023. The report [RU].pdf

Ransomware_Q3 2023. The report [RU].pdf

ИСТОЧНИКИ ИННОВАЦИОННОСТИ КИТАЯ (ПО ВЕРСИИ DGAP) | The Sources of China’s Inn...

ИСТОЧНИКИ ИННОВАЦИОННОСТИ КИТАЯ (ПО ВЕРСИИ DGAP) | The Sources of China’s Inn...

ИСТОЧНИКИ ИННОВАЦИОННОСТИ КИТАЯ (ПО ВЕРСИИ DGAP) | The Sources of China’s Inn...

СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS 4.0 / CVSS v4.0 [RU].pdf

СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS 4.0 / CVSS v4.0 [RU].pdf

СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS 4.0 / CVSS v4.0 [RU].pdf

MS Navigating Incident Response [RU].pdf

MS Navigating Incident Response [RU].pdf

MS Navigating Incident Response [RU].pdf

CVE. The Fortra's GoAnywhere MFT [RU].pdf

CVE. The Fortra's GoAnywhere MFT [RU].pdf

CVE. The Fortra's GoAnywhere MFT [RU].pdf

10 правил agile тестировщика IT-Brunch

1. 10 правил Agile тестировщика Андрей Дзыня

2. Andrii Dzynia Test Engineer/Consultant/Trainer @adzynia http://adzynia.com

3.

4. Техники Тест Дизайна Equivalence Class Domain Analysis Testing Testing Boundary Value Use Case Testing Testing Control Flow Testing Decision Table Testing Data Flow Testing Pairwise Testing State-Transition Testing “Practitioners Guide To Software Test Design” Lee Copeland

5.

6.

7. http://www.adzynia.com/2012/01/5.html

8.

9. Но чаще всего

10. 10. Постоянно улучшаться

11. 9. Приносить ценность продукту

12. 8. Заряжать духом тестирования

13. 7. Смотреть по сторонам

14. 6. Исследовать и экспериментировать

15. 5. Знать все практики тест дизайна

16. 4. Дружить с программистом

17. 3. Обладать техническими знаниями

18. 2. Задавать неудобные вопросы

19. 1. Быть смелым и решительным

20. 10 принципов Agile тестировщика Быть смелым и решительным Задавать неудобные вопросы Обладать техническими знаниями Дружить с программистом Знать все практики тест дизайна Исследовать и экспериментировать Смотреть по сторонам Заряжать духом тестирования Приносить ценность продукту Постоянно улучшаться

21. http://adzynia.com @adzynia me@adzynia.com