Деякі речі треба нагадувати періодично і сьогодні хочу нагадати про мою ініціативу "Ask Me Anything"

Це безкоштовні 30хвилинні сесії зі мною, де можна питати будь які запитання і не обов'язково про айті. Наприклад, обговорити улюблені книги, хоббі, або фільми 😎

Хто вже був — ви також можете ще раз долучитись 🙃
📞 Забронювати зустріч

Є хороша можливість потрапити на безоплатне менторство!

Last call, що вже на цьому тижні відбудеться Інтенсив - "Естімація задач по тестуванню"

Окрім технік та підходів будемо розглядати інструменти для візуалізації та планування. Ну і ще поговоримо про те, як доносити свою оцінку до інших.

Саме донести необхідну оцінку до стейкхолдерів буде ключовим челенджем, ніж порахувати години :)

Деталі тут 👀

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

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

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

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

#думки

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

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

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

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

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

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

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

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

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

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

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

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

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