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