Павло Сафонов - Як оцінити ефективність автоматизації

Summary

The speaker shares a humorous anecdote about preparing for a presentation, emphasizing the importance of proper lighting and effective storytelling techniques. He then delves into evaluating the efficiency of test automation, covering key metrics such as test frequency, success rate, execution time, and user adoption. The speaker stresses the significance of making automation accessible and trusted by the entire team, positioning it as a reliable source of information akin to media outlets. Throughout the lighthearted narrative, the speaker imparts practical insights and strategies for achieving efficient and impactful test automation.

Takeaways

• 😀 The goal of test automation is to provide reliable information about the build status as quickly as possible.
• 🔑 Test execution frequency is a key metric - tests should be run as frequently as possible, ideally on every build.
• 💚 A high pass rate (ideally 80-100%) for test runs is desirable and indicates an effective test automation process.
• ⏱️ Test execution time should be minimized, aiming for under 30 minutes for rapid feedback to developers.
• 👥 Involving as many team members as possible in using the test automation is crucial for its effectiveness.
• 📊 Metrics like test coverage, defect detection rate, and manual vs. automated test execution can be used to demonstrate the value of test automation.
• 📢 Act as an ambassador for test automation by sharing success stories and promoting its benefits within the team.
• 🔁 Techniques like parameterized tests and randomizers can help mitigate the "pesticide paradox" and improve test resilience.
• 🤖 Leveraging tools like AI-generated images can aid in making presentations more engaging and effective.
• 🎯 Clearly defining the goals and metrics for test automation is essential for measuring its effectiveness and driving continuous improvement.

Q & A

What is the main topic of the presentation?

The main topic of the presentation is measuring the effectiveness of test automation and discussing various metrics and approaches to achieve efficient test automation.

What is the primary goal of test automation, according to the presenter?

The primary goal of test automation, as stated by the presenter, is to provide reliable information about the state of the build as quickly as possible.

What are some of the metrics mentioned for evaluating the effectiveness of test automation?

Some of the metrics mentioned include: frequency of test execution, success rate of test runs, execution time of tests, code coverage, and the number of people using the automated tests.

Why is it important to run automated tests frequently?

Running automated tests frequently is important because it allows you to gather up-to-date information about the latest build and identify issues promptly. The presenter recommends aiming for a coefficient of less than 1, meaning running tests more frequently than once per build.

What is considered a good success rate for test runs, according to the presenter?

For end-to-end tests, the presenter considers a success rate of 60-80% to be reasonable, while for unit, integration, or API tests, a success rate of 80-100% is recommended.

Why is execution time of tests important?

Execution time of tests is crucial because developers and QA professionals are unlikely to use automation if the tests take too long to run. The presenter suggests aiming for test execution times under 30 minutes to encourage wider adoption.

How can involving more people in using test automation increase its effectiveness?

Involving more people, such as developers, managers, and analysts, in using test automation can increase its effectiveness as it ensures that the provided information is trusted and acted upon. The presenter emphasizes being an ambassador for test automation within the team.

What is the purpose of comparing manual testing efforts with automated testing efforts?

The purpose of comparing manual testing efforts with automated testing efforts is to demonstrate potential cost savings and justify the investment in test automation. However, the presenter cautions against relying too heavily on this approach, as it may not accurately reflect the true benefits of automation.

What is the presenter's view on using BDD (Behavior-Driven Development) and keyword-driven automation?

The presenter believes that using BDD and keyword-driven automation is generally ineffective for test automation. He suggests that these approaches often fail to automate effectively and instead provide a layer of abstraction that does not contribute to genuine automation.

How does the presenter recommend dealing with flaky tests?

The presenter acknowledges the challenge of flaky tests and suggests using techniques like parameterized tests and randomizers to mitigate the pesticide paradox. However, he emphasizes the importance of minimizing the number of flaky tests through proper test design and maintenance.

Outlines

00:00

🗣️ Introduction and Personal Background

The speaker introduces himself, shares his background as a QA engineer, YouTuber, and his experience in product companies. He discusses his motivation for the presentation and the importance of automation testing in bringing people together and sharing knowledge.

05:01

🎯 Understanding the Purpose of Test Automation

The speaker emphasizes the need to understand the purpose of test automation, which he defines as providing reliable information about the state of the build as quickly as possible. He highlights the importance of having a clear goal to measure the effectiveness of the automation process.

10:01

🔍 Measuring Effectiveness: Definition and Considerations

The speaker defines effectiveness as the measure of successfully performing an action, considering resource consumption, time, and other factors. He stresses the importance of considering personal growth and knowledge acquisition alongside company and product benefits when measuring effectiveness.

15:03

🤖 Automation as a Parallel Project

The speaker emphasizes that test automation should be treated as a parallel project within the main project, requiring proper attention and resources. He discusses the limitations of using Return on Investment (ROI) as a metric for evaluating automation effectiveness and the need for a more comprehensive approach.

20:04

💰 Calculating Cost Savings from Automation

The speaker presents a formula for calculating potential cost savings from automation by considering the expenses of manual testing, defect resolution, and infrastructure costs. He cautions against relying solely on this approach, as it often involves assumptions and may not reflect the true benefits of automation.

25:07

📈 Visualizing Automation Effectiveness

The speaker suggests using visual aids, such as graphs and charts, to demonstrate the effectiveness of automation to stakeholders. These visuals can include test coverage, defect detection rates, and the ratio of automated to manual testing over time, potentially highlighting the benefits of automation.

30:08

🔄 Frequency of Test Execution

The speaker emphasizes the importance of running automated tests as frequently as possible, ideally for every build. He introduces a metric to measure the frequency of test execution relative to the number of builds, highlighting the benefits of frequent testing and the potential pitfalls of infrequent execution.

35:10

🟢 Test Success Rate as an Indicator

The speaker discusses the percentage of successful test runs as an indicator of the effectiveness of automation. He provides guidance on interpreting different success rate ranges and their implications for the overall automation process, suggesting potential issues and areas for improvement.

40:13

⏱️ Test Execution Time and Developer Adoption

The speaker highlights the importance of minimizing test execution time to promote developer adoption and integration of automation into their workflow. He emphasizes the need for tests to run quickly, preferably within 30 minutes, to maintain developer engagement and encourage regular use of automation.

45:14

🌟 Promoting Automation as an Ambassador

The speaker encourages being an ambassador for automation, sharing success stories, promoting its benefits, and fostering trust in the automation process. He suggests involving as many team members as possible in the automation effort to increase its effectiveness and impact.

50:15

📰 Reliable Information and Trusted Automation

The speaker compares effective automation to a reliable news source, providing timely and trustworthy information that covers important topics. He emphasizes the importance of building trust in the automation process by ensuring reliable and actionable results, without which the automation efforts cannot be considered truly effective.

55:18

🎤 Q&A Session and Closing Remarks

The speaker engages in a Q&A session, addressing queries from the audience on various topics, including keyword-driven automation, the role of AI in automation, dealing with flaky tests, and fundraising efforts. He concludes by thanking the audience and encouraging donations for a charitable cause.

Keywords

💡Automation

Automation refers to the process of using software tools and scripts to automate repetitive tasks or processes that would otherwise be performed manually. In the context of this video, automation is specifically related to the automation of software testing. The speaker discusses the importance of automating tests to provide faster and more reliable information about the state of software builds. For example, the speaker mentions how automation can save time and effort by running tests automatically instead of manually testing each regression cycle.

