to post messages and comments.

Тут mail.ru внезапно устроил адекватные и полезные курсы на базе ВМК МГУ, где 2-4 курс учат прикладным навыкам, а не фундаментальной науке. Назвались "Техносфера".
Один из моих любимых детей, которые помогают проводить олимпиады, написал эссе про тестирование на примере саги "Звездные войны".

На самом деле огонь: cloud.mail.ru

Жуйк, помоги начинающему тестеру. Вот есть у меня набор тестов. С использованием вебдрайвера на Хроме. Написаны на питоне. У меня два вопроса. Как сделать, чтобы запускалась одна копия браузера? И второй вопрос — как запускать одновременно несколько тестов последовательно?

Сегодня разбирала то, как бы я тестировала интерфейс вкладок в Windows. Раздел оказался маленьким. Вкладок, как и всплывающий подсказок, несколько видов. Самое прикольное, как показалось — это запрет на совмещение горизонтальных и вертикальных вкладок и запрет на выпадающее меню в них :D
chugueva.wordpress.com

Вчера читала Windows User Experience Interaction Guidelines. А конкретно, про всплывающие подсказки. Читала и между делом записывала основные моменты, на которые нужно обращать внимание при тестировании ПО под Windows. Оказывется, что этих подсказок несколько видов и для каждого свои требования. В общем, тут все не опишешь. Вот статья в моем блоге о тестировании.
chugueva.wordpress.com

Что еще сегодня забыл похвалить, прежде чем спать чесать: Jasmine и Sinon.JS. Первый — попытка реализации RSpec для JS. Попытка, потому что, конечно это JS, и это не RSpec. Но альтернатива очень хорошая. Самое то ядро, в сочетании с CoffeeScript синтаксисом привносит то самое незабываемое ощущение лаконичности RSpec.
Чем примечателен Sinon.JS. Эта штука просто незаменима, при тестировании JS кода. Умеет наверное все, что требуется в 99% случаев. Spy, Stub, Mock, fakeXHRServer, fakeServer, fakeTimer. Короче, все что душе угодно. В чем еще его достоинство — он не привязан ни к какому фреймворку для тестирования. Лично я его использую с Jasmine, кто то его с успехом может для QUnit использовать.
На десерт: tinnedfruit.com Три статьи про тестирование приложений на backbone с помощью Jasmine и Sinon.JS.

В общем, наслаждайтесь, а я дрыхнуть пошел. И не пинайте за уже не первый раз рекламы(?) этих библиотек. Уж больно нравятся они мне. Больно хороши.

Чего-то я все чаще, натыкаюсь на следующее противопоставление многих императивных языков (в моем случае Python/Ruby), и функциональных (не важно, пусть будут ML-подобные). Заявление туманное, но все же. Мол программа четко ограничена, сокращенно количество ошибок, не нужны тесты. Конечно, я понимаю. В случае к примеру того же Python/Ruby — более тщательное тестирование может быть некоторой платой за гибкость в императивном подходе.

Но неужели функциональные языки, статическая типизация с выведением типов настолько защищают правильность программы, что тесты не нужны? Или это я встречаю обобщенное высказывание.

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

Для тестирования клиентского кода мне очень понравился Jasmine. По сути попытка клона RSpec, но честно признаться — слабый клон, если использовать сам по себе. Зато в паре с ним, просто великолепно работает sinon.js, который предоставляет stub, mocking, spy, а также fakeServer и прочие прелести вроде эмуляции AJAX. А для тестирования jQuery и вообще облегчения жизни — очень хорошо использовать jasmine-jquery. В общем связка jasmine.js + jasmine-sinon.js + jasmine-jquery.js — очень крута и красива. Очень рекомендую.

Нынче тут один человек, предложил идею, создания набора утилит для тестирования консольных утилит. То есть, без доступа кода, извне, и не зависящей от конкретной утилиты. "тестирование черного ящика без доступа кода". Он нашел один мертвый проект windows only. Вот я решил, обратиться к тебе, %username%. Может сталкивался с подобными задачами или инструментами, посоветуйте, есть ли такие инструменты вообще? Или какие-нить идеи на базе чего или как это можно сделать. Рекомендации приветствуются. И всем спасибо за внимание.

Подскажите джентельменский набор тестировщика мобильных приложений?
У меня пока вырисовывается такая картина:
Android:
— бюджетная модель, что-нибудь с QVGA экраном
— старенькая модель, с HVGA экраном
— новенькая модель, с WVGA экраном
— какой-нибудь планшет
iOS:
— старенький айфон, например, первый
— четвертый айфон
— айпад, пожалуй, первый сойдет
Для полноты картины:
— какой-нибудь Blackberry
— что-нибудь с Win Phone 7

Есть БД на девятом оракле(апргейд на новую версию в ближайшее время не планируется). Как бы наиболее просто и быстро протестировать ее на нагрузку? Т.е. подергать существующие хранимки и кастомные запросы от некоторого количества виртуальных пользователей?

code.google.com
Прежде чем выкладывать в Маркет очередную бету, хотелось бы узнать (у добровольных внимаемых бета-тестеров):
1. Достаточно ли вменяемо задаются таймеры?
2. Как, черт побери, у двух с половиной человек (по отзывам в Маркете), таймер при срабатывании зацикливается (пищит, пока не прибьешь приложение)?

Узнал сегодня в институте 3 главных правила тестирования программы: 1) Тестирование легко начать, но сложно закончить. 2) С ростом числа обнаруженных ошибок увеличивается вероятность обнаружения новых. 3) Никогда не тестируйте свою программу сами. Пусть за вас её тестирует другой программист.

До сих пор не верится, что лектор говорил это на полном серьезе. Хотя с этими пунктами тяжело поспорить.

Недавно столкнулся с проблемой, при установке созданного ipa файла у заказчика вылезла ошибка — “The app was not installed because an unknown error occured, 0xE8008017″, погуглив нашел и источник проблемы и решение. Где-то в каком-то названии файла рисунка вкрался какой-то некошерный символ, искать его мне достаточно долго-бы пришлось. Решение: использовать такой же способ упаковки как через Finder, для этого вместо zip — берем ditto, а посколькоку он берет содержимое директории которую мы ему указываем, то нужно Payload переместить в еще одну директорию, например под названием Package. Соответственно нужно добавить вначале скрипта строку:
/bin/mkdir “$CONFIGURATION_BUILD_DIR/Package”
/bin/mkdir “$CONFIGURATION_BUILD_DIR/Package/Payload”
и позаменять ниже упопоминание Payload на Package/Payload.
А вместо /usr/bin/zip -r пишем /usr/bin/ditto -c -k –sequesterRsrc

Деградация личности начинается до безобразия просто. Есть вот во внешнем API класс со статическими методами, из которых получаются нужные мне сущности. И не протестировать их таким образом, не замочить. И вот, блин, не могу дальше кодировать пока не придумаю как протестировать-то грамотно. Так то!