tестирование dot com
Шрифт:
В общем сложилась ситуация, когда сама спецификация имеет
проблему, так как мы ожидаем (или по крайней мере должны
ожидать), что в спеке будут подробности о тексте ошибки, а в
реальности их там нет. Так и запишем — "баг в спецификации"
(spec bug).
Кстати, вот варианты развития ситуации с проблемным спеком:
а. Скорее всего программист все
щение об ошибке. Ваше дело послать е-мейл продюсеру (продю
сером в интернет-компании называют товарища, создающего
спеки), чтобы тот внес текст, уже написанный программистом, в
пункт 19. а.
б. Если программист написал нечто противоречащее здравому смыслу
или стандарту, принятому в вашей компании, рапортуйте баг.
в. Может случиться так, что вы не заметили проблемы в спеке и не заме
тили, как программист написал сообщение об ошибке, противореча
щее здравому смыслу или стандарту, принятому в вашей компании.
Кстати, вот две релевантные политически важные вещи:
1. Как правило, работа в стартапе — это уникальный опыт, когда тяже-
лый труд сочетается с радостью созидания, расслабленной обста-
новкой (я, например, уже многие годы хожу на работу в шортах) и
окружающими вас милыми, веселыми людьми. Но бывают нештат-
ные ситуации (например, работа не сделана в срок или сделана не-
качественно), и, когда дело дойдет до выяснения "кто виноват" и
"что с ним сделать", многие из ваших коллег перестанут быть ми-
лыми, веселыми людьми и активно начнут вешать собак друг на
друга. Так вот, чтобы одну из этих собак не повесили на вас, посы-
лайте е-мейлы, сохраняйте их и ответы на них и при случае пересы-
лайте их заинтересованным сторонам. Пригодятся те е-мейлы в
дальнейшем — хорошо, не пригодятся — еще лучше, тем более что
каши они не просят,
рах и ничего не ждут от этой жизни.
2. Каждый должен заниматься своим делом и отвечать за свой участок
работы. В случае если спек сделан некачественно, то лучше под-
нять тревогу с рассылкой е-мейлов, чем делать допущения относи-
тельно того, как должно работать ваше ПО.
Перед завершением темы об ожидаемом и фактическом результа-
тах рассмотрим примеры других источников ожидаемого резуль-
тата, кроме спеков.
1. ЖИЗНЕННЫЙ ОПЫТ
Как справедливо отметил Борис Слуцкий: "Не только пиво-раки
мы ели и лакали". Мы также учились и работали, любили и нена-
видели, верили политикам и не слушались родителей, в общем
приобретали жизненный опыт (включая опыт работы). Так вот этот
Что такое баг
23
опыт настолько полезен в нашем черном деле, что для демонстра-
ции уважения к идее о его полезности (вместе с логикой и здравым
смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том,
что тестирование ПО — это то самое тестирование (которое мы
делаем постоянно), но только в отношении ПО. И моя задача
заключается лишь в том, чтобы дать вам основные концепции и
практический инструментарий по интернет-тестированию и помочь
их интеграции с тем, что у вас уже есть, — с жизненным опытом.
2. ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно
внук "ошибок трудных")
Это один из наших главных союзников, порой даже и при нали-
чии спека. Например, вы тестируете веб-сайт, где пользователь
может загрузить (upload) свои цифровые фотографии. Спек гово-
рит, что пользователь может загрузить лишь одну фотографию за
раз. А что, если у него таких фотографий 200? Будет он счастлив?
Что делаем? Правильно: пишем е-мейл ж [email protected] с
предложением о включении в спек функциональности, позво-
ляющей пользователю загружать цифровые фотографии оптом.
Кстати, баг такого рационализаторского плана лицемерно назы-
вается не багом, a Feature Request ("запрос об улучшении" — пока
остановимся на таком переводе).
3. ОБЩЕНИЕ
Даже самый лучший спек может вызвать необходимость в уточ-
нениях. А что, если спека нет вообще? Наш ответ: общение. Со-
ветуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хо-