Баннизмы

Вот такой баннерочек встретил на obozrevatel.com. Это баннер сайта ru-kids.com. Виннипух подглядывает за некоей дамой. А старший Джери ковыряется без анестезии в глазу у младшего. Очень педагогично...

Популярность иконок

Команда NMap.org составила карту популярности сайтов через размеры их иконок. Как всегда, Гугель впереди планеты всей. Facebook - второй. Ну, а там уже и Майкрософт с Яндексом и Вконтакте на подходе :). В форме поиска можно найти положение в этой пищевой цепочке интересующего сайта.

Индийский перл в коде

Не Perl, а Перл :)

FILE* pLog = 0;
if(!pLog)
{
 char szPathLog[MAX_PATH]={0}; 
...

Активные кнопки избранного на панели интернет-обозревателей

Краткое предисловие

Решил выделить отдельный пост для собирания в нем java-script-действий, которые позволяют выполнять кнопками на панели избранного интернет-обозревателей (Opera, FireFox, Chrome) различные действия. Как-то: перевод выделенного текста, помещение текущей открытой страницы в Google Bookmarks, etc. Функции основаны на вызове внешних ресурсов и передаче им соответствующих параметров: выделенного текста, URL документа, его заголовка и т.д. Получается оффлайновый вариант сервиса AddThis. Нажаль, не на всех страницах установлен гаджет этого сервиса. А в аддоне к FireFox, например, у него почему-то отсутствует кнопка размещения заметки в vkontakte.ru. Ну и, в конце концов, можно делать что-то, чего нет в AddThis.

Итаг. Принцип работы прост. В трех перечисленных броузерах у настраиваемых кнопок есть интересующее нас свойство "Адрес", в котором по-умолчанию прописывается URL какого-то документа. Однако, вместо начального "http:" в этом поле нам ничего не мешает написать "javascript:" а далее - тело скрипта, который выполнится в контексте открытого документа. А дальше - сколько фантазии хватит.

Настройка

Во всех трех программах она одинакова:
1. открываем любую страницу в обозревателе,
127. перетягиваем адрес на панель настраиваемых кнопок за пиктограмму сайта, которая расположена слева от URL в поле ввода адреса,
128. на созданной кнопке щелкаем правой кнопкой мыши и выбираем пункт Свойства. В открывшемся окне вводим в поле Имя (Name), то, что будет написано на кнопке. В поле Адрес (Location) - скрипт, который будет выполняться.
129. Сохраняем.

Скрипты

Собственно, полезняшки.

Перевод выделенного текста в Google Translator:
Name: Vocab
Location: javascript:void window.open('http://translate.google.com/#en|ru|'+(window.getSelection()));

Внести в Google Bookmarks:
Name: BM
Location: javascript:void window.open('http://www.google.com/bookmarks/mark?op=add&bkmk='+encodeURIComponent(location.href)+'&title='+(document.title));

UPD: 14:03:2011
Внести в Google Bookmarks с заранее заданным тегом (я добавил тег later, под которым сохраняю в букмарках материалы, которые планирую прочитать позже):
Name: BM-Later
Location: javascript:tagNames="poster%2Clater"; javascript:void window.open('http://www.google.com/bookmarks/mark?op=add&labels='+tagNames+'&bkmk='+encodeURIComponent(location.href)+'&title='+(document.title));
Дополнение: в этой строке tagNames="poster%2Clater" содержимое кавычек представляет собой набор тегов, которые нужно присвоить букмарке, разделенные символом %2C - закодированный символ запятой.

Поделиться с VKontakte.ru:
Name: 2VK
Location: javascript:void window.open('http://vk.com/share.php?url='+encodeURIComponent(location.href)+'&title='+(document.title));

Поделиться с Facebook.com:
Name: 2FB
Location: javascript:void window.open('http://www.facebook.com/share.php?u='+encodeURIComponent(location.href));

Поделиться с LinkedIn.com:
Name: 2LI
Location: javascript:void%20window.open('http://www.linkedin.com/shareArticle?ro=false&mini=true&url='+encodeURIComponent(location.href));

Перевод выделенного текста в Abbyy Lingvo Online:
Name: Lingvo
Location: javascript:void window.open('http://lingvo.abbyyonline.com/ru/en-ru/'+(window.getSelection()));

Перевод выделенного адреса в Яндекс.Карты:
Name: Lingvo
Location: javascript:void window.open('http://maps.yandex.ru/?text='+(window.getSelection()));

Генерация QR-кода для активной URL:
Name: QR
Location: javascript:void window.open('http://qrfree.kaywa.com/?l=1&s=8&d=' + window.location.href);

Будет что-то интересное - делитесь.

P.S.: Пункты с 2 по 126 потерлись.

Федорино горе. Размышлениям посвящается.

Давно у меня зрели в голове размышления на предмет подоплеки небезызвестного стихотворения К.И. Чуковского "Федорино горе" (ссылку привожу случайную - в интернете, благо, немало источников подобной литературы). Не знаю как сейчас (что-то сумлеваюсь на этот счет), а в мои школьные годы мы учили этот стишок. И даже, помнится, пересказывали наизусть.

Тогда, конечно, все было просто и понятно. Старая тетка не моет посуду. Фу, какая она глупая. Как же можно есть из старой посуды?!

Но приходится взрослеть и смотреть на разные вещи под другим углом. Примером этого взросления может служить этот мультфильм.

Но всё по порядку. Итак. С чего начинается произведение?

Скачет сито по полям,
А корыто по лугам.

За лопатою метла
Вдоль по улице пошла.

Топоры-то, топоры
Так и сыплются с горы,

Испугалася коза,
Растопырила глаза:

"Что такое? Почему?
Ничего я не пойму".

... и т.д. Пока всё радужно и сказочно. Немного можно поволноваться за "крышу" козы, но оставим это "зеленым" - она ж коза всего лишь. Однако дальше:

А за ними вдоль забора
Скачет бабушка Федора:
"Ой-ой-ой! Ой-ой-ой!
Воротитеся домой!"

А вот это уже настораживает! Вы где-нибудь видели, чтобы посуда бегала? Надеюсь нет. А знаете кого-либо, кто видел? Предполагаю возникновение хитрой улыбки и намеков на "Америка заметает следы", на свистуна на Греческой (кто не из Одессы - это блаженные персонажи одесского интерьера, думаю, их хватает в каждом поселении)... Вот то-то и оно. У Федоры-то, оказывается неполадки с психикой. Мало того, что она видит, как посуда от нее рвет когти. Федора еще и пытается увещевать ее вернуться обратно в дом (там, кстати, еще и коты разговаривают. да-да). Однако это не все симптомы. Посуда-то отчего убегает? От грязи! Содержание в такой грязи посуды, понятно крайне негативно будет влиять на пищеварение и другие составляющие здоровья нашей героини. Но она, как человек душевно больной, не в силах этого осознать. То есть, мы плавно подошли к основной идее этой заметки - Федора - тяжело больной человек. Не только физически (какое-то, довольно продолжительное время, она ж таки питалась из грязной посуды, что не могло не сказаться), но и психически - признаки мы увидели выше.
А знаете еще что? А вот что:

Тут Федорины коты
Расфуфырили хвосты,
Побежали во всю прыть,
Чтоб посуду воротить:

"Эй вы, глупые тарелки,
Что вы скачете, как белки?
Вам ли бегать за воротами
С воробьями желторотыми?
Вы в канаву упадёте,
Вы утонете в болоте.
Не ходите, погодите,
Воротитеся домой!"

И вот еще что:


Мимо курица бежала
И посуду увидала:
"Куд-куда! Куд-куда!
Вы откуда и куда?!"

То есть, в воображении Федоры разговаривает не только посуда, но и действительно живые, но обычно молчаливые существа - куры и коты, которые не смотря на недуги Федоры все-таки живут у нее. Что значит, что Федора заботится о них. По крайней мере о пропитании. А учитывая


Тут Федорины коты
Расфуфырили хвосты,
Побежали во всю прыть...

можно предположить, что коты имеют что расфуфыривать и достаточно имеют сил, чтобы гнаться во всю прыть за посудой. А это значит, что кормежка у них не самая худая. Посмотреть новости из Зимбабве - там многие двуногие не то что "во всю прыть", они и ползти-то не могут! Но это лирика.

Почему животные говорят? Да потому что Федора - человек абсолютно одинокий! У нее нет никого! Кроме животных. Которых она, чтобы пережить своё одиночество, силой воображения (а точнее немощью сознания) заставила говорить. Человек очень заботливый и очень одинокий.

Далее. Ежели ты, уважаемый читатель, прочел по приведенной выше ссылке упомянутое произведение детского (после этих размышлений уже немного странно звучит, правда?) поэта К.И. Чуковского, то, возможно ты заметил тот перечень посуды, который отправился в самоволку. А список это довольно внушительный. Сомневаюсь, что в нашем семейном посудном шкафу (aka горке) наберется две трети этого списка. А старый человек Федора живет одна. Зачем ей столько посуды-то? Посудная лавка у нее что ль? Напрашивается вывод, что наша героиня не всегда была одинока. Посуда у нее не пылилась. У нее была довольно большая и счастливая семья. Почему счастливая? Чуть позже. Сначала этот кусочек:

И они побежали лесочком,
Поскакали по пням и по кочкам.


и этот:

А посуда вперёд и вперёд
По полям, по болотам идёт.

Я хочу обратить внимание, что посуда в воображении Федоры движется не просто среди реально существующего городского (или сельского — не суть важно) антуража, окружающего Федору и являющегося фоном для ее мнимых картин. Посуда помимо этого движется по явно не городским массивам - по болотам, полям, горам... Да это же значит... Ага! Вот именно. Это значит, что Федора все эти картины дикой природы уже видела. Она путешествовала. И сейчас ее больное воображение достает из закоулков памяти давно забытые пейзажи, чтобы напомнить Федоре о тех временах, когда она с любимым человеком путешествовала по горам, по лесам, по болотам... По болотам редко устраивают туристические экскурсии. Резоннее было бы предположить, что в молодости наша героиня была геологом. А отношения, замешанные на трудностях и опасностях всегда очень крепки и дороги. Поэтому можно себе попытаться представить какую трагедию переживает Федора.

Однако и это еще не все. У меня, например, подкатил комок к горлу, когда я прочел эти строки:

Но чудо случилося с ней:
Стала Федора добрей.
Тихо за ними идёт
И тихую песню поёт:

"Ой вы, бедные сиротки мои,
Утюги и сковородки мои!"...

Сиротки! У нее были дети! У нее было несколько детей! Для нее эта пресловутая посуда олицетворяет ее детей! Она пытается поверить, что это ее дети! У нее была большая, счастливая семья! Они путешествовали, работали, веселились, радовались жизни... И в один миг Федора осталась одна! В полном одиночестве. Как? Почему? Где они? Что могло произойти? Вариант один - семья трагично погибла!

Какой же несчастный случай оставил этого человека - доброго, заботливого, умного (блондинок в геологи не берут) - совершенно одиноким? Какая ужасная трагедия произошла? Мне-то почем знать?! Боюсь, что это останется навсегда загадкой. Хотя автор произведения оставил нам небольшой намек на возможный сюжет развития тех ужасных событий:

И ответила посуда:
"Было нам у бабы худо,
Не любила нас она,
Била, била нас она,
Запылила, закоптила,
Загубила нас она!"
…

"Да, - промолвил медный таз, -
Погляди-ка ты на нас:
Мы поломаны, побиты,
Мы помоями облиты.
Загляни-ка ты в кадушку -
И увидишь там лягушку,
Загляни-ка ты в ушат -
Тараканы там кишат,
Оттого-то мы от бабы
Убежали, как от жабы,
И гуляем по полям,
По болотам, по лугам,
И к неряхе-замарахе
Не воротимся!"

Надеюсь, читатель, ты помнишь, что все эти диалоги рождает больное воображение нашей героини? Так вот, этими словами в лице посуды Федора проклинает себя за какой-то ужасный поступок. Посуда обвиняет ее и клянется в том, что никогда больше не вернется к своей хозяйке. Федора больше никогда посуду не увидит! НИ-КОГ-ДА! А как мы раньше уже отметили, посуда для Федоры олицетворяет собой ее безвременно ушедшую семью. Ее семья проклинает Федору за что-то. За какой-то ужасный проступок, из-за которого Федора обречена остаток дней своих влачить одинокое существование душевно-больного, покинутого всеми человека. "Загубила нас она!" Федора убила свою семью! Как? Почему? Была ли она в рассудке, или совершила это в бреду безумия? Совершила ли она этот поступок сама, или послужила одним из звеньев в цепи совпадений? Остается только гадать и рисовать себе ужасные картины, представшие перед ней, когда она осознала жестокость и непоправимость произошедшего.

Слабым утешением может служить, если так можно сказать, happy end этой ужасной истории:

И сказала скалка:
"Мне Федору жалко".

И сказала чашка:
"Ах, она бедняжка!"

И сказали блюдца:
"Надо бы вернуться!"

И сказали утюги:
"Мы Федоре не враги!"

Долго, долго целовала
И ласкала их она,
Поливала, умывала,
Полоскала их она.

"Уж не буду, уж не буду
Я посуду обижать,
Буду, буду я посуду
И любить и уважать!"

Хотя бы здесь, в реальности, нарисованной её больным воображением, Федора заслужила прощение. Единственное, что у нее осталось (посуда), решило не покидать ее в ее одиночестве.

Впервые ли? И надолго ли?

Искусство мыть слона

Вчера прочитал книгу (книга - сильно сказано - скорее брошюра, но оформлена хорошо) Влада Головача «Дизайн пользовательского интерфейса² Искусство мыть слона». Книга, как следует из названия, посвящена моральным началам разработки пользовательского интерфейса безотносительно к объекту применения оного. Автор книги не один год занимается разработкой UI всего, за что платят :) Так не сказать, чтобы книга открыла мне глаза, но несколько здравых мыслей я из нее почерпнул. По крайней мере, времени, потраченного на чтение, совершенно не жалею.

