Mac

Приходит директор по персоналу к генеральному за бюджетом на обучение сотрудников. Генеральный и говорит:
- Вот мы будем их учить, будем тратить на это деньги. А вдруг они после этого возьмут и уйдут?

 

Директор по персоналу отвечает:
- А что, если мы не будем их учить, а они возьмут и останутся?

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

 

На самом деле, приходится заниматься очень простыми вещами

 

1. Вытаскивать из болота потерявшихся в профессии. "Тестирование - это не перспективно". "Со мной не хотят считаться". "В моей компании к тестированию относятся как к никому не нужной деятельности". "Хнык-хнык-хнык".

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

3. Объяснять, чего же на самом деле нужно этим странным боссам. "Что от меня хочет босс, когда спрашивает сколько протестировали/когда релиз/почему так много тестеров/т.п? Я ему отвечаю, а он не понимает".

4. Одобрять решения. Людям очень часто на начальном этапе нужно, чтобы хоть кто-то одобрил их решение в виде "правильным путем идете, товарищ, молодцом, идите дальше"

5. И самое главное - слушать. Ментор - он как психолог, не станет показывать пальцем и смеяться над проблемами.  Зато даст выговориться, выпустить пар и самостоятельно выйти на возможное решение.

Михаила понимаю и поддерживаю. Puchoсk'а не понимаю. Просьбу топикстартеру рассказать чем все кончилось - поддерживаю.

Рановато у вас кризис среднего возраста наступил :)

В этой формулировке задача больше менеджерская, куда более простая и 60 минут - это как то слишком много времени на нее.

Мда. Попадись мне, тест-менеджеру с 8-летним опытом работы, эта задача на собеседовании, ответ был бы выдан за 10 секунд. "Спасибо, до свидания".

А собственно, почему? Ну вот мне надоело работать от забора до обеда.
Я хочу возможностей развития. Пусть не быстрого вертикального взлета, но хотя бы не сидения на одном месте. Год - это очень много для monkey clicking

Работать от забора и до обеда - вредно. Вообще, работать без мотивации - вредно. Только это совсем другая тема, не имеющая ничего общего с постом топикстартера.

А правда чтоли, что развитие - оно возможно только в автотестеры? А правда, что в автотестинге нет рутины? А правда, что там нет monkey coding и monkey autotests adoption to product changes?

А потом надоест - идем в разработчики. И займемся monkey bugfixing и monkey code refactoring. Хотя нет, разработка - это не наше. Идем в руководители. И займемся monkey meeting participation и monkey people motivation. Нет, лучше организовать собственный бизнес и заниматься monkey fundraising и monkey government authorities satisfying

;)

Автору - ваша текущая позиция "хочу многоденег, что для этого нужно знать?" заведомо проигрышна. Деньги просто за знания не дают. Для высоких зп нужно несколько больше:
1. Знания. "Я знаю Java"
2. Умения. "Я умею писать автотесты на Java"
3. Опыт. "Я умею писать автотесты на Java" vs "Я пишу автотесты на Java 10 лет"
4. Track record. "Я сделал движок автоматизированных тестов высоконагруженной биллинговой системы в заявленные сроки и этот движок успешно используется про тестировании <известного коммерчески успешного продукта>", и таких достижений несколько и по возрастающей. И желательно с рекомендациями от людей в роли заказчика.

Соответственно, ищите что вы такое интересное умеете, в чем у вас есть опыт. И продавайте это.

Нет такого? Увы, остаются варианты типа пойти в драг-дилеры. Или в грабители банков. Они, говорят, зарабатывают очень хорошо. Или продолжать набирать опыт.

- Допросите разработку с пристрастем. Какой API используется для работы со звуком? Какова по их мнению вероятность напороться на проблему с различием в работе этого API на разных битностях? Какие еще порблемы в связи с разной битностью ожидаются разработчиками?

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

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

По моему личному опыту, на данный момент приоритет должен быть каким-то таким:
1. W7 x64. Ибо именно такая в основном идет OEM с компьютерами и ноутбуками. 32бит остаются только людям со старым железом. Но они в основном предпочитают сидеть на XP (обжегшись в свое время на Висте)
2. XP x32. Приоритет такой же как у W7 x64. Ибо на XP сидят все домашние пользователи, кто по какой-то причине не захотел переходить на Vista/W7. Ну и в корпорациях она еще весьма распространена.
3. W7 x32
4. Vista x32
5. Vista x64
6. XP x64
Но этот "общие соображения". В вашем случае приоритеты могут быть совсем иными, в зависимости от вашей target audience.

- Соответственно, в общем случае имеет смысл тщательно тестировать W7 x64 и XP x32

- А на W7 x32 тщательно протестировать компоненты с высокой степенью риска. Например, инсталляцию. И пробежаться по низкорисковым компонентам в режиме дымового тестирования. И этим съэкономить время.

> Опытный тестировщик находит больше багов и это нормально, но если он находит намного больше багов, как быть тогда?

Баги сравнимы по серьезности? Пример: начинающий нашел два - и оба суть падения в базовых пользовательских сценариях, а опытный двадцать - и все минорные корявости UI на экранах куда 99% пользователей никогда не зайдет? Опытного - уволить нафик, начинающего перевести на зарплату опытного.

>Какова, по вашему мнению, нормальная разница между работой опытного и неопытного тестировщика?

Неопытный тестер не имеет в голове четкой системы, по которой тестирует. Найденные им баги - скорее случайность, и после его прохода вы, как менеджер, совсем не уверены, что багов не осталось. Поэтому, неопытным тестерам как правило поручают какую-то простую работу вроде регрессионного тестирования по готовым тесткейсам. Пусть учится и набирается опыта. Дать такому тестеру тестинг новой фичи (пусть даже по спекам) - себе дороже. Потом придется перепроверять его работу с помощью опытного тестировщика.

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

> И второй вопрос, если например, в требования что-то указано явно (даже додумывать не приходится), но при этом опытный тестировщик находит в этом месте баг, который пропустил неопытный тестировщик, то неопытный безнадежен?

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

Если вы ответили "нет" хотя бы на один из этих вопросов - он не безнадежен. Просто неопытен.