💡Effectiveness

Effectiveness is a measure of how well a particular action or process achieves its intended goal. In the context of this video, the speaker focuses on evaluating the effectiveness of automated testing processes. The speaker defines effectiveness as "a measure of successfully carrying out a particular action, taking into account the expenditure of resources, time, and other factors." The video discusses various metrics and approaches to assess the effectiveness of automated testing, such as the frequency of test execution, the success rate of test runs, and the execution time of tests.

💡Test Execution

Test execution refers to the process of running and executing automated tests. The speaker emphasizes the importance of executing tests as frequently as possible, ideally after every software build, to obtain up-to-date and reliable information about the state of the software. The speaker introduces a metric called the "build-to-run ratio," which is calculated by dividing the number of builds by the number of test runs. A ratio less than one indicates that tests are being executed more frequently than the number of builds, which is considered desirable.

💡Test Success Rate

Test success rate refers to the percentage of tests that pass or succeed during a test run. The speaker presents this metric as an indicator of the effectiveness of the automated testing process. A high success rate (e.g., 80-100%) suggests that the tests are stable, reliable, and providing accurate information about the software's state. However, a low success rate (e.g., less than 50%) may indicate issues with the tests themselves, such as flaky tests, environmental problems, or a lack of discipline in addressing failing tests.

💡Test Execution Time

Test execution time refers to the duration it takes to run a set of automated tests. The speaker emphasizes the importance of keeping test execution times as short as possible, ideally within 30 minutes for small projects and under two hours for larger projects. Shorter execution times encourage developers and team members to run tests more frequently and maintain a feedback loop. Long execution times, on the other hand, can lead to developers disregarding the tests or losing context while waiting for results.

💡Flaky Tests

Flaky tests are automated tests that exhibit intermittent and inconsistent behavior, sometimes passing and sometimes failing without any code changes. The speaker acknowledges the existence of flaky tests and the need to address them to maintain reliable test results. Flaky tests can negatively impact the test success rate and undermine the effectiveness of the automated testing process. The speaker suggests techniques like parameterized tests and randomizers to mitigate the impact of flaky tests.

💡Test Coverage

Test coverage refers to the extent to which the software's functionality, features, and code paths are covered by automated tests. The speaker mentions that effective automation should cover important topics or areas of the software, similar to how news media should cover important stories. Achieving adequate test coverage is essential for providing reliable information about the software's state and identifying potential issues or defects.

💡Adoption

Adoption refers to the process of encouraging and facilitating the use of automated testing by various stakeholders within a project or organization. The speaker emphasizes the importance of being an "ambassador" for automated testing, sharing success stories, and demonstrating the value of automation to increase its adoption. Widespread adoption of automated testing is crucial for maximizing its effectiveness, as it enables different team members (developers, managers, analysts) to leverage the tests and obtain reliable information.

💡Reliability

Reliability refers to the ability of the automated testing process to consistently provide accurate and trustworthy information about the software's state. The speaker emphasizes that the goal of automation is to provide "reliable information as quickly as possible." If the test results are ignored or considered unreliable, it indicates ineffective automation and the need to address underlying issues, such as flaky tests, environmental instability, or lack of discipline in addressing failing tests.

💡Exploratory Testing

Exploratory testing is a manual testing approach where testers actively explore the software, uncovering defects and edge cases through hands-on experimentation and critical thinking. The speaker mentions that automated testing should not replace exploratory testing but rather provide additional tools and support for manual testers engaged in creative and exploratory activities. Automated testing complements exploratory testing by handling repetitive regression tests, freeing up time and resources for manual testers to focus on more complex and critical areas.

Highlights

The goal of automation testing is to provide reliable information about the build status as quickly as possible.

The effectiveness of automation testing should be measured against its stated goal, not just calculations like return on investment.

Run your automated tests as frequently as possible, ideally for every build.

Aim for a high percentage of successful test runs, at least 60-80% for end-to-end tests and 80-100% for lower-level tests.

Fast test execution time is crucial, ideally under 30 minutes, to encourage developers and others to use the automation.

Make your automation accessible and encourage its use by as many team members as possible through promotion and ambassadorship.

The goal is for people to trust and rely on the automation results, treating failed builds as a serious concern to be investigated.

Automation testing is an ongoing process within the overall testing process, not a one-time solution.

Positive ROI calculations before implementation do not necessarily mean effective automation later on.

Low test success rate and lack of attention to failed builds indicate deeper problems with the automation process.

Complex project infrastructure and active development can make it challenging to maintain stable end-to-end test results.

Flaky tests, environmental issues, and lack of discipline in addressing failed builds can contribute to ineffective automation.

Divide tests into smaller scopes or prioritize them to allow developers to run only relevant tests quickly.

Share success stories and concrete examples of how automation has helped to promote its value and encourage adoption.

Continuously work on improving test resilience, environments, and team discipline to address flaky and failing tests.

Transcripts

одні

хвилі я історії якісь

порозповідаю ну тут буду дивиться Що

Що нормально короче що я почав з чого я

почав

готуватись я підготував презентацію І

так як я ніколи не виступав почав

дивитись не репетирувати перед людьми а

почав дивитись відео як потрібно

виступати і люди кажуть що перше що

треба зробити - це якісне

освітлення приміщення повинно бути

максимально світло щоб

люди щоб люди не засинали не зивали і

дивились на вас а не

на свій телефон і я Рома каже Да ми типу

В кінотеатрі я таки окей окей

окей розповідали що що це напевно

індуські курси ні ні це нормальний тип

він типу якийсь професор гарварда він

там класно ходив там ламав речі

всякінольні

Вони не індуси а індійці правильно

казати індійці

а друга тема Короче кажуть

ти є три шляхи відкрити презентацію типу

перше можна от зробити привіт мене звути

Паша я буду розповідати про те як

оцінити ефективність автоматизації други

шлях це пожартувати А я не пожартую я

просто розкажу історію як ми з Ромою

познайомились Точніше як я дізнався що у

Роми мабуть найдорожчий комп'ютер во

всій Україні

це про він виклада робоче місце це це

нетві це до Доу зробила Це була 1 червня

Я сьогодні передивився і тоді ми

познайомились з Ромою він він мене не

знав але я вже знав що він

існує хто ще так дізнався про Рому

всі

знали потім я зрозумів що Рома класний

хлопець дуже класний хлопець робить дуже

багато класних речей включаючи цю

конференцію це дуже круто зараз дуже

важливо робити якісь речі які об'єднують

людей навколу чогось в даному випадку це

благодійність і ми знайомимось ми

ділимось знаннями Це дуже

класно Ну і в принципі історію я вам

розповів можемо переходити і до теми мо

конференції я буду розповідати про те як

я оцінюю ефективність автоматизації

тестування чому я кажу я тому що тема

досить така холіварна немає якогось

одного правильного шляху щоб сказати от

робиться так я розкажу як це робив я на

протязі 2 з поно років Коли я прийшов на

проект Де була автоматизація тестування

але вона була повністю провалена що я

маю на увазі під повністю проваленою

а buл ніколи не був зелений тобто завжди

було 50% впавших тестів їх запускали

тільки для того що не знаю для чого щоб

подивитись що воно запускається ніхто не

дивився на ці тести під час релізу а

менеджер розглядав автоматизацію