Free launch bar

Давно я уже пользую под виндой утилиитку True Launch Bar. Утилитка добавляет панель быстрого запуска к панели задач Windows. Но эта панель на порядок более конфигурабельна, нежели стандартный Быстрый Запуск. Конфигурабельность заключается в разворачиваемых меню, подменю, настраиваемых иконках и прочих фичах. Однако сия программка платная.
По причинам, описанным тут, начал поиск бесплатной альтернативы. Сразу же наткнулся на бесплатный вариант True Launch Bar - Free Launch Bar. Утилита - обрезанный вариант TLB. Однако функции у нее отрезаны именно те, которые я практически никогда не пользовал - плагины, настраиваемые контекстные меню и т.д. Поставил - радуюсь :)

Холодный чай

В пик жары (которая наконец-то спала) решил я попробовать приготовить холодный чай, чтобы не платить 6 грн за 0,5 литра чая Нестле. Получилось неплохо. Алгоритм:
1. Кипячу кастрюлю воды. У меня кастрюля 5 литровая. Воды кипячу примерно 4 литра.
2. После того, как вода скипела, в отдельной посудине (чашка около 1,5 литров объему) завариваю этим кипятком 6 ложек заварки (для этих целей пользую чай "Беседа" за 5 грн.). Чашку накрываю крышкой и оставляю завариваться около часа.
3. После этого заварку выливаю через ситечко в кастрюлю.
4. Добавляю сахар. Мне по вкусу подходит 15 чайных ложечек. Чай получается не очень сладкий, но небольшой сладинкой.
5. Добавляю лимон. Примерно треть лимона очищаю от кожуры и отжимаю в кастрюлю обычной советской чесноковыжималкой.
6. Добавляю какой-нить сиропчик (мы покупаем сироп "Еврогрупп" - его лью грамм 50).
7. Размешиваю получившийся чай и оставляю остывать.
8. При подходящей температуре разливаю по бутылкам и ставлю в холодильник.

