Хто і чому бісить тестувальників? Наболіло

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

Привіт! Мене звуть Маша і як сказав один представник DOU спільноти я за його словами «понтовита типу блогерша, до речі кинула ото «ваше айті»

Так, насправді я кинула айті, але не повністю. Я просто не працюю на конкретну компанію, я працюю на себе, розвиваючи свій блог. Доречі, заходьте в гості www.instagram.com/masha.it.travels

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

Я пропоную вам розслабиися та випустити пар і розказати в коментарях, що вас бісить найбільше. Не тримайте біль у собі, виплиснить все, тут вас зрозуміють:)

Отже, Тестувальника бісять інші тестувальники:

• Коли в баг-трекінгу створюють дефект без опису, тільки заголовок. Особливо після регресійного тестування без вказівки кроків, даних, оточення та інших важливих пунктів для відтворення помилки. А вже про логи, скріншоти та очікувані результати я промовчу.

Та розробники:

• Коли розробник віддає на тестування код, не перевіривши його хоча б мінімально. Наприклад, баг начебто пофіксили, але система після фіксау зависає. Начебто розробник прозвітував, що передав завдання в QA, але основний функціонал не працює. А ти марнуєш час, щоб зрозуміти, що твої зусилля були марними.
• Коли розробник не читає уважно степи в базі та повертає його як Cannot reproduced
• Бісить, коли доводиться вмовляти розробника зробити його роботу або вказувати, що саме він повинен пофіксити баг, тому що він його і створив
• Коли розробник кодить логування таким чином, що його неможливо розшифрувати.

І звісно ж менеджери:

• Бувають ситуації, коли щойно викотили складання на тестування і відразу ж помітні дефекти, а менеджер вже запитує, коли можна буде впровадити на продакшн. Звідки мені знати, скільки часу займе у розробника виправлення помилок? Я можу відповісти на запитання лише про тестування!
• Бісить, коли накидають завдання більше, ніж запланували спочатку спринта. Особливо коли це відбувається повз тестувальника. Менеджер накинув аналітику, аналітик проаналізував та накинув розробнику, а тобі потім прилітає це все тестувальнику. Хто, що, як, де і звідки це взагалі, ніхто не пояснив.

А також ВА або його відсутність:

• Відсутність хоча б мінімальної документації. Доводиться мати справу з невідомо як працюючим функціоналом. І незрозуміло: де баг, а де фіча? Та й взагалі дратує, коли недостатньо документації і нема в кого запитати чи складно знайти потрібну інформацію.
• Незрузуміла документація при живому ВА...

Команда та процеси:

• Коли немає згуртованості та ініативності всередині колективу: колега розуміє, що є проблема, але це його безпосередньо не стосується. І він не робить нічого, щоб якось допомогти.
• Бісить відсутність версійності у проекті — коли ти навіть не розумієш, яку збірку зараз тестуєш. І в баг-репорті не можеш вказати номер білда, де було знайдено дефект.
• Бісить, коли через стислий термін обирається швидке впровадження релізу та, таким чином, на шкоду якості. Без повноцінного тестування потім як завжди щось «вилезе»
• Бісить, коли тобі самій приходиться ті білди збирати, витрачати час на те, щоб зрозуміти, як пофіксити помилки сборки, хоча розробник зробив би це за 5 хвилин

Замовник:

• Бісить замовник, який не в змозі чітко сформулювати вимоги до продукту. Приходиться додумувати та пропонувати йому рішення кожен раз начебто ми не команда розробки, а креативна фокус-група.
• Бісить, коли замовник думає, що якщо на проекті є тестувальник, то він і відповідає за якість. Так, тестувальник відповідає за якість своєї роботи. А якість продукту відповідає вся команда!

Не айтішники:

Бісить, що далекі від IT, не сприймають роботу тестувальника серйозно. Мовляв, сидить такий нероб, кнопочки натискає цілий день — нічого складного.

А що вас бісить в роботі?