як як

сказати Знаєте як собачки видаєте якісь

ласощі для того щоб вона не пішла з

роботи умовно ти даєш щось Що може бути

цікаве людини але ти не бачиш в цьому

велью Ти

єдиний для чого ти це робиш щоб люди

відчували що вони роблять щось цікаве а

не тільки тестують ручками попередній

спікер казав про те що немає у них не

було там процесів і оце все Я думаю що

мабуть 50% присутніх тут працюють в

такому енвайроменті Да коли нема ні

вимог ні процесів нічого Ну у нас було

так само все але була автоматизація яка

не працю цювала інтеграційні тести були

десь приблизно 1000 штук всі вони були

просто скіпнуті unнітести запускались

тільки на блді n2n тести не

запускались зовсім фактично але вони

існували і стояла моя задача тобто Я

коли прийшов в компанію я не хотів

руками вже тестувати типу Я вважав що я

це

переріз я про менеджмент я про

автоматизацію Я про все оце нове круте і

цікаве а мені кажуть на протестуй

дефектик і ще один і ще один і ще один і

ще ось тобі

сотня я такий я не хочу з цим миритись Я

хочу змінювати щось я хочу

автоматизувати мені це цікаво і в якийсь

момент ми ось я почав свого менеджера

пушити для того щоб зробити новий проект

на той момент вже став досить не досить

популярний він тільки вийшов пrй хто

користується плейрайтом

викті

пriй вийшов але без тестранера ми обрали

що там cyprс обрати пriй по ітогу взяли

плеrй і почали робити автоматизацію але

а у менеджмен у менеджмента досі не було

знаєте оцього бачення того що

автоматизація якось може позитивно

вплинути на існуючі справ е хід справ

тому

ее все що мені ну тобто одною з задач

моїх було переконати їх в тому що те що

ми робимо важливо те що ми робимо це

ефективно і те що ми робимо має якусь

користь

Ні це історія мені сказали почати з

історії і ось в принципі все про це я і

буду вам сьогодні розповідати як я

доводив користь і ефективність того що

ми робимо і в принципі ось Хто взагалі я

такий то я вже розповів багато хто я

взагалі такий я ось як півроку став

ютубером знімаю Відео про автоматизацію

тестування на каналі

qmpie у мене с на сьогоднішній день вже

666 підписників це найкращі люди в світі

ви можете стати одним з них перед

переходячи по цьому

qr-коду це обіцяна рекламна інтеграція А

чому QA S а хороше питання тому що я QA

і sai - це з японського людина яка іде

трохи попереду тобто є як звичайні

школота так скаже і у школоти є семпай

той який їм розказує як робити щось

правильно Ну я люблю Японію і тому sмпай

А цікавий момент я ніколи не працював в

аутсорсі є тут ще такі люди які

працювали лише в продукті

у Нормально Нормально сь я девть років

працював круто круто в продукті в

продуктових компаніях точніше компанія

була аусоource але я працював на

продукті А зараз займаю роль

реліз-менеджера і техліда ну а по тайтлу

типу senньor QA Менеджер це до речі всім

хто переживає типу Ось у мене тайтл

такий тайтл неважливо важлива Роль якою

ви

займаєтесь Також у мене двоє дітей і

одна собака породи баїну знаєте от я

пам'ятаю я приходив

на презентації Там хтось завжди котикі

вставляв А я собаку покажу просто вам

свою яка вона мила там і Класно О

бачитейшла аудиторі все в принципі все

про що я буду говорити про мету

автоматизації тестування про

ефективність як я і вмірюю і як я

рекомендую вимірювати вам Ну і метрики

які я використовував під час цього в

принципі все Навіщо вам це якщо ви

Одинокий автоматизатор як був Я одинокий

Самурай у вас повинен бути Шлях

і ця презентація Я сподіваюсь дасть вам

якісь об'єктивні поінти до яких ви

можете

рухатись щось

показувати вашому менеджменту і якось

вдоскнавлювати себе тому що тут будуть

не тільки метрики а і способи ну трохи

трохи буде способів їх досягнення чому я

не фокусувався саме на способі

досягнення цих метрик тому що мені Рома

сказав що тут буде якось людей пополам я

не хотів хотів щоб було цікаво всім якщо

ви

лід менеджер або мануальний тестувальник

це дасть вам

більш широкий погляд на те що

відбувається в автоматизації ви будете

розуміти які цілі ставити вашим

підлеглим якщо ви менеджер аболід якщо

ви мануальний тестувальник ви будете

розуміти чи не херню роблять ваші

автоматизатори тому що я наприклад коли

був мануальним тестувальником я не

розумів взагалі Для мене вони були такі

типу розумні якісь дядьки або хлопці і

вони щось роблять а я не розумів Як воно

взагалі впливає на те Що робимо ми Якщо

у вас є така ж ситуація можливо моя

доповідь вам

допоможе Ну і дисклеймер Я перейшов на

українську досить недавно тому в мене

Вона десь на рівні

B1 якщо будуть якісь слова російські

вибачаюсь будемо говорити про

автоматизацію в контексті

функціонального тестування тобто не про

Security тестинг не про перфоманс це

окрема тема окремі метрики і окремі люди

Ну і моя точка зору може не співпадати з

вашою або з людьми яких Ви читаєте або

дивитесь тому про все це ми з вами

можемо поговорити після доповіді або під

час Я закликаю вас Якщо у вас є питання

якісь можете походу піднімати руку і ми

будемо говорити мені буде так легше тому

що я буду бачити якийсь зворотній

зв'язок А і ще про

приколвеликий я собі там наготував кучу

просто анотацій для того щоб не забути

про що говорити Ну типу думав буду

стояти тут знаєте отак і читати вам не

то що на слайді А то що збоку але все це

як ви бачите відсутня і я дуже нервую

через це Отже говорити Ми будемо про

ефективність і про мету але там для того

щоб взагалі виміряти якусь ефективність

нам роз процесу якогось нам потрібно

розуміти навіщо взагалі цей процес був

створений тому що багато людей які

сперечаються щодо автоматизації

тестування

зараз так сперечаються щодо

автоматизації тестування і і не

погоджуються один з одним

трапляється тільки через те що люди

дивляться на одну і ту саму річ з різних

сторін хтось вводить процес

автоматизації тестування Тому що йому

просто

задовбало тестувати руками там він хоче

більше ЗП він хоче повчитись десь і

перейти в іншу

компанію менеджер хоче розширити штаб

наприклад ну типу Він каже Так нам

потрібна

автоматизація під це я отримаю новий

бюджет найму нових людей у мене буде не

п'ять людей а 10 це теж мо можеть бути

якісь політичні ігри і кожен може

переслідувати свої цілі я буду говорити

тут з точки зору людини яка хоче

і себе покращити і принести якусь

користь продукту і принести якусь

користь

собі але для початку давайте домовимось

що автоматизація тестування - це процес

який знаходиться всередині процесу

тестування Що це значить що не буде

моменту коли ви все автоматизували

і більше нічого тестувати не потрібно

це онго процес який відбувається до

кінця життого до кінця життєвого циклу

вашого продукту тобто в момент який коли

ваш продукт пересторяє розроблятись

автоматизація тестування і тестування як

процеси помирають Вони теж не мають

сенсу тому що продукт АА він він може

приносити ю він може приносити гроші але

як е розробка вже не війдеться нема в