Таким макаром себестоимостью гривни в 4 (около 50 центов) получается 4 литра холодного чаю, который очень приятно потягивать в жару. Да и не только в жару.

Один минус натуральности - срок хранения при комнатной температуре 2-3 дня. В холодильнике наверняка он может храниться дольше - проверить не было шансов - заканчивается раньше :)

Один из плюсов - можно регулировать разнообразные параметры напитка: крепость, сладость, привкус (за счет сиропов), и т.д. Если, например, положить больше заварки, то чай получится с приятной горчинкой - такой в бутылках не продают.

Undo history

Историческо-политический ляп. На лайтбоксе наложились 2 рекламных макетов - новый и старый. Получилось довольно символично. Снято вчера в Одессе, на ул. Космонавтов.

Наушники

Ремонтировал сегодня 2 пары наушников. Обычные китайские наушники Cosonic CD-850.
Обычная поломка - оборыв провода в месте пайки. На всякий случай решил набросать схему распайки проводов. Может пригодится кому.
Вот.

Что дальше?

Слёты=>BBS=>FIDO=>Usenet=>Персональные сайты=>JJ=>Блоги=>Twitter=>Ку. :)
Ку?
Ку!

Common mistakes in software testing and how to overcome

Еще одна заметка по тестированию софта от того же индуса:

