вторник, 24 мая 2011 г.

Как бы я писал тестовые сценарии

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

Итак, что важно:
Создавать сценарии, а не отдельные тесты. Это может быть набор из тестов связаных друг с другом. Это экономит время. Например,
Выделять в большом сценарии отдельные точки проверки (verification points) с ожидаемыми результаами и отмечать их по мере прохождения. А  не ставить большую кучу в конце. Как-то в процессе вы должны были ожидать вот это. Видел такое, и не в полугодовом наколеночном проекте. А в зрелой большой успешной компании
В отчетах учитывать каждую точку проверки. Она влияет прошел сценарий/сьют/модуль/набор или нет
Но для общей статистики избегать дублирующий учет точек проверки. Учитывать vp только где это необходимо. Например, если в каждом сценарии вы проходите логин, то не надо считать, что это каждый раз отдельная точка проверки. Либо исключите его как точку проверки: уберите оттуда ожидаемый результат и не ставьте резолюцию. либо при отчетности не учитывать его кроме как только один раз во время проверки самого логина: оставьте ожидаемый результат (жалко копипаста?), но не ставьте резолюцию. Но обязательно оставьте коментарий и пометьте, что в данном случае тест провалился на логине, если только в этом тесте свалился логин. Или только он запускается сейчас.

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

среда, 30 марта 2011 г.

Как в SQL получить то, чего в базе нет


Я не назвал бы себя знатоком SQL. Я просто знаю как мне выбирать, вставлять и изменять нужные мне данные. Поэтому решить мне такую задачку просто с ходу не хватило знаний. Хотя она не такая и сложная.

Предыстория: регистрировал 1000 пользователей через http-запросы к системе. Получил отказы в 70% случаев. Регистрировал по маске u000
Задача: Выбрать список пользователей не зарегестрированых в системе. Если известен список зарегестрированых пользователей. А список пользователей, которых надо зарегестрировать соответствует определенной с буквенным префиксом и цифровым суффиксом, вырастающим инкрементально с шагом 1.

Получил решения от своих коллег разработчиков :)

пятница, 25 марта 2011 г.

Работа не должна мешать жизни, а жизнь работе

Я сам ленивый и не очень люблю работать. Если честно я вообще считаю, что работать надо только тогда, когда хочется. И не смотря на то, что я ленивый, мне иногда хочется работать. А когда хочется и работа выходит лучше, быстре и приятнее. Просто потому что внутри у тебя появилась мотивация ее сделать. А когда я не хочу заниматься работой - заниматься надо чем-то другим. Детьми, если есть, любимой, собой в конце концов.
Я тут не хочу рассказать о том, как все это сделать, но хотел бы поделиться мыслями Найджела Марша


пятница, 4 марта 2011 г.

Где брать данные для проверки

Вещь поразительно очевидна. Самые лучшие тестовые данные - реальные данные.

Чем больше ваша система, чем дольше ваша система работает для пользователей, тем больше своих данных они там хранят. Дело ведь не столько в саппорте. Лучше, чем они, вы не будете использовать вашу систему. Сотни, тысячи пользователей используют ее каждый день. Они лучше всех нагенерируют варианты для ваших тестов. Не считая, к тому же, еще и исторические данные, т.е. данные самых старых пользователей. Они эволюционируют вместе с системой.

Господа и дамы лидеры команд тестирования и не только, обновляйте тестовые ХД с серверов так часто как возможно (перед релизом это крайне полезно).

среда, 2 марта 2011 г.

Почему мы не делаем работу на работе?

Пересматривал выступление Джейсона Фрида "Почему мы не делаем работу на работе" (Jason Fried Why Work Doesn't Happen at Work). Интересные результаты. 





Но вот при разработке программного продукта необходимо очень много командной работы. Когда действительно необходимо постоянное взаимодействие между людьми. И отвлекаться это нормально.
Хотя если надо написать тест дизайн или просто покрыть тестами функционал. Разобрать требования заказчика и проанализировать их. Проанализировать состояние проекта и написать отчет.... То тут явно хочется повесить видимую не только тебе табличку "Не беспокоить" на видимую не только тобой дверь (open space).