Про 2008-й

Захотелось сделать отчет для самого себя о заканчивающемся 2008 годе.За этот год я успел сменить место работы(да и должность тоже :) ) с ведущего специалиста в компании Ikeen на должность начальника QA отдела компании ITB. Как бы там не было, я очень рад что работал в Ikeen, именно там я вырос и многому научился как QA.
Вместе с новой для себя должностью начал изучение управленческой деятельности, провел несколько интересных для себя экспериментов, которые опишу уже в следующем году. Под конец года вместе с Ромой открыли портал QAлификация. Теперь три этих блога(мой, Ромы и QAлификация ретранслируются на SoftwareTesting.ru, получили рекламу от IT4business.ru, что не может не радовать :)
Из общественных IT событий этого года конечно хотелось бы отметить:
1. Мировой финансовый кризис. Пострадали чуть ли не все, естественно IT население не осталось в стороне
2. Появление браузера Google Chrome. Теперь еще 1 браузер в котором нужно проверять работоспособность разрабатываемых решений :( .
3. Огромное количество разного рода очень интересных стартапов в виде сервисов(software as a service). Я понимаю, что они появлялись и в прошлые годы, но в этом году их рост был огромным.
4. Непонятная мода на OpenSource. Такое впечатление, что все софтверные компании открыли исходный код, хотя бы на 1 из своих продуктов.
5. Пиковая популярность соц сетей типа facebook, одноклассников и т.д.
6. Ну и конечно же, не удавшаяся покупка Yahoo Microsoft-ом.
От себя же: Поздравляю всех с наступающим новым 2009 годом и желаю всем всего наилучшего!

Открыл общий доступ к своему RSS ридеру

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

О необходимости знаний в программировании для QA

В каком то из постов я уже касался такой темы, что для меня лично, идеальный QA это прежде всего тот, кто указывает на ошибки, еще посмотрев на изменения в коде. При этом я не исключаю ни ручного, ни еще какого либо тестирования. Как показывает всеобщая практика 70-80% багов находятся в процессе именно ручного тестирования. Все должно быть в совокупности.Теперь начнем рассуждать по делу с самого начала... Все так или иначе столкнулись или столкнуться с тем временем, когда нужно набирать людей в свой QA отдел. Лично я приверженец того, что если человек решил заняться тестированием ПО "серьезно", то ему естественно нужен некий базис. В моем понимании базиса, QA должен иметь как минимум IT образование, причем я имею в виду не только высшее образование, это может быть и просто опыт работы без всякого "диплома". Скажу честно, что человека без IT прошлого на роль QA, я не стану даже рассматривать. Я знаю, что есть множество примеров, когда люди без "образования" тестировали продукты лучше специалистов. Но на этот факт надо смотреть по другому: ведь QA не занимается постоянным ручным тестированием в надежде найти ошибку, кроме этого он должен писать автоматизированные тесты, понимать хотя бы архитектурную суть софта и многое другое. А вот брать и учить даже этому, человека совсем не просвещенному в этих вопросах я не хочу и не буду. Мне жалко и свое время и свои нервы.Пойдем дальше. Автоматизированные тесты как бы к ним не относились... это тоже программный код, который в любом случае будет иметь свою логику и архитектуру. При этом написанные тесты придется усиленно поддерживать. Еще на данном этапе будут необходимы хотя бы минимальные знания программирования. Еще дальше. Всем опытным QA когда то приходилось тестировать задачи которые очень тяжело воспроизвести. В таких случаях тоже могут понадобиться те самые знания программирования. Т.е. смотрим в исходный код и смотрим где что могло вывалиться или сработать не корректно. Теперь о том, что было еще в начале. К примеру у меня уже давно стало привычкой еще до начала тестирования смотреть в изменения в коде для того, чтобы понять что, как и где изменилось и на что это может повлиять. Мой опыт показывает, что это как минимум не мешает общему процессу тестирования. Описал не все свои доводы, но постарался написать хотя бы общие.

Открылся новый сервис для микроблоггинга по адресу http://qa.co.kg

Обращаюсь к колегам QA. Заходите и регистрируйтесь на http://qa.co.kg. Будем обмениваться инфой и линками. Попробуем сделать комьюнити :)

В Казахстане и Кыргызстане заблокирован доступ к LiveJournal

В Казахстане и Кыргызстане заблокирован доступ к LiveJournal вот причина того, что не постился в блоге. Подробнее можно почитать на mignews.com . Ситуация честно говоря просто обескураживающая. Я как житель Кыргызстана отрезан от блога, потому что некто в Казахстане закрыл доступ. Где собственно логика??? Просто почти все кыргызстанские интернет провайдеры выходят в глобальную сеть через оптику лежащую именно в Казахстане. Интернет доступ работающий у нас в стране это просто отдельный разговор, впрочем я уже скидывал ссылку об этом. Сейчас пишу в блог через http://mylj.ru. Очень хороший ресурс все таки :) Рекомендую всем кто лишился своего ЖЖ по вине злобных админов, ну или по каким то политическим соображениям :). Думаю скоро поделюсь своими новостями, их уже много и есть чем поделиться...

С днем тестировщика

9-сентября не официальный праздник в принципе, но от этого не менее знаминательный День тестировщика или День QA. Поздравляю коллеги с праздником хоть и с опозданием в 1 день:). Почему 9-сентября можно узнать здесь . Первому найденному багу 63 года:) P.S. Че то я совсем забыл про блог, впредь буду отчаянно пытаться писать хотя бы 1 раз в неделю