---

Common mistakes in software testing and how to overcome: "There are common mistakes we do in testing. I am giving few examples from it.

1. Regression testing: we never follow
2. Developers word: this is my code; 100% accurate
3. Always testing with only the positive scenario
4. While reporting defect never thinking of developer’s situation or mind
5. Never explore the application
6. Missing code in the final deployment
7. Performance never observed or too late
8. Testing time estimation
9. Start testing too late
10. Clients always like to change the requirements
11. Test is continuing still code changes in the final deployment; not a full cycle testing/complete testing
12. Recruiting testers from the ranks of failed programmers
13. Using testing as a transitional job for new programmers and anyone can test
14. Better understanding and efficient communication between programmers and test engineers
15. Programmers cannot test their own code, not happy with Unit testing and testing script
16. Liking more execution of test rather than design/ un-reviewed test designs
17. Not but testing also need to take as group work not isolated than development
18. UI issue or cosmetic issue never gets priority by developers
19. Attempting to automate all tests/ expecting to rerun all manual tests
20. Test coverage

1. Regression testing: Whenever its time to regression tests; we never have enough support for time, talents and test environment. If we like to regression test properly then help of automation script base test required. But initial cost and time of automation is more and expertise for automation test is not available. So, never come up with better solution for regression test and this is basically partial test and obviously it’s dangerous for live project like www.ourleague.com