цьому ніякого сенсу і давайте зробимо

невеличкий інтерактив Як ви думаєте саме

ви яка мета взагалі автоматизації

тестування Економія часу економія

часутиці ви бачите гро думаєте А ви

бачили

зарплату

автоматизація рутини рутини так кноміч

такнняго Вибачте виключенняли Так це

теж Важливо щоб тестерам було цікаво

супер супер тому що Хто з вас знає що

таке тестувати регресію кожен хто

проходив в цикл регресії десятки разів

знає що це ну просто можна то аналізував

десятки разів однакові репорти так само

знаю Як

ваши так так так свого роду зменшення

ефорту так так в якийсь момент часу це

буде зменшення ефорту так

ре е повторювальність так повторювані

Тобто ми будемо очіку якісь е одні і ті

самі дії виконувати знати точно що в нас

буде в результаті і це все так але це не

кінцева мета автоматизації я про це

трохи більше покажу він реально схожий

на тебе Так в цьому була

сенс В цьому є сенс

Я не знаю чому во вуса

дорисував я написав якийсь там промпт і

він оце видав А що автоматизація

тестування може зробити саме для вас

тобто для вас як особистості для вас як

інженера Як ви думаєте підняти настрій

підняти настрій або зіпсувати

правильно це алкоголь Ти про що ти про

алкоголь тільки що сказав про піднятий

настрій ні про

автоматизацію ви не думали про

це Вибачте дати більше часу на Що на

ютубчик на те щоб дивитись твій канал на

мій канал правильно і Щоб вчитись

автоматизації добре насправді

автоматизація тестування може дати

багато багато дати тому що в мене там в

якийсь момент був оця криза Я не знаю

була у когось криза того що ви всередині

творець але створюєте лише

дефекти було у когось так їх створює і

то да да да ви тільки описуєте їх Да і

типу що що в цій жи що в моєму житті не

так А коли ви пишете код вам трохи легше

ви думаєте О я щось реальноне роблю щось

Що да І далі ви теж стоворюєте дефекти

але в автоматизації добре Я це до того

щоб ви ніколи не виключали коли Ви

думали про автоматизацію тестування про

якийсь процес про мету не викидайте себе

з цього завжди шукайте для себе щось що

ви можете знайти Ну

себе Якось туди підлаштувати щоб не

тільки компанія і продукт виграв від

вашої діяльності а також і ви це мій

меседж який я теж буду підкреслювати на

протязі

всієї доповіді як на

мене мету треба формувати дуже коротко

для того щоб вона була зрозуміла для

всіх і я думав про це і сформував її так

мета автоматизації надавати якомога

швидше надійну інформацію стосовно стану

бл да тобто надавати надійну інформацію

якомога швидше все все що ви казали тут

раніше це скоріше знаєте як сайде-ефекти

всього того що ми отримуємо швидку

надійну

інформацію тому я пропоную вам

фокусуватись Коли ви ставите соі мету

якусь коротку але все об'ємного тому я

зійшовся на цьому визначенні для себе це

не з інтернету це я от там щось і думав

думав Як це можна оформити і прийшов до

цього Тому все далі от мені оце

подобається слайдик чому на блін оцей

слайдик знаєте в пам'ятаєте цей фільм

або книжку Коли в чому сенс життя і там

був комп'ютер який 100 млнів

років вичисляв і потім сказав 42 так от

і я сидів сидів і якось ось мету для

себе і с сформулював і навколо цієї мети

я вже вибудовував свої якісь метрики для

того

щоб як дізнатись чи моя автоматизація

ефективна і тільки знаючи мету ми можемо

дійсно оцінити наскільки ефективно ми до

неї рухаємось без цього як ефективність

майже неможлива тобто коли у вас немає

чіткої цілі ви ніколи до неї не прийдете

тому коли починаєте щось робити

обов'язково Намалюйте собі в голові або

на на паперчику десь те до чого ви

дійсно прагнете я вже сказав я буду

надалі оцінювати процес автоматизації

Спираючись на цю мету е у вас може бути

інша мета ви можете думати зовсім іншими

категоріями це нормально наприклад як я

уже казав ви подумаєте просто ну я хочу

ЗП більше типу Я запілю маленький

проектик який буде робити 10 кейсів і на

performомаanceсревw там скажу от я

автоматизацію за ее зробив у нас на

проекті ганіть п

500 це теж це теж нормально Ну типу якщо

ви отримаєте

це це це теж я я це підтримую я це

підтримую якщо це працює Головне щоб ви

були

щасливі це про те що ніколи не

викреслюйте себе з рівняння

ее мети тобто у вас теж навколо у вас

буде все крутитись компанія закриється

проект помре а ваші знання і навички

завжди будуть з

вами і тут хтось з вас хто може матьорий

автоматизатор а можливо менеджер який

мислить категоріями грошей можна сказати

Паш що ти нам тут дч втираєш вже існує

така метрика як y return of Investments

і якщо рої позитивно то і автоматизація

має сенс вона валідна ефективна І

взагалі все добре і проблема в рої що це

насправді метрика

яка рахується перед початком

запровадження автоматизації тестування

для того щоб порахувати в який

момент ми повернемо наші

інвестиції і тим самим ми будемо вважати

що Окей У нас все працює Тобто ви не

можете рахувати роy якщо у вас вже

автоматизація запущена Ну звичайно ви

можете це зробити але

сенсу в цьому не так

багато проблема щерою в тому що зазвичай

воно рахується для проектів які

приносять якісь кошти умовно ви вирішили

відкрити точку з кавою вклали в неї 2000

доларів порахували що місяць фукці

функціонування цієї точки буде коштувати

там 500 до$в Я не знаю скільки це коштує

насправді і кожен день ви будете

заробляти там 300 долав умовно і ви

можете легко порахувати в який момент ви

повернете свої 2000 і вийдете на якусь

окупані окупаємість і будете заробляти

гроші по автоматизації це так не працює

Тому що Во вона не заробляє гроші вона

може економити Якщо ви все зробили

правильно і то якщо ви все зробили

правильно тому роy як метрика Вона часто

дуже в автоматизації рахується на

багатьох припу

при тому що ми щось зекономимо десь

знайдемо дефект автоматизуємо якусь там

тися кейсів І взагалі перестанемо

використовувати мануальне тестування це

велики ну дуже часто це маніпулятивна

дуже метрика для того щоб

переконути замовника в тому щоб нам

потрібен бюджет на те щоб найняти

автоматизаторів І це нормально це бізнес

Ну типу всі від цього виграють Можливо

навіть замовник якийсь момент виграє а

компанії вигідно продавати нові послуги

Ну тобто умовно У вас є команда 10 людей

п'ять з них тестувальники а такі А

давайте

зробимо автоматизацію тестування але

коштувати вам це буде там плюс 10 000 на

місяць доларів тому що ми там два

сіньйоракихось або одного Рома

наймемо І як І от повернеться вам якась

інвестиція ось колись але ви ж платіть

ці ну тобто це вигідно всім але

пам'ятайте що це все-таки прогнози які

можуть насправді

не

не не справдитись і позитивне Рой - це

ніколи не значить що у вас ефективна

автоматизація це лише значить що ви

провели якісь обчислення які Можливо в

якийсь момент будуть правдивими А

можливо і

ні тому що реальна автоматизація може

поховати всі спрогнозовані розрахунки

