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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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. Все это исключительно личное мнение и наблюдение за своими стажерами.

Добрый день.

//*[contains(text(), 'Ваш текст')]

в "Ваш текст" пишите то что вам надо найти, но это не спасет при возможной дубликации указанного Вами текста на странице.

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

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

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

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

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

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

1. Стратегию тестирования описываю в тест-плане.

2. Работа отдела, Работы с ошибками, Написания сценариев и пр - это больше относится к внутренней документации отдела.

P.S. Это личные выводы.

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

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

    Случай 1:

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

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

    Случай 2: 

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

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

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

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

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

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

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

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

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

Работал как-то в игровой конторе.

Был багнутый навык:

Каждый 6 секунд в течении 1 минуты вводит персонажа в состояние невидимости.

Навык мог получить только 1-2 игрока на сервере.

Баг висел с момента открытия проекта, 2 года примерно. Писали разрабам(китайцам) - толку ноль. Ответ был в стиле: "Мы не можем его воспроизвести".

Баг заключался вот в чем: с определенной вероятностью крашатся клиенты у игроков которые видят игрока использующего этот скил.

Так как загруженность у меня была небольшая, мне дали его на тест. Время воспроизведения этого бага колебалось от 2 минут до 4 часов.

На сервере в логах не было этой ошибки.На клиенте в логах было много ошибок, но никто до этого не мог понять или не хотел ковыряться с этим.

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

Проблема была в анимации, так как пути к этой анимации, как и самой анимации попросту нет.

Отправил баг-репорт разрабам.

Они написали что у них все норм, но исходник анимации не предоставили.

По просьбе продюссера проекта начал думать это исправить.

Сделал то, что первое взбрело в голову: создал нужные директории и положил туда изображение весом в 10+ Мегабайт,

так как если кидать меньше картинку - в логах писалось что этот файл не может быть меньше 10Мб.

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

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

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

Ну а так как все правки были у меня локально, этот баг не исправили.

Через неделю мне по скайпу звонил QA-лид и просил обьяснить как я его правил.

Но у него ничего не получилось. Так что по сейчас в этой игре есть этот баг.

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

 

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

 

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

 

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

 

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

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

Конечно,это может быть очень смешно,но я реально попросил помощи. спасибо за ваши "умные" ответы

Ответ заключается в знании теории. Посмотрите здесь что такое регрессионное тестирование.

А вот тут что такое ручное тестирование.

Выводы делайте сами.

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

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

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

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

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

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

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

Если у заказчика нет конкретных требований по браузерам, то проверяю в:

- Chrome

- FF

- IE 10,11

- Opera(иногда заглядываю, так как движок такой же как и у Chrome)

- Safari (только на Mac Os, так как демонстрация заказчику именно на нем)

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

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

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

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

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

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

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

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

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

Результат:

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

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

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

Как то так.

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