🐞 П’ятнична флудильня для QA-спільноти #13. Що робити, коли ти — єдиний тестувальник на проєкті

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

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

Тема на сьогодні: Давайте поговоримо про те, що робити, коли ти — єдиний тестувальник на проєкті. У кого був такий досвід? Пишіть свої за і проти. Діліться досвідом в коментарях! 💬

У подкасті DOU для тестувальників, ведучі вже це обговорили. 🎧 Слухаємо їх відповіді тут.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Працював єдиним автоматизатором рік на одному проекті, а потім 2 на іншому. Деякі переваги є. Наприклад швидкість. Нема мітингів з командою, нема код рев’ю і інших обговорень. Не треба нікому допомагати. Від того рухаєшся швидше. Але. Ті самі плюси, які дають швидкість, сповільнюють там, де того код рев’ю не вистачило. Спочатку намагався сам собі робити, потім забив і пушив напряму в головну гілку. Робив деякі інструменти, які мені виглядали зручними, а потім прийшов інший інженер і йому воно вже було не так зручно і він мав рацію. Погляд зі сторони — то дуже важлива історія.
У відпустку сходити не так просто. Намагався обирати дати, коли не було релізів. Коли щось починає горіти, то в будь-якому разі кидаєш все, що робив — не дуже зручно. Рутину теж нема з ким розділити :) Ну і бас фактор ніхто не відміняв. Коли робиш в одні руки щось велике, то є додаткова відповідальність — а що буде с проектом, якщо я захочу піти.
Висновок — в команді краще :)
Ще дуже залежить від рівня спеціаліста. Якщо синіор може спроектувати рішення, яке потім сам зможе підтримувати, то спеціалісти нижчого рівня і досвіду можуть зробити рішення, які потім самі не зможуть підтримувати.

PS а можна цю п’ятничну історію робити не ввечері, а зранку, щоб флудильня все ж таки припадала саме на п’ятницю, а не на понеділок? )

Я був на одному з перших своїх проектів одним QA. Досвід цікавий, проте нікому не рекомендую такої історії коли ти джуніор, практично без досвіду. На щастя, на проекті досить «повільний» темп розробки, я встигав, попри основної діяльності на проекті, ще й додатково проходити онлайн курси. Може звучати досить смішно оскільки на проекті лише я QA, але налаштував процеси тестування на проекті) шкода, що менеджмент не помічав позитивних змін. Що в стало причиною зміни проекту.

Зробити собі футболку з цим принтом:
i.pinimg.com/...​d092ba74da3bd43b484d3.jpg
і ходити в ній на всі мітинги
:D

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

Не согласен не много, у нас есть разрабы как выше описано 1 к 4м, а есть один разраб, где наоборот. К одному приставлено 3/4 тестера и не успевают.

Підписатись на коментарі