колись на роботі (в центрі бронювання житла) користувались mantis'ом для обробки заявок, в принципі всі ці системи схожі, але складно собі уявляю як для таких речей використовувати трелло
Проекти різні, різні бюджети. Хтось виділяє кошти, хтось шукає якнайдешевше. Тому не завжди все оптимізовано, проте головне щоб тестування продукту відбувалось якнайкраще за даних наявних ресурсів.
@@samasobitester нічого страшного, це все одно досвід, буквально півгодини тому дивився ваше одне з перших відео там значно більше траблів, але важливо, що воно є)
Так, дякую! Бачу що якість в такому форматі гірша, тому наступного разу запишу відео з екрану. Навіть за допомогою Win+G можна зробити з відновса. Дякую за коментар!
@@samasobitesterДоброго дня. Підкажіть будь ласка який компʼютер підходить для тестування? У вас віндовс, а в айті часто мак ос. На цю тему можна ціле відео зробити. Також зачепити усю галузь айті і компʼютери вінду чи мак ос, що все таки більш розповсюджене
@NoNo-ww4rc В мене є і віндовс, і мак. На роботі можуть видавати компʼютер, теж залежить від потреб та бюджету компанії. А можуть і не видавати, тому користуєтесь тим, чим маєте. Який купити? - Тут більше залежить від ваших потреб та цілей як ви будете користуватись цим комп’ютером. Відео напевно зроблю, бо часто про це питають) Дякую що пишете!
Дякую за цікавий туторіал по темі QA і Bug report. Якщо можна - поділіться будь-ласка, що то за доповнення чи програма, що постійно підказує які англійські слова ймовірно будуть надруковані (по типу клавіатури Google в телефоні)? І ще декілька моментів... 1) Як впливає номер збірки, на прикладі з відео це 4-та цифра в версії (Build number) до основної версії продукту, або до релізу Bug fix? Бо щось новачкам не зрозуміло що білдиться, а що фікситься... та як правильно нумерується - з права наліво чи кожна цифра може змінюватися незалежно ))) 2) Вибачте, але за пріоритети та вагу багу щось зовсім не зрозуміло. Мені здається, що вони (всі три одночасно) лише заважають один одному. І взагалі, на початку вивчення теми тестування ці пріоритети чимось схожі на номери версій (з мого першого питання) де багато цифр і не зрозуміло як вони взаємодіють між собою.
Щодо підказки слів то це сам Word із заінстальованими словниками. В File-Settings-Verification можете заглянути та перевірити чи заінствльовані у вас словники (якщо ні, їх треба скачати), тоді треба зазначити відповідні чекбокси згідно ваших вподобань щоб висвітлювалась автоматична перевірка слів.
1) Загалом нумерація послідовна, з ліва на право. Просто кожна цифра означає якусь готову версію продукту, яка вже була видана. Наприклад, є новий продукт - програма яка тільки виходить 1.0.0.199 Тут означає що готується перша релізна версія, ще не було ні мінорних версій (перший 0), ні баг фіксів (другий 0). 199 білд означає що вже оновлювалась програма стільки разів, робилися фічі, фіксили поточні баги і т.д. Наприклад тестер знаходить знову баг, зголошує його і зазначає версію в якій знайшов цей баг 1.0.0.199 Розробник до якого приписаний цей баг його фіксить та пише, що фікс буде доданий у версію 1.0.0.201 бо наприклад його колега щойно пофіксив ще одну іншу багу і згенерував новий білд 1.0.0.200 Тому баг який нас цікавить, буде доданий у наступну версію, 201, а у 200 фіксу не буде. Далі наприклад версія йде до клієнта 1.0.0.555, тільки без останніх цифр а як 1.0.0 коли вній знаходять нові баги і потім випускають фікс до цієї версії то виходить версія 1.0.1 до клієнта. Якщо клієнт хоче нову фічу чи модуль і це імплементується, то версія змінюється на 1.1.0 і якщо знову фіксають наприклад 10 мінорних багів і випускають клієнту то версія буде 1.1.1 а усі білди використовуватимуться внутрішньо при розробці і перевірці цієї версії і вибору її до релізу. Коли будуть розробляти новий дизайн сайту чи багато нового функціоналу, то версія зміниться на 2.0.0 і так далі. Також можна використовувати наприклад версію 1.1.1.222 до імплементації нового дизайну та функціоналу у версії 3.0.0, а версію 2 підтримувати лише баг фіксами.
2) Пріорітет - показує наскільки швидко треба поправити фунціонал, який не працює. Наприклад, лого фірми на основній сторінці відображено неправильно, це найвищий пріорітет, а критичність низька. А вага багу буде теж низька, адже цей фікс доволі швидко фікситься й не займе багато часу. Вага багу є для того, щоб вираховувати вашу роботу в чомусь, наприклад кожен зголошений баг має 1 сторі поінт, адже ви потратили час на те щоб його створити, і розробник його має ще й пофіксити, якщо фікс займатиме багато часу, то розробник може зміниии цю вагу на 3 чи 5 пунктів. Це все умовно, і залежить яку вистему оцінювання ви використовуєте в команді чи на проекті, в даному випадку я ввикористовую фібоначчі, тобто 1, 2, 3, 5, 8, 12. Така оцінка дає можливість враховувати вашу роботу до спрінта (на питання про спрінт відповіла вже раніше). Критичність показує наскільки баг зачепляє різні модулі в додатку. Наприклад, кнопка пошук не працює на головній сторінці, але якщо втиснути то пошук працює. В такому випадку це буде високий пріорітет, та висока северіті (критичність), особливо якщо це комерційна сторінка, в якій користувач постійно щось шукає, і кнопка пошуку відображена у різних частинах програми. Тут теж важливо в назві багу наголосити в тому що сама кнопка не працює, а не фунціональність пошуку, адже якщо з клавіатурою пошук працює правильно, то діло лише в кнопці та кліку саме на неї (“Search button is not responsive“ instead of “Search does not work”). Щодо ваги то тут напевно фікс буде швидким, і залишиться на 1, але буває так, що баг викриває якісь прогалини у фунціоналі і тоді для цього створюються інші завдання чи навіть юзер сторі. І тоді баг є заблокований іншим таском, який поки не вирішиться, не буде змоги протестувати цей конкретний баг. А номери версій, це наприклад та кнопка пошуку не працює у версії 5.19.4.345 Ви зголосили баг і зазначили саме цю версію що зверху. Потім баг приписується до розробника, і він робить фікс, зазначає що ретест можна зробити у версії 5.19.4.349 Чому саме така версія? Бо девелопер наприклад мав багато роботи і цейфікс не був пріоритетом, тому увійшов у пізнішу версію, а не одразу у наступну (5.19.4.346) Тому добре коли вказується версія, тобто конкретний білд де зроблений фікс для даного багу, проте так є не завжли. І буває так що тестер робить ретест, але фікс ще не включений до цього білда, і йде зайва комунікація, що щось не працює і чому.
Привіт! Залежить що ти маєш на увазі під «пасивною формою» :) Якщо вживання пасивного часу англійської, там де це додає об‘єктивності то так, звичайно, краще так і писати. Наприклад: Створення юзера - Повернений статус код 204, а очікується 200 як зазначено у вимогах. Якщо використання «пасиву» ускладнює зрозуміння проблеми/дефекту, то однозначно це не потрібно. Чим простіше і зрозуміліше тим краще. Якщо баг на якомусь конкретному типі юзера, наприклад адмін, який повинен мати доступ до данних клієнтів, і ці дані не висвітлюються у повному обсязі для нього, то краще так і написати: адмін - дані клієнтів частково висвітлені на сторінці. Ну і в фактичному і очікуваному результаті тоді добавити які саме поля є а яких бракує.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
дякую, що використовуєте англійську та українську)))
Дякую дуже за зворотній звʼязок ❤️
дуже вдячний за інформативне відео! ❤
єдине побажання робити запис з екрану, багато полів (особливо на скріншотах) не видно
колись на роботі (в центрі бронювання житла) користувались mantis'ом для обробки заявок, в принципі всі ці системи схожі, але складно собі уявляю як для таких речей використовувати трелло
Так, цілком погоджуюсь, тут варто було робити запис екрану.
Проекти різні, різні бюджети. Хтось виділяє кошти, хтось шукає якнайдешевше. Тому не завжди все оптимізовано, проте головне щоб тестування продукту відбувалось якнайкраще за даних наявних ресурсів.
@@samasobitester нічого страшного, це все одно досвід, буквально півгодини тому дивився ваше одне з перших відео там значно більше траблів, але важливо, що воно є)
Доволі нагоядно. Дякую👍
Якщо можу дату пораду то можливо спробуйте запис екрану комп’ютера. Це можна зробити в безкоштовних додатках OBS або VLC.
Так, дякую! Бачу що якість в такому форматі гірша, тому наступного разу запишу відео з екрану. Навіть за допомогою Win+G можна зробити з відновса. Дякую за коментар!
@@samasobitesterДоброго дня. Підкажіть будь ласка який компʼютер підходить для тестування? У вас віндовс, а в айті часто мак ос. На цю тему можна ціле відео зробити. Також зачепити усю галузь айті і компʼютери вінду чи мак ос, що все таки більш розповсюджене
@NoNo-ww4rc В мене є і віндовс, і мак.
На роботі можуть видавати компʼютер, теж залежить від потреб та бюджету компанії.
А можуть і не видавати, тому користуєтесь тим, чим маєте.
Який купити? - Тут більше залежить від ваших потреб та цілей як ви будете користуватись цим комп’ютером.
Відео напевно зроблю, бо часто про це питають)
Дякую що пишете!
Так дуже дякую за відео , якщо буде можливість то робити запис екрану, щоб не думати що ви робите))))))))
Звісно, роблю тепер запис з екрану) Це одне з старих відео 😊
Дякую що коментуєте!
Дякую за цікавий туторіал по темі QA і Bug report. Якщо можна - поділіться будь-ласка, що то за доповнення чи програма, що постійно підказує які англійські слова ймовірно будуть надруковані (по типу клавіатури Google в телефоні)?
І ще декілька моментів...
1) Як впливає номер збірки, на прикладі з відео це 4-та цифра в версії (Build number) до основної версії продукту, або до релізу Bug fix? Бо щось новачкам не зрозуміло що білдиться, а що фікситься... та як правильно нумерується - з права наліво чи кожна цифра може змінюватися незалежно )))
2) Вибачте, але за пріоритети та вагу багу щось зовсім не зрозуміло. Мені здається, що вони (всі три одночасно) лише заважають один одному. І взагалі, на початку вивчення теми тестування ці пріоритети чимось схожі на номери версій (з мого першого питання) де багато цифр і не зрозуміло як вони взаємодіють між собою.
Щодо підказки слів то це сам Word із заінстальованими словниками. В File-Settings-Verification можете заглянути та перевірити чи заінствльовані у вас словники (якщо ні, їх треба скачати), тоді треба зазначити відповідні чекбокси згідно ваших вподобань щоб висвітлювалась автоматична перевірка слів.
1)
Загалом нумерація послідовна, з ліва на право. Просто кожна цифра означає якусь готову версію продукту, яка вже була видана.
Наприклад, є новий продукт - програма яка тільки виходить 1.0.0.199
Тут означає що готується перша релізна версія, ще не було ні мінорних версій (перший 0), ні баг фіксів (другий 0). 199 білд означає що вже оновлювалась програма стільки разів, робилися фічі, фіксили поточні баги і т.д.
Наприклад тестер знаходить знову баг, зголошує його і зазначає версію в якій знайшов цей баг 1.0.0.199
Розробник до якого приписаний цей баг його фіксить та пише, що фікс буде доданий у версію 1.0.0.201 бо наприклад його колега щойно пофіксив ще одну іншу багу і згенерував новий білд 1.0.0.200
Тому баг який нас цікавить, буде доданий у наступну версію, 201, а у 200 фіксу не буде.
Далі наприклад версія йде до клієнта 1.0.0.555, тільки без останніх цифр а як 1.0.0 коли вній знаходять нові баги і потім випускають фікс до цієї версії то виходить версія 1.0.1 до клієнта.
Якщо клієнт хоче нову фічу чи модуль і це імплементується, то версія змінюється на 1.1.0 і якщо знову фіксають наприклад 10 мінорних багів і випускають клієнту то версія буде 1.1.1 а усі білди використовуватимуться внутрішньо при розробці і перевірці цієї версії і вибору її до релізу.
Коли будуть розробляти новий дизайн сайту чи багато нового функціоналу, то версія зміниться на 2.0.0 і так далі.
Також можна використовувати наприклад версію 1.1.1.222 до імплементації нового дизайну та функціоналу у версії 3.0.0, а версію 2 підтримувати лише баг фіксами.
2)
Пріорітет - показує наскільки швидко треба поправити фунціонал, який не працює. Наприклад, лого фірми на основній сторінці відображено неправильно, це найвищий пріорітет, а критичність низька. А вага багу буде теж низька, адже цей фікс доволі швидко фікситься й не займе багато часу.
Вага багу є для того, щоб вираховувати вашу роботу в чомусь, наприклад кожен зголошений баг має 1 сторі поінт, адже ви потратили час на те щоб його створити, і розробник його має ще й пофіксити, якщо фікс займатиме багато часу, то розробник може зміниии цю вагу на 3 чи 5 пунктів. Це все умовно, і залежить яку вистему оцінювання ви використовуєте в команді чи на проекті, в даному випадку я ввикористовую фібоначчі, тобто 1, 2, 3, 5, 8, 12. Така оцінка дає можливість враховувати вашу роботу до спрінта (на питання про спрінт відповіла вже раніше).
Критичність показує наскільки баг зачепляє різні модулі в додатку. Наприклад, кнопка пошук не працює на головній сторінці, але якщо втиснути то пошук працює. В такому випадку це буде високий пріорітет, та висока северіті (критичність), особливо якщо це комерційна сторінка, в якій користувач постійно щось шукає, і кнопка пошуку відображена у різних частинах програми. Тут теж важливо в назві багу наголосити в тому що сама кнопка не працює, а не фунціональність пошуку, адже якщо з клавіатурою пошук працює правильно, то діло лише в кнопці та кліку саме на неї (“Search button is not responsive“ instead of “Search does not work”). Щодо ваги то тут напевно фікс буде швидким, і залишиться на 1, але буває так, що баг викриває якісь прогалини у фунціоналі і тоді для цього створюються інші завдання чи навіть юзер сторі. І тоді баг є заблокований іншим таском, який поки не вирішиться, не буде змоги протестувати цей конкретний баг.
А номери версій, це наприклад та кнопка пошуку не працює у версії 5.19.4.345
Ви зголосили баг і зазначили саме цю версію що зверху.
Потім баг приписується до розробника, і він робить фікс, зазначає що ретест можна зробити у версії 5.19.4.349
Чому саме така версія? Бо девелопер наприклад мав багато роботи і цейфікс не був пріоритетом, тому увійшов у пізнішу версію, а не одразу у наступну (5.19.4.346)
Тому добре коли вказується версія, тобто конкретний білд де зроблений фікс для даного багу, проте так є не завжли. І буває так що тестер робить ретест, але фікс ще не включений до цього білда, і йде зайва комунікація, що щось не працює і чому.
Привіт! Як ти відносишя до написання саммері, фактичного та очікованого результатів в пасивній формі?
Привіт! Залежить що ти маєш на увазі під «пасивною формою» :)
Якщо вживання пасивного часу англійської, там де це додає об‘єктивності то так, звичайно, краще так і писати.
Наприклад: Створення юзера - Повернений статус код 204, а очікується 200 як зазначено у вимогах.
Якщо використання «пасиву» ускладнює зрозуміння проблеми/дефекту, то однозначно це не потрібно.
Чим простіше і зрозуміліше тим краще.
Якщо баг на якомусь конкретному типі юзера, наприклад адмін, який повинен мати доступ до данних клієнтів, і ці дані не висвітлюються у повному обсязі для нього, то краще так і написати: адмін - дані клієнтів частково висвітлені на сторінці.
Ну і в фактичному і очікуваному результаті тоді добавити які саме поля є а яких бракує.
Як з Вами зконтактувати?
Доброго дня! Можете писати мені на пошту samasobitester@outlook.com або в соціальних мережах у інстаграм чи фейсбук. Лінки знайдете тут на ютубі 😊