Здравствуйте, Mihal9, Вы писали:
M>Как вы относитесь к тестировщикам ПО?
С глубоким уважением как к людям с безграничным терпением и внимательностью к деталям.
M>Нужны ли они? Избыточны ли?
В настоящий момент они критически необходимы в производственном процессе разработки ПО. Некоторые аспекты ручного тестирования можно и нужно заменять автоматическими тестами, но в настоящий момент 100% ручного тестирования для пользовательских программных продуктов я не вижу как можно было бы заменить (ну или будет дороже чем ручное тестирование, наверно).
Здравствуйте, Mihal9, Вы писали:
M>Как вы относитесь к тестировщикам ПО? M>Нужны ли они? Избыточны ли?
Очень очень нужны. Именно из-за особенностей работы человеческого мозга, а именно:
1. Берут ответственность на себя, что позволяет тебе снизить уровень стресса. Работать в стрессе крайне тяжело. Вот, если из-за твоего косяка клиент может потерять миллион долларов — представь какой уровень стресса. А так тестеры берут всю ответственность на себя — косяк их, ибо они недосмотрели.
2. Тебе не нужно переключаться — переключаться очень тяжело и требует огромных ресурсов. Когда делаешь — это одна роль, а когда переходишь на другую сторону шахматной доски и проверяешь — то это другая роль. Переключаться между ними — требует огромного количества интеллектуальных ресурсов.
Здравствуйте, Mihal9, Вы писали:
M>Как вы относитесь к тестировщикам ПО? M>Нужны ли они? Избыточны ли?
Когда в CBOSS работал в первой половине 2000-х, палочкой-выручалочкой были. Там целых два подразделения были: модульное тестирование (тестирование конкретного приложения) и комплексное тестирование (тестирование системы в целом). Из комплексного тестирования вообще элитные вредители (звери своего дела) были, баги находили самые закамуфлированные, с опытом тестирования минимум четыре года. Некоторые из тестировщиков периодически в программерское подразделение переводились.
M>Из комплексного тестирования вообще элитные вредители (звери своего дела) были, баги находили самые закамуфлированные
И что потом?
Любой продукт размером больше чем hello world имеет столько открытых багов, что находить новые, тем более закамуфлированные, особо пользы нет... вот пофиксить — это совсем иное дело.
Здравствуйте, Shmj, Вы писали:
S>Дело вот в чем. Есть люди, который не способны переносить стресс. Очень часто креативность, способность создавать системы, способность писать код — у человека есть, а вот стрессоустойчивость равна нулю. Что делать в таком случае?
а баг этому неженке потом отдать фиксить можно? плакать будет ведь. Или у вас по голове бьют за баги в продакшене? S>Либо искать того, кто обладает всеми этими навыками + стрессоустойчивость в одном флаконе — либо перенести стресс на других. S>И вот ищем спец. людей, которые НИЧЕГО из вышеперечисленного не умеют, но зато обладают дюжей стрессоустойчивостью и способностью взять ответственность на себя. Называем этих людей — отдел качества — возлагаем на них всю ответственность, в т.ч. юридическую. S>Справедливость в том, что программировать они то не умеют — зато умеют брать ответственность на себя. Можно сказать что именно за то, что готовы взять ответственность — они и деньги получают.
по описанию чистый зицпредседатель фунт получается — ничего не могу, могу только тюрьму сесть если кто-то другой накосячил. S>А вся ответственность разработчика — уже сводится к количеству багов перед этим отделом качества.
мне кажется так не работает, баги в прод всё равно пройдут, особенно при отношении "моя хата с краю". Чинить их надо будет вместе, решать почему пропустили — тоже вместе.
S>Предварительное тестирование ты по-любому проведешь, но все кейсы перебрать — очень нудно.
Ну хоть так и на том спасибо. А может, написал бы автотестов и уже не очень нудно стало бы.
Здравствуйте, Pauel, Вы писали:
P>Пока тестировщик не документирую баг, вы ничего пофиксать не сможете, будете испытывать терпение юзеров
Это, кстати, может быть боль для разработчиков.
В одном из прошлых проектов было. Тестировщики видят что-то, что не вписывается в их картину мира не соответствует руководящему документу. И сразу бегут к разработчикам выяснять, что не так. Причем прямо к ним, миныя тимлидов и прочее начальство. Они не знают, кто писал код, потому напрягают всех. Какое-то время спустя выясняется, что тестировщики не умеют читать. Несоответствие было только в их воображении.
В какой-то момент разработчики почувствтвали облегчение. Оказалось, что у тестировщиков сменился тимлид. Прежнего сменила молодая девушка, и жизнь наладилась буквально сразу.
Тестировщик — друг разработчика. Но должен быть определенный порядок.
M>>Как вы относитесь к тестировщикам ПО? M>>Нужны ли они? Избыточны ли? S>Очень очень нужны. Именно из-за особенностей работы человеческого мозга, а именно: S>1. Берут ответственность на себя, что позволяет тебе снизить уровень стресса. Работать в стрессе крайне тяжело. Вот, если из-за твоего косяка клиент может потерять миллион долларов — представь какой уровень стресса. А так тестеры берут всю ответственность на себя — косяк их, ибо они недосмотрели.
Здравствуйте, AlexGin, Вы писали:
AG>Перешли в разработчики?
А кто сказал что делись? Просто это сравнительно легкая в освоении профессия, переизбыток. Так же есть возможность делегировать на сторонние конторы во многих случаях.
Здравствуйте, SkyDance, Вы писали:
M>>Из комплексного тестирования вообще элитные вредители (звери своего дела) были, баги находили самые закамуфлированные
SD>И что потом? SD>Любой продукт размером больше чем hello world имеет столько открытых багов, что находить новые, тем более закамуфлированные, особо пользы нет... вот пофиксить — это совсем иное дело.
Они ищут, ты фиксишь. Пока они хоть один баг находят, в продакшн не идёт.
M>>Из комплексного тестирования вообще элитные вредители (звери своего дела) были, баги находили самые закамуфлированные
SD>И что потом? SD>Любой продукт размером больше чем hello world имеет столько открытых багов, что находить новые, тем более закамуфлированные, особо пользы нет... вот пофиксить — это совсем иное дело.
Польза все равно есть. Чем больше знаешь о багах — тем более адекватное принимаешь решение о том, что фиксить сейчас, а что отложить до лучших времен.
Здравствуйте, Shmj, Вы писали:
S>1. Берут ответственность на себя, что позволяет тебе снизить уровень стресса. Работать в стрессе крайне тяжело. Вот, если из-за твоего косяка клиент может потерять миллион долларов — представь какой уровень стресса. А так тестеры берут всю ответственность на себя — косяк их, ибо они недосмотрели.
перекладывая всю ответственность на тестеров — вы перекидываете свой стресс на них, что тоже не хорошо и может приводить к проблемам. Качество продукта — общая забота и ответственность всей команды.
S>2. Тебе не нужно переключаться — переключаться очень тяжело и требует огромных ресурсов. Когда делаешь — это одна роль, а когда переходишь на другую сторону шахматной доски и проверяешь — то это другая роль. Переключаться между ними — требует огромного количества интеллектуальных ресурсов.
Но и кидать тестеру хрень, которая может и не работает — тоже трата ресурсов. Так что тестировать, то что сделал в какой-то степени приходится.
Здравствуйте, AntoxaM, Вы писали:
S>>1. Берут ответственность на себя, что позволяет тебе снизить уровень стресса. Работать в стрессе крайне тяжело. Вот, если из-за твоего косяка клиент может потерять миллион долларов — представь какой уровень стресса. А так тестеры берут всю ответственность на себя — косяк их, ибо они недосмотрели. AM>перекладывая всю ответственность на тестеров — вы перекидываете свой стресс на них, что тоже не хорошо и может приводить к проблемам. Качество продукта — общая забота и ответственность всей команды.
Дело вот в чем. Есть люди, который не способны переносить стресс. Очень часто креативность, способность создавать системы, способность писать код — у человека есть, а вот стрессоустойчивость равна нулю. Что делать в таком случае?
Либо искать того, кто обладает всеми этими навыками + стрессоустойчивость в одном флаконе — либо перенести стресс на других.
И вот ищем спец. людей, которые НИЧЕГО из вышеперечисленного не умеют, но зато обладают дюжей стрессоустойчивостью и способностью взять ответственность на себя. Называем этих людей — отдел качества — возлагаем на них всю ответственность, в т.ч. юридическую.
Справедливость в том, что программировать они то не умеют — зато умеют брать ответственность на себя. Можно сказать что именно за то, что готовы взять ответственность — они и деньги получают.
А вся ответственность разработчика — уже сводится к количеству багов перед этим отделом качества.
S>>2. Тебе не нужно переключаться — переключаться очень тяжело и требует огромных ресурсов. Когда делаешь — это одна роль, а когда переходишь на другую сторону шахматной доски и проверяешь — то это другая роль. Переключаться между ними — требует огромного количества интеллектуальных ресурсов. AM>Но и кидать тестеру хрень, которая может и не работает — тоже трата ресурсов. Так что тестировать, то что сделал в какой-то степени приходится.
Предварительное тестирование ты по-любому проведешь, но все кейсы перебрать — очень нудно.
Здравствуйте, SkyDance, Вы писали:
SD>И что потом? SD>Любой продукт размером больше чем hello world имеет столько открытых багов, что находить новые, тем более закамуфлированные, особо пользы нет... вот пофиксить — это совсем иное дело.
Пока тестировщик не документирую баг, вы ничего пофиксать не сможете, будете испытывать терпение юзеров
Здравствуйте, AntoxaM, Вы писали:
S>>Справедливость в том, что программировать они то не умеют — зато умеют брать ответственность на себя. Можно сказать что именно за то, что готовы взять ответственность — они и деньги получают. AM>по описанию чистый зицпредседатель фунт получается — ничего не могу, могу только тюрьму сесть если кто-то другой накосячил.
Может проверить и заявить — я все проверил и могу ответственно заявить что все работает, что ничего не пропустил. У тестера есть набор тесткейсов для проверки, понимание как все работает. Более опытные частично автоматизируют процесс с помощью спец. инструментов, иногда не дешевых.
В нашем проекте, когда мы делали большую часть (а не другие конторы), без системного тестирования было не обойтись. Банально, чтобы собрать и настроить тестировочное место надо столько всего знать, что это только выделенные люди могу исполнять на регулярной основе. Ни у кого из разрабов не было на столе системы достаточно полной, приближенной к продакшн. Теоретически, без можно было сильно сократить системное тестирование за счет кучи автоматизированных тестов отдельных компонент, привлечения эмуляторов/симуляторов, но в реальности это не работает, проще нанять сапиенса, чтобы он тестировал как можно ближе к условиям продакшена. Того же сапиенса, уже с опытом можно использовать в другом проекте, минимумом переобучения. А весь автоматизированный хлам придется выбросить.
Не обойтись без тестировщиков никак.
Здравствуйте, Shmj, Вы писали:
S>Дело вот в чем. Есть люди, который не способны переносить стресс. Очень часто креативность, способность создавать системы, способность писать код — у человека есть, а вот стрессоустойчивость равна нулю. Что делать в таком случае?
Прямо здесь и сейчас конечно же исправить не выйдет. Если стрессоучтойчивость низкая, то это нужно тренировать, и дополнять дисциплиной, планированием, итд. К сожалению, низкая стрессоустойчивать говорит о том, что сотрудник плохо управляет эмоциями. Рано или поздно это станет причиной проблем и в креативности, и в написании кода.
Здравствуйте, AntoxaM, Вы писали:
S>>Дело вот в чем. Есть люди, который не способны переносить стресс. Очень часто креативность, способность создавать системы, способность писать код — у человека есть, а вот стрессоустойчивость равна нулю. Что делать в таком случае? AM>а баг этому неженке потом отдать фиксить можно? плакать будет ведь. Или у вас по голове бьют за баги в продакшене?
В среднем, стрессоустойчивость у разработчиков слабовата по сравнению с другими специальностями. Издержки труда. У тестировщиков как правило больше коммуникации и по этой причине они в стрессоустойчивости натренированы лучше.
Здравствуйте, SkyDance, Вы писали:
M>>Они ищут, ты фиксишь. Пока они хоть один баг находят, в продакшн не идёт.
SD>Это что-то из серии "ночные мечты программиста". В реальности все обстоит, гм, слегка иначе.
Там альфу тестишь сам, бету тестировщики. Ещё и методику тестирования они с тобой согласуют. Контора была на 2500 человек, по другому нельзя было.
Здравствуйте, Pauel, Вы писали:
P>Прямо здесь и сейчас конечно же исправить не выйдет. Если стрессоучтойчивость низкая, то это нужно тренировать, и дополнять дисциплиной, планированием, итд.
Короче, процессы. Процесс может сильно помочь, подстраховать.
