На проєкті не було навантажувального тестування, тому і потреби не було вирішувати таку задачу, все банально)

Як згенерувати 100 000 користувачів — не знаю, максимум 100 створювала через Постман під робочу задачу. На 100 000 не виникало потреби.

Якщо казати про ту програму, що я вище написала

crowdin.com

то тут воно працює норм, можна обрати, який ресурс підключити, щоб перекладало. Хоч гугл транслейт, хоч джипіті. 30 днів і дається, щоб все попробувати там, а далі вже платно весь функціонал буде. Про інше не підкажу, програм багато, в кожній по своєму.

Вітаю
Якщо розглядати інструменти для тестування локалізації, то Crowdin один з найпростіших та його можна опанувати поза робочим проєктом (я так робила, бо в мене немає тестування локалізації на проєкті), там є 30-денний безкоштовний період. потрібно:
1) зареєструватись
2) створити свій проєкт (публічний або приватний може бути)
3) обрати мову перекладу
4) завантажити потрібні файли
5) можна зробити інтеграцію з різними системами, такими як GitHub, Bitbucket, Google Drive тощо, це допоможе автоматизувати завантаження та оновлення файлів
6) можна додати декілька людей до проєкту, щоб ті могли оцінити роботу (по суті це тестувальники)
7) Але Crowdin пропонує власні інструменти для автоматичної перевірки якості перекладів:
— перевірка термінології
— перевірка довжини рядків
— перевірка форматування
8) Тестувальник дає фінальне слово чи ок чи ні, якщо затверджено, то можна або руками все вивантажити, або через інтеграцію з системами це автоматично робити

Функціонал широкий насправді, можна надовго застрягти з вивченням того всього. Там і статистика є, і можна вносити різні правки тощо. Посилання на платформу: crowdin.com

Вітаю, Олексію)
Дякую за фідбек, мені дуже приємно, що стаття була корисною))

Deep Test від Google — це розробка від Google DeepMind, воно не є чимось окремим, а застосовується у купі з іншими програмами. Але саме Deep Test (на базі АІ) відповідає за створення тестових прикладів та їх автоматичного виконання у вебзастосунках.

Дуже цікаво було почитати статтю і зауваження, що до того, що українських ІТ-каналів мало. Це дійсно так, але все попереду і все буде) Я також створила свій канал, потрохи рухаюсь і шось та й буде :)

Пробуйте різні варіанти CV, можливо якоїсь інформації не вистачає, або занадто багато і не читабельно, або пістряво, або формат не зрозумілий, варіантів може бути купа, чому з ним щось не так. Пробуйте писати супровідний лист, коли надсилаєте резюме, так рекрутер буде бачити, що ви точно читали опис вакансії, читали про компанію, а не відправили не дивлячись далі заголовка.
На жаль, не всі дають зворотній зв"язок по ТЗ, але не соромтесь просити його дати, хтось то й дасть, або якщо бачити що сама співбесіда йде криво-косо, то в кінці можете запитати, що вам треба підтягнути, ведіть діалог. Одного разу я знала вже на етапі технічної співбесіди, що все пропало, і в кінці запитала, наскільки все погано і на що звернути увагу, щоб надалі не лажати :)

ахахах)))

слушна думка, дякую))

64 — це багато, покрити всі 64 банери складно, це ж скільки ресурсів треба мати. Доцільно розбити на групи. Наприклад, як Ви вказали, на групи по віку. Відповідно, для категорії

жінка 18-25 років

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

Доброго дня)
Так, потрохи набираюсь досвіду і писала статтю більше опираючись на те, що відбувається у мене на проєкті, де не 1 QA. Відповідно як записка собі на майбутнє і тим, хто шукає шляхи покращення.

передбачається, що рутинність знижує ефективність через «втому» і як наслідок зниження концентрації на роботі, але як на мене цей факт може компенсуватись набуттям досвіду, коли людина просто відчуває де шукати дефекти і робить це без всього того складного тест дизайну. 10 тестів, 7 з яких знайдуть дефекти.
а як щодо тих людей які дуже полюбляють рутину і хотіли би поменше думати і побільше проганяти тести і репортити баги. Чи їм теж треба зменшувати рутину? Особливо під час війни, коли безкінечне регресійне тестування є чт не єдиним острівцем стабільності в їх житті?

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

... хм, а що заважає рутинно створювати зрозумілі тест-кейси, теоретично це навіть збільшує монотонність роботи, тому що ви починаєте в моменті більше писати нудних, очевидних тестів. І це як раз приклад, коли рутинність може конфліктувати з ефективністю підтримки тестів для складного проекту.
У прикладі ви вказали, що precondition треба розписати прямо в тест-кейсі (принаймні я так зрозумів з тексту). Дуже спірно, я б навіть сказав шкідливо, оскільки ви тільки обтяжуєте тест-кейси цим, а от посилання на інший тест-кейс, який переводить систему в це стан (і вони наприклад обєднані в єдиний test suite), або ці preconditions розписані в якомусь документі, наприклад у тому ж тест плані, це вже більше до справи.

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

