Советую Вам удалиться с такими предложениями.

Вставлю и свои 5 копеек.

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

    Случай 1:

После разговора с фронтенд разработчиком, мне был дан ясный ответ:

"Если нужно поправить верстку, было бы отлично чтобы было указано что и насколько сместить/отодвинуть/добавить отступ и т.д"

    Случай 2: 

После общения с бэкенд разработчиком, ответ был немного иначе:

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

Правда есть и те кому пофиг, но это уже отдельная тема.

Как всегда, вывод один: Прежде чем что то менять в подходе к описанию/копания бага, спросите разработчиков, надо им это или нет.

Если идею никто из разработчиков не поддерживает, то это бесполезный выхлоп для компании который влечет потерю времени(как для себя это вполне годный скил в любом случае).

А есть смысл начать с тестировщика ПО, понять суть работы программ и перейти в программирование, просто я поставил такую цель и думаю стоит ли переходить или остаться в тестирование. Зарплаты у программистов вроде как побольше.

Ну да, больше(сарказм)

я создаю такие баги.

Создавать баги это круто 

Удаленной возможности сертификации не предусмотрено?

Огромное спасибо за этот маленький, но очень полезный сервис.

Обязательно покажу менеджерам, чтобы им было легче 

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

Лично стараюсь перечитывать то, что написал в баг-репорте.

Такую же рекомендацию даю менеджерам.

"Мы ответственны за то, что мы завели." 

В чем хочу в том и хожу. У нас даже есть разработчик, который ходит в пляжных шортах, майке и шлепках. 

По поводу воспитания хочу рассказать свой пример.

Менеджеры проектов очень любят на все что им видится багом заводить репорты. При этом зачастую они просто не разобрались как это должно работать.

Они не понимают что такое "Ожидаемый результат".

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

Примерно такой слоган написал: "Мы ответственны за что, что мы завели" 

Когда презентовал эту статью разработчикам, менеджерам и руководству, предложил такую мотивацию:

"Если баг-репорт написан без соблюдения этих рекомендаций, то разработчик оставляет комментарий

"Неправильная формулировка баг-репорта" и не берет в работу до того, пока автор репорта не сформулирует в соответствии с рекомендацией."

Результат:

Оформлять репорты стали более понятно, как для разработчика так и для тестировщика.

Самые честные менеджеры стали уточнять у тестировщика или разработчика как это работает.

Остальные читерят такой фразой в скайпе: "Подойди пожалуйста". При этом не говорит зачем 

Как то так.

Есть весьма хорошая книга про "узкие звенья" в процессах.

"Элияху Голдратт Цель - непрерывное совершенствование"

Пошел на почту получать   IT-календарь 2016: типы багов

Принес распечатку с багом 

Немножко грубовато, но оставлю это здесь.

Вы все правильно поняли.

Можно так:

(//*[@class = 'x-column-header-text'])[1]

(//*[@class = 'x-column-header-text'])[2]

(//*[@class = 'x-column-header-text'])[3]

Можно еще так:

//span[contains(text(), 'Код')]

//span[contains(text(), 'Код СКК')]

//span[contains(text(), 'Наименование')]

И название полей укажите пожалуйста =)

Добрый день!

Выложите код страницы на которой этот элемент

Для "Группа продавцов"

(//*[@class = 'x-form-item-label x-unselectable x-form-item-label-left'])[1]

Можно еще так:

//*[contains(text(), 'Группа продавцов')]

И так

(//*[@class = 'x-form-item-input-row']//label)[1]

Для "Офис"

(//*[@class = 'x-form-item-label x-unselectable x-form-item-label-left'])[2]

Можно и так:

//*[contains(text(), 'Офис')]

И еще так

(//*[@class = 'x-form-item-input-row']//label)[2]

будет тогда для этих инпутов так:

(//*[@class = 'x-form-field x-form-text'])[1]

(//*[@class = 'x-form-field x-form-text'])[2]

(//*[@class = 'x-form-field x-form-text'])[3]

гуглить не пробовали "водопадная методология" и "тестирование калькулятора" ?

Алексей, спасибо за пояснение.

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

Судя по количеству вопросов от стажеров - нет.

Опираясь на Ваше мнение - нет.

Вывод очевиден. 

Недавно на одном из приложений для IOS ввел всем известный набор символов "لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ

冗" - ничего не произошло. Но если удалить 2 последних символа то приложение падает, актуально для iphone 5s.

У знакомого IOS разработчика от этого набора символов xcode повис =)

P.S. Фейсбук запрещает публиковать этот текст

 

Антон, по первому пункту про отсутствие (или низкое качество) документации ситуация явно выходит за рамки обсуждения книги :). Если вернуться к контексту, то:
1) Я рассматриваю обучение "совсем начинающих" по аналогии с автошколой: сначала учим ПДД и "как правильно". Если есть желание ездить как в "Mad Max: Fury Road", то это это будет потом, в особых случаях при понимании и осознании всех условий и последтвий.
2) У начинающих тестировщиков и так часто бывает ступор, но информация о документации даёт хотя бы какой-то ориентир. Даже если документации нет: появляются идеи о том, какие вопросы задавать.

3) Чем больше будет людей, которых "с пелёнок" приучали к адекватным процессам, тем быстрее эти процессы станут адекватными. Да, не сразу. Но если ничего не предпринимать, ситуация точно не будет улучшаться.

 

1. Для начала, как мне кажется, нужно сначала показать новичку "автомобиль" и "дороги", чтобы он сам задал  правильный вопрос: "А как ездить по дороге?".

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

3. Абсолютно согласен, что надо приучать "с пеленок". Правда можно донести до читателя(новичка), что бывает не всегда так и стоит стремиться к таким "адекватным процессам".

Святослав, лично для себя считаю эту книгу весьма полезной, как справочник.

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

Я не имею такого опыта, как у вас, в прокачке 150-200 человек в год. Возможно в этой ситуации книга полезна.

Цель критики в адрес книги - сделать ее более понятной для новичков, так как информация в ней действительно полезная.