люди які займаються і знають яка

кількість

проблем трапляється по ходу розробки

тому що небагато людей розуміють що

повноцінна автоматизація - це

паралельний проект всередині вашого

основного проекту

тобто ставитись до нього треба ніяк для

якогось паралельної активності а до

повноцінного проекту який вам дозволяє

отримувати інформацію якомога швидше

надійну інформацію якомога швидше якщо

ви не будете ставитись до цього проекту

правильно то всі розрахунки які ви там

провели вони у вас

будуть ви можете їх просто викинути але

це не значить що А давайте так а що Ми

зрозуміли на цей момент у мене є пес

автоматизація має свою мету рої не

використовується для оцінки ефективності

автоматизації і позитивні розрахунки

не на початку не дорівнюють ефективній

автоматизації

резюмували резюмували можемо рухатись ра

далі так я трохи

Так а далі будемо говорити про

ефективність уже про саму суть мого

виступу про те як цю ефективність

вимірювати і для того щоб ми були

залайнені з як з термінологію я визначаю

ефективність як мірою виконання певної

дії успішно

виконання певної дії тобто наскільки ми

успішно щось робимо Тобто це якась міра

оцінки того що відбувається в даний

момент з урахуванням витрат ресурсів

часу та інших факторів це тоже теж дуже

важливо але але але але я тут багато

буду казати ну такі речі які будуть

зрозуміли лише автоматизаторам як суть

болі але є ситуації коли вам треба

порахувати цю ефективність не для себе

не для членів команди не для людей які

шарять як скажемо а для людей які

оперують тільки поняттями час і гроші це

зачасту типу менеджери яких ми вже

назвали

демілами тобто люди які не шарять я їх

називаю але які дивляться там на

графічки якісь на циферки і їм ось це

цікаво а не те що ви там почали

релізитись бельш без

Тому це теж треба рахувати і є

спеціальні формули які допомагають вам

порахувати ефективність автоматизації з

моменту її застосування тость

введення рахується воно наступним

чином пам'ятаємо що автоматизація - Це

не про заробіток це про економію тому

будемо рахувати економію формула проста

Ми сумуємо суму коштів яку ми могли б

витратити на оплату спеціалістів які б

вручну тестували Тести які вже

автоматизовані Тобто ми почали щось

автоматизовувати 10 тестів

А ми знаємо що на проходження цих тестів

нам треба заплатити мануальним

тестувальникам суму

і ось це ми сюди і поідставляємо я далі

трохи подробно про це розкажу далі ми

вводимо якусь суму яка ми як ми думаємо

ее буде ви Ну ми ми потратимо на те щоб

якщо ми побачимо якийсь баг на проді або

щось Що зламалось Ми рахуємо сюди

зарплату програмістів а сапорта і інших

людей які займаються обробку інцидентів

для того щоб сказати Окей тобто

е-е якби у нас була автоматизація то

цього б не сталося це вже економія але

це теж зновутаки припущення але як ми

кажемо ці цифри не повинні бути

абсолютно точними ці цифри існують для

того щоб їх показувати десь на графіках

І щоб люди думали О які ми класні тобто

в першому там де ми плюс Ми сумуємо

якусь економію потенційно від

автоматизації і в рядку мінус Ми рахуємо

всі витрати абсолютно які б

ми які б

ми потрібні

для для початку автоматизації тестування

Це зарплата автоматизаторам ліцензії

enвайменти equipment будеш з понеділка

оцінювати дякую тобто да до речі там

спойлер далі не треба так

робити тобто все все що вам необхідно

зроби Всі гроші які необхідно

використати для того щоб автоматизація

почала працювати все це рахується вце

aвomation як порахувати ваші

збереження по тестуванню час який раніше

спеціалісти могли б витратити на

виконання тестів які теперто атизовані і

середні витрати на оплату праці фахівця

ручного тестування за хвилину умовно У

вас є 150

тестів фахівець з тестування проходить

кожен тест за 15 хвилин ми помножаємо

150 на 15 і заробляє він за хвилину

умовно там якщо це Рома о

долар множимо і у нас виходить якась

Сума яку ми економимо тому що це тест

був автоматизований типу людина

мануальчик і більше не треба його

виконувати

е і увас гарно І у вас повинен бути в

ідеалі ось такий от

графік що він

означає я про це теж пожартую зараз як

це відбувається ви на початку витрачаєте

багато грошей для того щоб закупити

ліцензії налаштувати

інвайромент найняти автоматизатора тому

що найм це теж дорогостояча тому

економії у нас ніхера нема Ми все

витрачаємо потім цей автоматизатор

починає працювати у вас накоплюється

якась кількість автоматизованих тестів і

в якийсь момент ось це

Manual стає більше так як тестів стає

більше По ідеї економії стає більше це

автототаal у вас залишається сталим так

як у вас уже працює автоматизатор вили

навіть зменшується може зменшуватись

тому що кожен місяць е вам не треба

Наприклад платити за там ліцензії ви

один раз купили або якийсь там enваймен

Ну тобто в якийсь момент у вас цей

графік вийде в плюс але коли цей момент

Настане ніхто не знає

тому Рахувати треба кожен місяць рахуєте

ви кожен місяць додаєте і в якийсь

момент цей графік буде йти в плюс В

бонусом до цього

А тобто в ідалі це повинно працювати так

як это буде працювати у вас я не знаю А

в який момент

льчики починаємо звільняти О ось я ж про

це і кажу вони переходять в

автоматизацію не треба

нікого

так і ось про те що я казав проводьте

такі подібні розрахунки тільки за

крайньою потреби тобто по факту вони не

відображають реальної картини тому що ми

показ що ми заміняємо правильний дуже

коментар ми показуємо те що ми заміняємо

мануальне тестування на автоматизоване

але автоматизація тестування Це не про

заміну це на надання додаткових

інструментів людям які займаються

exploratory теestнгом який займається

творчою діяльністю а тестування може

бути творчою діяльністю тобто

автоматизація - Це не про заміну це про

надання нових можливостей тому рахувати

це потрібно тільки якщо у вас є крайня

необхідність для когось там показати

результати е ви можете використовувати

подібні прийоми Додайте до цього ще

графік зростання покриття автотестами

люди такі люблять графіки більше

графіків кількість дефектів які були

виявлені автотестами ще один графік і

кількість тестів які були виконані

вручну за реліз і скільки в

автоматизований спосіб і вони там десь у

вас в якийсь момент будуть перетинатись

і виглядати так буде що автоматизація

взагалі перекриває ручне тестування всі

будуть в

захоті мануальщики не потрібні

так так так

так там якись момент явно буде коли

кільшсть автоматичних тестів також буде

велика буде в іншу

ро доби я не дуже зрозумів Давайте потім

я просто не дуже

зрозумів ну тобто такий підхід Я

рекомендую використовувати який коли є

така необхідність коли є замовник якому

треба показати щось красивеньке якусь

презентацію зробити показати що гроші

були витрачені не просто так можна

звийно якому домані я

а-а я не знаю як правильно

назвати ну В нас сервіс який допомагає

маркети маркетинг маркетинг мабуть да

маркетинг спеціалістам організовувати

свої

компанії ну я чому це питання задаю тому

що наприклад все можна покрити

автотестами наприклад у нас мбеди і є

речі які ти просто автоматизацією не

покриє є вебтестування Де ти можеш прям

