Сообщений в теме: 163

[Case]

Вон, у Case даже тренинг есть - RoboMonkey или что-то типа того. Вячеслав, обижался кто-нибудь?

Вообще-то RoboMonkey тренинг про карьеру. Я просто не понял как оно по контексту в эту тему :)

[Clauster]

умение их предотвращать

Своевременное нахождение и есть предотвращение. А само предотвращение скорее работа аналитика и девелоперов.

Например нашли вы багу с утечкой памяти, переполнением буфера и т.п. Будете ли вы выявлять места где эта бага может всплыть (даже если это не ваша область\проект\продукт и т.п.) или это забота аналитиков с разработчиками? Кстати, выяснение таких моментов очень важно на собеседовании для оценки зрелости кандидата как специалиста.

[Bars Master]

ворвусь, я поддержу тех, кто писал, что работа тестировщика это не нахождение багов, и оценка работы это не колличество нахождения оных, Последнее все равно, что оценивать труд Рубенса и Микеланджело в килограммах потраченной краски. (с)

[SALar]

Потому что для выяснения подходов и знания области не надо давать кандидату тестировать программу. Это выясняется на бумаге на раз-два при помощи абстрактных (раз вы любите это слово) задач.
- за то время пока вы будете оценивать кандидата при помощи программы, можно успеть разобрать несколько таких задачек, уделив каждой минут 15-20.
- на выходе у вас список багов а не "подход к тестированию и знание области тестирования"
- вы не знаете как человек тестирует программу, какие модели строит в голове
- поиск ошибок в программе это лишь часть работы тестировщика
- условия задач могут варьироваться как угодно и даже в процессе разбора
- сколько времени надо чтоб научить человека тому что надо "использовать сниффер для проверки запросов и ответов"? Вы думаете это действительно важное знание тестировщика?
- извините, времени жалко дальше писать, надеюсь, суть донёс

Действительно, мало кто задумывается, что может быть важнее в тестировщике, чем уметь искать баги и писать баг репорты? Разве не может, к примеру, аналитик искать баги, или даже ПМ, а я ещё знаю (прости, господи!) разработчиков которые не хуже других тестировщиков могут баги искать (и что интересно, ищут).

Вообще-то у коллеги Clauster-а вполне грамотная позиция, потому как "находить баги" вообще не является ни задачей, ни целью тестирования ПО. Один из результатов тестирования - да, но не более того. Я бы даже чуток преувеличив сказал, что баги это "шлак", который получается при обработке "породы" (если проводить аналогию с добычей угля, к примеру): то есть баги то есть, но мы не их ищем, когда продукт тестируем.

Вот это в мемориз. Есть комсомольцы, которые в статью оформят?

[Clauster]

Вон, у Case даже тренинг есть - RoboMonkey или что-то типа того. Вячеслав, обижался кто-нибудь?

Вообще-то RoboMonkey тренинг про карьеру. Я просто не понял как оно по контексту в эту тему :)

Ну как же:

РобоМартышка™ (RoboMonkey™) — послушный и тупой исполнитель. «Мечта» некоторых работодателей. Удобен ограниченному менеджеру и недалёкому начальству. Управляется просто, верит словам, для чего отращивает большие уши. В возрасте 35-40 лет понимает, что пора сваливать и открывает ларёк проклиная всё-на-свете и этот .... IT в первую очередь!

Я в том же самом контекте имел ввиду. UI-мартышка — послушный и тупой исполнитель. «Мечта» некоторых работодателей. Удобен ограниченному менеджеру и недалёкому начальству. Управляется просто, верит словам, для чего отращивает большие уши. И т. д.

[Clauster]

Спорно. Во первых, анализ найденных багов может помочь в определении подхода. А знание области тестирования не всегда есмь требование к кандидату:) Для меня идеальный кандидат в тестеры это сисадмин (больше как склад ума), который догадался прочитать хелп в тестовой программе, найти дефектов больше чем можно было бы благодаря этому хелпу и оформил их, письменно и устно понятно изложив суть дефекта и шаги его воспроизведения. Я без риска возьмусь за неделю довести до него всю остальную базу:)

