Оптиміст бачить проєкт наполовину готовим...
Привіт друзі! Нещодавно ми з колегами робили оцінку автоматизації тестування на одному проєкті. Ми вже згадували про це раніше - саме для цієї задачі досліджували playwright.
Не буду скромним - мені моя власна оцінка дуже подобається, зробив все по науці:
✅ зробив декомпозицію на дрібні задачі
✅ врахував ризики
✅ поставив питання та отримав відповіді (❗️) на всі свої питання для кращого розуміння проєкту
✅ зробив триточкову оцінку для обрахунку імовірності виконати роботу вчасно (ми колись писали про неї, може хочете ще один пост?)
Після моєї оцінки ми вирішили попросити колег з інших департаментів теж зробити поверхневу оцінку, щоб зрозуміти, наскільки наші думки сходяться (оскільки менеджери завжди радять множити на 2 чи навіть на 3, якщо бюджет дозволяє 💰). І виявився дуже цікавий факт:
Я, зі свого досвіду, завжди закладаю на автоматизацію готового тест кейсу мінімум 1 годину. Враховуючи складність, маппінги, ризики, дебаг. Бо в сьюті навіть з 10 тестів на 9 можна витратити сумарно годину, а з останнім будеш копирсатись 9! А потім взагалі вказати, що тест швидше руками проходити, ніж написати стабільний автотест.
А один з моїх колег вказав, що заклав би на автоматизацію самих тестів не більше як пів години на один тест (а ще мене називають оптимістом😁).
Тепер хочу почути думку широкого загалу - який мінімум часу ви зазвичай закладаєте/закладали б на автоматизацію одного тест кейсу?
Привіт друзі! Нещодавно ми з колегами робили оцінку автоматизації тестування на одному проєкті. Ми вже згадували про це раніше - саме для цієї задачі досліджували playwright.
Не буду скромним - мені моя власна оцінка дуже подобається, зробив все по науці:
✅ зробив декомпозицію на дрібні задачі
✅ врахував ризики
✅ поставив питання та отримав відповіді (❗️) на всі свої питання для кращого розуміння проєкту
✅ зробив триточкову оцінку для обрахунку імовірності виконати роботу вчасно (ми колись писали про неї, може хочете ще один пост?)
Після моєї оцінки ми вирішили попросити колег з інших департаментів теж зробити поверхневу оцінку, щоб зрозуміти, наскільки наші думки сходяться (оскільки менеджери завжди радять множити на 2 чи навіть на 3, якщо бюджет дозволяє 💰). І виявився дуже цікавий факт:
Я, зі свого досвіду, завжди закладаю на автоматизацію готового тест кейсу мінімум 1 годину. Враховуючи складність, маппінги, ризики, дебаг. Бо в сьюті навіть з 10 тестів на 9 можна витратити сумарно годину, а з останнім будеш копирсатись 9! А потім взагалі вказати, що тест швидше руками проходити, ніж написати стабільний автотест.
А один з моїх колег вказав, що заклав би на автоматизацію самих тестів не більше як пів години на один тест (а ще мене називають оптимістом😁).
Тепер хочу почути думку широкого загалу - який мінімум часу ви зазвичай закладаєте/закладали б на автоматизацію одного тест кейсу?
На 1 автотест я зазвичай планую
Anonymous Poll
7%
10 хвилин 💪 (nightmare)
10%
30 хвилин 🏆 (hard)
28%
1 година 😁 (medium)
19%
2 години 🤓 (easy)
36%
2+ годин 🤔(play safe)
Як оцінити проєкт з автотестування?
#testplan
Привіт друзі! Вчора написав пост про оцінку часу на автоматизацію одного тест кейсу і отримав дуже слушний комент - а що саме включено в цю оцінку? Чи є в ній час "на подумати"? Чи на інші активності? Пишучи відповідь, я зрозумів, що в розгорнутому вигляді вона цілком заслуговує окремого посту. Коротка відповідь - вчора я робив опитування саме про час на імплементацію одного тесту. Які ж інші типові активності я додаю в оцінку? Для зручності, я розділив чек ліст того, що треба оцінити, на фази:
1️⃣ Аналіз проєкту
✅ аналіз додатку, що тестується
✅ аналіз тест кейсів
✅ поверхневий аналіз вимог та дизайну
✅ аналіз середовища, де будуть виконуватись тести
2️⃣ Підготовка
✅ вибір тула для автоматизації (tool evaluation)
✅ підготовка PoC (proof of concept) та структури проєкту для автотестів
✅ налаштування CI для автотестів
3️⃣ Імплементація тестів
✅ час на автоматизацію одного тесту (про нього було опитування)
✅ час на дебаг тестів
4️⃣ Підтримка
✅ аналіз звітів з виконання тестів
✅ виправлення багів в коді тестів
✅ оптимізація тестів
Мітинги і перерви на каву зазвичай в цю оцінку не входять.
А от ризики, що можуть відноситись до окремих активностей, я зазвичай включаю. наприклад - в аналіз тест кейсів можна закласти додаткові години, якщо є ризик - тести в поганому стані і потребують адаптації для автоматизації.
Далі, зазвичай, можна вирахувати час на автоматизацію проєкту.
В нас перелічено 11 активностей + безпосередньо реалізація тест кейсів, виділимо на кожну по 20 годин (тільки для прикладу). І давайте припустимо, шо є 100 тестів для автоматизації, на кожний по 1 годині. В сумі маємо 320 людино годин.
Тепер рахуємо, за який час цей проєкт можна виконати (з урахування часу на мітинги і каву - 6 год/день) 1 тестер👷♀️: 320 / 6 = 54 дні ~ 2,5 місяці
Але це дуже груба оцінка. Спробую на цьому тижні зробити пост про триточкову на цьому ж прикладі.
Як вам мій чек ліст? Щоб ви додали?
#testplan
Привіт друзі! Вчора написав пост про оцінку часу на автоматизацію одного тест кейсу і отримав дуже слушний комент - а що саме включено в цю оцінку? Чи є в ній час "на подумати"? Чи на інші активності? Пишучи відповідь, я зрозумів, що в розгорнутому вигляді вона цілком заслуговує окремого посту. Коротка відповідь - вчора я робив опитування саме про час на імплементацію одного тесту. Які ж інші типові активності я додаю в оцінку? Для зручності, я розділив чек ліст того, що треба оцінити, на фази:
1️⃣ Аналіз проєкту
✅ аналіз додатку, що тестується
✅ аналіз тест кейсів
✅ поверхневий аналіз вимог та дизайну
✅ аналіз середовища, де будуть виконуватись тести
2️⃣ Підготовка
✅ вибір тула для автоматизації (tool evaluation)
✅ підготовка PoC (proof of concept) та структури проєкту для автотестів
✅ налаштування CI для автотестів
3️⃣ Імплементація тестів
✅ час на автоматизацію одного тесту (про нього було опитування)
✅ час на дебаг тестів
4️⃣ Підтримка
✅ аналіз звітів з виконання тестів
✅ виправлення багів в коді тестів
✅ оптимізація тестів
Мітинги і перерви на каву зазвичай в цю оцінку не входять.
А от ризики, що можуть відноситись до окремих активностей, я зазвичай включаю. наприклад - в аналіз тест кейсів можна закласти додаткові години, якщо є ризик - тести в поганому стані і потребують адаптації для автоматизації.
Далі, зазвичай, можна вирахувати час на автоматизацію проєкту.
В нас перелічено 11 активностей + безпосередньо реалізація тест кейсів, виділимо на кожну по 20 годин (тільки для прикладу). І давайте припустимо, шо є 100 тестів для автоматизації, на кожний по 1 годині. В сумі маємо 320 людино годин.
Тепер рахуємо, за який час цей проєкт можна виконати (з урахування часу на мітинги і каву - 6 год/день) 1 тестер👷♀️: 320 / 6 = 54 дні ~ 2,5 місяці
Але це дуже груба оцінка. Спробую на цьому тижні зробити пост про триточкову на цьому ж прикладі.
Як вам мій чек ліст? Щоб ви додали?
Excel - filter by color
#offtopic #truestory
Життя вже ніколи не буде таким як раніше: вчора дізнався, що в Excel можна фільтрувати рядки не тільки за значенням в певному стовпчику, а й за кольором 🤯
Тепер обирати зафейлені рядки в чеклістах буде не тільки зручно а й естетично довершено :)
ПС в гуглдоках працює так само.
Це тільки я слоупок, чи ви також не знали?
#offtopic #truestory
Життя вже ніколи не буде таким як раніше: вчора дізнався, що в Excel можна фільтрувати рядки не тільки за значенням в певному стовпчику, а й за кольором 🤯
Тепер обирати зафейлені рядки в чеклістах буде не тільки зручно а й естетично довершено :)
ПС в гуглдоках працює так само.
Це тільки я слоупок, чи ви також не знали?
Вимоги. Low Tech, High Life.
#truestory #requirements
ℹ️ Disclaimer: те що написано далі не є найсучаснішим, й найоптимальнішим способом працювати зі змінами в документах, але це дуже просто й це працює!
Якщо спростити: є маленькі проекти, а є великі.
На маленьких не часто виникає потреба мати всі вимоги до продукту в одному документі, зазвичай достатньо сумлінно вести беклог з користувацькими сценаріями.
А от на великих проектах кількість вимог в беклозі достатньо швидко, вже за декілька десятків ітерацій, може перебільшити той обсяг, який ще дозволяє тримати загальну картину продукту в голові. Тому дуже корисною виявляється наявність детальних вимог до продукту, або до кожної з його великих фіч, оформлених у вигляді документу. Як правило такий документ називається SRS - Software Requirements Specification. В мене на проекті він називається FSD - Functional Specification Document. Й ці документи доводиться оновлювати кожну ітерацію.
Тестувальникам доволі часто доводиться не тільки читати вимоги, а й писати їх. Як от мені довелось оновлювати документи з вимогами на великому проекті декілька ітерацій поспіль.
Питання: як оновити документ з вимогами так, щоб було зрозуміло які саме зміни були впроваджені в певній ітерації?
Ми це вирішили дуже просто, але й дуже дієво в той самий час.
Наприклад в ітерації №40 було декілька змін в функціональності Login.
1️⃣ Створюємо папочку з назвою "Release 40"
2️⃣ З папочки "Release 39" копіюємо документ "Login 39" в новостворену папочку "Release 40"
3️⃣ Перейменовуємо "Login 39 "в "Login 40"
4️⃣ Відкриваємо Login 40, виділяємо весь текст та скидаємо колір заливки тексту
5️⃣ Додаємо наші зміни
6️⃣❗️Й найголовніше - виділяємо наші зміни заливкою жовтим кольором
Й цей простий трюк забезпечує легкість розуміння всіма членами команди того, які саме зміни відбулися в кожній конкретній ітерації.
А чи доводиться вам займатись оновленням вимог на проекті?
#truestory #requirements
ℹ️ Disclaimer: те що написано далі не є найсучаснішим, й найоптимальнішим способом працювати зі змінами в документах, але це дуже просто й це працює!
Якщо спростити: є маленькі проекти, а є великі.
На маленьких не часто виникає потреба мати всі вимоги до продукту в одному документі, зазвичай достатньо сумлінно вести беклог з користувацькими сценаріями.
А от на великих проектах кількість вимог в беклозі достатньо швидко, вже за декілька десятків ітерацій, може перебільшити той обсяг, який ще дозволяє тримати загальну картину продукту в голові. Тому дуже корисною виявляється наявність детальних вимог до продукту, або до кожної з його великих фіч, оформлених у вигляді документу. Як правило такий документ називається SRS - Software Requirements Specification. В мене на проекті він називається FSD - Functional Specification Document. Й ці документи доводиться оновлювати кожну ітерацію.
Тестувальникам доволі часто доводиться не тільки читати вимоги, а й писати їх. Як от мені довелось оновлювати документи з вимогами на великому проекті декілька ітерацій поспіль.
Питання: як оновити документ з вимогами так, щоб було зрозуміло які саме зміни були впроваджені в певній ітерації?
Ми це вирішили дуже просто, але й дуже дієво в той самий час.
Наприклад в ітерації №40 було декілька змін в функціональності Login.
1️⃣ Створюємо папочку з назвою "Release 40"
2️⃣ З папочки "Release 39" копіюємо документ "Login 39" в новостворену папочку "Release 40"
3️⃣ Перейменовуємо "Login 39 "в "Login 40"
4️⃣ Відкриваємо Login 40, виділяємо весь текст та скидаємо колір заливки тексту
5️⃣ Додаємо наші зміни
6️⃣❗️Й найголовніше - виділяємо наші зміни заливкою жовтим кольором
Й цей простий трюк забезпечує легкість розуміння всіма членами команди того, які саме зміни відбулися в кожній конкретній ітерації.
А чи доводиться вам займатись оновленням вимог на проекті?
триточкова оцінка
#testplan #linkz
Привіт друзі. Минулого тижня я писав про те, як я зазвичай покроково оцінюю впровадження автоматизації в проєкті.
Але вважаю, що тему ще не розкрито до кінця. Бо приходить до вас замовник чи менеджер, і питає - "яка оцінка?" А ви зробили декомпозицію, проаналізували все і кажете "з урахуванням ризиків - 1000 годин", наприклад. Звісно, число чимале, і шанс помилитись є. Тому буде корисно використати науковий підхід до оцінки і спробувати вирахувати, з якою імовірністю проєкт буде виконано вчасно. І тут нам в нагоді стане триточкова оцінка. Її теоретична база досить складна, але користуватись нею просто:
1️⃣ для кожної задачі у вашій декомпозиції треба вказати мінімальний (оптимістичний O), реалістичний (R) та максимальний (песимістичний P) час, за я кий її можна виконати
2️⃣ Розрахувати середнє значення для кожної задачі за формулою:
4️⃣ Розразувати середнє квадратичне відхилення проєкту:
5️⃣ На основі бета розподілу вирахувати імовірність оцінки:
✅ 68% - MP ± SP
✅ 90% - MP ± 1.65 SP
✅ 95% - MP ± 2 SP
Як приклад додам умовний розрахунок проєкту з автоматизації на 100 тестів (з минулого посту) з умовою, що аналіз вже було зроблено.
P.S. Поки готував пост, гуглив, чи все правильно роблю і знайшов дуже класну статтю, що детально описує метод
#testplan #linkz
Привіт друзі. Минулого тижня я писав про те, як я зазвичай покроково оцінюю впровадження автоматизації в проєкті.
Але вважаю, що тему ще не розкрито до кінця. Бо приходить до вас замовник чи менеджер, і питає - "яка оцінка?" А ви зробили декомпозицію, проаналізували все і кажете "з урахуванням ризиків - 1000 годин", наприклад. Звісно, число чимале, і шанс помилитись є. Тому буде корисно використати науковий підхід до оцінки і спробувати вирахувати, з якою імовірністю проєкт буде виконано вчасно. І тут нам в нагоді стане триточкова оцінка. Її теоретична база досить складна, але користуватись нею просто:
1️⃣ для кожної задачі у вашій декомпозиції треба вказати мінімальний (оптимістичний O), реалістичний (R) та максимальний (песимістичний P) час, за я кий її можна виконати
2️⃣ Розрахувати середнє значення для кожної задачі за формулою:
M = (O + 4R + P)/6. Скласти суму всіх середніх значень: MP = ΣM
3️⃣ Розрахувати похибку для кожної задачі: S = (P - O)/6 (песимістичне значення мінус оптимістичне, розділене на 6)4️⃣ Розразувати середнє квадратичне відхилення проєкту:
SP = sqrt(Σ(S^2)) (квадратний корінь суми квадратів похибок)5️⃣ На основі бета розподілу вирахувати імовірність оцінки:
✅ 68% - MP ± SP
✅ 90% - MP ± 1.65 SP
✅ 95% - MP ± 2 SP
Як приклад додам умовний розрахунок проєкту з автоматизації на 100 тестів (з минулого посту) з умовою, що аналіз вже було зроблено.
P.S. Поки готував пост, гуглив, чи все правильно роблю і знайшов дуже класну статтю, що детально описує метод
Важливість тестового оточення
#truestory #bugseverywhere #linkz
Привіт друзі! Нещодавно прочитав надзвичайно цікаву статтю про те, як пишуть софт у SpaceX 🚀
Стаття цікава не тільки описом підходу до розробки і тестування, а референсами до катастроф, які ставались, коли баги не були виявлені вчасно і кожного разу змушували інженерів підіймати планку якості.
Серед інших мене особливо вразив один, який я і хочу переказати вам.
14 грудня 1966 року, на тестовому запуску ракета з безпілотним кораблем "Союз" не змогла взлетіти зі стартового майданчику - один з двигунів не загорівся. Автоматика зупинила запуск. Персонал космодрому пішов перевіряти стан ракети. І в цей час не заплановано спрацювала система аврарійного спасіння (САС) "Союзу" (у випадку аварії корабель з екіпажем має вистрілити від ракети та посадити на парашутах на безпечній відстані). Двигуни САС підпалили горючу рідину, що була розлита на землі, сталася пожежа, одна людина загинула.
Розслідування причин аварії встановило, що ракету обладнано інерційною системою відліку, і комп'ютери порівнюють положення ракети за даними системи та згідно запланованої траєкторії. Якщо є різниця - вистрілює САС. Під час розробки системи було закладено, що Земля - нерухома (і ракета на землі теж). В той же час Земля рухається і за приблизно пів години після невдалого старту ракета разом з усією планетою (чималу змінну не врахували) відхилилась від запланованої траєкторії на 8 градусів, що і викликало запуск САС.
До чого це я? Всі ми часто ловимо гейзенбаги, які не можемо відтворити. Але ніякої містики немає - просто ще не всі змінні врахували. Наступного тижня поділюсь свіжою байкою про такий баг на своєму проєкті.
Гарних вихідних!
#truestory #bugseverywhere #linkz
Привіт друзі! Нещодавно прочитав надзвичайно цікаву статтю про те, як пишуть софт у SpaceX 🚀
Стаття цікава не тільки описом підходу до розробки і тестування, а референсами до катастроф, які ставались, коли баги не були виявлені вчасно і кожного разу змушували інженерів підіймати планку якості.
Серед інших мене особливо вразив один, який я і хочу переказати вам.
14 грудня 1966 року, на тестовому запуску ракета з безпілотним кораблем "Союз" не змогла взлетіти зі стартового майданчику - один з двигунів не загорівся. Автоматика зупинила запуск. Персонал космодрому пішов перевіряти стан ракети. І в цей час не заплановано спрацювала система аврарійного спасіння (САС) "Союзу" (у випадку аварії корабель з екіпажем має вистрілити від ракети та посадити на парашутах на безпечній відстані). Двигуни САС підпалили горючу рідину, що була розлита на землі, сталася пожежа, одна людина загинула.
Розслідування причин аварії встановило, що ракету обладнано інерційною системою відліку, і комп'ютери порівнюють положення ракети за даними системи та згідно запланованої траєкторії. Якщо є різниця - вистрілює САС. Під час розробки системи було закладено, що Земля - нерухома (і ракета на землі теж). В той же час Земля рухається і за приблизно пів години після невдалого старту ракета разом з усією планетою (чималу змінну не врахували) відхилилась від запланованої траєкторії на 8 градусів, що і викликало запуск САС.
До чого це я? Всі ми часто ловимо гейзенбаги, які не можемо відтворити. Але ніякої містики немає - просто ще не всі змінні врахували. Наступного тижня поділюсь свіжою байкою про такий баг на своєму проєкті.
Гарних вихідних!
Топ анти-патернів у автоматизації
#linkz #automation
Цікава стаття з'явилась в львівському клубі тестувальників перед вихідними - стаття з рубрики "впізнай себе".
Причому впізнати можна як в униканні 😎 так і в додержанні 🤪 перелічених анти-патернів :)
https://olegzarevych.medium.com/мій-топ-анти-патернів-у-автоматизації-тестування-72785668c3cc
#linkz #automation
Цікава стаття з'явилась в львівському клубі тестувальників перед вихідними - стаття з рубрики "впізнай себе".
Причому впізнати можна як в униканні 😎 так і в додержанні 🤪 перелічених анти-патернів :)
https://olegzarevych.medium.com/мій-топ-анти-патернів-у-автоматизації-тестування-72785668c3cc
Medium
Мій топ анти-патернів у автоматизації тестування
Більшість своєї кар’єри я займався автоматизацією тестування. І за цей час зібралось декілька речей у нашій сфері, які бісять. Частина з…
Неочевидний баг
#truestory #bugseverywhere
Привіт друзі! Минулого тижня обіцяв розказати про свіжий гейзенбаг, що ми недавно відловили в нашому проєкті. Може інформація стане комусь в нагоді. Чи просто розважить.
Отже, є в нас один продукт - розподілена система. Коли користувач робить в ній "певну дію", система А формує запит до системи С, але не напряму, а через систему В (щось типу прокачаного проксі). А ➡️ B ➡️ C
В певний момент часу постала задача провести тестування навантаження продукту. І тест показав, що остання ланка, система С - сильно тормозить. Як в E2E тестах, так і напряму. Інформацію опрацювали, зробили оптимізацію та виділили більше ресурсів. Проблема не вирішилась взагалі, але її стало значно важче відтворити.
Аж ось через деякий час від користувачів приходить баг - при виконанні "певної дії" все тормозить! Порішайте!
Ми знову проводимо тести, бачимо, що система С тормозить, але щось трішки не сходиться - загальна продуктивність нижча за продуктивність системи С. Підключаємо моніторинг, дивимось веб запити і бачимо схему (як на картинці). Навіть у рідких випадках, коли система С обробляє все швидко - сумарний час запиту великий! І що це за проміжки між запитами? Такого точно немає бути згідно коду - опрацював запит - передай далі.
І ось приходить розуміння, що проблема навіть не одна, але все пов'язано з налаштуваннями.
❌ кожна система використовує скінченний connection pool - тобто на дію кожного користувача з пулу береться з'єднання і використовується для прийому/передачі даних, після чого з'єднання повертається в пул. Так от, коли одна з систем починала тупити, з'єднання не так швидко повертались в пул і навіть швидкі запити починали "тупити", оскільки чекали вільного з'єднання. Справжня TCP пробка😄
❌ схожа ситуація була і з підключенням до БД - якщо системі треба було зчитати власні дані, а вільних підключень не було - система на них чекала 🤷♂️.
Збільшення з'єднань в налаштуваннях трохи збільшило ресурси, що використовуються системами, але значно зменшили затримки, а отже - збільшили продуктивність🤓
Ось так - ніякої магії. Дуже легко було без детального аналізу звинуватити одну систему в усіх гріхах, і дуже важко без спеціального софту і розуміння покращити якість.
#truestory #bugseverywhere
Привіт друзі! Минулого тижня обіцяв розказати про свіжий гейзенбаг, що ми недавно відловили в нашому проєкті. Може інформація стане комусь в нагоді. Чи просто розважить.
Отже, є в нас один продукт - розподілена система. Коли користувач робить в ній "певну дію", система А формує запит до системи С, але не напряму, а через систему В (щось типу прокачаного проксі). А ➡️ B ➡️ C
В певний момент часу постала задача провести тестування навантаження продукту. І тест показав, що остання ланка, система С - сильно тормозить. Як в E2E тестах, так і напряму. Інформацію опрацювали, зробили оптимізацію та виділили більше ресурсів. Проблема не вирішилась взагалі, але її стало значно важче відтворити.
Аж ось через деякий час від користувачів приходить баг - при виконанні "певної дії" все тормозить! Порішайте!
Ми знову проводимо тести, бачимо, що система С тормозить, але щось трішки не сходиться - загальна продуктивність нижча за продуктивність системи С. Підключаємо моніторинг, дивимось веб запити і бачимо схему (як на картинці). Навіть у рідких випадках, коли система С обробляє все швидко - сумарний час запиту великий! І що це за проміжки між запитами? Такого точно немає бути згідно коду - опрацював запит - передай далі.
І ось приходить розуміння, що проблема навіть не одна, але все пов'язано з налаштуваннями.
❌ кожна система використовує скінченний connection pool - тобто на дію кожного користувача з пулу береться з'єднання і використовується для прийому/передачі даних, після чого з'єднання повертається в пул. Так от, коли одна з систем починала тупити, з'єднання не так швидко повертались в пул і навіть швидкі запити починали "тупити", оскільки чекали вільного з'єднання. Справжня TCP пробка😄
❌ схожа ситуація була і з підключенням до БД - якщо системі треба було зчитати власні дані, а вільних підключень не було - система на них чекала 🤷♂️.
Збільшення з'єднань в налаштуваннях трохи збільшило ресурси, що використовуються системами, але значно зменшили затримки, а отже - збільшили продуктивність🤓
Ось так - ніякої магії. Дуже легко було без детального аналізу звинуватити одну систему в усіх гріхах, і дуже важко без спеціального софту і розуміння покращити якість.
Playwright та асинхронність
#linkz #automation
Привіт друзі! Як ви могли зрозуміти по попереднім дописам, зараз я активно досліджую інструмент для автоматизації тестування Playwright. І мені дуже кортіло придумати сценарій, в якому було б сенс використати асинхронне API. І, як це часто буває, такий сценарій сам прийшов до мене. Вирішив для різноманіття зробити невеликий допис на DOU - Playwright — запускаємо тести паралельно for fun.
А ще відео записав.
Як вам?
#linkz #automation
Привіт друзі! Як ви могли зрозуміти по попереднім дописам, зараз я активно досліджую інструмент для автоматизації тестування Playwright. І мені дуже кортіло придумати сценарій, в якому було б сенс використати асинхронне API. І, як це часто буває, такий сценарій сам прийшов до мене. Вирішив для різноманіття зробити невеликий допис на DOU - Playwright — запускаємо тести паралельно for fun.
А ще відео записав.
Як вам?
YouTube
Playwright python - how to run browsers concurrently
Коли читаєш документацію (https://github.com/microsoft/playwright-python ), перші ж приклади показуть, як працювати з інструментом синхронно та асинхронно. Приклади працюють однаково і відрізняються лише стилем написання.
“Синхронний варіант простіший” -…
“Синхронний варіант простіший” -…
Не своя робота
Привіт друзі. Сьогодні пост, ідея якого довго була в моєму TODO списку. На перший погляд дуже проста, але коли починаю формулювати, сам ловлю себе на суперечливих думках. Пропоную вам подумати разом зі мною - чи треба виконувати чужу роботу?
Поясню, що я маю на увазі - всі дуже цінують такий софт скіл як ПРОАКТИВНІСТЬ. Про нього пишуть в CV, розказують на співбесідах та на мотивуючих лекціях. Нема роботи - знайди! Бачиш проблему (в документах, в продукті, в процесі) - як мінімум, повідом про неї, а потім follow up. А краще сам зроби щось, щоб все виправити. Ми ж всі agile, QA в широкому сенсі цього слова, слідуємо кращим рекомендаціям ідеології DevOps/TestOps.
А ще це бажання показати себе, особливо коли тільки почав працювати:
✅ Можеш поовертаймити, щоб спринт добре закрити? - Так, звичайно!
✅ Там в базі дані не консистентні, можешь глянути, поки DBA у відпусці? - Та без проблем, давно хотів поглибити знання Oracle.
Я сам такий. І від інших очікую. Але у вас ніколи такого не було, що ви бігаєте в милі і не маєте часу навіть в туалет сходити, але не пишете тести і не тестуєте. Бо аналітик замовника чимось дуже зайнятий ™️, і менеджмент дав добро самому виправити всі баги в вимогах. А ціла команда девопсів теж чимось дуже зайнята ™️ та не має часу виправити конфіги, розгорнути енвайрмент, налаштувати білди, тому ось тобі адмінські права - роби сам (або ще гірше - зась тобі а не права! Зроби все якось через костилі, а якщо не впораєшся, ще й винуватим будеш)
І дуже добре, що в команди є такий спеціаліст як ВИ🏅 І вам до якогось моменту цікаво все робити. І тут питання - до якого? Щоб не перегоріти і не зненавиді всіх взагалі. Чи треба зупинятись? І де? А якщо всіх посилати з чужою роботою, ще й атмосферу в команді можна погіршити...
Моя думка така - роби все, що цікаво, поки воно цікаво. Бо без розвитку швидко тупієш. Але якщо для кожної роботи в команді вже є спеціально виділені люди, просто вони постійно чимось зайняті ™️ - то не треба робити все самому - треба змусити їх робити свою роботу. Самим. І вчасно. Репортити, фолоапити, ескалювати.
І хоп - ви вже менеджер 😆
А що ви думаєте про не свою роботу?
Привіт друзі. Сьогодні пост, ідея якого довго була в моєму TODO списку. На перший погляд дуже проста, але коли починаю формулювати, сам ловлю себе на суперечливих думках. Пропоную вам подумати разом зі мною - чи треба виконувати чужу роботу?
Поясню, що я маю на увазі - всі дуже цінують такий софт скіл як ПРОАКТИВНІСТЬ. Про нього пишуть в CV, розказують на співбесідах та на мотивуючих лекціях. Нема роботи - знайди! Бачиш проблему (в документах, в продукті, в процесі) - як мінімум, повідом про неї, а потім follow up. А краще сам зроби щось, щоб все виправити. Ми ж всі agile, QA в широкому сенсі цього слова, слідуємо кращим рекомендаціям ідеології DevOps/TestOps.
А ще це бажання показати себе, особливо коли тільки почав працювати:
✅ Можеш поовертаймити, щоб спринт добре закрити? - Так, звичайно!
✅ Там в базі дані не консистентні, можешь глянути, поки DBA у відпусці? - Та без проблем, давно хотів поглибити знання Oracle.
Я сам такий. І від інших очікую. Але у вас ніколи такого не було, що ви бігаєте в милі і не маєте часу навіть в туалет сходити, але не пишете тести і не тестуєте. Бо аналітик замовника чимось дуже зайнятий ™️, і менеджмент дав добро самому виправити всі баги в вимогах. А ціла команда девопсів теж чимось дуже зайнята ™️ та не має часу виправити конфіги, розгорнути енвайрмент, налаштувати білди, тому ось тобі адмінські права - роби сам (або ще гірше - зась тобі а не права! Зроби все якось через костилі, а якщо не впораєшся, ще й винуватим будеш)
І дуже добре, що в команди є такий спеціаліст як ВИ🏅 І вам до якогось моменту цікаво все робити. І тут питання - до якого? Щоб не перегоріти і не зненавиді всіх взагалі. Чи треба зупинятись? І де? А якщо всіх посилати з чужою роботою, ще й атмосферу в команді можна погіршити...
Моя думка така - роби все, що цікаво, поки воно цікаво. Бо без розвитку швидко тупієш. Але якщо для кожної роботи в команді вже є спеціально виділені люди, просто вони постійно чимось зайняті ™️ - то не треба робити все самому - треба змусити їх робити свою роботу. Самим. І вчасно. Репортити, фолоапити, ескалювати.
І хоп - ви вже менеджер 😆
А що ви думаєте про не свою роботу?
The European Software Testing Awards - Finalist
#news
Infopulse, компанія, в якій ми працюємо, стала фіналістом щорічної премії в галузі тестування. Причому відразу в двох номінаціях: Leading Vendor та Best Overall Testing Project - Finance!
Звичайно, в першу чергу це стало можливим завдяки тому, що ми дійсно іноді робимо класні проекти з тестування, дедалі більше. Але, загальновідомо, що для того щоб займати призові місця в конкурсах - треба як мінімум приймати в них участь :)
Тому й безпосередня заслуга авторів цього каналу тут також є. Разом із колегами подавали компанію на цю премію, збирали необхідну інформацію й тримали пальчики схрещеними 🤞 :)
Трохи прикро, що від поїздки в Лондон на процедуру нагородження довелось відмовитись 🦠😢
#news
Infopulse, компанія, в якій ми працюємо, стала фіналістом щорічної премії в галузі тестування. Причому відразу в двох номінаціях: Leading Vendor та Best Overall Testing Project - Finance!
Звичайно, в першу чергу це стало можливим завдяки тому, що ми дійсно іноді робимо класні проекти з тестування, дедалі більше. Але, загальновідомо, що для того щоб займати призові місця в конкурсах - треба як мінімум приймати в них участь :)
Тому й безпосередня заслуга авторів цього каналу тут також є. Разом із колегами подавали компанію на цю премію, збирали необхідну інформацію й тримали пальчики схрещеними 🤞 :)
Трохи прикро, що від поїздки в Лондон на процедуру нагородження довелось відмовитись 🦠😢
Ми прокачали себе в гугл пошуку
#news
Привіт друзі! Нещодавно ми прокачали наш сайт в пошуку гугл - тепер маємо власну картку з посиланнями на розділи і сторінку відгуків.
А ще (в теорії) наш сайт та канал тепер імовірніше буде пропонуватись тим, хто шукає матеріали з тестування ПЗ.
І саме ви, наші читачі, можете позитивно вплинути на цю імовірність - для цього треба лише написати відгук. Бог Рандому обов'язково оцінить такий дар (чи ні, тут 50/50 😄)
Як мінімум нам, авторам, буде приємно і більше мотивації готувати якісний контент.
Дякуємо ❤️
#news
Привіт друзі! Нещодавно ми прокачали наш сайт в пошуку гугл - тепер маємо власну картку з посиланнями на розділи і сторінку відгуків.
А ще (в теорії) наш сайт та канал тепер імовірніше буде пропонуватись тим, хто шукає матеріали з тестування ПЗ.
І саме ви, наші читачі, можете позитивно вплинути на цю імовірність - для цього треба лише написати відгук. Бог Рандому обов'язково оцінить такий дар (чи ні, тут 50/50 😄)
Як мінімум нам, авторам, буде приємно і більше мотивації готувати якісний контент.
Дякуємо ❤️
Що ти робив?
Привіт друзі! Знаєте, яке в мене одне з найулюбленіших питань на співбесідах?
"Вам треба написати звіт про свою роботу в на цьому тижні. Що ви напишите?"
Відповідь на нього дає чітке уявлення, як кандидат
✅ уявляє свої робочі активності
✅ розподіляє час на активності
✅ трекає результати своєї роботи
✅ аналізує результати роботи і які висновки робить
Приклад однозначно поганої відповіді на питання 😢:
Ну, я тестував, багів не знайшов. Ще документацію читав...
Приклад хорошої 😇:
Написав А тестів, виконав В тестів (їх статуси), зарепортив С багів (їх статуси та пріоритети), витратив на ці активності D часу. Поточна якість тестового продукту - 42. + брав участь у наступних активностях: ... і т.д.
І якщо раніше я частіше чув першу відповідь, то зараз, на щастя, – тільки варіації другої 😁
А як у вас зі звітами?
Привіт друзі! Знаєте, яке в мене одне з найулюбленіших питань на співбесідах?
"Вам треба написати звіт про свою роботу в на цьому тижні. Що ви напишите?"
Відповідь на нього дає чітке уявлення, як кандидат
✅ уявляє свої робочі активності
✅ розподіляє час на активності
✅ трекає результати своєї роботи
✅ аналізує результати роботи і які висновки робить
Приклад однозначно поганої відповіді на питання 😢:
Ну, я тестував, багів не знайшов. Ще документацію читав...
Приклад хорошої 😇:
Написав А тестів, виконав В тестів (їх статуси), зарепортив С багів (їх статуси та пріоритети), витратив на ці активності D часу. Поточна якість тестового продукту - 42. + брав участь у наступних активностях: ... і т.д.
І якщо раніше я частіше чув першу відповідь, то зараз, на щастя, – тільки варіації другої 😁
А як у вас зі звітами?
QA Mania
Що ти робив? - QA Mania
Привіт друзі! Знаєте, яке в мене одне з найулюбленіших питань на співбесідах?“Вам треба написати звіт про свою роботу в на цьому тижні. Що ви напишите?”Відповідь на нього дає чітке уявлення, як кандидат✅ уявляє свої робочі активності✅ …
WebSockets
#tools
Привіт, друзі! У вас часто буває, що ви читаєте про нову технологію і думаєте: «Оце круто! Я б дуже хотів сам з таким попрацювати!»?
А потім ніколи в роботі її не зустрічаєте, бо у вас багато легасі, а ключові системи взагалі ще динозаври на коболі писали. У мене така історія з веб сокетами — часто про них чую, читаю, але в основній роботі ніколи не зустрічав (на відміну від звичайних TCP сокетів).
Вирішив для себе трохи покопати тему, накопав на невелику статтю для DOU - https://dou.ua/forums/topic/32325/
Чи ви тестуєте ПЗ з веб сокетами? Чим користуєтесь? Які цікаві випадки у вас з ними були?
#tools
Привіт, друзі! У вас часто буває, що ви читаєте про нову технологію і думаєте: «Оце круто! Я б дуже хотів сам з таким попрацювати!»?
А потім ніколи в роботі її не зустрічаєте, бо у вас багато легасі, а ключові системи взагалі ще динозаври на коболі писали. У мене така історія з веб сокетами — часто про них чую, читаю, але в основній роботі ніколи не зустрічав (на відміну від звичайних TCP сокетів).
Вирішив для себе трохи покопати тему, накопав на невелику статтю для DOU - https://dou.ua/forums/topic/32325/
Чи ви тестуєте ПЗ з веб сокетами? Чим користуєтесь? Які цікаві випадки у вас з ними були?
DOU
Як тестеру з веб сокетами взаємодіяти?
У вас часто буває, що ви читаєте про нову технологію і думаєте: "Оце круто! Я б дуже хотів сам з таким попрацювати!"? А потім ніколи в роботі її не зустрічаєте, бо у вас багато легасі, а ключові системи взагалі ще динозаври на коболі писали.
В Олексія
В Олексія
Як перестати хвилюватися та почати делегувати
#longread
Привіт друзі! Сьогодні хочу поговорити про менеджмент команд. Коли думав над постом, вирішив не писати банального - не бійся, дай частину роботи колегам, потім фолоап. Це так само тупо, як казати людині, що боїться павуків "та не бійся" та дати в руку тарантула🕷. На що тут розраховувати? Що вам скажуть "О, точно, не боюсь! Прикольно, він такий волохатий" чи "АААААААААА!!!" Тому я напишу кілька історій, а якщо впізнаєте себе, значить варто задуматись і може щось змінити в своїй роботі 😉
Всі збіги з реальними людьми випадкові
Універсальний солдат
Аліса вже довго працює в IT, все знає і уміє, успішно менеджила десятки проєктів і є взірцем для наслідування. Зараз менеджить теплий ламповий проєкт, що не вимагає залучення 100% часу, тому Аліса бере додатковий проєкт, на 20% часу, чисто приглядати, що команда робить все правильно. Але в обох проєктах регулярні мітинги, і звіти треба підготувати, і плани спланувати, а ще й самій щось потестити, а ще є не проєктні активності (вона ж експерт у всьому і часто консультує інших). Тому починає свій робочий день раніше, закінчує пізніше, а деякі задачі залишає на вихідні. Бо їй дійсно цікаво. А ще ніхто, крім неї, з цим не впорається. А потім Аліса вигорає, а її друзі ображаються, що вона завжди зайнята. Бо вчасно не передала частину своєї роботи іншим, хоча мала нагоду
Всім тестерам приклад
Боб - справжній ІТ динозавр, що особисто брав участь в зародженні індустрії. У Боба неймовірна репутація - менеджить по 10 проєктів за раз, виступає на конференціях, пише книги, викладає в університеті, консультує команди. А ще має час на сім'ю, друзів та екстравагантне хобі типу жонглювання бензопилами з зав'язаними очима, балансуючи на м'ячику. Все, що приходить на думку - ВАУ! Оце людина! Якщо буду їпрацювати, то теж буду таким крутим. Все можливо!
А потім випадає нагода попрацювати в одній команді з Бобом, та виявляється, що він пропустив майже всі дейлі в цьому спринті, постійно переносить лекції, бігає в милі з мітинга на мітинг... Власне, виявляється, що дива нема - Боб всюди зайнятий і нікуди не встигає 🥺
Лєв Толстой
З Чарлі ви познайомились нещодавно. Він - голова відділу якості великої компанії, ваш безпосередній керівник та наставник. він делегував вам 2 свої проєкти і назначив щотижневу фолоап зустріч. "Як грамотно все влаштовано!" - радієте ви. Розібравшись зі своєми проєктами, ви розумієте що свою роботу в задані сроки їх виконати неможливо, треба команду розширювати, чи сроки рухати. Повідомляєте Чарлі і отримуєте відповідь "не нервуй так. Придумай блокер, повідом про нього і далі забий, хай інші розбираються. Ходи на мітинги, кажи, що старанно працюєш, але все складно і сроки назвати не можеш. Якщо проєкт не виконають вчасно, головне - то буде не твоя провина. Я так роками працюю і все встигаю 😱"
Маг 80-го рівня 🧙♂️
Коли Дейв малий був, грав в якусь онлайн-RPG, качав основного персонажа (мага), а друзів-помічників (танка, хіла) не качав, бо "крутий і сам впораюсь". А потім дійшов до боса з анти-магією і злився 🤷♂️ Проходячи гру другий раз, Дейв не просто давав команди своїй команді, а вчив їх грати ефективно - що купляти, що качати, куди краще ходити. В результаті, навіть коли в Дейва пропав інтернет, його команда пройшла всіх босів сама! Чим він дуже пишався
Зустрічали таких менеджерів? Чи впізнали себе? Чи може знаєте ще персонажів? Пишіть коментарі!
#longread
Привіт друзі! Сьогодні хочу поговорити про менеджмент команд. Коли думав над постом, вирішив не писати банального - не бійся, дай частину роботи колегам, потім фолоап. Це так само тупо, як казати людині, що боїться павуків "та не бійся" та дати в руку тарантула🕷. На що тут розраховувати? Що вам скажуть "О, точно, не боюсь! Прикольно, він такий волохатий" чи "АААААААААА!!!" Тому я напишу кілька історій, а якщо впізнаєте себе, значить варто задуматись і може щось змінити в своїй роботі 😉
Всі збіги з реальними людьми випадкові
Універсальний солдат
Аліса вже довго працює в IT, все знає і уміє, успішно менеджила десятки проєктів і є взірцем для наслідування. Зараз менеджить теплий ламповий проєкт, що не вимагає залучення 100% часу, тому Аліса бере додатковий проєкт, на 20% часу, чисто приглядати, що команда робить все правильно. Але в обох проєктах регулярні мітинги, і звіти треба підготувати, і плани спланувати, а ще й самій щось потестити, а ще є не проєктні активності (вона ж експерт у всьому і часто консультує інших). Тому починає свій робочий день раніше, закінчує пізніше, а деякі задачі залишає на вихідні. Бо їй дійсно цікаво. А ще ніхто, крім неї, з цим не впорається. А потім Аліса вигорає, а її друзі ображаються, що вона завжди зайнята. Бо вчасно не передала частину своєї роботи іншим, хоча мала нагоду
Всім тестерам приклад
Боб - справжній ІТ динозавр, що особисто брав участь в зародженні індустрії. У Боба неймовірна репутація - менеджить по 10 проєктів за раз, виступає на конференціях, пише книги, викладає в університеті, консультує команди. А ще має час на сім'ю, друзів та екстравагантне хобі типу жонглювання бензопилами з зав'язаними очима, балансуючи на м'ячику. Все, що приходить на думку - ВАУ! Оце людина! Якщо буду їпрацювати, то теж буду таким крутим. Все можливо!
А потім випадає нагода попрацювати в одній команді з Бобом, та виявляється, що він пропустив майже всі дейлі в цьому спринті, постійно переносить лекції, бігає в милі з мітинга на мітинг... Власне, виявляється, що дива нема - Боб всюди зайнятий і нікуди не встигає 🥺
Лєв Толстой
З Чарлі ви познайомились нещодавно. Він - голова відділу якості великої компанії, ваш безпосередній керівник та наставник. він делегував вам 2 свої проєкти і назначив щотижневу фолоап зустріч. "Як грамотно все влаштовано!" - радієте ви. Розібравшись зі своєми проєктами, ви розумієте що свою роботу в задані сроки їх виконати неможливо, треба команду розширювати, чи сроки рухати. Повідомляєте Чарлі і отримуєте відповідь "не нервуй так. Придумай блокер, повідом про нього і далі забий, хай інші розбираються. Ходи на мітинги, кажи, що старанно працюєш, але все складно і сроки назвати не можеш. Якщо проєкт не виконають вчасно, головне - то буде не твоя провина. Я так роками працюю і все встигаю 😱"
Маг 80-го рівня 🧙♂️
Коли Дейв малий був, грав в якусь онлайн-RPG, качав основного персонажа (мага), а друзів-помічників (танка, хіла) не качав, бо "крутий і сам впораюсь". А потім дійшов до боса з анти-магією і злився 🤷♂️ Проходячи гру другий раз, Дейв не просто давав команди своїй команді, а вчив їх грати ефективно - що купляти, що качати, куди краще ходити. В результаті, навіть коли в Дейва пропав інтернет, його команда пройшла всіх босів сама! Чим він дуже пишався
Зустрічали таких менеджерів? Чи впізнали себе? Чи може знаєте ще персонажів? Пишіть коментарі!
Соціальна активність
#news #dou
Привіт друзі! Пам'ятаєте чи ні, в попередніх постах ми заохочували всіх писати статті, дописи. Ділитись досвідом та цікавими статтями, щоб світ ставав кращим. І самі подавали приклад 😊
Власне, сьогодні хочу похвалитись: отримав від DOU новорічний подарунок за "писемну активність" 😁
Пишіть! Це не тільки цікаво, а іноді ще й приносить сюрпризи 🎁
Якщо у вас є бажання почати - напишіть нам в бота @qamania_feedback_bot, чи коменти, чи на пошту contact@qamania.org
#news #dou
Привіт друзі! Пам'ятаєте чи ні, в попередніх постах ми заохочували всіх писати статті, дописи. Ділитись досвідом та цікавими статтями, щоб світ ставав кращим. І самі подавали приклад 😊
Власне, сьогодні хочу похвалитись: отримав від DOU новорічний подарунок за "писемну активність" 😁
Пишіть! Це не тільки цікаво, а іноді ще й приносить сюрпризи 🎁
Якщо у вас є бажання почати - напишіть нам в бота @qamania_feedback_bot, чи коменти, чи на пошту contact@qamania.org
Підсумки року 2020
#qamania
Вітаємо всіх! Вже наступного дня ми замість того щоб гортати сторінки календаря - замінимо його на новий, дістанемо подарунки з під ялинки, дзвінко зустрінемось келихом ігристого з кимось нам близьким, сподіваємось особисто, але накрайняк можна й по зуму ;)
Та, пригадавши події двадцятого, зітхнемо з полегшенням, або ж посміхнемось з вдячністю - це вже хто що пригадає :)
Ми в QAMania з вдячністю за дуже різноманітний досвід проводжатимемо 20-й та з оптимізмом дивитимемось та будуватимемо плани на 21-й.
Дещо з того, що пригадується за 20-й:
👥 Канал росте. В 20-му ми отримали можливість ділитись досвідом та думками з більшою кількістю людей. +1000. Починали рік з 214, закінчуємо з майже 1,300 підписників. В планах подальше зростання. Дякуємо, що з нами.
⭐️ Якість та кількість матеріалів. За 20-й зробили 188 дописів. Загальна ж кількість постів в каналі на даний момент: 278. Так само намагаємось писати кожен день, але в цьому році досить часто перемагав внутрішній перфекціоніст, тому з однієї сторони - не завжди вдавалось кожен день, з іншої - стало більше власних статей, лонгрідів та особистих думок.
📣 Нові формати. В цьому році ми започаткували наш youtube канал, спочатку суто для студентів в рамках курсу з тестування в КПІ, але потім й для класних технічних воркшопів. Завдяки одній добрій людині почали партнеритись з організаторами різних подій, конференцій, привели трохи до ладу facebook сторінку. Зареєструвались в google maps - тепер qamania можна знайти й там :)
Пробували навіть Pinterest для нашої рубрики #linkz, та й взагалі багато чого іншого пробували, але не все пішло 🤷♂️
💡 Рубрики. Очікувано позитивні враження отримали від нової рубрики #quiz з питаннями по теорії тестування за мотивами istqb - судячи з кількості відповідей, вам також сподобалось :) Багато писали власне про #istqb - також популярна тема, судячи з кількості вподобайок та відгуків. Плануємо продовжувати як з istqb, так і з опитувальниками. Взагалі ось наші топ рубрики, які мають від 10 постів:
#learnit 58
#tools 43
#truestory 26
#friday 20
#istqb 20
#bugseverywhere 15
#longread 15
#automation 14
#linkz 11
#fun 11
#testdesign 10
А які рубрики були до вподоби вам? Чи може якихось не вистачало? Напишіть в коментах.
🎬 Події. Стікерпаки з багами, "кріпто-квест" з призами, конференції, мітапи, статті на ДОУ. Є що пригадати :) Та й на наступний рік деякі ідеї вже є.
Якщо й ви маєте такі ідеї - напишіть нам в коменти, може вдасться їх реалізувати :)
Рік відбувся. Збагатив всіх нас новим досвідом, когось позитивним, когось нажаль й негативним, а когось просто неочікуваним.
Залишаємось на зв'язку :)
Дякуємо, що з нами!
QAMania
#qamania
Вітаємо всіх! Вже наступного дня ми замість того щоб гортати сторінки календаря - замінимо його на новий, дістанемо подарунки з під ялинки, дзвінко зустрінемось келихом ігристого з кимось нам близьким, сподіваємось особисто, але накрайняк можна й по зуму ;)
Та, пригадавши події двадцятого, зітхнемо з полегшенням, або ж посміхнемось з вдячністю - це вже хто що пригадає :)
Ми в QAMania з вдячністю за дуже різноманітний досвід проводжатимемо 20-й та з оптимізмом дивитимемось та будуватимемо плани на 21-й.
Дещо з того, що пригадується за 20-й:
👥 Канал росте. В 20-му ми отримали можливість ділитись досвідом та думками з більшою кількістю людей. +1000. Починали рік з 214, закінчуємо з майже 1,300 підписників. В планах подальше зростання. Дякуємо, що з нами.
⭐️ Якість та кількість матеріалів. За 20-й зробили 188 дописів. Загальна ж кількість постів в каналі на даний момент: 278. Так само намагаємось писати кожен день, але в цьому році досить часто перемагав внутрішній перфекціоніст, тому з однієї сторони - не завжди вдавалось кожен день, з іншої - стало більше власних статей, лонгрідів та особистих думок.
📣 Нові формати. В цьому році ми започаткували наш youtube канал, спочатку суто для студентів в рамках курсу з тестування в КПІ, але потім й для класних технічних воркшопів. Завдяки одній добрій людині почали партнеритись з організаторами різних подій, конференцій, привели трохи до ладу facebook сторінку. Зареєструвались в google maps - тепер qamania можна знайти й там :)
Пробували навіть Pinterest для нашої рубрики #linkz, та й взагалі багато чого іншого пробували, але не все пішло 🤷♂️
💡 Рубрики. Очікувано позитивні враження отримали від нової рубрики #quiz з питаннями по теорії тестування за мотивами istqb - судячи з кількості відповідей, вам також сподобалось :) Багато писали власне про #istqb - також популярна тема, судячи з кількості вподобайок та відгуків. Плануємо продовжувати як з istqb, так і з опитувальниками. Взагалі ось наші топ рубрики, які мають від 10 постів:
#learnit 58
#tools 43
#truestory 26
#friday 20
#istqb 20
#bugseverywhere 15
#longread 15
#automation 14
#linkz 11
#fun 11
#testdesign 10
А які рубрики були до вподоби вам? Чи може якихось не вистачало? Напишіть в коментах.
🎬 Події. Стікерпаки з багами, "кріпто-квест" з призами, конференції, мітапи, статті на ДОУ. Є що пригадати :) Та й на наступний рік деякі ідеї вже є.
Якщо й ви маєте такі ідеї - напишіть нам в коменти, може вдасться їх реалізувати :)
Рік відбувся. Збагатив всіх нас новим досвідом, когось позитивним, когось нажаль й негативним, а когось просто неочікуваним.
Залишаємось на зв'язку :)
Дякуємо, що з нами!
QAMania
