« Я тестер ! »

Есть у меня необходимость использования в рамках автоматизации внутренних библиотек dll, написанных на C#. Однажды гуглив столкнулся с фразой, что некомовские (non-COM) библиотеки нельзя использовать в VBScript. Тогда на этом шаге остановился и обошелся переносом кода тогда ещё маленькой функции на VBScript.

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

Стоит сказать, что попытки реализовать предоженный метод были и раньше, но почему-то они не увенчались успехом. Теперь же всё получилось, поэтому решил написать этот пост.

namespace namespacename
{
    public class classname
    {
        public int GetValue()
        {
            return 1;
        }
    }
}

Set obj = DotNetFactory.CreateInstance("namespacename.classname", "c:\\namespacename.dll")
MsgBox obj.GetValue()

Вот и всё, теперь наша библиотека работает в QuickTest'e.

Есть небольшой нюанс: по своей глупости мне казалось необходимым после пути к dll ещё одним параметром ставить micString - тип возвращаемого значения. И в таком виде оно не работало - ругалось на меня почти матными словами.

Удач в использовании QTP ;)

Тут давеча уважаемый Samat Jukeshov прислал приглашение в Google Wave. Уже много раз слышал про этот новый сервис от Google'a. Теперь пришло время пощупать.

Сейчас пользователям дана только Preview версия, но это только начало. Они обычно вообще не спешат выходить на релизы с такими штуками - помните сколько их почтовый сервис висел в Beta версии?

Тем, кто ещё не слышал про это, будет полезно посмотреть вот это видео (1 час 20 минут!! ).

Мой пост скорее направлен к тем, у кого аккаунт к этому чудо-сервису уже есть: давайте wave'иться, господа. Заодно и протестируем сей сервис! Мой Wave Address: maksim.hr@googlewave.com

Буду рад познакомиться и поговорить. Дабы не нести чепуху или флуд, предлагаю несколько тем для обсуждения (реальное использование - есть лучшее тестирование):
- внедрение автоматизации там, где её до сих пор не было: проблемы, known issues, know how, etc. Ссылка на волну
- внедрение процессов (создание отдела/группы/команды) тестирования там, где их до сих пор не было. Ссылка на волну.
Обе темы мне интересны самому, признанным экспертом не являюсь, поэтому ожидаю конструктивное общение.
- но можно-таки и просто пофлудить :)  (+ обсудить этот блог) Ссылка на волну.

Когда мне будет дана возможность раздавать приглашения - обязательно отпишусь.
Upd: т.к. меня самого пригласили в ближайшее время получить возможность раздавать приглашения у меня не будет :(

Судя по комментам всех беспокоит возможность получения приглашения. Его можно получить здесь www.inviter.ru

Тестирование GUI (graphical user interface) очень редко проходит отдельно от основного функционального тестирования. Конечно:

- бывают большие проекты, где этому уделяется внимание;

- бывают пропущены серьезные проблемы, после которых все тестировщики проекта некоторое (зачастую недолгое) время тестируют ГУЙ / ГУИ / УЙ / УИ / UI / GUI

Вот скажите мне, разве можно тестировать то, принципы чего сам до конца не понимаешь? Разве можно найти ошибки в калькуляторе, если не знаешь таблицы умножения?

Многие менеджеры считают, что можно! И тогда все тестировщики становятся не только ГУИтестерами, они сразу ещё и ГУИтворители (ведь программисты исправят ровно так, как это скажет тестировщик).

Такая ситуация очень похожа на историю возникновения самих тестировщиков: программисты (или их начальники) поняли, что писать код и выпускать ПО без ошибок не одно и то же!

Я понимаю, должно пройти время, когда всем станет более-менее понятно: функциональное тестирование и тестирование графического интерфейса пользователя - должны делать разные по своей профессиональной подготовке люди!

Ладно, от теории перейдем к практике.