Тестировать по хелпу это примерно как удалять гланды ректально (через задний проход). Откуда мне знать что Хелп верен?
Для меня идеальный кандидат это инженер службы поддержки. Я и сам оттуда и ещё двоих действительно классных тестировщиков знаю лично.

[Case]

Вообще-то у коллеги Clauster-а вполне грамотная позиция, потому как "находить баги" вообще не является ни задачей, ни целью тестирования ПО. Один из результатов тестирования - да, но не более того. Я бы даже чуток преувеличив сказал, что баги это "шлак", который получается при обработке "породы" (если проводить аналогию с добычей угля, к примеру): то есть баги то есть, но мы не их ищем, когда продукт тестируем.

Вот это в мемориз. Есть комсомольцы, которые в статью оформят?

Дык, у меня это в тренингах от лекции к лекции проходит пунктирной ниткой.

[Case]

Я в том же самом контекте имел ввиду. UI-мартышка — послушный и тупой исполнитель. «Мечта» некоторых работодателей. Удобен ограниченному менеджеру и недалёкому начальству. Управляется просто, верит словам, для чего отращивает большие уши. И т. д.

А, теперь понял.

[Clauster]

Дык, у меня это в тренингах от лекции к лекции проходит пунктирной ниткой.

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

[Case]

Не всегда. Маерс, "Арт оф софтваре тестинг", "Тестирование - деятельность с целью обнаружения ошибок". Так оно и кочует от тестера к тестеру.

[Clauster]

Не всегда. Маерс, "Арт оф софтваре тестинг", "Тестирование - деятельность с целью обнаружения ошибок". Так оно и кочует от тестера к тестеру.

Ну это уже средневековье по меркам IT :) Тогда ещё не было ни коврового бомбометания, ни танковых клиньев...

[astenix]

Case правильно говорит - это основы.
Другое дело, что их считают ошибочными.

[Green]

Вообще-то у коллеги Clauster-а вполне грамотная позиция, потому как "находить баги" вообще не является ни задачей, ни целью тестирования ПО. Один из результатов тестирования - да, но не более того. Я бы даже чуток преувеличив сказал, что баги это "шлак", который получается при обработке "породы" (если проводить аналогию с добычей угля, к примеру): то есть баги то есть, но мы не их ищем, когда продукт тестируем.

Вот это в мемориз. Есть комсомольцы, которые в статью оформят?

Дык, у меня это в тренингах от лекции к лекции проходит пунктирной ниткой.

Коллеги!
Не сочтите за труд, растолкуйте убогому.

Если нахождение дефектов не является целью работы тестировщика, то какова его цель?
(Если это оффтоп, то согласен на другую ветку.)

[Yuliana]

Wow, сколько полезной инфы
Спасибо всем за комменты:)) Но я осилю только последнюю страничку.

Например нашли вы багу с утечкой памяти, переполнением буфера и т.п. Будете ли вы выявлять места где эта бага может всплыть (даже если это не ваша область\проект\продукт и т.п.) или это забота аналитиков с разработчиками?

Буду. Заметьте вы сами пишете, что путь к предотвращению лежал через первое нахождение:)

Откуда мне знать что Хелп верен?

Во время теста для приема на работу, в зависимости от сложности теста, это единственная документация которая выдается:) Поверьте, бывают работники со стажем, которые не догадываются туда глянуть.

Но мы ведь уже крутые спецы, зачем нам читать главы для новичков

Запишите себе где-нибудь с пунктиром - крутые спецы умеют себя сдерживать:)))

Конечно же вы с радостью возьмете на работу тестировщика цитирующего Шульмейера и Хорша:) Зачем он должен уметь находить и репортить баги? Зачем?? Это же так вторично

[dlg99]

Например нашли вы багу с утечкой памяти, переполнением буфера и т.п. Будете ли вы выявлять места где эта бага может всплыть (даже если это не ваша область\проект\продукт и т.п.) или это забота аналитиков с разработчиками?

Буду. Заметьте вы сами пишете, что путь к предотвращению лежал через первое нахождение:)

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

1. анализ. Анализ кода (code reviews), паттернов в найденных багах и инцидентах в тех.поддержке.
2. поддержание и улучшение процесса разработки (например, на основании результатов п.1)
2.1. использование правильных, полезных практик в процессе разработки - TDD, unit tests etc.

