В моем опыте на долгосрочную перспективу - такие разработчики сваливали или их увольняли в итоге. Если им настолько все равно, что они там пишут и как это потом поддерживать.

У нас там менеджеров было как у майкрософта. Многие не представляли процесса разработки и не пытались даже. На тимлида жалобы писали, что говорит непонятными словами и выставляет их дурами :D

Тут вот минуток 5 посидишь и сразу хочется подойти к своим разработчикам и расцеловать их и сказать, какие они у нас замечательные. :)

Тут вот минуток 5 посидишь и сразу хочется подойти к своим разработчикам и расцеловать их и сказать, какие они у нас замечательные. :)

На прошлой работе из 11 программистов было 2, у которых почти никогда не было багов в коде. Разве что опечатки. Но они и задачи делали дольше. А был один товарищ, у которого таска за час проскальзывала из очереди в тестинг, а потом ещё неделю возвращалась на доработки, потому что вот реально вообще ничего не работало. Как ломом по проекту проходил – одно делал, в трёх местах ломал. Зато быстро

именно, программисты могут выдать полностью рабочий продукт без участия "непрограммистов". я ничего не сказал про его юзабельность, карсоту, ништяки и что угодно ещё. просто как факт - программисты могут предоставить полностью рабочий, выполняющий ТЗ продукт без участия тестировщиков. что никак не противоречит тому, что в процессе разработки тестировщик - равноправный участник процесса. если вы не видели рабочих продуктов от программистов в командах без тестировщиков - ну ок. безбажных - очевидно не видели, хотя вроде есть ЛаТеХ, ага, но абсолютно точно существуют продукты разработанные в командах без QA и работающие так, как задумано и не крешащиеся и не убивающие систему и даже с норм интерфейсом. а тут вот мнение типа "ой, да программеры без нас никто" - ну это вы чо - серьёзно?

а вы что, серьезно называете бажный продукт рабочим?

это ж не предположение, это аксиома тестирования

багзилла это уже эребор. Редмайн хотя бы.

я в жизни очень часто сталкиваюсь с плохо протестированными (или совсем не тестированными) продуктами, и мне как пользователю очень неприятно

винда, иос, андроид, мсофис и ваще все большие продукты релизятся с десятками, если не сотнями тысяч задокументированных багов, в том числе и репортнутых кастомерами, вы не пользуетесь софтом вообще?

да, тестер должен минимизировать количество незакрытых дефектов

пользуюсь конечно, и уверена, что у этих компаний огромные куа отделы

бесспорно огромные и количество багов в их продуктах огромно

куа лид в курсе экзит критерии? приоритизации? оценивания более и менее важных функциональностей продукта?

> Max есть успешные проекты без тестировщиков, в как правило это стартапы с минимальной фунциональностью

и добавлю про "написанный код" - вы представляете как выглядит код в энтерпрайз продуктах с циклом жизни 10-15 лет, например? это просто склад многоэтажных заплаток

Ещё на память пришла история Андрея Солнцева (selenide), он хвастался что вполне себе живут хорошо без тестеров, выполняя тестирование самостоятельно

Ещё на память пришла история Андрея Солнцева (selenide), он хвастался что вполне себе живут хорошо без тестеров, выполняя тестирование самостоятельно

В маленьких командах так можно делать, наверное.

ну, много способов первый, которому я учу своих ребят - это не быть заложником менеджера везде по-разному, но общая практика такова, что добро на публикацию (в базовом варианте - информацию о соответствии качества релиза ожиданиям) дает отдел qa далее уже вопрос того, как тестера уболтает менеджер, которому нужен срок, а не качество иногда надо повоевать, иногда - просто упереться, иногда - договориться и объяснить все от квалификации тестера зависит, в общем

ну есть чем хвастаться, конечно, но практика плохая

Trello как багтрекер!)

ситечко же лучший багтрекер в мире =)

Почему плохая? Наличие тестера на проекте делает его хорошим? Как талисман?

ну, много способов первый, которому я учу своих ребят - это не быть заложником менеджера везде по-разному, но общая практика такова, что добро на публикацию (в базовом варианте - информацию о соответствии качества релиза ожиданиям) дает отдел qa далее уже вопрос того, как тестера уболтает менеджер, которому нужен срок, а не качество иногда надо повоевать, иногда - просто упереться, иногда - договориться и объяснить все от квалификации тестера зависит, в общем

А маленькие команды масштабировать до больших

нельзя всё под одну гребёнку, ситуации бывают разные

плохая практика самим тестировать то, что писали

коллега, это спорное утверждение, вернее та его часть, которая "в любом корпорейт проекте" мой опыт мне говорит о том, что бывает совершенно по-разному

и что это доказывает?