Drive your career as React Developer with Symphony Solutions!
×Закрыть
QA engineer в ELEKS Software
  • Никогда не писали автотесты? Попробуйте Cypress

    но это лишает удобства и занимает больше времени

    xunitpatterns.com/...​nditional Test Logic.html

  • Писать ли Unit-тесты до готовности MVP

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

  • Как выжить, если ты один QA на проекте. 10 советов

    это один из признаков развития общества

    розділення праці != розділення обов’язків. Ви ніяк не можете мене зрозуміти.
    У певних сценаріях, задля ефективного процесу, роботу можна розділяти. Але у певних сценаріях можна і не розділяти. Наприклад, коли проект маленький. Або той рівень якості який забезпечує команда без тестувальника, задовольняє замовника чи клієнтів. І це ок.

    І для того, щоб трошки подумати www.youtube.com/watch?v=qd9N9eU1Qn0

    тестировщиков достаточно и у Гугла, и у Майкрософта

    вони то там є, але у великій меншості і також займаються девелопментом. За якісь та тестування там відповідають розробники
    testing.googleblog.com/...​ts-software-part-two.html
    Test Engineer is the exact reverse of the SET. It is a a role that puts testing first and development second. Тобто, тест інженери також є девелоперами

  • Как выжить, если ты один QA на проекте. 10 советов

    заменить QA инженера девелопер не может

    а чому тоді у лідерів ринку (Google, Microsoft) практично немає тестувальників ?

  • Как выжить, если ты один QA на проекте. 10 советов

    Это специалисты разного профиля

    ось в цьому і проблема. Ми починаємо розділяти обов’язки між людьми, створюємо ролі і тд і тп. І у нас виходять учасники проекту які не знають як працюють їхні колеги. І у нас виходить команда, де кожен знає лише свою маленьку пісочницю і нічого не знає про проект в цілому. І це проблема

    читал и о ровно противоположных по смыслу

    Ви бачите процес з чітко розподіленими ролями і відповідальностями. Десь як у 90-тих, там воно працювало бо середовище таке було.У сучасному швидкому світі все йде до спільних відповідальностях та розмитих ролях — DevOps, FullStack development і тд і тп. І все тому, що потрібно швидше і швидше роботи delivery. Практики 90-тих вже не працюють
    Якщо дев не розуміє як тестувати — результат його роботи буде важко тестувати, або і взагалі неможливо. Йому пофіг як хтось буде виконувати тестування, він свою роботу зробив. Якщо дев повинен ще і тестувати свою роботу — йому доведеться зробити її так, щоб можна було тестувати.

    Поддержал: Sergey Sheshenya
  • Как выжить, если ты один QA на проекте. 10 советов

    та ок. але хороший девелопмент опирається на тестування. І будь який хороший девелопер займається тестування, на тому чи іншому рівні. Хтось пише юніт тести, а хтось e2e тести. Це все тестування. Багато девів також перевіряють свої зміни ручками.
    Тому, не завжди потрібна окрема людина для тестування

    Это не ок, поймёте это позже)

    багато команд можуть працювати без окремих тестувальників без проблем
    Та і взагалі за цим майбутнє — continues testing, shift-left testing і тд це тенденції які не хочуть бачити окрему людину, яка тестує, а пропонують тестувати всі команді, на всіх рівнях

  • Как выжить, если ты один QA на проекте. 10 советов

    unit testing\TDD — це не mindset девелоперів ?

  • Как выжить, если ты один QA на проекте. 10 советов

    Не могут

    чому ?

  • Как выжить, если ты один QA на проекте. 10 советов

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

  • Как выжить, если ты один QA на проекте. 10 советов

    Это не ок

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

  • Як за допомогою тестів пришвидшити реліз

    воно обов’язково наєбнеться в наступному кварталі

    власне, ось ці всі тести допомагають відтермінувати наступний квартал

  • Як за допомогою тестів пришвидшити реліз

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

  • Як за допомогою тестів пришвидшити реліз

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

  • Як за допомогою тестів пришвидшити реліз

    трохи не зрозумів, до якого саме твору йде відсилка ? і якої цитати ?

  • Як за допомогою тестів пришвидшити реліз

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

  • Як за допомогою тестів пришвидшити реліз

    100% покриття коду не гарантує те, що все покрито. Рядки коду то покриті, а чи всі вхідні дані ?
    Для кінцевих користувачів без різниці скільки і які у вас тести. Тому, краще зосередитись на основних та критичних бізнес сценаріях

    Поддержал: Kyrylo Romanenko
  • Як за допомогою тестів пришвидшити реліз

    аби дешевше вийшло

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

  • Як за допомогою тестів пришвидшити реліз

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

  • Performance of Performance Testing tools

    я проганяв всі тести по 3 рази

    оо. хотів запропонувати це. а в таблицях середній результат за всі прогони ? чи якоїсь однієї ?

    від реалізації http клієнту та багатопоточності

    скоріш за все. + можливо, ще метрики по різнову оцінюються. Я колись копав у доках Jmeter, то там Response time рахується від надсилання першого пакету tcp, до отримання першого пакету. Можливо інші тули це по іншому рахують

    Поддержал: Oleksii Ostapov
  • Performance of Performance Testing tools

    круто ! дуже крута стаття ! Сам давно цим цікавлюсь і думав над подібним проектом.
    Дуже дивно побачити такі відхилення по RPS та response time. Цікаво би знайти корінь проблеми і як зрозуміти, що ці дані корелюються з реальними метриками кінцевих користувачів.
    Моя думка, що це може бути проблема з NAS або мережею. Було би круто задеплоїти кудись в клауди і спробувати там

    Поддержал: Oleksii Ostapov
← Сtrl 123456...53 Ctrl →