You could certainly see your skills within the work you write. The arena hopes for even more passionate writers like you who are not afraid to say how they believe. At all times go after your heart….

Если нужно одно слово, то я выберу это.

Оно емкое, в него много всего помещается. Кроме этого оно как бы взывает к миру во всем мире, и на работе в том числе.

… на поверхности конечно эти двое…
Тестировщик не понял тест-менеджера, зачем тому понадобились вся эти прибамбасы.
Менеджер не понял, что тестировщик ничего не понял и собирается все тестировать по-старому.

… а чуть поглубже …
> Когда ошибки были исправлены, он ответил «ДА» на священный вопрос: он сказал «да, можно выпускать наш продукт пользователям!»
Вот это «ДА» каждый понял по своему:
- директор решил, что раз опытный тестировщик тестировал под присмотром системно мыслящего тест-менеджера, то в продукте не осталось сколь-нибудь значительных баг. И сказал «ГОТОВО» клиентам.
- клиенты решили, что сайт полностью готов и так понравится пользователям, что те мигом перейдут к ним от конкурентов. И дали «ДОБРО» публикации на живой.
- а пользователи увидев, новую версию сайта, сначала были просто не очень довольны, что им сейчас придется изменять привычные способ покупки билетов. Но решив, что, в конечном счете, он должен стать более удобным, еще сильнее расстроились напоровшись пусть даже не на очень критические ошибки, и засыпали суппорт клиента своими жалобами.

и покатилась волна недовольства назад …

А тестировщик, своим «ДА», скорее всего хотел сказать что: «Да, я проделал большую работу, нашел кучу ошибок, и они поправлены. Я думаю, там могли, конечно, остаться незначительные проблемы, но, мне кажется, они особо никого не потревожат».

(Кстати, а где был в это время тест-менеджер? Или это секрет?)

——————————

Поэтому тестировщику обычно не рекомендуют отвечать на вопрос «можно выпускать наш продукт пользователям?» столь односложно.

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

Именно для более четкого ответа на этот вопрос и нужны все эти тест-менеджерские прибамбасы.

Если все сделать правильно, тогда у всех будет более четкое (взаимо)понимание, что из себя представляет проект, а значит и принять правильно решение с учетом рисков.

PS: Правда, это нифига не застрахует нас от недовольства некоторых пользователей.

PPS: Кстати, а ведь и в реальной жизни мы часто не можем найти взаимопонимания, если не используем всякую магию вроде «родства душ», «понимания с полуслова», и прочей телепатии. Надо как-то будет в этом случае тестпак забабахать, может поможет…

>Что?

Те-о-ри-я.

А-а-аа.. я понял!

Чеклисты!… Риски?… Цели?… Ну что же?

Почему менеджер пришел и сказал «писать тесты, чтобы не пропускать ошибки. » Ведь тесты мало написать, по ним надо пройти., т.е. провести тестирование
Если тесты были написаны , и » там все эти мелкие проверки, которые казались такими неважными», то почему инженер не делал их, эти проверки?
Если менеджер такой умный и прозорливый, что предлагал шаблоны и метрики, то перед релизом его устроил ответ «да, можно выпускать наш продукт пользователям!» , вместо отчета о тестировании с покрытием ? Т,е. почему менеджер не отследил, что было проверено, а что — нет, до релиза?

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

P.S. Имхо, инженеру в этой ситуации не хватило понимания целей.

Автоматизация этих мелких проверок совместно с тестированием данных в базе!

Потому, что:

1. Неизвестно, когда появился этот баг и email и реквизитами. А может быть, его внесли в последний момент перед релизом?

2. Организация непрерывной выкатки новых билдов, покрытых тестами разработчиков и тестировщиков: ну хорошо, ну есть баг от пользователя. Пользователи будут находить и другие баги, в таких сценариях, которые даже не снились менеджменту и тестировщикам. Просто, нужен процесс, который бы позволял быстро их исправить. Это – веб-сайт, а не десктопное приложение. Обновить веб-сайт должно быть просто.

Кстати, если такие проверки считались мелко приоритетными, такими, что на них внимание даже никто не обращал, то может быть что-то не так с приоритезацией ? Ну, конечно же, как же мы можем узнать, что важно пользователю, а что нет… а можем!

Это же веб сайт. Начать можно с анализа логов веб сервера. А дальше – добавить трассировку кода на серверной и клиентской стороне.
Так можно выяснить, с какими фичами пользователи работают больше всего, и сконцентрироваться только на них перед релизом.

Ситечко, например, так делает.

Кстати, там ошибка 404 при отправке лога. Не скажу, как воспроизвести

http://i.imgur.com/ZUt0Pxd.png