Ну наконец то в 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. Больше всего радует то, что можно будет пнуть долбанных индусов в Вики на форумах и не париться.

Меня одного вот это бесит?

Я конечно понимаю, что самому ЖЖ выгодно чтобы я писал каждый день и можно было продать каждый показ баннера(которых итак много ИМХО!) при просмотре, но всему есть предел. Тут еще и подгонять юзера это уже ни в какие ворота не лезет.

Стыдно но все же

Недавно улучшили процесс деплоя как на сторону заказчика, так и себе. Честно говоря очень обидно, что не доперли до этого сразу но все же. Принцип следующий:
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.

О 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-ом.

Ну в общем то для начала думаю хватит.

О читабельности кода

Недавно стал задумываться о том, какого хрена молодые разработчики (особенно студенты) сильно не гадуют почему нужно переменные, методы, классы, интерфейсы и т.д. и т.п. называть нормальными именами( как их принято называть жаваподобными именами). Каждый раз называют любимыми x, y, i и т.д. В чем заключается собственно барьер?
Школа. Проблема на мой взгляд кроется даже не в увиневере, а в школе. Итак вспоминаем школу урок математики. Приводится какая то задача и там же как было принято какие то неизвестные величины, тобишь переменные всегда называются x и y. Далее идет огромное дерево решений с использованием этих имен. При этом это является нормальным для всех, читабельным решением.
Универ. Такая же фигня после этого наблюдается и в универе когда препод говорит мол называем прибыль x, себестоимость a, цена b. И давайте мол решение автоматизируем и напишем x = b - a; и все счастливы. А на первый вопрос как во всем этом разобраться советует писать комментарии. Вот и настает полная фигня и бардак в коде. А это извините меня 10 лет в школе(грубо говоря) и 5 лет(в универе) впихивание таковой культуры.
Естественно на первые грабли такие товарищи наступают очень быстро, при первом же коммите ну или чуть позже, если конечно человек устроился на работу в команде)). По правде я когда то видел целые группы разработчиков у которых x и y-ки забиты в проекте и сопровождаются не менее большими комментариями. Это уже полный ахтунг.
Помню случай когда студенты спорили друг с другом на то, кто пишет труднее и в чьем коде трудней разобраться и это на самом деле для них являлось просто офигительным решением. Смешно конечно, но это было на самом деле.
Лекарство. Самый лучший пример по извлечению таких вредных привычек у такого товарища наверное просто заставить переписать его собственный код под новую логику. Там и выходят все отрицательные стороны его подхода и человек начинает понимать собственные ошибки. Если не понимает, то писец... Лучше сменить порфессию, либо работать одному.
P.S. Мысль возникла после того, как увидел автоматически сгенеренный скрипт от TestComplete(кто видел, тот наверное поймет). Такое впечатление что его писали именно такие товарищи о которых
писалось выше...
Хотелось бы подчеркнуть что тоном хорошего кода является не только название переменных конечно, но как то это зацепило так что не судите строго:)

Интересный пост о КырНете

Товарищ Пузанов недавно написал собственное ИМХО по поводу плачевной ситуации стартапов в Кыргызстане. Собственно сам пост http://news.kg/?p=548 . Неожиданно тема получила большую огласку и стала большой темой для обсуждения. Что же на мое мнение так это то, что все аргументы обоснованы и отражают суровую действительность, сложившуюся на сегодняшний момент...

Блог компании где я работаю

Быть может для кого то будет интересным, блог компании где я работаю находиться на http://news.kg . На блоге компании пишутся очень разные полезные вещи.Собственно сам сайт компании можно посмотреть на http://ikeen.com/ .