Забудьте о правилах: вредные советы для аналитиков, разработчиков и тестировщиков

Всем привет! На связи команда Usetech. В нашем блоге мы уже рассказывали о стереотипах в работе тестировщиков, о практике обучения в QA отделе и разработке на iOS. Наверняка многие в детстве читали Остера и в вашей библиотеке была книга с его вредными советами?

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

Ну что, поехали? 😎

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

1. Если разработчик перед уходом говорит, что доделал фичу и отправил её на регресс — не проверяйте, сделал ли на самом деле. Людям надо верить.
2. Никогда не оставляй техдолг на завтра, если его можно оставить на послезавтра. Техдолг не корова, есть не просит.
3. Можешь смело откатывать зарелизенные фиксы и не сообщать об этом аналитику. Он умный, он сам догадается, когда прод увидит.
4. Если при вставке в код апи-токена к стороннему сервису ты случайно придавил ещё пару клавиш — ничего страшного, это ни на что не повлияет, главное, что сам токен проверен и поставку можно сразу катить в прод.
5. Никогда не проверяй пароль к сервису перед его шифрованием и выкаткой на прод.
6. Нет смысла писать обработчики исключительных событий, пусть пользователь видит ORA – так интересней локализовать ошибку.
7. Никогда не спрашивайте у заказчика, зачем ему такое поведение системы. Может выясниться, что оно ему на самом деле не нужно, а вы уже обратили его внимание на это.
8. Недокументированное поведение называй фичами и говори, что так и было задумано.
9. Не разноси код по файлам, если всё лежит в одном месте, то потом проще в этом разобраться.
10. Имя переменной должно отражать ее назначение. Поэтому если переменная используется как параметр функции, то ее стоит называть “parameter”, а если это результат вызова функции или результат функции, в которой эта переменная объявлена, стоит называть ее “result”. Даже не зная контекста, можно легко заметить баг в хорошем коде. Например: var result = Foo (fooParameter1, fooParameter3, fooParameter2).
11. Нужно заботиться о расширяемости системы, поэтому не поленитесь добавить дополнительные поля в свои структуры данных и пометьте их как “зарезервировано для будущего использования”.
12. Заключая рискованный долгосрочный договор на поставки и работу с подрядчиком, прописывай весь бюджет как сумму договора и не забудь предоплату в 30%, даже если нужно не все сразу. Это же так весело, потом возвращать предоплату за то, что не выполнено / не поставлено.
13. Не видите тэги “head and revision” в пакете и  не надо. Пусть никто не знает, что на проде тело пакета из другой ветки и ревизии.
14. Если вас заставили использовать систему контроля версий, отключите линтер и поиграйте с отступами – будет весело.
15. Не используйте системы контроля версий. Раньше как-то жили без этого и сейчас можно обходиться без лишних телодвижений.
16. В случае возникновения проблем, перезапускай сервис и чистите логи, пока никто не видит.
17. Не делая бэкапов — смело выполняй truncate.
18. Попробуй ничего не менять и передать в тестирование – они сами разберутся.
19.  Если требуется что-то “достилить” в системе, не ищите, где используются текущие стили. Просто дописывайте свои в конце файла и перебивайте все предыдущие, даже если видите 100К строк – ведь так гораздо быстрее.
20. Добавляйте побольше загадочных цифр и аббревиатур в названия пакетов и классов. Классы лучше именовать с сокращениями и нижними подчеркиваниями, так ваш код будет выглядеть еще более профессионально!

Ну и напоследок советы от наших любимых тестировщиков, как же без них.

21. Не бойтесь тестировать на бою, используя свои данные. Однажды перед декретом дала коллеге свою карту — протестировать интеграцию с системой платежей. Через полтора года до слёз смеялась — мне как сюжет мистического триллера рассказали, как всем банком искали источник нескольких лишних рублей на балансе. А они были мои…
22. Никогда не задавайте уточняющие вопросы — всегда тестируйте задачу так, как подсказывает ваше сердце.
23. Если видишь баг — не заводи на него таску. Обсуди в чатике и спустя неделю там же напомни, что баг ещё не поправили. Таск-трекеры — для слабаков.
24. Не стоит заводить тесты в тест-менеджмент системе: написанные на коленке в блокнотике проверки самое то для специалистов экстра класса — они ведь талантливые и крутые.
25. Отчёты о тестировании никому не нужны, не надо их составлять. Достаточно сказать что “всё ОК”, и вся команда этим удовлетворится. 
26. Если разработчик передаёт задачу и говорит, что там всё работает, то не надо проверять. Зачем на ретест тратить время? Доверяйте людям! И жить станет проще.
27. Тестировать юзабилити – неинтересно. Пользователь сам во всём разберётся. А потом ещё раз придёт и снова во всём разберётся. Людям нравится разбираться в сложных вещах, не будем лишать их такого удовольствия.
28. Если вы в ступоре и не понимаете как работает фича, которую нужно протестировать, отложите её на самый последний этап тестирования – когда-нибудь к вам придёт просветление и вы всё поймёте. Вопросы – это лишнее, нужно ждать пока нас осенит!
29. Регресс придумали трусливые и неуверенные в себе люди. Не нужно его проводить, ведь мы уже всё протестировали на проекте по отдельности, что может пойти не так…
30. Вам говорят про грамматические ошибки в баг-репорте? Скажите, что человек “душнила”. Мы не в школе – разработчик поймёт, что там чинить.
31. Никогда не прикрепляйте к баг-репортам такие артефакты как видео, скриншоты или логи. Вы и так всё подробно описали, кому надо, тот разберётся.

Ну что, сталкивались с каким-либо из советов на практике? А может, можете предложить что-то новое? Делитесь в комментариях! 👇🏻