Вибачте, не знаю деталей, але чому тест-кейси з ID C1, C3, C5 у вас мають однакову назву — Instagram: Create account? То це однаковий тест чи є між ними різниця? Якщо є, то її треба відобразити у назві, якщо ні — то це повинен бути тест C1, що повторно використовується для тестування в різних test suites

— Тому що перевірка на різних пристроях (web, iPad, iPhone) одного й того ж функціоналу. В мене на проєкті така система і вона достатньо зручна. Якщо можна по іншому згрупувати — чому б ні, не заперечую :)

Легким розчерком руки ви надали тестувальнику обовязки тест менеджера або й цілого директора департаменту :). Тестуємо на тому, що компанія має/використовує. Ой як рідко тестувальник може повпливати на вибір інструменту. Це на адресу того, для кого ця стаття.

— так, що маємо те й використовуємо, але знати, що є взагалі варінти — чому ні? :)

Чим пункт «розуміння користувача» відрізнається від «емпатія до користувача»?

— досить схожі, але розуміння користувача може базуватися на дослідженнях, аналітиці даних, опитуваннях, спостереженнях та інших методах для отримання об"єктивної інформації. Емпатія до користувача включає емоційний аспект, тобто базування на суб«єктивності, як би Ви діяли емоційно на місці користувача.

Тут трохи не зрозумілий приклад, оскільки якщо 3 тестувальники працюють в одному проекті, то вони начебто всі повинні знати про ці фічі, або принаймні приймати участь в їх обговоренні, бо з вашого прикладу навіть виникають кейси коли з розсилки ми можемо перейти по посиланню і авторизуватись (тільки не кажіть що рестрацію та логін теж відповідають різні тестувальники :) ) або незавершена покупка в корзині может потрапити до теми розсилки. І якщо ж кейс такої прям «ізоляції» людей в команді, то це питання до менеджерів.
Якщо обмін знаннями іде просто «щоб не було нудно» і ці люди навряд чи будуть робити тести одне одного, то тут ще питання для чого це?
З точки зору тім ліда, то тут треба уникати ситуацій наявності «унікальних знань» які втрачаються разом з людиною. В розвязанні проблеми тут допоможе такий інструмент як star map або skill map. Але також як рішення проблеми — створення документації і діставання знань з будь-якої голови. Тобто взагалі не згоден з цим пунктом якщо говоримо про ефективність і дуже умовно згоден, якщо це про рутину, хоча навіть в цьому контексті, саме рутина виглядає не такою великою з інших можливих наявних.

— приклад наведений не з реальності, а для простоти сприйняття, звичайно, що на реальному проєкті саме так не буде. Але знову ж таки спираючись на мій досвід, в мене було, що я займалась тестуванням певних фіч, хтось інший — інших фіч, дивлячись на які в мене округлювались очі, тому що мені треба було повноцінно з нуля розібратись, що це, для чого і як це працює, коли тієї людини не було. Потім цю ситуацію виправили, щоб всі мали рівномірні знання і кожен міг тестувати все, що є і нашому скоупі. Впевнена, не в мене однієї така ситуація виникала чи в когось може виникнути.
У Вас більше досвіду і з висоти цього досвіду більше розуміння що і як можна зробити. Але це все практика, набиття гуль, яких не уникнути все одно. Вважаю не поганим поділитись цим і якщо хтось візьме для себе хоч щось на замітку — буде добре :)

З останнім абзацом згодна і як бачите, мені в голову воно не прийшло через брак досвіду. Але зауваження слушне, дуже дякую, є над чим задуматись :)

Вітаю, Віктор)
Так, все не буде ідеально. Але «прийняття» не завжди і щось потрохи змінювати у підходах до роботи можливо.
Озираючись на проєкт, на якому працюю, багато підходів застосовані, що робить роботу в якомусь сенсі легшою. А боротись із вигоранням та рутиною шляхом зміни професії — дивно, бо ці супутники є в кожній професії і від себе не втечеш.

Все змінюється, а мануальне тестування досі потрібне :)

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

Це я щось поспішила, але дякую за зауваження, виправила :)

дякую, Вікторія, за ваш зворотній зв"язок :)

Дякую за фідбек))
Так, стаття дійсно розрахована на початкове ознайомлення, яке зазвичай дається в рамках курсів. Принаймні в мене було так :)
Але згодна, що можна ще дописати деякі моменти, щоб покрити якомога більше. Є над чим працювати))

Дякую за зауваження, виправила :)

Додала мотивацію на початок, щоб було зрозуміліше :)

Дякую, Генадію, врахую зауваження))

Олена, дякую Вам за зворотній зв"язкок 😊
Рада, що сподобалась стаття))

Дуже дякую за такий фідбек! 🤗