To overcome this issue we need to allocate enough time, talent and test environment.

2. Developers word: this is my code; 100% accurate: Over confidence is dangerous same as lack of confidence. Sometime developer would say: this is my code; 100% accurate and never believe.

I know how super smart programmer you are and obviously I will appreciate this but I will do my testing that should be fulfilled my already planned test. If you believe this type of word simply you will get killed.

3. Always testing with only the positive scenario: Some or for many reason we do only positive testing and basically this is not testing. Software will work, everyone knows but why we are testing? We need to break the box so that client never gets the panic.

The programmer also tests their own code and they work for running the application. So, if we test engineer do the same task with more exploring the positive scenario that’s not sounds good. We need to cover negative scenario as well.

Here also time, cost and test environment is the de facto.


4. While reporting defect never thinking of developer’s situation or mind: This is a very common mistake for test engineers, while reporting defect they never think from developer mind. We always report defects and think it’s understandable. This is something like handwriting; if someone thinks that I can read my hand writing and saying: other people can read because I can read it.

Defect reporting is very special quality for a test engineer. Before reporting please reproduce it properly and try to make the path of replication clear and concise, give idea to the developer what makes this defect. Then only they will respect and will give us value for saving their time by proper defect reporting. Every time we must think it’s not me but others also need to be understandable. Write it with text, if needed put images if more then make video file.

5. Never explore the application: Exploring the application is very important so that we can rarely miss any defects. Most of us never try to explore the application; only trying with limited scenario. Later clients find bugs and the test engineer cried loudly!!! What makes me miss this silly mistake; it’s needed exploring.

For example, MS Word; we can print several ways 1. File option 2. Ctrl+P 3. Print button 4. Preview and Print button and so on

If there are several input fields then changing the sequence may work.

How to do this I cannot give any answer but just one word “EXPLORE”


6. Missing code in the final deployment: This is the worst case ever we worked. This can messed up every good works, one of our build is ready for the live suddenly we found mixing of old and new codes. Unfortunately it’s not the entire version code but partial code and finding and merging it more difficult and the final moment of deployment.

I guess we need more awareness of code management tools and use. Moreover tag for the version is essential and every developer must be careful of checking in and out and if there are branches then the merging also important. We should take care of these before the final deployment and for this we can use checklist.


7. Performance never observed or too late: Application goes in live without measuring the performance that really crucial. How many users will hit at time? Or how will be the hardware configuration? These things need to be resolved before deploying in the production. Maximum cases we never care about the performance and if we think then too it’s late just before the deployment we used do some formal performance testing not enough for the live. As a result when server goes down; nothing could be done except cutting off the engineers sleeping time and heavy load work and returning home late night with panic.

