Proving E2E tests are a Scam

#testing

Цікава стаття, де пояснюється, чому контрактні тести - це круто, а Е2Е тести - ні.
Стаття у блозі розробника інструменту для контрактного тестування, тому й недивно, що контрактні тести хвалять.

А ви як думаєте? Що краще?

Автоматизація десктопу (або знову той JS!)

#testing #tools

Веб та АПІ автоматизують усі. А що там по десктоп автоматизації?
Сьогодні в одному подкасті почув про бібліотеку на JS - nut.js, що дозволяє управляти десктопом.
- Інтегрується з Jest.
- Є плагін з розпізнаванням картинок.

Думаю, досить цікавий проект. Але ЗНОВУ на JS!)

Посібник по змінам для рядових веслярів

#leadership

“Somebody said (and I think it's on Wiki somewhere), ‘People hate change.’ The first reaction is, ‘Yeah, well, everyone knows that!’ To which the proper reply is, ‘No, you don't understand, people really really hate change.’ –Anonymous

Змінюватись тяжко. А змінювати людей, команду або компанію навколо - ще важче.
Єдиний фактор, який може полегшити впровадження змін - це бути менеджером. Мати команду.

А що робити, коли ти звичайний інженер та прагнеш змін?

Я знайшов коротку, але цікаву роботу на цю тему: “Change Your Organization (For Peons)”.
У сьогоднішньому нотатку я коротко поділюся основними ідеями звідти. (Але звісно краще почитати оригінал).

Мені в свій час ця стаття дуже б допомогла. Та навіть зараз допомагає.

Що таке зміни: зміна процессів, підходів до розробки та тестування, нові інструменти, тощо. Можуть бути, як на рівні окремої команди, так і на рівні департаменту чи цілої компанії.

Тактики впровадження змін
1. Запитайте себе - нащо ці зміни? Ви почули про новий підхід чи інструмент на конференції чи мітапі та подумали "а прикольно б було це застосувати в нас?” Що буде, як зміна у процесі не буде впроваджена або запрацює лише наполовину? Чи ви готові бути за це відповідальні?
2. Підготуйте шляхи для відступу. В разі, коли зміни не запрацюють або запрацюють не повністю.
3. Процес змін - дуже повільний, тому майте родину та друзів, що підтримають вас на цьому шляху.
4. Знайдіть невеликі задачі кожного дня, які можна виконати та бачити прогрес своїми очами - прямо зараз.
5. Повага - це ваша валюта. Чим більше вас поважають, тим більше довіри до ваших слів та пропозицій.
6. Поважайте інших та їх думки та пропозиції. Навіть, якщо вони суперечать вашим.
7. Будьте найкращим у тих задачах, що виконуєте. Якими б простими чи нудними вони не були.
8. Не намагайтеся змінити усіх та одразу. Знайдіть своє коло впливу та працюйте з ним.
9. Знайдіть союзників, що розділяють ваші погляди. Допомагайте їм розповсюджувати ваші ідеї.
10. Не критикуйте усе й одразу (навіть якщо дуже хочеться). Уважно досліджуйте, чому процеси чи люди працюють саме так, як ви бачите.
11. Знайдіть розрив між бажанням та реальністю. Пам’ятайте, що змінити людей можна тільки, якщо вони цього хочуть.
12. Практикуйте самі те, що впроваджуєте - будьте прикладом.
13. Приділіть увагу до термінів, якими оперуєте. Одні й ті ж слова, можуть мати різні значення для різних людей.
14. Завжди знайте відповідь на питання - чому? Чому процеси побудовані саме таким чином? Чому люди користуються саме цими інструментами?

Цікава візуалізація моделі розвитку інженерів та лідів.

Thoughtworks Technology Radar V.28 - очима тест інженера

#engineering

Тут не так давно вийшов черговий випуск звіту про технології від компанії Thoughtworks.
Я його вже прочитав та виписав для вас найголовніше з точки зору тестування, якості та автоматизації.

Як менеджмент дивиться на тест репорти після regression тестування. (Все ж зрозуміло, чи не так?)

Приклад про те, чи роблять тест інженери той самий defect prevention

#testing

Читав я тут статтю PAUL SEAMAN під назвою "TESTING AND PREVENTION – THE ILLUSION". У ній він розмірковує щодо того, чи справді тест інженери можуть запобігти появленню багів - чи ні.

Наведу звідти цікаву аналогію:
"Testing is like this. You’re a passenger in a car, driving down a road that has a variety of speed limit signs. The car has a speedometer which you can see and you glance at it occasionally to check the car’s speed. Does the speedometer reading prevent the driver from driving over the speed limit (which is an issue)? It doesn’t. The speedometer provides you with a signal which you can either ignore or act upon. You might say to the driver “gee the speed limits change a lot around here, we just moved from an 80 km/h zone and into a 60 km/h zone”. The driver can choose to listen to you or ignore you. They might increase speed, decrease speed or stay at the same speed. Changing speed requires a direct input on the accelerator and it is the sole responsibility of the driver to make that adjustment. As a tester you have a focus on the speedometer (and other conditions that are part of the context such as the weather, the road conditions, etc.).

You are providing feedback, perhaps even encouraging slowing the car to a more appropriate speed. You are an observer of what is happening, not the driver who has control and can make changes based on your feedback. You are providing feedback that can be acted upon, but you’re not the person making the adjustments."

А ви як думаєте - чи справді тестувальник працює саме так, як наведено у прикладі, чи ні?
А як же той quality assurance, continuous testing, shift left and right?

Читаємо: “Developer Testing: Building Quality into Software”

#books #testing

Минулого місяця я прочитав книгу - Developer Testing: Building Quality into Software за авторством Alexander Tarlinder.

Ось мої п’ять причин, чому її варто прочитати:
1. Хороший огляд того, які активності з тестування робить розробник.
2. Дається базовий словник тестувальника: різні види та типи тестів, а також техніки тест дизайну. Окремо даються навіть чеклісти того, що зазвичай потрібно перевіряти в коді. (Не ISTQB Syllabus, але непогано)
3. Якщо ви хочете нарешті розібратися з тим, що ж таке testability - в книзі про це виділено аж декілька розділів.
4. Розібрані підходи до модульного тестування та різні види моків, стабів та усього такого.
5. Багато прикладів тестів на різних мовах програмування.

Але книжка не без мінусів:
- Деякі концепції, як наприклад інтеграційне тестування - подаються дуже розпливчасто.
- Хоча більшість прикладів суто практичні, зустрічаються й філософські роздуми без конкретних порад.
- В техніках тест дизайну та рівнях тестування ви не знайдете чогось революційно нового, але для новачка (або розробника) це буде те, що треба

Загалом ця книга, разом із “Effective Software Testing” - поки що є найкращими книгами з практичного тестування. Обидві - можна (та треба!) дати почитати вашим розробникам. Причому, вона не так тяжко читається, як наприклад xUnit Test Patterns.

Ця книга - саме те, чого мені не вистачало на старті кар’єри.

BiDirectional Contract Testing

#testing #contracttesting #java

Вкрай практична стаття про контрактне тестування за допомогою Pactflow з прикладами на Java.
Рекомендую для читання.

Записи доповідей з Testing Stage 2023

#testing #video

Для тих, хто полюбляє дивитися доповіді - маю записи з конференції Testing Stage, що відбулася минулого місяця.

- Дивитись Track A
- Дивитись Track B

Боремося с синдромом самозванця та закриваємо прогалини в знаннях

#engineering

Для тих хто відчуває на собі синдром самозванця - Dr. Milan Milanović написав чудовий короткий гайд про те, як боротися з цим синдромом.

А для тих, хто дійсно хоче вчитися (особливо фундаментальним речам) - є така штука як Open Source Society University. Люди зібралися та створили цілу програму курсів для тих, хто хоче отримати знання Computer Science університетського рівня. Курси частково безплатні, частково - на Coursera.
Там стільки різного та цікавого, що якщо пройти усі успішно (та створити проeкти в кінці) - то навіть на сучасному ринку праці без роботи не залишишся.

Про жаргон та зірковість

#thinking

It’s Wednesday, dudes!
Цього тижня я натрапив на цікаву статтю від Gergely Orosz - “Is Critical Thinking the Most Important Skill for Software Engineers?”.
В ній автор розповідає про дві важливі речі: жаргонізми та довіру "зіркам".

Жаргонізми
Це - будь-які незрозумілі нам терміни - як бізнесові, так і технічні. Проблеми з ними у тому, що коли ми їх чуємо та не розуміємо - ми з якихось причин боїмося запитати. В більшості випадків - причина страху в тому, що усі подумають, що ви мало знаєте та й взагалі дуже сумнівний спеціаліст. А питати треба. По-перше - ви дізнаєтесь нове та розберетеся в незрозумілому. По-друге - дасте шанс людині пояснити ці терміни простими словами. Адже якщо ти не можеш пояснити термін, який застосовуєш - ти не до кінця розібрався в ньому.

Довіра “зіркам”
Коли ми починаємо кар’єру (та й надалі) ми стикаємося з лідерами думок: в Твіттері, телеграм каналах, на конференціях. Ці люди, зазвичай, дуже впевнено стверджують різні речі. А через їх досвід та “медійність” - ми схильні таким людям довіряти.
Але варто пам’ятати, що ці “зірки” можуть помилятися або грунтуватись на суто власному досвіді (а потім натягувати цей досвід на будь-які ситуації).

В обох випадках, треба критично ставитися до інформації. Розбиратися та перевіряти. Навіть, якщо це говорять люди з великим досвідом.

Для тих, хто хоче дізнатися більше - ласкаво прошу прочитати оригінал.

💡Українські телеграм канали з тестування.

Так як лінка трохи міняється - додам окремий пост.
Збірка активних українських телеграм каналів з тестування. Приєднатись - тут.

P.S. краще відкривати з мобільного

Що це за канал та чи варто його читати?

Днями на канал підписалося багато нових людей. Тому я хотів би ще раз розповісти про те, хто я та чому варто читати цій канал.

Про автора
Мене звати Олександр Романов. В IT я працюю з 2011 року. Декілька місяців був тестувальником, а потім більшу частину своєї кар’єри займався автоматизацією тестування як у продуктових компаніях так і в аутсорсі. Був автоматизатором, СДЕТом та лідом СДЕТів. На даний момент я працюю в компанії IOHK. Ми розробляємо блокчейн Cardano та різні продукти з ним пов’язані.

Основний мій технологічний стек - це Java. Але довелося також працювати із C# та Scala. Цього року перейшов на новий проект та пишу на Python. У вільний час досліджую питання тестування та безпеки смарт-контрактів та блокчейну.

Крім каналу, я веду блог, роблю доповіді та є в Twitter. Також пишу дайджести на DOU та приймаю участь у подкасті “Не баг, а фіча”. А ще - я займаюся менторингом з автоматизації.

Про канал
У цьому каналі я збираю інформацію про технічну сторону тестування та інженерії - тобто про великі складні розподілені системи, як вони працюють та як підходити до їх перевірки.

Основний фокус саме на практичних знаннях та нових підходах. Що саме головне - я намагаюся пояснити навіть найскладніші речі простими словами.

Точніше, в каналі ви знайдете:
- Історії з власного досвіду
- Практичні статті та доповіді з автоматизації
- Рецензії на книжки з тестування та розробки
- Короткі огляди на різні дослідницькі роботи з тестування та якості загалом
- Підбірки цікавих постів та інструментів
- Відгуки на конференції та курси

І ще одне! В каналі є можливість шукати матеріали по тегам: #testing #digest #books #engineering

Ласкаво прошу у канал. До зустрічі в коментарях. Давайте разом робити тестування більш технічним та цікавим.

Які є інструменти для автоматизації в ...

#testing #python #java #tools

Доброго ранку.
Коли ми тільки знайомимось з автоматизацією, або ж переходимо з однієї мови програмування в іншу - постає багато питань.
- Яку бібліотеку для ассертів взяти в мові Х?
- Які є альтернативи бібліотеці репортів у мові У?
- Чи є BDD інструмент для мови …?
- Та інше …

Авжеж можна запитати в каналі чи в чатах тест інженерів. Але мені допомагають списки типу awesome-X. У них хтось дуже добрий вже зібрав купу інструментів та виклав у публічний доступ.

Які списки використовую я сам:
- awesome-test-automation від atinfo. Є для багатьох мов програмування - у тому числі - Java, Python, JS.
- awesome-python-testing - лист інструментів для Python.
- java-testing-toolbox - набір прикладів з книги “30 Testing Tools & Libraries Every Java Developer Must Know”. (Знайшов цього тижня, але виглядає непогано для початківців).

Для інших технологій та мов програмування, можна пошукати списки awesome списки на GitHub.

Ще раз про оцінювання задач

#testing #process

Минулого тижня я прочитав дві вкрай практичні статті про те, як робити естімейти.
- Rules of Thumb for Software Development Estimations
- My Software Estimation Technique

Далі я наводжу мої короткі нотатки (авжеж краще ознайомитись із оригіналом!)

Про оцінки
- Не існує двох повністю ідентичних проєктів
- Невизначеність буде завжди
- Комунікації між командою та бізнесом впливають на оцінки

Як НЕ треба робити естімейти
- Намагатись “вгадати” чи взяти оцінку з довідника “стеля”
- Користуватись одним та тим самим підходом для будь-яких задач
- “Забивати” на зовнішні фактори
- Відмовлятись переглядати оцінки з часом

Яку техніку естімації пропонує Jacob Kaplan-Moss:
1. Розбийте роботу на невеликі менш складні підзадачі. В залежності від складності це можуть бути small, medium, large та extra-large задачі.
2. Оцініть невизначеність. Розробіть свою виміру: чим більше невизначеність, тим більший множник. Для низького рівня множник може бути 1.1, для найбільшого - 5.0.
3. Виконайте розрахунки. Для кожної задачі розрахуйте очікуваний час виконання, а також час з урахуванням невизначеності.
4. Уточніть дані, якщо є потреба. Якщо у вас багато extra-large задач, спробуйте або розбити їх, або додати окремі задачі на research - щоб зменшити ризики та невизначеність.
5. Відстежуйте точність, щоб покращуватись із часом. Порівнюйте, наскільки ваші оцінки відрізняються від реального часу виконання задачі - та робіть відповідні зміни у своїх підходах.

Які ще техніки оцінки задач існують
- Program Evaluation and Review Technique
- Evidence-based scheduling
- Fruit-salad scrum

Як допомогти менеджеру та команді робити оцінки краще
- Більше комунікуйте
- Користуйтеся своїм досвідом
- Не забувайте про ризики
- Заохочуйте культуру, де задавати питання та уточнення - це нормально

P.S. Наче нічого кардинально нового, але ...
P.P.S. Думаю, Артем та Артур можуть доповнити замітки щодо оцінок ... 😉

Секрети тестування від Matt Heusser

#testing #video

Matt Heusser щотижня викладає короткі відео, в яких розповідає про тестування та ділиться секретами із власного досвіду.

Вже вийшло три випуски: 1, 2, 3

Про що там?
- Який найбільший секрет тестування
- Чому ми прокрастинуємо, коли потрібно тестувати та як зробити тестування веселим
- Скільки часу ми дійсно витрачаємо на тестування

Test Engineering Notes: Volume 2

#testing #engineering #digest

Всім привіт. Черговий дайджест цікавих статей вже тут.

З найкращого, у цій підбірці ви знайдете:
- чи можна копіпастити код у тестах та чи працює дослідницьке тестування в Agile
- тренди автоматизації в 2023 та підходи до тестування навантаження розподілених систем
- чи потрібно переписувати усе за "папєрєдніками"?
- як працюють Slack, ChatGPT, алгоритми рекомендацій та пошуку аномалій
- чи моноліт краще за мікросервіси та чи можна вже зараз створювати додатки та тести зі специфікації з ChatGPT

а також купу інструментів, включно з новою тулою для тестування мобілок.