все все все все покрити тому єсть такі

поняття як покриття і все вони Ну не

завжди будуть не завжди може бути рої

відбутись 100% 100% абсолютно точно я ж

кажу що це таки тонкі матерії і ви

повинні відчувати коли це треба робити

коли це робити взагалі не треба А я

нагадаю про мету автоматизації надати

якомога швидше надійну інформацію

стосовно стану білда і я зроблю коротку

теж історію вам щось оце

нагадує партія

о Короче я роблю виділяю цей синьою

стрічкою ну типу я люблю синій колір

мені він подобається і щось я дивлюсь Це

типу цей свободна я или щось таке я

такий так щось короче

неправильно да щось короче неправильно

Не хочу я тут ніяких прапорів свободної

Росії додам ще одну стрічку зверху щоб

во не виглядало так Фінляндія Да і

просто от я потім через те що Мені

здалось що це весело вирішив не міняти

колір тому що думаю вже якась типу

смішна

історія і далі переходимо до

ефективності перше на що я хочу звернути

у увагу це частота запуску

автоматизованих тестів Ви повинні

запускати ваші тести як умога більше я

вже казав виходячи з нашої мети ми

хочемо отримувати результати стосовно

кожного білда Ми хочемо бачити цю

інформацію і робити якісь висновки якщо

ми не хочемо це Інше питання скоріш за

все Я розкажу чому ми не хочемо цього

трохи пізніше тому ваші тести повинні

запускатись як умога більше це як

порівняти з з дорогим автомобілем ви

його придбали і не їздите він у вас стоє

в гаражі а їздите ви на

якісь іншій старій машині або навіть на

таксі але з автомобілем є нюанс в тому

що якщо він хороший дорогий він може

стати ще дорожчим з автоматизацією так

не буде автоматизація не стає

дорожче Ну

типу тому якщо ви щось почали робити

старайтесь використовувати це якомога

швидше більше я бачив проекти де я питав

а коли ви запускаєте автоматизацію Ну за

годину до релізу були такі в мене

відповіді типу А що ви якось реагували

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

якомога частіше добре якби як ну типу

формулу яку ви можете застосовувати щоб

вимірияти Чи у вас все добре це

кількість білдів поділіть просто на

кількість запусків тестів якщо

коефіцієнт буде менший один значить що

ви запускаєте автоматизацію частіше ніж

на кожен блд Навіщо це робити Ну

наприклад це значить що користувачем

автоматизації є не тільки ви а інші люди

можуть її використовувати на різних

енвайроментах на різних браузерах ну

тобто це може бути різні типи

автоматизації це значить що ваш

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

якщо

ви у вас коефіцієнт один або трохи

більше або але менше одиниці це вже

непогано Це значить що Ви запускаєте

хоча б на кожен блд або трохи менше і

якщо коефіцієнт більше двух це значить

що ви запускаєте менше ніж на Кожен

другий

блд багато з вас хто Мабуть

займаєтьсятома це ж неможливо у нас

автоматизація 10 годин де і про це ми

теж поговоримо чому так не повинно бути

тобто

запускайте так я про це вже проговорив

запускайте тести як у мога

частіше Так ви будете знати актуальну

інформацію

стосовно нового

білда якщо ви не хочете цього робити для

цього скоріш за все є проблеми у вас є

інші проблеми про які ми теж поговоримо

далі Ну типу хтось З вас може скаже Та

мені воно не треба на сам Ну треба

треба Якщо не треба це значить що ви

десь робите щось

неправильно далі Ось чому одна одна з

метрик яка через яку ви можете сказати

воно мені не треба це відсоток

успіху тестових прогонів якщо ваша

автоматизація виглядає як на правому

скріні це до речі моя з одного з

проектів так це все теж мої але це це

моя моя прям А якщо ваша автоматизація

виглядає так то у вас є проблеми у вас є

проблеми в тому що вона

не показувала вам об'єктивних

результатів того що відбувається у вас з

білдом або показувала

Але у вас є багато інших проблем які теж

треба вирішувати це грак неправиль чому

Ну типу треба щоб він був Ну типу в в

спектрі від зеленого до червоного Ну

типу треба зробити Рома ти що пива

випивробити такий графік щоб він кож цію

відмальовував кольоро спектрі від

зеленого до червоного ідея для

стартапа зроби такі графіки єсть такі

градієнтом я щось не

дадизайне ну короче Серга задача на

понеділокмене на понеділок Короче я

уль тобто якщо у вас

кількість відсоток провалених білдів

дуже великий У вас є проблема Але хтось

що

ящо і це про це ми поговоримо зараз я

просто

показую зараз в мене є там да Якщо у вас

менше

50% успішних білдів то у вас дійсно є

проблема скоріш за все автоматизацією

мало хто займається ви не відслідковуєте

результатів ви не реагуєте на те що вам

вона показує і інформація яку вам надає

вона вам скоріш за все не цікава

А показую низьку дисципліну всередині

команди і всередині проекту Тобто це теж

сигнал якщо команда не звертає увагу на

те що у вас є червоні білди і це

регулярно ніхто на це ніяк не реагує

включає у вас у вас

проблеми проблеми про ці проблеми Ми

також трохи поговоримо пізніше Якщо 6080

це вже непогано дивіться тут є

нюанс цей графік для toend тестів якщо у

вас подібний графік для Unit integration

або API то це взагалі Ну

типу Я не знаю що ви робите Та там може

бути навіть зелене але воно нічого не

покаже це теж ми про це теж пока

поговоримо про покриття

проваленийважаєдьяму Чому він впав це

теж нюанс Чому він а чому він не

заігнорений якщо це зламаний тест а чому

він флекі а чому він чому у вас

нвайромент поганий а чому се паy не

спрацювала в той момент може бути багато

нюансів тому в мене система типу Ну

суперінтегровано в нас в ртпаті типу Я

не знаю десятки Якщо десь якась команда

щось не задеплоїть неправильно це

значить що в мене типу відвалиться

половину тестів і це теж треба

пропрацьовувати все це показує на

проблеми так багато проблем Ми не можемо

вирішити це факт але не звертати на них

уваги - це не наш шлях якщо ми говоримо

про ефективність тому 6080 для мене

особисто я вважаю нормально для нтуn

тестів якщо ви тримаєте цей результат це

значить у вас більш-менш порядна

автоматизація на неї

дивляться вона стабільно відпрацьовує Ви

працюєте з флекі тестами у вас

стабільний енвайромент і більш-менш

стабільний Давайте так і все добре для

мене це Окей як для вас мені було б теж

цікаво послухати і 8100 - це для мене

недосяжний недосяжна мета але недосяжна

в -туend тестах в API тестах Unity

integration якщо у вас менше

80% успішних білдів це значить у вас

проблема проблем проблема є їх треба

вирішувати тобто У вас є неефективність

А чому так відбувається чому от взагалі

от ми працюємо ми робимо все по книжці

все правильно але все одно білди не

зелені як у мене

наприклад дуже складна система яка має

Ну я ж кажу десятки сепаі десятки

сервісів які деплояться одночасно якщо

там один сервіс може не задеплоїться або

задеплоїться з помилкою мене там

половина тестів

відвалиться тобто складна інфраструктура

проекту і там якщо у вас це тун тести це

дуже буде складно

підтримувати стабільність інфраструктури

активність розробки до прикладу в якийсь

