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

Згодом ми доскролили до першого повідомлення в цьому каналі й помітили два цікавих моменти.
Канал було створено 19 лютого 2019 року, а перший допис з'явився 25 лютого 2020 року.

На той час у мене вже було 8 років досвіду. Радію, що протягом усього цього часу продовжую писати та ділитися своїми думками.

Висновків не буде.

#думки

Сьогодні зустрічаємось тут.
Є час залетіти!

Запис буде, презентація буде 😎💪

*🥷* Про приховані задачі (невидимі задачі)

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

Такі задачі виконують важливу функцію і супроводжують основний процес, але їхній вклад часто залишається поза увагою під час створення WBS (work breakdown structure). Пропуск цих задач під час планування може спотворити реальну картину та призвести до відхилення від оцінки, навіть якщо планувальник був переконаний у її точності.

Ось кілька прикладів прихованих задач, які можуть не враховуватись:
- Створення та підготовка тестових даних – це важлива частина підготовки до тестування, яка іноді залишається поза увагою.
- Дослідження нових технологій чи функціональностей – зокрема, коли проект вводить нові технології або функції, з якими команда ще не працювала.
- Створення дефектів та їх ретест після виправлення – завдання, які не завжди враховуються, але потребують чимало часу. Часто думаємо, що протестуємо без багів :)
- Актуалізація тестової документації – оновлення чеклістів, специфікацій та тест-кейсів при зміні вимог.
- Нефункціональне тестування – перформанс, безпека, UX, відповідність стандартам та гайдлайнам тощо, які іноді сприймаються як додаткові.
- Дослідницьке тестування – часто це просто хаотичне тестування в рендомний момент часу.
- Проектні комунікації – координація з розробниками, аналітиками, DevOps, яка займає час, але не враховується.

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

На моєму інтенсиві ми детально розглядаємо питання WBS та прихованих задач, щоб навчитися точніше оцінювати об'єм необхідної роботи. Приєднуйтесь, щоб дізнатися більше!

А які приховані задачі ви спостерігаєте у своїх проектах?

Хочу підкреслити деякі моменти

1. Автоматизованого тестування не існує.
2. Ручне (мануальне) тестування навіяно знеціненням професії та спроби відокремити певну частину спеціалістів в окрему касту
3. Тестування - це складний (комплексний) процес дослідження, вивчення, відкриття продукту, щоб отримати інформацію про нього та зменшити ризик виникнення проблем у кінцевого користувача.

Дякую за увагу ?

#суворийqa #думки?Суворий блог? Сувора QA Спільнота

Буквально через 7 хвилин давайте зустрінемось тут з вами!
Думаю буде корисно! ?

? "Follow the flow"
— саме так би я розпочав свій шлях у новій компанії в якості керівника. Це важлива порада для кожного, хто щойно почав працювати у новому колективі.

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

Зміни, впроваджені без адаптаційного періоду, можуть дестабілізувати систему. Нова людина, яка починає ініціювати зміни протягом перших 2-3 тижнів, створює атмосферу нестабільності та непередбачуваності. Колеги можуть не знати, чого від вас очікувати, що ускладнює спільну роботу.

Крім того, такі зміни можуть негативно вплинути на процеси, які будувалися роками і стали стабільними та зрозумілими для всіх учасників (окрім вас, звичайно?).

Щоб уникнути таких ситуацій та як не потрапити в пастку ініціатив, які можуть нашкодити вашій кар'єрі та команді долучайся до навчання ?

P.S.
Забавний факт, що цей вислів прийшов до мене вчора підчас AMA сесії ?

#суворийqa?Суворий блог? Сувора QA Спільнота

? Testμ Conference.Decode the future of testing

? Дата: 21-23 серпня 2024
? Вартість: безкоштовно
?Місце проведення: онлайн

? Опиc:
Testμ (TestMu) це онлайн-конференція, яка ставить вас у центрі уваги. Це від спільното, для спільноти! Будь то сесії про тенденції, практичні навчальні заняття чи розмови про формування правильної культури, ми тримаємо вас у центрі всього цього.

?Посилання за деталями та реєстрацією
https://www.lambdatest.com/testmuconf-2024/

Обов'язково до перегляду та прослуховування ?

Новий буде ?
Інформація завтра ☺️

?‍♂️Якщо ви починаєте свій шлях в IT, і проходите або пройшли курси. В якийсь момент вам буде здаватись, що ви готові рухатись далі і вам захочется почати вчити "автоматизацію".

Але хочу нагадати наступне:- Якщо ви не знаєте основ в тестуванні - автоматизація не допоможе.
- Якщо ви не знаєте основ технік тест-дизайну - автоматизація не допоможе.
- Якщо ви не знаєте які є HTTP методи та як їх використовувати - автоматизація не допоможе.
- Якщо ви не знаєте які є різновиди API - автоматизація не допоможе.
- Якщо ви не знаєте базового інструментарію (Dev.Tools, Postman і ко, JIRA і ко) - автоматизація не допоможе.
- Якщо ви не вмієте доносити свої думки до інших - автоматизація не допоможе.

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

Це сугубо власні суб'єктивні думки, з якими ви можете не погоджуватись і це ок ?

#думки