@qa_ru
Вячеслав24.10.2017
08:00:29
08:00:29
созидание и разрушение
zombopanda24.10.2017
08:00:51
08:00:51
на самом деле изначально разница в разном мышлении и подходе, и вот этому очень сложно научить
Думаю, что Роман не воспринимает это как аргумент. Его уже вчера приводилиВячеслав24.10.2017
08:01:08
08:01:08
Роман вообще ничего не воспринимает, как я вижу
Prokop24.10.2017
08:01:19
08:01:19
Может это второй аккаунт шу?)
GoogleВячеслав24.10.2017
08:01:44
08:01:44
или первый %)
Anton24.10.2017
08:19:28
08:19:28
то, что вы пишете, лишено логики
нет никакой взаимосвязи между говнокодерами и наличием тестировщиков
проблема говнокодеров решается снижением удельного веса говнокодеров и ростом качества кодеров
проблема тестировщиков точно такая же, удельный вес говнотестеров, которые никогда не вникали в азы тестирования, не знают даже баз кодинга и как работает ПК железо, и считают, что тестирование - это написание и прохождение тестов побольше, чем говнокодеров, эту проблему вы будете решать как?
пока есть Говнокодеры готовые сделать работу Дешевле чем Хороший кодер - рынок будет наполнен Говнокодерами и Тестировщиками (разного уровня квалификации)
решать проблему monkey-тестировщиков - я не собираюсь никак ))
Обезьянки то же нужны этому миру для чего-то ))на мой взгляд подход "разработчик-сам-себе-тестировщик" имеет огромный минус - что этому человеку нужно иметь хорошую квалификацию как разработчику, так и хорошую квалификацию тестировщика, что бы оценивать свой продукт с точки зрения бизнеса/юзера/взломщика
а тут только человек с раздвоением личности с этим хорошо справится и никогда не попадет в ловушки мышления )
Вячеслав24.10.2017
08:24:03
08:24:03
хороший тестировщик - это специалист, который развивается долгие годы, и имеет так же технические навыки и знания, приобретает опыт. так же как и программист. и вот таких специалистов не заменить ситуацией "научу ко я программиста тестировать за собой"
Alexander24.10.2017
08:30:56
08:30:56
Alina24.10.2017
08:36:06
08:36:06
http://software-testing.ru/library/around-testing/management/2624-motivating-testers
Григорий24.10.2017
08:36:41
08:36:41
Все привет, я тут начал разбераться в WebdriverJS и вот столкнулся с токой проблемой. когда я запускаю тестовый скрипт открывается браузер делает то что надо, но вот куку почему то всегда обнуляются. Как можно добавить чтоб скрипт не обнулял куку при запуске браузера
Alina24.10.2017
08:36:45
08:36:45
http://software-testing.ru/library/around-testing/management/2651-encouraging-testers-to-share-testing
Вячеслав24.10.2017
08:38:26
08:38:26
Все привет, я тут начал разбераться в WebdriverJS и вот столкнулся с токой проблемой. когда я запускаю тестовый скрипт открывается браузер делает то что надо, но вот куку почему то всегда обнуляются. Как можно добавить чтоб скрипт не обнулял куку при запуске браузера
при старте браузера старт происходит "вчистую",без всяких кук и настроек. либо ставить куку и перезагружать страницу, либо делать профиль с кукойи уже стартовать с профилем
Максим24.10.2017
08:38:54
08:38:54
Все привет, я тут начал разбераться в WebdriverJS и вот столкнулся с токой проблемой. когда я запускаю тестовый скрипт открывается браузер делает то что надо, но вот куку почему то всегда обнуляются. Как можно добавить чтоб скрипт не обнулял куку при запуске браузера
гуглить "WebdriverJS cookie" пробовал уже? ?Григорий24.10.2017
08:41:47
08:41:47
гуглить "WebdriverJS cookie" пробовал уже? ?
да, ну думал тут профессионалы предложат вариант по лучше.Google
Ilya24.10.2017
09:10:00
09:10:00
ребята, как вы относитесь к переоткрытию багов в статусе Verified/Closed?
zombopanda24.10.2017
09:10:58
09:10:58
ребята, как вы относитесь к переоткрытию багов в статусе Verified/Closed?
у нас такое запрещено. если оно воспроизводится - заводим новый
Filipp24.10.2017
09:12:03
09:12:03
Richard24.10.2017
09:14:34
09:14:34
Завести новый, но в дескрипшне указать, что такое уже было и ссылку на закрытый тикет.
Nikolay24.10.2017
09:14:54
09:14:54
ребята, как вы относитесь к переоткрытию багов в статусе Verified/Closed?
тут смотря с какой стороны посмотреть, если баг действительно был пофикшен и таска с фиксом была заверифаена/закрыта то имхо такое переоткрывать не стоит
и если аналогичный баг позже всплыл снова, то надо делать новую с новым фиксомFilipp24.10.2017
09:14:57
09:14:57
Я обычно стремился организовать так, чтобы переоткрывать можно было из любого состояния. Тем более, что при желании тут получается интересная метрика. Но иногда меня ограничивал именно воркфлоу. Поэтому и интересуюсь
Nikolay24.10.2017
09:15:07
09:15:07
а если хреново проверили и заверифаили то тут мб и переоткрыть можно))
Vage24.10.2017
09:16:14
09:16:14
имхо, если при проверке багфикса баг воспроизводится - переоткрывать. Если баг был закрыт N фиксов назад, не воспроизводился некоторое время и снова всплыл - создавать новый баг с линкой на старый
zombopanda24.10.2017
09:18:40
09:18:40
имхо, если при проверке багфикса баг воспроизводится - переоткрывать. Если баг был закрыт N фиксов назад, не воспроизводился некоторое время и снова всплыл - создавать новый баг с линкой на старый
вот чаще всего оно так и всплывает. по крайней мере у насIlya24.10.2017
09:19:45
09:19:45
вот и у нас построили воркфлоу, где физически нет возможности переоткрыть закрытый
даже если это именно тот же баг всплыл
со словами, что это портит статистику
мне это неудобно для работы, собираю статистику других проектов и аргументы
Roman24.10.2017
09:21:36
09:21:36
Думаю, что Роман не воспринимает это как аргумент. Его уже вчера приводили
это очень устаревший скучный миф из нулевых, в который я тоже по молодости верилNikolay24.10.2017
09:21:50
09:21:50
о боже.. он снова вернулся...
Roman24.10.2017
09:22:32
09:22:32
ребята, как вы относитесь к переоткрытию багов в статусе Verified/Closed?
всегда переоткрывать, новые баги не писать ибо историяна самом деле изначально разница в разном мышлении и подходе, и вот этому очень сложно научить
нет никакого разрушения, ориентир должен быть на созидание, не нужно учить людей разрушать, нужно стратегически планировать и анализировать до того, как "накодить свой говнокод"Вячеслав24.10.2017
09:24:25
09:24:25
ну если "нужно", то конечно
GoogleВячеслав24.10.2017
09:24:35
09:24:35
нужно писать код без багов!
Sergei24.10.2017
09:24:39
09:24:39
нет никакого разрушения, ориентир должен быть на созидание, не нужно учить людей разрушать, нужно стратегически планировать и анализировать до того, как "накодить свой говнокод"
во вселенной без сроков выполнения задач это работаетRoman24.10.2017
09:25:08
09:25:08
в смысле? предварительный анализ сокращает сроки выполнения задач, а не увеличивает
Вячеслав24.10.2017
09:25:20
09:25:20
учитывая, что деятельность тестировщика может быть направлена не только на поиск ошибок, но и на улучшения удобства и прочее
нужно сразу все делать очень удобным и понятным
agile методологии тоже не нужны
Roman24.10.2017
09:25:45
09:25:45
Вячеслав24.10.2017
09:26:01
09:26:01
пользуется продуктом и дает обратную связь вместо пользователя
Vage24.10.2017
09:26:21
09:26:21
ТНН - тестирощики не нужны ??
Roman24.10.2017
09:26:32
09:26:32
Вячеслав24.10.2017
09:27:03
09:27:03
где же взять идеальных людей то
Roman24.10.2017
09:27:06
09:27:06
agile методологии тоже не нужны
разрабатывать огромные софтины с тыщами функционала по 5 лет на релиз нужно?Roman24.10.2017
09:27:16
09:27:16
для консьюмерского рынка? зачем?
Вячеслав24.10.2017
09:27:47
09:27:47
ну можно не пять лет, а два месяца например
Помоему Роман описывает идеальную ситуацию и говорит, что весь мир идет к ней
но вот ... НЕТ
GoogleВячеслав24.10.2017
09:29:56
09:29:56
так в чем ваша основная мысль в итоге?
Roman24.10.2017
09:30:52
09:30:52
есть понятие "оптимальной стратегии" и "good enough" принцип
Вячеслав24.10.2017
09:31:08
09:31:08
ну так это все основывается на людях
одно дело "надо так", другое дело, что людей то таких нет
помоему достаточно поработать в командах с хорошими тестировщиками и разработчиками разного направления, чтобы все понять =)
Roman24.10.2017
09:34:59
09:34:59
Вячеслав24.10.2017
09:35:22
09:35:22
но их не так много, чтобы покрыть вашу идею для ВСЕЯ АЙТИ ОТРАСЛЬЪ
Roman24.10.2017
09:35:57
09:35:57
это проблемы образования и того, что подход класса "этого нет и невозможно чтобы оно было" мешает правильному развитию
Вячеслав24.10.2017
09:36:42
09:36:42
правильного развития тоже не существует, потому что оно везде разное и опять же базируется на людях
Roman24.10.2017
09:37:43
09:37:43
но уже несильно, современные процессы почти все "оптимизируют" состав команд разработки и считают тестирование - активностью, а не человеко-позицией
Вячеслав24.10.2017
09:38:11
09:38:11
тестирование всегда было активностью, разве нет?
Zewa ?24.10.2017
09:38:13
09:38:13
ребята, как вы относитесь к переоткрытию багов в статусе Verified/Closed?
У нас к этому нормально относятся. Воркфлоу выстроен так, что в реопен можно из закрытых вытащить, так как не отдел тестирования был создан для воркфлоу, а воркфлоу для отдела тестирования :)Roman24.10.2017
09:38:18
09:38:18
правильного развития тоже не существует, потому что оно везде разное и опять же базируется на людях
речь о векторе, вектор достаточно понятенВячеслав24.10.2017
09:38:23
09:38:23
просто тестировщик делает его по другому
более глубже/лучше
потому что он полностью сосредоточен на этом
Roman24.10.2017
09:38:45
09:38:45
тестирование всегда было активностью, разве нет?
нет, я вот руководитель отдела тестирования, кодеров среди нас нетВячеслав24.10.2017
09:39:42
09:39:42
тестирование - активность, но слишком разная
Roman24.10.2017
09:39:43
09:39:43
просто тестировщик делает его по другому
с чего такие выводы? у вас есть опыт посадить кодера тестировать и посадить тестировщика тестировать один и тот же продукт, дать одинаково времени и потом сравнить?Вячеслав24.10.2017
09:39:51
09:39:51
конечно
GoogleВячеслав24.10.2017
09:40:06
09:40:06
хоть не продукт,а задачу
у нас в команде было принято решение, что часть задач тестируются теми, кто их делает. и ответственность полностью на них
при этом даже в этом случае разработчик понимал и говорил, что тестировщик сделает это лучше
Sergei24.10.2017
09:41:31
09:41:31
при этом даже в этом случае разработчик понимал и говорил, что тестировщик сделает это лучше
но у Романа не так, поэтому ты не прав!)Roman24.10.2017
09:42:16
09:42:16
нет, не теми кто делает, а внимательно:
берём продукт, который не кодил конкретный дев
1) садим тестить его (или фичу) кодера
2) садим тестить его (или фичу) тестировщика
допустим обое синьор левел и фичу оба видят впервые
Светлана24.10.2017
09:42:43
09:42:43
обое
Вячеслав24.10.2017
09:43:03
09:43:03
ну я считаю что у них просто будут найдены разные баги
Nikolay24.10.2017
09:43:07
09:43:07
зачем кодера заставлять тестить чужой код?
Вячеслав24.10.2017
09:43:29
09:43:29
а что за странная ситуация вообще?
Nikolay24.10.2017
09:43:46
09:43:46
это ситуация из какой-то другой реалии
реалии когда съел грибов и все такое хорошее и цветное вокруг
где кодера стоят на рынке дешевле тестеровщиков и все такое
очевидно, что Роман именно из такого мира ибо он про него уже давно рассказывает и всем это не понятно
Вячеслав24.10.2017
09:44:35
09:44:35
синьор тестировщик имеет огромный скилл по тестированию, задаст кучу вопросов и протестирует в любом случае глубже. потому что он этому учился долгие годы
в чем проблема то?
это как посадить рядом разработчика трактора и тракториста на новый трактор
чушь
Открыть в Telegram