We can avoid this panic if early performance tests plan and execution possible.


8. Testing time estimation: This is an issue always fussing between testing and development team. The programmer thinks about testing that it should not take longer time. Obviously maximum cases deployment get ready and test engineer starts test execution and it will be the eleventh hour for the shipment and not getting enough time to test. There are some tools to estimate the testing time but you know non can say the estimation is accurate; so many variables and dependency.

As a software test manager better is to define the task could be finish by timeline. If management asks about testing time estimation we could say by this time we could cover these area and if you give us time then we can cover full regression etc.

9. Start testing too late: It is another common problem with testing. Test engineer never get involve from the very beginning of the project. So, there were huge gap with test engineer and the project; may be the test engineer is busy with testing another project.

But you know it’s never been wise decision always it will kill our time. If the test engineer could be engaged with the project he/she could give better output. So, eleventh hour testing and humping and jumping won’t work to build better software. Continuous testing is always better than the traditional testing, it saves time and cost.

10. Clients always like to change the requirements: This happens for maximum clients and we cannot ignore it. There are lots of funny story about client requirement changes. Things like their requirement initially and finally far difference it’s because of unable to fix their requirements.

To cope up with the requirements we need very close interaction with the clients from the start to end of the projects. We have to understand the clients’ knowledge on the domain of the software and regular feedback from customer. It’s better to build the software sprint wise and feedback will be accommodated within the sprint to save panic and headache.

11. Test is continuing still code changes in the final deployment: Again common scenario; we have started our regression testing and supposed to be complete the regression cycle without having any more changes. But we CANNOT stop it, management or may be influence of present needs there will be code changes and deployment while we are half or some portion of regression testing.

Finally half done situation we will continue with regression testing with the code changes and deployment and you believe me this is not the full cycle REGRESSION test.

12. Recruiting testers from the ranks of failed programmers: This is simply horrible; some people got the idea TESTING is the easiest job in the world anyone can do it. I have faced this problem from my experience; management insist to hire those are failed in programming skill. Even I have seen one of the engineers in software testing even does not have the idea EXCEL needs to save to retrieve data for the future.

There is only one way to stop this type of situation that is showing how critical testing JOB is and how much important to make the software better to compete in the market to grab clients and users.


13. Using testing as a transitional job for new programmers and anyone can test: Here is another thinking of software testing. Management why to unutilize our new programmers they can do testing job and that is enough. Even some of them are thinking anyone can do testing…


14. Better understanding and efficient communication between programmers and test engineers: This is a vital point to build better software. It’s a TEAM work not one man show job. Because one man can do many things but his concentration will be focused on some area and other area will be dark enough to spoil it. When there are better communication channel with programmers and testers its make huge different than NOT.

Regular team meeting and milestone of the project and understanding between team members are essential. This type of gap can mess up in the end. We can use tools for better communication and regular team meeting achieve this goal.


15. Programmers cannot test their own code, not happy with Unit testing and testing script: I have seen so many programmers; they are great in their coding skill nicely implementing critical logic but when you say you have to write test code. That’s make over-burden to them but I guess it should not be like this. Anyone who is passionate on developing software should not afraid of test code. I know it’s again headache to write the codes but later it will bring the best fruit. And may be always its better to test code with peer or something like that to bring better results e.g. we review our test script/test cases.


16. Liking more execution of test rather than design/ un-reviewed test designs: This is major part of testers and maximum we failed here to make it. Whenever we develop test plan and test cases/scripts once execution starts we never update or re-design the test plan and test cases/scripts. Everyone wish to execute/testing more rather updating or re-designing the test plan and test cases/scripts. As a result we unable uncover critical issue in the end.


17. Not but testing also need to take as group work not isolated than development: Some people have the idea that testing is a different kind of job and so this talents are isolated from the TEAM. We need to remember again and again it’s a TEAM work. This lead to miscommunication, misunderstanding and the other type of mis…


18. UI issue or cosmetic issue never gets priority by developers: Huh! This is very minor issue and we are not going to fix it- its development view. Developer used to blame testers you unable find bugs with the functionality and finding this type of low priority issues. When we met someone we glance each other face not the internal things e.g. how soft minded the person would be? That part will come later. Same way the UI issues might be not critical as functional breakage but again this is like the given example. So many clients are there; they liked to see the UI is accurate first otherwise they will not go for touch it.