по-моему, что-то забыл, ну да ладно пока что.

Откуда мне знать что Хелп верен?

Во время теста для приема на работу, в зависимости от сложности теста, это единственная документация которая выдается:) Поверьте, бывают работники со стажем, которые не догадываются туда глянуть.

забудьте про Вашу песочницу на секунду.
попробуйте протестировать, например, web search engine (live.com, google, yandex) базируясь только на том хелпе, который для них доступен.

некоторые "работники со стажем" долгое время тестировали приложения для которых хелпа нет в принципе. и не будет никогда.
или он был, но для тестирования, например, бекенда, просто бесполезен.

Опять-таки, при собеседовании этот одиночный факт недостаточен для того, чтобы сделать какой-либо вывод вне контекста опыта человека и впечатлений от остального интервью.

[Yuliana]

забудьте про Вашу песочницу на секунду.

Речь шла о задаче которую я даю при собеседовании.

Опять-таки, при собеседовании этот одиночный факт недостаточен для того, чтобы сделать какой-либо вывод вне контекста опыта человека и впечатлений от остального интервью.

А где я утверждаю, что этот одиночный факт мне достаточен для таких выводов?

[Case]

Если нахождение дефектов не является целью работы тестировщика, то какова его цель?

Я за эти определения.

Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

Обобщённо. Тестирование – процесс проверки соответствия заявленных к продукту требований и реально реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом.

PS
Green, заинтригован – революцию задумал?

[Case]

Конечно же вы с радостью возьмете на работу тестировщика цитирующего Шульмейера и Хорша:) Зачем он должен уметь находить и репортить баги? Зачем?? Это же так вторично

Когда ваш приступ веселья минует, попробуйте подумать вот над чем.

Сколько в этом форуме ошибок? (Хелп дать?)
Если мы потестируем, найдём и исправим 10 ошибок (2 критикал, 3 важных и 5 тривиальненьких) - сколько ошибок осталось?
Меня как клиента волнует сколько вы нашли или сколько осталось?
Как выдумаете, меня как клиента вообще волнует как вы описываете баги?
Скажите мне, пожалуйста, после проведённого выше раунда тестирования - форум как Продукт можно выпускать в продакшн и продавать мне как клиенту?

Пока вы не отвечаете мне как Клиенту или как Менеджеру Проекта в каком состоянии сейчас Продукт, мне вообще сиреневенько сколько усилий вы там куда-то потратили и насколько вы красиво описали баги. Неожиданно?

PS
Стрёмно мне, коллеги, когда такие тест-менеджеры, таким образом тестеров отбирают. Напоминает какую-то притчу про колонну слепых, которые идут вперёд положив друг-другу руку на плечо. Когда первый уже летит в пропасть, 2 только догадывается, а 3 топает себе уверенно.

[Case]

Речь шла о задаче которую я даю при собеседовании.

Хотите я вам дам задачку, ну так - размяться немного в форуме?

[Clauster]

Во время теста для приема на работу, в зависимости от сложности теста, это единственная документация которая выдается:) Поверьте, бывают работники со стажем, которые не догадываются туда глянуть.

Хелп это не документация, это часть продукта которая потенциально содержит баги и должна быть протестирована.

Запишите себе где-нибудь с пунктиром - крутые спецы умеют себя сдерживать:)))
Конечно же вы с радостью возьмете на работу тестировщика цитирующего Шульмейера и Хорша:) Зачем он должен уметь находить и репортить баги? Зачем?? Это же так вторично

Не надо передергивать и соскакивать на личности когда кончаются аргументы. Пример нашей задачи на собеседовании я привел. Иногда мы просим кандидата описать тестирование (типа чек-листа) области какого-нибудь устройства, в котором, как ему кажется, он хорошо разбирается (обычно это мобильник, калькулятор, банкомат и т.п.). По тому, как решаются такие задачи очень хорошо видно чего действительно стоит кандидат - модель, стратегия, приоритеты, техники, методики, bug advocacy и т.д. Как кандидат репортит баги нам абсолютно неинтересно - жизнь заставит репортить правильно.