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

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

Ну а раз вы тестировщик, то вам позарез нужны эти вредные советы:

Цели и пути развития продукта не должны вас интересовать, они только для менеджера. А вы пока сможете протестировать много-много (избыточных) сценариев и не потратите драгоценное мыслетопливо.
Никогда не анализируйте свою работу и пропущенные ошибки, а то ведь не сможете их повторить.
Так же и с чек-листами: написанное однажды трогать запрещено. Накопленный со временем опыт тут ничем не поможет.
Расписание и планирование для слабаков, любой тестировщик умеет играючи одновременно писать чек-лист, вести собеседование и изучать python.
Будьте самостоятельными и никогда не задавайте вопросов. Ну а если вопросы все же накопились, то задавать их нужно все сразу и желательно в день выпуска релиза.
Если ответы на вопросы вам покажутся непонятными, то сделайте вид, что все окей, и не разбирайтесь дальше, иначе ваша компетентность может оказаться под сомнением. Особенно, если вы стажер, вдруг продлят испытательный… Ну что непонятного в ожидаемом результате “Система отработала корректно”?

Проект - это страшный секрет, его могут украсть, отобрать или начать вас учить, как надо вести эти самые проекты. Поэтому никому не сообщайте о новых проектах, особенно, если они задевают еще 500 соседних функционалов. Не сомневайтесь, ваши коллеги будут очень рады увидеть уже готовенький проект на prod, желательно с ошибками в их зоне ответственности.
Решили все же поделиться проектом и поручить коллегам что-то проверить? Отлично! Только тестовых данных никаких не давайте, пусть учатся сами с нуля настраивать систему. Инструкцию конечно можете написать, но там все должно быть кратко – не разжевывать же очевидные основы «ракетостроения». Исп. больше. сокращ. и ваша эффект-ть бдт оценена! МЛРД %!
Всегда верьте разработке, они не ошибаются. И менеджер тоже не ошибается. Документация ничего не доказывает. И здравый смысл - не доказательство. Сказали, что не ошибка - смело закрывайте баг-репорт. Сказали, что пользователи с этим поживут - смело сдвигайте сроки исправления.
А можно наоборот, как можно больше скандалить и на каждое поручение выдавать свои собственные противоположные рекомендации. Так вы зарекомендуете себя “самым умным” и думающим человеком (правда, думающим недолго).
Не вздумайте развиваться и спрашивать у руководителя о способах и точках роста (soft & hard skills). Молчание и недовольство сегодняшним днем модно в это сырое промозглое лето.
Или наоборот, спрашивайте о повышении по дюжине раз на дню, чтобы ваш руководитель наконец понял, что именно вами движет. Только не удивляйтесь, если в ответ от вас потребуют определенный уровень в навыках тестирования.
Не вздумайте изучать тест-дизайн. Протыкивание всех-всех сценариев – вот путь к успеху, это и называется полным тестовым покрытием.
При тестировании почаще уходите в крайности, чтобы найти такие баги, какие никто до вас не находил: ранним утром четырнадцатого числа весеннего месяца нисана воспроизведите ошибку, оформите на разработку с пометкой «срочное», включите в ближайший выпуск. Будет еще лучше, если ошибка из чужого функционала (только тссс, ошибку никому не показывайте – это еще одна страшная тайна). А если так и не смогли понять, как точно воспроизводить ошибку, то нагоните побольше тумана и мистики в баг-репорт, разработчики обожают заниматься локализацией таких проблем.
Помните про импровизацию, и ничего не записывайте, дабы не терять время. Быстренько проверьте новый проект – и в продакшен, а чек-листы потом как-нибудь напишете, или еще лучше, если кто-нибудь другой их напишет.
А если не хотите быть спонтанным, то будьте педантом! Обязательно проверьте работу вашего сайта в Internet Explorer 6 и в переводе на язык “бикья”.
Не успеваете проверить релиз? Оставьте это развлечение пользователям, пусть будут гордо носить звание бета-тестеров! Можно потом хвастаться, что у вас используется бета-тестирование, и не важно, что вы, к примеру, Банк.
Никогда не читайте техническую документацию, она слишком сложная и только для разработки, а у нас есть тест-кейсы в черном ящике. И не вздумайте общаться с разработкой, у них полно своих задач, а тестирование продукта - совсем не их дело.
Никогда сразу не пишите сообщения и не ждите ответа, ведь любая ваша работа слишком важна и безотлагательна. Чаще бегайте к столу разработчика, тогда он не сможет отвлекаться на код, отвечая на ваши вопросы. И к менеджеру почаще ходите, а то что он один сидит скучает. Еще можно позвонить раз 100500, если на ваши звонки всё ещё отвечают.
До чего дошел прогресс! Написали автотест!
А потом еще сто тысяч - и не страшно за релиз!
Их использовать не вздумай, и поддерживать не смей,
Потому что автотесты могут вытеснить людей!
(с детства с рифмой я дружу, не нашел - и не ищи)
С первого пункта у вас наверняка многое накопилось, и вот наконец настала пора как следует обидеться на данный текст. А может и не стоит обижаться.. потому что все мы люди, все ошибаемся, периодически позоримся, испытываем эмоции. А если вы не совершали ни одной из этих ошибок или не узнали в них кого-то из своих коллег, то очевидно тест Тьюринга вам не по зубам.

P.S.Пункт №418. Если от стола вашего разработчика слышится “I'm a teapot ”, то позовите его (разработчика) на кофе, а потом вместе пересмотрите документацию.

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

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

Спасибо за внимание!

Вредные советы для тестировщиков