19. Attempting to automate all tests/ expecting to rerun all manual tests: Automate test is superb; it’s faster, efficient, less time and cost consuming. True, but we cannot automate ALL the features. Nothing is above MANUAL testing. Some will understand that we will automate our testing process and it will take care of manual testing. That’s what there is certain criteria before going for automation tools and again this cannot fulfill the gap of manual testing. We should have better understanding of it.


20. Test coverage: How we will measure test coverage? We know there is NO way to complete testing. But we have stop our testing process and it cannot be an infinite process. There are certain points to set the test coverage. In my opinion, we can set the criteria depending on nature of the project and always it will differ one to another.

We can have a look here for complete testing and test coverage: http://www.kaner.com/pdfs/impossible.pdf
http://asusrl.eas.asu.edu/cse565/content/coverage/coverage.pdf



References:

1. Classic Testing Mistakes, Brian Marick, Testing Foundations

2. M. Cusumano and R. Selby, Microsoft Secrets, Free Press, 1995.


3. Michael Dyer, The Cleanroom Approach to Quality Software Development, Wiley, 1992.

4. M. Friedman and J. Voas, Software Assessment: Reliability, Safety, Testability, Wiley, 1995.

5. C. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software (2/e), Van Nostrand Reinhold, 1993


6. Cem Kaner, J.D., Ph.D. (http://www.kaner.com)

7. http://asusrl.eas.asu.edu/srlab/

"

---

Startup testing part 1

Заметка индийского блоггера и тестировщика Md. Shaiful Islam. Его блог посвящен тестированию ПО - aka QA. В этой заметке собраны основные постулаты области QA, из которых выростает дальнейшая гора всего остального :)

---

Startup testing part 1: "

I am starting here my new sharing “Startup testing part 1” for those who likes to start career of software testing. This will give a basic idea about testing and glimpse of it.

Definition:

• Testing is a process of evaluating a system by manual or automation means and verifies that it satisfies specified requirements or identifies difference between expected and actual result.


• Quality provides customer satisfaction for the first time and every time. It is the factor affecting an organizations long term performance and improves productivity and competitiveness.

Why Testing?

• Software testing is important as it may cause mission failure, impact on operational performance and reliability if not done properly.

• Deliver quality software products; satisfy user requirements, needs and expectation.


• Uncover defects before the products install in production, it can save a huge loss.

Participants in Testing:

• Software Customer


• Software User


• Software Developer


• Tester


• Information Service Management


• Senior Organization Management

Some Recent Major Computer System Failures Caused by Software Bugs:

• According to news reports in April’04 software bug was determined to be a major contribution to the 2003 Northeast blackout, the worst power system failure in North American history. The failure involved loss of electrical power to 50 million customers, forced shutdown of 100 power plants, and economic losses estimated at $6 billion. The bug was reportedly in one utility company’s vendor supplied power monitoring and management systems, which was unable to correctly handle and report on an unusual confluence of initially localized events. The error was found and corrected after examining million of lines of code.

• In India September ’04 Aircel Cell Company got a defect in their prepaid subscriber billing system. Result nearly one month we got all free outgoing. They found the defects earlier but correcting the defects itself it took long time. I don’t have the exact official estimation of loss. But I made all ISD call nearly 100 hours free of cost.

• A software bugs in a Soviet early warning monitoring system nearly brought on nuclear war in 1983, according to news reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet Satellites picking up sunlight reflections off cloud tops, but failed to do so. Disaster was averted when a Soviet commander, based on what he said was a’...funny feeling in my gut’, decided the apparent missile attack was a false alarm. The filtering software was rewritten.  

Software Development Life Cycle:

• Requirement- SRS (Software Requirement Specification)

                             SRAS (Software Requirement & Analysis Specification)

                             FS (Functional Specification)

• Design- HLD (High Level Design)

                    LLD (Low Level Design)

• Coding- According to code format


• Testing


• Implementation


• Maintenance

Testing Economic & Cost:

Traditional Test			Continuous Test
Accumulated Test Cost	Accumulated Error Remaining	Development Cycle	Accumulated Test Cost	Accumulated Error Remaining
0	20	Requirement	10	$10
0	40	Design	15	$25
0	60	Code	18	$42
$480	12	Testing	4	$182
$1690	0	Production	0	$582

Testing:

Static (Review)

