“Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами…” – как раз строго наоборот, практика многих лет разработок чего бы то ни было говорит обратное: чем жёстче стандартизация и чем выше требования соблюдать изначальный дизайн от А до Я – тем выше качество результата. То есть если к разработке ПО применить методики разработки, к примеру, марсоходов или ядерных бомб – качество ПО возрастёт.

“В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития.” – и это адовая проблема, отсутствие жёсткого контроля за происходящим порождает беспредел. То есть не просто “контроля” – контроль как бы есть, но есть отличное мнение, что если раз дать откусить палец, то в следующий раз отгрызут руку, поэтому контроль быть жёстким, а отношение таким: налажал – отгребаешь. Я не ошибусь, если скажу, что сча весь код всего десктопного и мобильного софта состоит из говна и заплаток. Из всего софта, что я пользовал за последний год единственным решением, которое не содержало явных и очевидных глюков – это Вин8, причём чисто сама ось+вин эксплорер, без учёта метро-софта и родного десктопного софта – там ещё тот адок. И то – официально уже вроде 20 апдейтов или даже больше встало, но это всё таки ОСь – многкомпонентная система. А так то релизы один глюкавее другого, все соревнуются не в качестве, а в скорости выпуска, в результате софт превратился в бесконечный поток ширпотребного поноса, который вылетает, глючит и обновляется каждый день, потому что “нафига тестировщики нужны?” или потому что “мы всё сделаем по ХР и со Скрамом”. Мир сходит с ума, одни слушают Адель, Бибера и Леди Гагу, другие релизят каждый день новую версию продукта, потому что отладить, отдебажить и месяц-два потестить – нет времени. А о нормальном планировании я вообще молчу. Эхх, нет сча эффективного менеджмента, Ден Кеннеди абсолютно прав.

“Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). ”
дак я понимаю, речь же о том, что на них “мода” и их суют туда, куда нужно и не нужно и это крайне удручает

“По поводу свободы и вариантов реализации вы заблуждаетесь. ” – да ладно, хотите поспорить с Оруэллом? 😉 Вы ж не забывайте, что “незнание – сила” в дополнение к “свобода – это рабство”. То есть правильный подход – это когда те, кто разрабатывают – делают всё в жёстких рамках, а те, кто пользуются – максимально ограничены в возможности выбора и всё закрыто защитой от дурака и нет никакой информации о возможности что-то как-то менять. Шикарный пример – продукция компании Эппл.
“Но вероятнее всего из-за того, что вы не программист” – более того, я тимлид команды ручного тестирования (ибо у нас всё ещё команда автоматизации выделенная, правда это скорее плюс иначе если поменять структуру – весь тот хламовый код автоматизации пришлось бы переписывать с нуля, а там наверное уже даже миллионы, а то и ещё более строчек кода в силке). Продукт – движок и фронтенд распознавания речи, так что о простоте тут и речи быть не может.
“И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.” – если обрезать все двусмысленности, нечёткие трактовки и детализировать принципы работы системы, жёстко формализовать дизайн по всем аспектам, то реально если не 90, то минимум 80% тестирования, которое требует внешнего контроля (мануальное или полуавтоматическое, всё таки человеческий фактор убрать хрен получится, автотест не скажет “не удобно”) можно перевести в процессы до написания первой строчки кода, причём первая имплементация потребует больше тестирования, но чем дальше в лес – тем меньше будет требоваться прямого тестирования, при этом при планировании нового функционала или обновлений будет намного проще убрать лишние риски и уточнить реально важные детали.

А я предлагаю перестать считать тестированием “прокликивание” GUI (даже автоматическое) и чтение документации. Но это слишком сложная концепция, так что давайте продолжать дальше 🙂

в этом плане полностью поддерживаю Лёшу Лупана: нужно перестать называть автоматизацию тестирования автоматизацией и поменять подход. Автоматизаторы = программисты. Автоматизация = программирование. “Автоматизацией” должны заниматься программисты. Тестирование – это процесс поиска ошибок в конечном продукте, всё, что нужно – учить людей тестировать, потому что тестирование – это подход, который требует критической оценки кода/продукта и скептического отношения к работе продукта в целом (даже если кажется, что всё хорошо).
Правда вот я что понял: Николай всегда всё про интернеты и интернеты, но кроме “интернет-софта” есть ещё много другого разного и не везде ваши подходы (да и ваще эджайл) применим. А от повальной увлечённости Скрамом и Канбаном просто тошнит уже.
Впрочем я тоже считаю, что чистый Quality Control не нужен, Quality Assurance – то есть когда происходит реальное тестирование до написания первой строчки кода и убирается любая двусмысленность в том что и как нужно реализовывать и в каком порядке – это идеальный вариант. А потом тестирование чисто юнит-тестами и “автоматизацией” + небольшой QC перед релизом и всё ок.
Вообще у программистов должно быть минимум свободы и минимум вариантов для выбора как реализовывать. Свобода – это рабство, жаль, что всякие ратующие за “полёт творчества” в ИТ этого не понимают.

На основе наблюдений в нашей компании, согласен по всем пунктам 😉

Во первых спасибо что не евреи виноваты. Во вторых, вы должны это знать, что автоматизация применима далеко не всегда. В лучшем случае, на 30% проектов. Т.е она применима конечно же на 100% проектов, но полезный выхлоп будет дай бог с 30%. В любом случае рынок диктует свои условия, и на данный момент когда автоматизатор стоит как разработчик, всегда лучше взять разработчика.

Вообще выделенной команды тестировщиков даже без автоматизации стоит избегать