Доклад расчитан для тех, кто собирается связать свою жизнь с миром тестирования программного обеспечения или только начал осваивать профессию тестировщика. Собраны самые популярные мифы о тестировании, в основе которых которых лежат ложные стереотип и представления о QA.
VivaMP, система выявления ошибок в коде параллельных программ на языке С++, и...Tatyanazaxarova
В статье приводятся результаты исследований ошибок, которые допускают программисты, использующие С++ и OpenMP. Для автоматического обнаружения этих ошибок предлагается использование статического анализа. Описывается интегрирующийся в среду Visual Studio анализатор VivaMP, реализующий поставленную задачу.
Доклад расчитан для тех, кто собирается связать свою жизнь с миром тестирования программного обеспечения или только начал осваивать профессию тестировщика. Собраны самые популярные мифы о тестировании, в основе которых которых лежат ложные стереотип и представления о QA.
VivaMP, система выявления ошибок в коде параллельных программ на языке С++, и...Tatyanazaxarova
В статье приводятся результаты исследований ошибок, которые допускают программисты, использующие С++ и OpenMP. Для автоматического обнаружения этих ошибок предлагается использование статического анализа. Описывается интегрирующийся в среду Visual Studio анализатор VivaMP, реализующий поставленную задачу.
лившиц владимир - независимое тестирование мифMagneta AI
Сюжет этой короткометражки рассказывает о том, как можно трансформировать «незавсимую» команду тестирования для обеспечения качества в нескольких Scrum командах (работающих в одном известном инвест-банке). Это почти что боевик о ломке устоявшихся принципов и небоязни меняться. Обсуждается вопрос: приносят тест-кейсы пользу? Тут есть немного философии: отношения тестировщиков и не совсем к тестированию и качеству в Agile командах.
Опросный лист оценки знаний по соревновательной робототехникеAlexander Kolotov
Опросный лист оценки знаний по соревновательной робототехнике, содержащий матрицу компетенций, которыми рекомендуется овладеть потенциальным участникам робототехнических состязаний уровня World Robot Olympiad.
лившиц владимир - независимое тестирование мифMagneta AI
Сюжет этой короткометражки рассказывает о том, как можно трансформировать «незавсимую» команду тестирования для обеспечения качества в нескольких Scrum командах (работающих в одном известном инвест-банке). Это почти что боевик о ломке устоявшихся принципов и небоязни меняться. Обсуждается вопрос: приносят тест-кейсы пользу? Тут есть немного философии: отношения тестировщиков и не совсем к тестированию и качеству в Agile командах.
Опросный лист оценки знаний по соревновательной робототехникеAlexander Kolotov
Опросный лист оценки знаний по соревновательной робототехнике, содержащий матрицу компетенций, которыми рекомендуется овладеть потенциальным участникам робототехнических состязаний уровня World Robot Olympiad.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Денис Тучин, Проверка гипотез Kanban Method с помощью имитационной моделиScrumTrek
Используя имитационную модель на докладе мы проверим, что лучше работает:
Что делать если команда не сбалансирована
Может ли сбалансированная команда работать без ограничения WIP
Как подобрать оптимальные ограничения WIP
Помогает ли приоритезация бизнесу
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Crucible или почему для Code Review нужна не только голова, но и инструментMaxim Kuzmich
Мы все мечтаем о фотоаппарате, после покупки которого сразу станут получаться отличные снимки, о покупке нового компьютера, на котором разработка будет идти в два раза быстрее, и о покупке новой гитары, на которой наконец-то можно будет научиться нормально играть. Иногда мы мечтаем и о покупке инструмента, с которым Code Review начнет проходить быстро, легко и без обид. Но инструмент никогда не заменит искреннее желание научиться фотографировать или делать обзоры кода. Инструмент может только сделать этот процесс более комфортным.
В докладе будет сказано о том, почему же все-таки следует присмотреться к инструментам для проведения Code Review и почему среди них стоит выбрать Crucible. Поговорим о ситуациях, когда Crucible не поможет, рассмотрим основные варианты его использования и ситуации, когда он может послужить стимулом к проведению Code Review. Немного затронем вопросы интеграции Crucible с другими продуктами и возможности его расширения.
Антон Непомнящих - 100 лет без авралов или зачем проекту креативный менеджер ...HappyDev
Рассказ о развитии проекта объемом 100 человеко-лет с нуля. От BodyShop с четырьмя разработчиками и микроменеджментом к стабильному процессу на 33 человек.
Разница между теорией и практикой заключается в том, что, в теории, этой разницы нет. А на практике оказывается, что она есть." (с) Неизвестный автор.
Являясь ярым приверженцем процессного подхода, я расскажу, как строил процесс разработки на одном из проектов нашей компании. Объем проекта на данный момент составляет 100 человеко-лет. А выстроенный процесс уже прошел проверку временем и остается практически неизменным на протяжении последних 2х лет.
Всё начиналось, как и у многих омских команд, с обычного bodyshop-проекта на 4 разработчика и меня в роли менеджера. Заказчик полностью контролировал работу каждого члена команды. Тотальный микроменеджмент. Но со временем мы доказали заказчику, что можем эффективно организовать работу и отвечать за ее качество. И заказчик передал нам все основные функции по разработке, оставив себе только концептуальную постановку задач. А также, значительно расширил бюджет.
На данный момент в проекте участвует 33 человека. Процесс представляет из себя конвеер по поставке новой функциональности для решения различных нужд компании заказчика. От достаточно простых элементов корпоративного портала, до сложных кластерных систем рендеринга графики или своей собственной системы а-ля Dropbox.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Тестирование — это способ узнать о разнообразных проблемах, которые могут возникнуть во время разработки вашего проекта. В лекции рассмотрены различные виды тестирования и различные практики, которые позволят вам узнавать о проблемах заранее.
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.
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.
What does it mean to be a test engineer?Andrii Dzynia
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.
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.
Hermetic environment for your functional testsAndrii Dzynia
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.
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
Applying testing mindset to software developmentAndrii Dzynia
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/
Working Software Over Comprehensive DocumentationAndrii Dzynia
Не один десяток раз каждый из нас видео этот пункт Agile манифеста. Кто на официальном сайте Agile Manifesto, кто в книгах или статьях, кто на тренингах или конференциях. Звучит правильно очевидно и просто, но на практике возникают некие сложности с его реализацией. Как определить какие документы писать нужно, а какие не стоит? Как поддерживать документы с наименьшими усилиями? От каких документов нужно отказаться или заменить на более простые решения? Что стоит документировать тестировщику, разработчику, бизнес-аналитику в Agile проектах, для того чтобы презентовать результаты своей работы. На все эти вопросы я постараюсь ответить в своем докладе, закрепляя примерами которые вы сможете попытаться применить на своих проектах.
«Самоорганизуй» себя, пока не «самоорганизовали» тебяAndrii Dzynia
«Возможно ли управлять временем? Спорный вопрос. Время идет и мы ничего не можем поделать. Но в наших силах научиться управлять собой, своими привычками, идеями. При этом, очень важно, чтобы мы управляли своими собственными идеями, а не теми которые кто-то придумал за нас. Учиться самоорганизации можно по-разному и каждый находит свой индивидуальный путь обучения. На докладе я расскажу о своем пути развития Self Management System(SMS), о тех практиках которые применял и продолжаю применять ежедневно».
“Очень часто, внедряя Behavior Driven Development на проекте, думаешь только о быстрых выгодах и о краткосрочной перспективе. На первый взгляд нету ничего сложного в том, чтобы написать приемочный сценарий в стиле Given When Then, простым языком и дальше связывать эти конструкции с языком программирования. Но как показывает практика у многих возникают сложности с составлением непосредственного сценария. Если написать сценарий не правильно, это может повлиять на весь процесс разработки как приемочных тестов, так и на логику работы самого приложения. В докладе я расскажу о том с какими проблемами сталкивается каждый проект, внедряя практику Acceptance Test Driven Development используя Gherkin синтаксис для написания приемочных тестов. На примерах мы рассмотрим частые ошибки при написании приемочных сценариев и разберем основные правила, которые нужно использовать для того, чтобы Acceptance Test-ы помогали каждому члену команды. Доклад будет интересен как тестировщикам, так бизнес аналитикам и разработчикам.”.
Мир мобильных телефонов очень сильно изменил нашу жизнь. В наше время невозможно представить современного человека, без этого чудо устройства. На рынке появляется все больше устройств и приложений. И чтобы удобнее пользоваться этими приложениями пользователи выбирают “умные” телефоны, или как их еще принято называть смартфоны. В своем докладе я хочу поделиться своим опытом автоматизации приложений под Android и iOS. Я расскажу о том, какие инструменты автоматизации я использовал. Поговорим о недостатках этих инструментов и какие из них стоит использовать у себя на проекте.
Тема тестирования в Agile очень большая. Ведь теперь за качество отвечает не отдельный QA департамент, а вся команда разработки. Но не стоит забывать, что на тестировщика ложится намного больше обязанностей и требуется набор новых навыков и умений. Уже немало докладов было на эту тему. Я не хочу повторять предыдущих спикеров, а лишь подведу итог своей работы тестировщиком в Agile командах в простых 10 правилах.
3. О чем будем говорить
• О традиционных методологиях
• О гибких методологиях
• О проблемах между программистами и
тестировщиками
• Об ошибках
• Как их избежать
4.
5. Очевидные проблемы
• По ту сторону баррикад
• Конфликт «Свой-Чужой»
• Перебрасывание багами
• Это баг, нет это фича
6. Ошибка №1
Разделять команду на разные локации
Решение
Оптимальный размер команды 5-7 человек
Все должны работать в одном пространстве
7.
8. Ошибка №2
Говорить тестировщику фразу
«Это фича, а не баг»
Решение
Посмотрите на требования к системе.
Быть может, баг именно там!
9.
10. Новые проблемы
• Работа в команде
• Командные оценки задач
• Как это тестировать?
• Не успеваем протестировать
• UI Автоматизация
• Ты почему не спросил?
11. Эта фича Ситуация
3 Story Points
Я считаю,
Ха-ха-ха, эта фича 8
вот сам ее story points
и делай
Два месяца назад мы
делали рефакторинг в этой Тестировщик
области и это вызвало два
Программисты критичных бага из-за чего
Хм,
действительно отложили релиз
… Давайте
переголосуем
12. Ошибка №3
Проводить оценки без участия
тестировщиков
Решение
Тестировщики должны принимать
участие во всех командных митингах
15. Ошибка №4
Ты тестировщик – ты и тестируй
Решение
Вовлечь программистов в тестирование!
16. Да зачем нам эти
Ситуация
Это будет
UI тесты. Вон есть
экономить мое
unit тесты их
время
достаточно
Вот сам бери и
занимайся
Тестировщик
Программист
17. Ошибка №5
Поручить тестировщикам
автоматизацию тестирования
Решение
Найти точки взаимодействия
тестировщик – программист
Парное программирование UI тестов
18. Эти UI тесты такие Ситуация Ок, давай
хрупкие. Сами уменьшим их
фиксите их, у меня количество и
на это мало выберем только
времен самые основные
Хм…….
Тестировщик
Программист
20. Ситуация Я вчера ночью
решил поработать.
Отрефакторил
половину кода,
внес изменения
Б***, где этот
метод.
**, это что
за г**код.
Мы это уже
рефакторили.
Че ты не
спросил? Тестировщик
Программист
21. Ошибка №7
Быть д’Артаньяном
Решение
Советуйтесь с командой!
22. Рекомендации
• Находите консенсус
• Помогайте друг другу
• Практикуйте парное программирование
при автоматизации
• Практикуйте командные пересмотры
логики тестов
• Помните, у каждого члена команды есть
право голоса
Сергей, Игорь, Алекс: Эта фича 3 стори поинтаКоля: Я считаю, эта фича 8 стори поинтовСергей, Игорь, Алекс: Ха-ха-ха-ха, что сам ее будешь делать?Коля: Два месяца назад мы делали рефакторинг в этой области и это вызвало два критичных бага из-за чего отложили релизСергей, Игорь, Алекс: Хм, действительно… Давайте переголосуем
Программист: Да зачемнам эти UI тесты. Вон есть unit тесты их достаточноТестировщик: Это будет экономить мое времяПрограммист: Ты и так пол релиза непонятно что делаешь. Чем ты будешь заниматься когда мы все автоматизируем?Тестировщик: Exploratory тестированиемПрограммист: Хм…….
Программист: Эти UI тесты такие хрупкие. Сами фиксите их, у меня на это мало времениТестировщик: Ок, давай уменьшим их количество и выберем только самые основныеПрограммист: Хм…….
Я вчера ночью решил поработать. Отрефакторил половину кода, внес изменения