Dynamic (Execution)

Static:

       Only review not execution of the program

Dynamic:

Structural (logic, white box testing, developer)

Functional (no logic, black box testing, tester)

What is Test Plan?

·        Road map for the entire testing activity

What are Test Cases?

·        Set of procedures which we execute in our system to find defects

Primary Role of Software Testing:

·        Determine whether the system meets specification (Producer View)

·        Determine whether the system meets business and user needs (Customer View)

Role of Tester:

• Find defect not correcting the defects

What is Defects?

• A defect is a variance from a desired product attributes


• Variance from customer/user expectation

Classification of Defects:

• Wrong (ER! = AR)


• Missing (Missing some point)


• Extra (Extra point)

Regression Test:

Tester-> 1000-test cases-> 100 defects-> developer-> tester

Functional Testing:

• Structure of the program is not considered


• Test cases are decided base on the requirements or specification of the program or module


• Hence it is called “Black Box” testing

Structural Testing:

• Concerned with testing the implementation of the program


• Focus on the internal structure of the program


• The intention of structural testing is not to be exercise all the different I/P or O/P condition but to exercise the different programming structure and the data structure of the program

Testing Levels:

• Unit Testing


• Integration Testing


• System Testing &


• Application Under Test (AUT) or

User Acceptance Test (UAT)

Unit Testing:

• LLD


• Module Testing


• Individually Testing


• White Box Testing


• Developer job

1. Test each module individually


2. Follow White Box Testing (logic of the program)

Integration Testing:

• LLD+ HLD (Developer+ Tester)


• Communication+ Data Flow


• WB+ BB= Gray Box


• Integrate two or more module i.e. Communicate between modules


• Follow a White Box Testing (testing the codes)

System Testing:

• Confirms that the system as a whole delivers the functionality originally required.


• Follow Black Box Testing


• Functionality Testing, Tester job

User Acceptance Testing:

• Building the confidence of the client and users is the role of the acceptance testing phase


• It is depend on the business scenario


• Red Box Testing (crucial)

"

---

Unreal Commander - бесплатная альтернатива Total Commaner-у

На текущем месте работы строго настрого запретили ставить платное ПО. Практически всё, что нужно, я уже давно себе подобрал. А вот Total Commander-ом до сих пор пользуюсь. Но пришлось искать бесплатную альтернативу - хоть он и shareware, но не бесплатный.
Перепробовал несколько вариантов. Остановился на файл-менеджере Unreal Commander. Программка хороша тем, что практически полностью копирует функционал TC - перепривыкать не приходится (ну, ежели только к пиктограммке). Есть небольшие косметические отличия (есть некоторые ляпы и неаккуратности), некоторые различия в горячих клавишах. Но все эти немногочисленные недостатки покрываются бесплатностью, настраиваемостью и поддержкой плагинов к TC.
В общем, рекомендую.

Скрещивание Opera и Google.

Возвращаясь к заметкам http://rettpop.blogspot.com/2010/02/google-opera.html и http://rettpop.blogspot.com/2010/01/opera-google-bookmarks.html. Тот же самый механизм работает без изменений в Google Chrome. Что не может не радовать :).

UPD: 24/08/2010
В FireFox этот механизм работает без изменения. Кроссплатформенность, аднака :)

aviary.com - набор онлайновых генераторов

Набрел на сайтик aviary.com, на котором представлен набор генераторов/редакторов различного контента - музыки, векторной графики, скриншотов, etc.


Улыбнуло и приятно порадовало наличие генератора музыки. Когда-то было популярным направление трекерной музыки, которая создавалась в специальных редакторах и представляла собой набор семплов (коротких звукозаписей чего угодно), расположеных на временной линии, с указанным тоном воспроизведения, громкостью и еще некоторыми параметрами. В результате получались очень симпатишные композиции, для создания которых не требовалось какого-то специального оборудования и особых знаний.
И вот, в 21 веке этот механизм перенесли в WEB.


В дополнение к этому могу порекомендовать онлайн-конвертер http://www.online-convert.com/. Конвертирует аудио, видео, текст, изображения, ебуки и в дополнение генерирует HASH-ы. Сервис доаольно редко требующийся, но когдга под рукой нет нужного конвертера - очень раздражает. А тут - почти всё - в одном флаконе.

"The Link" Music Video - 8BIT Rap. Квазиретро :)