[Test Engineering Weekly] Про віртуальні середовища Python, піраміди в тестування та гайд по вивченню на Quality Engineer

#testing #engineering #weekly #digest

Черговий дайджест цікавих статей про тестування, розробку та інші технічні штуки.

Чому варто читати цей дайджест:
- побачите великий гайд по розвитку в тест інженера та автоматизатора
- розберетеся, як працюють віртуальні середовища в Python
- дізнаєтеся як застосовувати скінчення автомати в тестуванні?
- побачите приклади створення рішень з автоматизації за допомогою ChatGPT, а також Java + Playwright
- згадаєте як копіювати об'єкти в Java
- дізнаєтеся чому Python то не Java
- багато іншого...

Інструменти для тест інженера

#testing #tools

Для тих, кому не вистачає інструментів для тестування або ж тим, хто завжди у пошуках чогось новенького - маю корисний ресурс.
На ньому зібрано доволі багато різних тулів, більшість з яких безкоштовні.
Але не даю гарантії, що усі вони корисні.
Обирайте та досліджуйте самі.
Усім гарного дня!

Фантастичні SDET'и та де їх шукати

#testing

Якось в Linkedin мене попросили розповісти трохи більше про те, хто ж такі SDET та як ними стати.
Тому у сьогоднішньому дописі я розповім усе, що мені відомо про SDET'ів.

Якщо маєте питання чи доповнення - чекаю у коментарях.

Attention!
Додатково, цікаві статті, відео та дослідницькі роботи з коментарями буду постити в профілі цього каналу у Twitter
Підписуйтесь.

SimulatedRides: How Lyft uses load testing to ensure reliable service during peak events

#testing #load

Сьогодні пропоную почитати цікаву, а що саме головне - практичну статтю про те, як в Lyft підходили до тестування навантаження, чому вирішили створити своє рішення та як воно технічно працює у продакшені.

Ось такі статті дуже важливі. Коли описується проблематика та конкретний кейс вирішення.

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

Тут Артем зробив свій авторський курс для QA Lead'ів та тих, хто ними хоче стати.
Записуйтесь, думаю буде корисно.

Javanoscript Best Practices

#testing #js

Знайшов тут класний репозиторій, де зібрані кращі практики та поради для тих, хто пише тести на JS.
Якби я писав би на JS, мені було б корисним.

Cypress Framework Boilerplate

#automation #js

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

На мій погляд найголовніше, чого не вистачає, коли вже є базові знання мови - це побачити приклад реального рішення з автоматизації.
Тому сьогодні я хочу поділитися прикладом на JS + Cypress від Mohammad Monfared.

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

API Testing from Entry Level to PhD - Jason Ioannides

#testing #api

Доброго дня!

Сьогодні до Вашої уваги пропоную цікаву доповідь про те, що таке API, які вони бувають та що відбувається "під капотом".

Відео допоможе трохи глибше зануритися у світ API. (Але все ще без хардкору).

Test Engineering Notes: Volume 1

#testing #engineering #digest

Всім привіт!

Сьогодні п'ятниця - саме час для того, щоб завершити робочі справи та зробити реліз о шостій вечора почитати цікаві статті.

Цього разу я вирішив трохи відійти від weekly дайджестів. Бо то занадто багато (та й дайджести виходили не кожного тижня). До того ж, не у всіх є час читати кожного тижня.

Тому надалі підбірки будуть виходити нерегулярно, але більш насиченими та різноплановими. Сподіваюсь, вам буде цікаво!

Гарного читання!

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?