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

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

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

    Случай 1:

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

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

    Случай 2: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат:

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

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

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

Как то так.

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

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

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

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

(//*[@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]

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

Добрый день!

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

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

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

Можно так:

(//*[@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(), 'Наименование')]

Вчера промелькнула новость , что ошибка при установке программного обеспечения привела к майскому крушению военного самолета в Испании – само ПО багов не содержало, а вот установка и использование в реальных условиях проверки не выдержали. Цена ошибки – 4 унесенных жизни и сотни самолетов этой модели, не допущенные к полетам в настоящий момент.

 

Тут уместно вспомнить про LightSail, беспилотный космический корабль на солнечных батареях, который недавно потерял связь с Землей из-за ошибки в софте, и только спустя несколько дней смог перезагрузиться и возобновить обмен данными.

 

Поделитесь, с каким наиболее критическим багом сталкивались лично вы в своей практике?

 

Из моего опыта (конечно, размах трагедии не тот) – баг в ММОРПГ, при котором сервер передавал право на определение того, что это за предмет, клиентской части. Багоюзер ловил пакет какой-нибудь дешевой бесполезной фигни, подменял его на что-нибудь ценное, а дальше производил с предметом ряд манипуляций в игре. При определенной последовательности манипуляций сервер начинал доверять клиенту и воспринимал предмет, как ценный. Баг был выловлен при обнаружении, что экономика сервера падает стремительным домкратом, так как ушлые игроки вовсю начали багом пользоваться. Последовательность действий с предметом была такая, что, наверное, ни одному тестировщику в страшном сне бы не привиделось это проверять.

 

Расскажите о своем опыте, интересно)

по поводу бага в ММОРПГ - это было в Lineage 2. Он в паблике очень долго висел.

2.2.2. Важность требований

Продуктная документация (product documentation, development documentation49) используется проектной командой во время разработки и поддержки продукта.

Она включает:

o План проекта (project management plan50) и в том числе тестовый план (test plan51).

o Требования к программному продукту (product requirements document, PRD52) и функциональные спецификации (functional specifications53 document, FSD54; software requirements specification, SRS55).

o Архитектуру и дизайн (architecture and design56).

o Тест-кейсы и наборы тест-кейсов (test cases57 , test suites58).

o Технические спецификации (technical specifications59), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.

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

- "А как тогда тестировать если всей этой документации нет?"

- "Бывают ли вообще проекты со всей этой документацией?"

- "А можно ли требовать это документацию?"

- "У кого ее требовать?"

На основе своих наблюдений пришел к выводу:

Начинающий тестировщик, прочитавший данную информацию, придет на свое первое место работы и просто впадет в ступор.

Впадет в ступор потому, что:

- документации всей может не быть

- вообще может не быть документации

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

- восприятие такой информации он может принять за общепринятую стандартизированную практику, которая применяется везде,

но в действительности это далеко не так.

Спросил отдел разработки о таком кол-ве документации. На что получил от сеньеров внятный ответ:

"пункты 2 и 5 достаточно часто бывают, 3 реже, но тоже делают"

Так же один из фронтендщиков сказал такое: "А зачем вся эта документация для сайта-визитки?". 

Вроде бы он пошутил, но на самом деле стоит задуматься.

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

Так же хочу отметить, что 8 этапов в разделе "2.1.2. Жизненный цикл тестирования" перенасыщает начинающего тестировщика

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

P.S. Все это исключительно личное мнение и наблюдение за своими стажерами.

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

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

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

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

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