среда, 5 ноября 2008 г.
Открылся новый сервис для микроблоггинга по адресу http://qa.co.kg
Обращаюсь к колегам QA. Заходите и регистрируйтесь на http://qa.co.kg. Будем обмениваться инфой и линками. Попробуем сделать комьюнити :)
четверг, 30 октября 2008 г.
В Казахстане и Кыргызстане заблокирован доступ к LiveJournal
В Казахстане и Кыргызстане заблокирован доступ к LiveJournal вот причина того, что не постился в блоге. Подробнее можно почитать на mignews.com . Ситуация честно говоря просто обескураживающая. Я как житель Кыргызстана отрезан от блога, потому что некто в Казахстане закрыл доступ. Где собственно логика??? Просто почти все кыргызстанские интернет провайдеры выходят в глобальную сеть через оптику лежащую именно в Казахстане. Интернет доступ работающий у нас в стране это просто отдельный разговор, впрочем я уже скидывал ссылку об этом. Сейчас пишу в блог через http://mylj.ru. Очень хороший ресурс все таки :) Рекомендую всем кто лишился своего ЖЖ по вине злобных админов, ну или по каким то политическим соображениям :). Думаю скоро поделюсь своими новостями, их уже много и есть чем поделиться...
среда, 10 сентября 2008 г.
С днем тестировщика
9-сентября не официальный праздник в принципе, но от этого не менее знаминательный День тестировщика или День QA. Поздравляю коллеги с праздником хоть и с опозданием в 1 день:). Почему 9-сентября можно узнать здесь . Первому найденному багу 63 года:) P.S. Че то я совсем забыл про блог, впредь буду отчаянно пытаться писать хотя бы 1 раз в неделю
понедельник, 26 мая 2008 г.
Ну наконец то в Wiki
Начну наверно из далека. Такое направление как software testing или qa хоть и появилось относительно давно, но все community такого рода специалистов не консолидированы.
Что я имею в виду? Есть конечно какие то базовые понятия для любого QA но вот их взгляды на одни и те же понятия расходятся колоссально. Для примера открываем самые большие форумы и наблюдаем в обсуждениях просто кошмар. К примеру из 30 последних тем, около 25 будет с вопросом типа: А что такое тесткейс?, Что такое сценарий тестирования?. Причем это наблюдается как на англоязычных, так и на российских форумах.
Эта проблема известна многим и было много попыток сделать единую базу знаний для всех QA, примером такого может быть http://www.softwareqatest.com/ . Да я признаю что база знаний у нее неплохая, но вот 1 незадача, туда мало кто заходит просвещаться. А теперь главная фишка: Ни для кого не секрет, что большинство IT-товарищей первым делом пытаются просветиться либо в Гугле, либо в Википедии . Ну и вот наконец то к конкретно самой новости: в Wikipedia открылся отдельный портал для QA по адресу http://en.wikipedia.org/wiki/Portal:Software_Testing . Для себя открыл несколько интересных понятий, да и мне кажется, что любой QA найдет там массу интересного и база знаний будет дополняться.
P.S. Больше всего радует то, что можно будет пнуть долбанных индусов в Вики на форумах и не париться.
Что я имею в виду? Есть конечно какие то базовые понятия для любого QA но вот их взгляды на одни и те же понятия расходятся колоссально. Для примера открываем самые большие форумы и наблюдаем в обсуждениях просто кошмар. К примеру из 30 последних тем, около 25 будет с вопросом типа: А что такое тесткейс?, Что такое сценарий тестирования?. Причем это наблюдается как на англоязычных, так и на российских форумах.
Эта проблема известна многим и было много попыток сделать единую базу знаний для всех QA, примером такого может быть http://www.softwareqatest.com/ . Да я признаю что база знаний у нее неплохая, но вот 1 незадача, туда мало кто заходит просвещаться. А теперь главная фишка: Ни для кого не секрет, что большинство IT-товарищей первым делом пытаются просветиться либо в Гугле, либо в Википедии . Ну и вот наконец то к конкретно самой новости: в Wikipedia открылся отдельный портал для QA по адресу http://en.wikipedia.org/wiki/Portal:Software_Testing . Для себя открыл несколько интересных понятий, да и мне кажется, что любой QA найдет там массу интересного и база знаний будет дополняться.
P.S. Больше всего радует то, что можно будет пнуть долбанных индусов в Вики на форумах и не париться.
вторник, 13 мая 2008 г.
Меня одного вот это бесит?
Я конечно понимаю, что самому ЖЖ выгодно чтобы я писал каждый день и можно было продать каждый показ баннера(которых итак много ИМХО!) при просмотре, но всему есть предел. Тут еще и подгонять юзера это уже ни в какие ворота не лезет.
четверг, 8 мая 2008 г.
Стыдно но все же
Недавно улучшили процесс деплоя как на сторону заказчика, так и себе. Честно говоря очень обидно, что не доперли до этого сразу но все же. Принцип следующий:
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.
пятница, 11 апреля 2008 г.
О Continuous Integration (ci)
Вытаил время для очередного топика. На этот раз захотел написать о таком понятии как Continuous Integration, ну или просто CI. Для тех кто не знает что это такое, то читаем в Wiki . Прочитав можно сразу понять, что понятие ci было впервые озвучено многоуважаемыми Фаулером и Беком в качестве набора базовых практик которые позволяют команде наиболее быстро получать фидбек по работе софта.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...
Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.
Ну в общем то для начала думаю хватит.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...
Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.
Ну в общем то для начала думаю хватит.
Подписаться на:
Сообщения (Atom)