момент

Наша компанія вирішила

що Який у нас там був Angular Angular

неніні Angular якийсь інший йworк короче

для ui Framework він не досить добрий

давайте все перепишемо на react А у мене

типу 150 ту тестів і ви розумієте що

відбувається в цей момент всі ці 150

тестів один за одним починає падати з

кожною новою сторінкою ну тобто вони

щось змінюють сторінка змінюється і вам

потрібно все переписувати І в цей період

часу коли ідуть ці зміни активна

розробка яка е-е впливає на ui це дуже

складний період для n2n тестування і

звичайно в цей момент мати там зелений

блд ну це неможливо тому що у вас кожен

новий коміт в Master е ламає там 10

тестів там бо переписується повністю

рейworк там змінюються всі

локатори далі чому може бути червоне це

якість цих тестів ну тобто resilenc

наскільки ваші тести стійкі до змін як

це робити правильно це окрема тема до

презентації до доповіді бо це дійсно

знаєте така широка тема і працювати над

цим теж треба і ваша дисципліна якщо ви

в якийсь момент перестаєте реагувати на

червоні білди то вони і залишаться

червоними працювати з червоними

білдадами нужно потрібно постійно Ви

повинні залучи якщо у вас не витрачає

часу залучайте розробників мануальних

qaїв всіх кого завгодно ваша задача

зробити блд зеленим це не буде завжди

Можливо але ми прагнемо до е як

комунізмі

до ідеалу який ніколи не трапиться і

звичайно ці червоні білди дуже сильно

впливають на інші метрики які ми

поговоримо далі наступна метрика - це

час виконання тестів і це над

над Важливо щоб ваші тести виконувались

швидко що таке швидка ось до прикладу є

теж з трьох моїх проектів є тести які в

мене виконуються 26 секунди Це близько

30 API тестів є тести які в мене

виконуються 82 хвилини це 300 n2n тестів

повноцінних великих -ту-end тестів і є

проектик

невеличкі end-то-end тестами які там 6

хвилин чому я показав ось ці три скріна

тому що Ну ви бачите різницю тобто

різниця драматична і коли

ви розробник або ви

QA Ви дуже лінива людина як правило Ви

не хочете на ви не хочете чекати ви

хочете результат тут і зараз особливо у

девелоперів Якщо ви хочете залучати

велику кількість людей до до

використання автоматизації тестування

виконання цього прогону повинна бути

максимально маленька виконуйти тести в

10 потоків переходьте на API тести Я не

знаю робіть все можливе для того щоб

ваші тести виконувались менше хоча б

двох годин для великого повноцінного

проекту дві години - це вже

багато у мене наприклад вони півтори

години виконуються але є нюанс у мене

лише деплой проекту там займає щось до

ьох годин ну тобто Ви повинні ро Окей 3

години ми почекаємо ну почекаємо ще

півтори години на прогон тестів але якщо

у вас дуже швидко виходить деплоїти у

вас швидко виходить збирати нові білди

Ви повинні

прагнути до менше 30 хвилин це той час

коли девелопер зможе щось закомітити у

себе або локально запустити всі тести

подивитись чи він щось зламав якщо тести

будуть виконуватись більше 30 хвилин

Ніхто їх не буде буде використовувати

крім вас це дуже багато люди девелопери

вони ту Ну

вони втрачають контекст дуже швидко

ні-ніні вони втрачають контекст і

переключаються дуже швидко він завершив

задачу він на натиснув коміт і ви йому

там 100 раз скажете протестуй свої зміни

потестуй що ти там зробив він не буде

Цього робити ось попередня спікерка

казала там от про спілкування всередині

команди

Я впевнений що ви всі знаєте Ну блін Ну

чого ти цей Бах не знайшов Він же

очевидний Да йому в падло ну впадло йому

якщо це довго тестувати він цього робити

не буде У нього ще 10 ТАС в джирі він

відкриє і буде робити наступну

автоматизація може вирішити це ви можете

сказати му Слухай Коля Просто натисни

воно все зробить за тебе і тоді можливо

він це зробить лише в цьому випадку якщо

це буде півтори години він не буде Цього

робити він почне створить нову бранчу

він почне нову розробку і забуде взагалі

про те що автоматизація існує Якщо ви

хочете залучати девелоперів для до

використання вашої автоматизації вона

повинна бути у вас

супершвидка це аксіома це перевірено

спробуйте у вас Якщо ви дасте девелоперу

і скажете тут Нажми і Почекай 3

години він скаже ти що Да ти що ні якщо

він іноземець він типу скаже він типу

скаже окей окей but

I will do it I will do it ти на

наступний день до нього приходиш Ну що

ти виконав я такий Sorry Sorry myer

contct with and ask to do some Stu I

forg Sorry Man добре якщо автоматизація

на великому проекті і деякі тести є

довгими деякі короткими якщо розбивати

їх на певні більш короткі сковпи за

пріоритетами і робити можливість вибору

як наприклад тестрейлі робити можливість

того що буде проганяти так тестах і тим

самим скоротити оцей час і отримати

результат Саме так я і зробив е це Дякую

Дуже я я б забув про це говори сказати

оці всі результати що ви бачите це все

як один проект але через те що я дав

змогу запускати тести е в нас великий

проект Але багато команд я їх розбив по

командам я в мене є як рани який

запускає всі тести є рани для окремих

команд Якщо девелопер хоче перевірити

свій скоп У нього є спеціальна е

так добре вже вже о добре короче Да мені

тут каж Що завершувати діліть будь ласка

по командам для того щоб у девелопера

була можливість запустити лише ті тести

які йому необхідні Дякую

дуже ви зрозуміли

а щодо тестів і велоко кіль тягнув до

Ющенка

а блін тут велика тема блін Ромчик мене

підганяє Ладно давайте Я до важливого я

пропущу це якщо захочете поговоримо про

це пізніше я просто скажу про те що а

ваша мета зробити так щоб вашою

автоматизацією користувалася Якомога

більше людей Чим більше людей буде

користуватися тим вона ефективніша тим

більше людей буде знати І

використовувати її отримувати необхідну

інформацію і якось на неї реагувати

девело зможе

ее дізнатись чи його

е зміни вплинули на проект негативно ви

зможете швидко дізнатись чи є у вас

дефекти менеджер може побачити красивий

репорт в той момент який він захоче

аналітик може перевірити якусь

продуктову тезу ваша задача залучати

всіх кого можливо для цього мітинги е

показуйте результати будьте амбасадором

автоматизації вам треба розповідати про

те якісь історії про те як автоматизація

врятувала реліз як вона знайшла дефект

який ніколи ніхто не мог знайти будьте

амбасадором і омбутсменом ваш

автоматизацію це дуже важливо без цього

Навіть оці цифри які вам казав про

ефективність ніхто не буде сприймати

розказуйте історії показуйте реальні

результати і тоді ефективність буде

максимально зростати тому що багато

людей буде її

використовувати і на все це і впливають

ті метрики про які я казав рані якщо у

вас відсоток досить низький то люди

будуть боятись на це дивитись вони

боятись буду натискати кнопочку бо буде

ва бачити негативний результат ніхто не

хоче бачити негативний результат хочуть

натиснути і побачити що все добре тому

тести повинні бути стабільні час

виконання повинен бути мінімальний і

звичайно Пропаганда внутрішня на всіх

членів команди будьте амбасадором вашої

