leftCh

Считаю что нет ничего сложного, если у обучаемого есть мозги. Можно загрузить классами эквивалентности, но мое мнение что для первого этапа лучше обойтись без спец терминологии. Объясните ей, что тестер должен проверять все возможные пользовательские сценарии. Сядьте с ней рядом и проведите несколько тестовых сессий, когда она будет кнопки нажимать, а вы говорить, что именно надо протестировать, не забывая объяснять почему это нужно.

Но есть еще два варианта, которые не лечатся, и при которых поможет только увольнение: 1. Она просто ленится 2. Она считает себя умнее всех (тогда она просто не будет слушать ваши объяснения и требования)

Ууу, тут много что можно сказать ))) Про себя не буду говорить, скажу про тех кого учила тестировать последние полтора года:

Ошибка первая "Как много у них глупых правил! Но разве это важно?" или недостаточная внимательность к (казалось бы) мелочам. Например, забыл установить какой-нибудь пункт в багтрекере, описал баг не по правилам – все это ведет к затратам времени вашего "наставника", которому приходится за этим следить и исправлять (или заставлять вас исправлять) Он один, а вас таких много, да и других дел у него много.

Ошибка вторая "Я напишу об этом в багтрекере завтра". Вы, конечно, не поверите, но часто бывает так, что завтра уже поздно.

Третья ошибка "А я не знал". Как было сказано выше, надо спрашивать. Все и всегда. Недостаточная информированность ведет ко многим проблемам.

Ошибка четвертая "Я знаю модуль А, и не знаю модуль Б", то есть тестировщик не стремится изучать продукт. Даже если вы тестируете другую часть, вы все равно должны иметь представление о продукте в целом, о всех его темных закоулках, даже если сейчас не понимаете, зачем это нужно. Вы должны изучать продукт при любой возможности!

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

Шестая ошибка "Программисты у вас криворукие!". Обидная критика, так или иначе к вам вернется в виде внезапных проблем.

Привет ребята,
Интересно узнать о мифах о тестировщиках....

По себе знаю такие:
1. Тестировщик - недопрограмист
2. Чтобы стать тестировщиком, базового знания компьютера достаточно

Перефразирую:
1. Каждый тестировщик мечтает стать программистом, но не может
Многие могут, но не хотят
2. Тестировать может каждый, кто умеет пользоваться компьютером
Нет, тестирование требует как минимум способности к анализу

Добавлю:
3. Самое лучшее тестирование - это когда тестировщик не знает как устроена программа
Нет, некоторые баги можно найти при изучении внутреннего устройства. А еще знание внутреннего устройства помогает определить, как лучше всего тестировать
4. Тестировщик - это такой человек, который проходит тест кейсы
Далеко не всегда, например я вообще не прохожу тест кейсы
5. Автоматизация рулит!
6. Автоматизация только мешает!
5,6 без комментариев :)
7. Тестировщику нравится мучить программистов, указывая на их ошибки
Лично я таких не встречала. Предполагаю, что любая злонамеренность тестировщика повлечет за собой адекватный ответ разработчиков, а враждовать с ними невыгодно

Добрый день, форумчане.
Необходимо профессиональная подсказка и направление в области расчета трудозатрат на тестирование.

Есть ли какой-то шаблон и алгоритм подсчета трудозатрат для тестирования того или иного функционала? Что необходимо учитывать, а что нет ?

Я всегда думала, что этим занимается руководитель проектов. Но тут попросили меня, тестировщика, оценить свои приблизительные трудозатраты (наперед).
Буду благодарна за Вашу помощь, т.к. я даже не знаю с чего начать, чтобы потому не вышло так, что я рассчитывала на 15 часов, а вышло 115 часов.

С уважением.

Мое мнение, что тестировщик не может назвать цифру не обладая даром предсказания. Во-первых, почитайте здесь и можно попробовать дать почитать начальству
http://software-test...-taking-so-long
то есть время затраченное на тестирование очень сильно зависит от разработчиков и от того сколько ошибок они сделали

Во-вторых, бывают дефекты blocker - то есть делающие невозможных или крайне медленным дальнейшее тестирование. Таким образом тестировщик зачастую сидит и плюет в потолок пока программист что-то фиксит "по быстрому". Появление таких дефектов и время на их фикс предсказать заранее невозможно. Еще хотелось бы добавить, что программист может фиксить такие дефекты очень и очень неторопливо :) все зависит от человека и как он относится к работе.

В-третьих время на тестирование сильно зависит от количества разных поддерживаемых окружений (то есть на каких именно операционных системах (или браузерах для веб) должна работать программа, должна ли поддерживать разные форматы даты и времени и т д)

В-четвертых, на сколько "старый" код, требуется ли тестирование регрессии.

В-пятых, в-шестых, в-седьмых...

В общем какие-либо оценки можно попытаться сделать исходя из предыдущего опыта работы на подобном проекте с теми же самыми разработчиками. Если такого опыта нет, то можно попробовать взять время затраченное на разработку и фикс багов и поделить на два. Но тут проблема, разработчики часто (я бы даже сказала чаще всего) сами не могут дать внятных оценок и оценивают задачу в 40 часов, а реально получается 400. При таком раскладе, может быть, ваше начальство не поймет, что оценка на тестирование уже не 20, а превращается 200 часов.