автоматизації і ваша кінцева мета

зробити так щоб люди їй довіряли умовно

якщо у вас провалився блд всі повинні

піти і подивитись Чому він провалився

які тести впали і чому так трапилось

якщо у вас ігнорується Ваша інформація

не вважається надійною Це погана

автоматизація це значить що ви робите

щось невірно щось відбувається

неправильно тому я порівнюю

автоматизацію з зі ЗМІ який може

надавати інформацію

регулярно вчасно Вона надійна покриває

важливі теми обов'язково те що Рома

сказав про те що може бути

автоматизовано там 80% в мене проє про

це є слайди але вони завжди зелені бо

ніфіга не перевіряють таке тоже може

бути тому покривать повинно важливі теми

це ЗМІ повинні читати і довіряти без

цього ви не можете вважати те що ви

робите ефективним Дякую за увагу

підписуйтесь на канал Ставте лайки Дякую

та тепер питаннячко за кепочку

Скажи будь ласка у тебе був

досвід страждан

дождання якби внідряти автоматизоване

тестування в команди мануальних paa

шляхом написання спеціальних кійбордів

для автотестів на твою думку наскільки

це зараз актуально наскільки це модно і

чи вважаєш ти цю таку практику

ефективною і з взагалі У мене є відео на

цю

тему називається що не так з btd

а так у мене є такий досвід проект про

який я казав який на який я прийшов був

провалений це саме був проект

застосуванням bdd і метою якого було

залучення як умога більшої кількості

людей до автоматизації

тестування з використанням Гіркін Ну в

мене питання наскільки ти вважаєш цю

практику ефективною Вона зовсім не

ефективна в мене зовсім неефективно це

не працює

а по факту у вас виходить ситуація коли

ви не автоматизуєте А ви надаєте

можливість Кому писати комусь писати

якісь речення ви додаєте можливість на

зверху Точніше так я вже заговориюсь

трохи ви надаєте просто обгортку якусь

яка повинна надавати цю можливість Але

вона по факту не дає і суть геркіна і

bdd зовсім в іншому тобто ристання

інструментів про які ми казали які

keyword keyw driven automation

створювалась вона не для цього але

через недбалість непрофесійність і

корисні

якісь наміри людей це продається як

заміна автоматизованого тестування для

мануальних qaїв і продається це як типу

Ось у вас переста ваші мануальні QA

почнуть писати автотести по факту це

звичайно не працюю Може десь колись із

кимось Якщо у вас є позитивний досвід

роботи з гєркіном мені буде цікаво

послухати вас підготуйте Я обов'язково

прийду послухати Так у вас є

у круто поговоримо потім в мене питання

Я просто в шці з

слайдів в приємному сподіваюсь реально

Клас дякую де картинки такі А це bн

браузер они на далі на далі роблять ага

ага Да

Да І він до речі апдейтнувся і вони

реально прикольні Вони реально прикольні

робилять Привіт В мене було питання

якраз чи картинка створена штучним

інтелектом

так і наскільки штучний інтелект

допомагає в автоматизації і Як ви

думаєте У мене теж є про це

відео так дуже допомагає да да Ромчик да

допомагає допомагає І я використовую

його регулярно

Дуже дякую за

презентаціюсто питання я от лайчик і

таке питання У вас є принцип тестування

парадокс пестициду як його обходити в

автоматизацію да це це гарне питання А

чи треба його

обходити я от думаю Ну згіднот

Я думаю знаю я знаю як відповісти на

ваше питання

від Ні я знаю я знаю відповідь на ваше

питання насправді це це дуже гарне

питання Дякую І це дасть мені Знаєте як

я не думав про це Але зараз я думаю що

можна його обходити за допомогою

параметризованих тестів і рандомайзерів

А ти маєш на увазі техніки та дизайн Ні

Ні він

казав я думаю рандомайзер і

параметризовані тести Я думаю що це

єдиний спосіб

обходити ну якісь бібліотеки які видають

рандомні

значення Дякую за доповідь головне

питання було декілька разів сказано про

надійний результат але як же що всі

автоматизатори пишуть як боротися з флаг

І тестами у вас все надійно як як

отримати надійні результа не було фле те

там там про флекі нічого не було сказано

тому що це все рішали все працює тести

зелені е Дивіться Ну це окрема тема

Мабуть буде як боротись з лекі тестами і

так давайте правду ну вна же ш

коларналар Ну я правду ні так я все ж

казав все це правда Це ніяких видумок і

як я борюсь те отримати ну надійні

результати якщо флакі тести є так

зробити так щоб їх не було Да

Ні ну це типу Це типу Ну питання таке Да

ось відповідь відповідь правильна

зробити щоб не було у мене на проекті

зараз заігнорено реально чотири тести із

280

toend Три з них заігнорені тому що там

баги і один з них флеки один тест У мене

флеки всі інші Ну блін обвішуюсь

вейтерами сьогодні Ромена До речі була

презентація яка була погано чути іноді

треба клікнути в циклі поки не Клік

Інколи так так так так само в мене все

так само типу є ситуа от упй по

наприклад дуже непогана функція яка

допомагає вам виконувати ітеративні

якісь дії Ну воно як асерт ну ти далі

просто не будеш рухатись якусь

ітеративну дію до моменту поки вона не

прийде не пройде інколи ну це погано але

без цього ніяк Добре

комукетки я повинен да

обрати Та я не знаю хто мене

похвалив людина давайте хлопц він

задавав питання регулярне і за вам

потрібна кепка

томуправа давайте он дівчині вона теж

похвалила мене Дякую всім Вибачте якщо

хтось не отримав кепку Дякую всім за

увагу кру Дякую дякую дякую гарна справа

Да в чатику є посилання на збір за

найбільше донат Я вже 500 грн скинув хто

більше на браковану кетку надписк клап

Львів перевернутий це супер

спеціально зроблений баг щоби тестувати

зна тому скидайте

гроші я щось короче розпиздився хлопці

щоб сюди приїхати Я витратив 7 000 грн

короче будь ласка скида Ні Ніні я споча

на дорогу на готелі і на усе це А в мене

щей дочка руку витягнула тому якщо ми не

зберемо

на ці грмані

ночники це буде Я дуже розстроюсь

скидайте будь ласка Давайте допоможемо

хлопцям з Азову отримати Night Vision

glasses так так будь ласка

скидайте все насправді Сарян заразрева

коробка і коробка із-за того що була

тривога тому 5 хвилин на перекур і нова

доповідь а потім просто обвішайся

кулуарами потім

Кумпель А я знаю що таке Кумпель Ну

короче потім паль чи що Та 5 хвилин пере

А це Кумпель це про про ресторан Так а я

думав Кумпель це ми общ ванну це Чан Чан

Ну вони кумпелями не то саме слово почти

Да да да Так це ж кумпелі так

такке та файно тільки на початку так

сказати затягнув але розумію чому я на

птій хвилині тільки зрозуміла що

А ти в тебе фотка є Ні давай спільну

фотку ще давай давай давай тільки на

п'ятій хвилині зрозуміло що ми їли разом

піцу Ти

серйозно блін оцеже

га Дуже дякую Дуже дякую Дуже дякую вам

А ти ж ну не їдеш ще правда

сгодйде ні та дружина пише що мала А я

до речі знаєш куди їх відправ куди в ні

в Музей Науки там в мене мала