Периодами в работе приходится считать сумму НДС, для тех, кто не знает, объясняю... У Вас есть сумма 100 000 у которой написана хорошо всем известная, но загадочная для многих фраза "в т.ч. НДС", и Вам как раз нужно определить сумму НДС.
Ну, как обычно и бывает один раз понадобилось, подумал, посчитал ну и забыл за не надобностью, но вдруг спустя пару месяцев снова надо... опять думать, считать и... забывать. :) И вот буквально вчера, моя девушка попросила помочь, посчитать эту саму сумму НДС, алгоритм расчёта которой я, конечно же, забыл, пришлось вспоминать и помогать... И тут я подумал "Я же супермегапрограммист!" и решил написать маааалюююсенький скриптец, который будет мне помогать думать меньше по пустякам, и надеюсь, кому-то ещё поможет.
В итоге, обращаю внимание тех, кто сталкивался, сталкивается или столкнулся с задачей определить сумму НДС на правую часть блога чуть ниже облака тегов и рекламы, там прячется калькулятор расчёта суммы НДС :)
Излучайте добро!
четверг, 18 февраля 2010 г.
среда, 17 февраля 2010 г.
Stickies, а мне нравится...
Хочу поведать об очередной, по-моему, мнению удобной и полезной тулзовине. Называется она Stickies. Программа позволяет вешать на рабочий стол стикеры-записки, мне программа показалась удобной. Плюс ко всему вес её последнего на данный момент релиза составляет ~ 1028kb, программа имеет простой и понятный интерфейс, кучу настроек и очень приличное кол-во скинов.
вторник, 16 февраля 2010 г.
Написание тест-кейса на процесс завязывания шнурков
Продолжая серию заметок о собеседованиях, хочу рассказать о задачке о которой услышал от своего нынешнего руководителя. Суть задачки состоит в том, чтобы собеседуемый описал процесс завязывания шнурков, в идеале в виде тест-кейса если речь идёт о специалисте. Задачка по сути не представляет ничего инетресного, в прочем как и тестирование чашки, но по опыту хочу Вам сказать, что не говоря уже о способах решения и о самих решениях, даже реакция у многих очень интересная.
Нюанс задачки в том, что её можно усложнить исключив из использования в нашем тест-кейсе некоторые слова, например, слово петля.
Откровенно говоря некоторые тест-кейсы меня, мягко говоря, удивили... т.е. были написаны так по моему мнению качественно и понятно, что мне такое описание и в голову бы даже не пришло.
В общем советую Вам попробовать использовать эту задачку, только сначала попробуйте определить цели и выводы которые Вы сможете сделать при тех или иных решениях....
Нюанс задачки в том, что её можно усложнить исключив из использования в нашем тест-кейсе некоторые слова, например, слово петля.
Откровенно говоря некоторые тест-кейсы меня, мягко говоря, удивили... т.е. были написаны так по моему мнению качественно и понятно, что мне такое описание и в голову бы даже не пришло.
В общем советую Вам попробовать использовать эту задачку, только сначала попробуйте определить цели и выводы которые Вы сможете сделать при тех или иных решениях....
понедельник, 15 февраля 2010 г.
Тестирование чашки
Забавное, но по моему показательное задание для тестировщиков... его можно применять как при приёме новых сотрудников, так и при работе с уже работающими в компании специалистами.
Задание заключается в том, чтобы протестировать чашку! Написать своеобразный чеклист, набор пунктов, что именно и зачем нужно протестировать, по сути можно по ходу общения с "подопытным" изменять и дополнять задание.
Смешно?!
На первый взгляд да, смешно, но если попытаться ответить, то окажется, что не для всех это задание окажется простым. Хотя конечно стоит понимать, что задание призвано оголить подход, мышление человек...
Основной плюс этого задания в том, что на его основание можно судить о направлении мыслей тестировщика.... Попробуйте составить список того, что и как необходимо протестировать в чашке... после того, как составите, смотрите чужие наброски:
Источник
Задание заключается в том, чтобы протестировать чашку! Написать своеобразный чеклист, набор пунктов, что именно и зачем нужно протестировать, по сути можно по ходу общения с "подопытным" изменять и дополнять задание.
Смешно?!
На первый взгляд да, смешно, но если попытаться ответить, то окажется, что не для всех это задание окажется простым. Хотя конечно стоит понимать, что задание призвано оголить подход, мышление человек...
Основной плюс этого задания в том, что на его основание можно судить о направлении мыслей тестировщика.... Попробуйте составить список того, что и как необходимо протестировать в чашке... после того, как составите, смотрите чужие наброски:
- Предназначение: для какого напитка? горячего или холодного?
- Габариты
- материал
- теплопроводность: мы же не хотим обжечься, если будем пить что-то горячее и наоборот хочется, чтобы холодная (горячая) жидкость была как можно дольше холодной (горячей)
- устойчивость на поверхности: если она пуста, если она полна горячей жидкости, а если холодной, проверить влияние на это состава жидкости (кола, кофе, чай, сок, вода)
- устойчивость к падению с поверхности: если она пуста, если она полна горячей жидкости, а если холодной, проверить влияние на это состава жидкости (кола, кофе, чай, сок, вода)
- форма каемки (вдруг порежимся или жидкость будет выливаться мимо рта)
- форма ручки (вдруг палец не влезет или застрянет)
- удобство (как ложится в руку, легко ли ее поднимать). туда, конечно, же можно отнести и 8, и 9 пункты, но я их все-таки решила выделить отдельно.
- дизайн: цвет, наклейки, веселые рисунки
- не маркость. чистота. чтобы тот самый дизайн не остался на наших руках в виде разводов и пятен, а уж тем более не попал в наш кофе :) при этом стоит проверить, поведение как при холодной жидкости, так и при кипятке (не говоря уж о составе)
- экологичность. чтобы ничего "анти-полезного" не выделялось из кружки в жидкость или окружающую среду. опять же протестировать с разными составами и температурой жидкости
- легко ли ее утилизировать?
- а какова себестоимость? цена?
Источник
пятница, 12 февраля 2010 г.
Митинг как необходимая часть рабочего процесса...
Википедия гласит:
Практика проведения ежедневных митингов для сихронизации работы команды, наверное, самая полезная из всех практик гибкой разработки. Я не раз слышал, как её рекомендовали использовать вполне себе классические менеджеры проектов.
Такие митинги называются по-разному. В Scrum - это Daily Scrum Meeting, в XP - это stand-up meeting. Иногда его называют просто Status Meeting. В Luxoft его принято называть Daily Scrum или просто скрам. Так зачем нужен скрам?
Основная цель скрама — синхронизация работы команды. Каждый член команды должен знать чем занимаются другие люди. Что дает такое знание? Прежде всего минимизацию напрасной траты времени, связанной с недостаточной осведомленностью членов команды.
А как Вам такой взгляд на митинги?!
Митинг (англ. meeting — собрание) — массовое собрание для обсуждения злободневных вопросов текущей жизни, в поддержку определённых требований, так и для выражения солидарности или протеста.
Практика проведения ежедневных митингов для сихронизации работы команды, наверное, самая полезная из всех практик гибкой разработки. Я не раз слышал, как её рекомендовали использовать вполне себе классические менеджеры проектов.
Такие митинги называются по-разному. В Scrum - это Daily Scrum Meeting, в XP - это stand-up meeting. Иногда его называют просто Status Meeting. В Luxoft его принято называть Daily Scrum или просто скрам. Так зачем нужен скрам?
Основная цель скрама — синхронизация работы команды. Каждый член команды должен знать чем занимаются другие люди. Что дает такое знание? Прежде всего минимизацию напрасной траты времени, связанной с недостаточной осведомленностью членов команды.
Длительность этого митинга строго ограничена — она не должна превышать 15 минут. Скрам не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за его пределы.
А как Вам такой взгляд на митинги?!
К сведению:
Федеральный закон от 19 июня 2004 г. № 54-ФЗ «О собраниях, митингах, демонстрациях, шествиях и пикетированиях» формулирует митинг как «массовое присутствие граждан в определённом месте для публичного выражения общественного мнения по поводу актуальных проблем преимущественно общественно-политического характера».
четверг, 11 февраля 2010 г.
Цитата от Авраама
Мой отец говорил, что нужно много работать. Он не говорил, что нужно любить много работать.
Авраам Линкольн
вторник, 9 февраля 2010 г.
Очередная порция цитат...
Нет ничего хуже для потери имиджа и доверия, чем оправдания!
Не надо оправдываться. Надо изначально быть честным. Это - единстенно выиграшная стратегия. И в жизни, и в бизнесе.
Лучше получать по 1% от усилий 100 человек, чем 100% только от своих собственных усилий
Лучше украсть чьё-то хорошее, чем сделать своё, но плохое.
Друзей за деньги не купишь, а вот врагов можно выбрать поприличнее...
Не надо оправдываться. Надо изначально быть честным. Это - единстенно выиграшная стратегия. И в жизни, и в бизнесе.
Репан Д.
Лучше получать по 1% от усилий 100 человек, чем 100% только от своих собственных усилий
J. Paul Getty
Лучше украсть чьё-то хорошее, чем сделать своё, но плохое.
Голландская пословица
Друзей за деньги не купишь, а вот врагов можно выбрать поприличнее...
Неизвестный автор
Полезный плагин для Mantis Bug Tracker'а
Хочу поведать Вам об одном показавшимся мне полезным, т.е. скорее даже делающим более удобным использование mantis'а плагине - это плагин HTMLmail.
По сути этот плагин просто облагораживает внешний вид уведомления приходящего на почту при тех или иных событиях на баг трекере.
Возможности
Установка плагина HTMLmail производится через Plugin Manager. Что касается настройки, то я для себя немного допиливал интерфейс, делал его вид немного приятней моему глазу, а в остальном плагин HTMLmail никаких настроек не потребовал. Если кто хочет, то с помощью редактирования или создания собственных шаблонов можно поиграться с телом письма, а непосредственно через интерфейс можно изменять формат темы письма, выбирать шаблоны для проектов, пользователей или изменять глобальные настройки по умолчанию.
Настройка формата сообщения
Выбор используемого шаблона
Указание формата темы сообщения
Работа
Что касается самих писем, то вот так выглядит стандартное уведомление приходящее на почту при тех или иных событиях
А вот так аналогичное уведомление выглядит при использование стандартного шаблона плагина HTMLmail и при использовании формата HTML
Для тех кто работает с mantis'ом этот плагин должен показаться интересным, ведь он по сути присылает "скриншот" расширенного просмотра отчёта.
Скачать плагин можно здесь
По сути этот плагин просто облагораживает внешний вид уведомления приходящего на почту при тех или иных событиях на баг трекере.
Возможности
- Несколько форматов письма: текст, HTML и смешанный;
- Возможность работать с уведомлениями в Skype;
- Поддержка шаблонов;
- Кастомизация для каждого проекта и пользователя индивидуально;
- Простота в установке;
- Mantis начиная с версии 1.0.5
- Plugin Manager начиная с версии 0.4.0
- Плагин Skype начиная с версии 0.0.1 в случае если вы хотите получать уведомления в Skype
Установка плагина HTMLmail производится через Plugin Manager. Что касается настройки, то я для себя немного допиливал интерфейс, делал его вид немного приятней моему глазу, а в остальном плагин HTMLmail никаких настроек не потребовал. Если кто хочет, то с помощью редактирования или создания собственных шаблонов можно поиграться с телом письма, а непосредственно через интерфейс можно изменять формат темы письма, выбирать шаблоны для проектов, пользователей или изменять глобальные настройки по умолчанию.
Настройка формата сообщения
Выбор используемого шаблона
Указание формата темы сообщения
Работа
Что касается самих писем, то вот так выглядит стандартное уведомление приходящее на почту при тех или иных событиях
Для тех кто работает с mantis'ом этот плагин должен показаться интересным, ведь он по сути присылает "скриншот" расширенного просмотра отчёта.
Скачать плагин можно здесь
Нужно ли знание теории тестировщику?!
Зачастую сталкиваюсь с ситуацией, когда от начинающих тестировщиков требуют знаний теории тестирования, знаний методологий, подходов....
Ну скажем так, для менеджеров и инеженеров по тестированию эти знания естественно важны, ведь они ведущие, а как быть с ведомыми, как быть с monkey?!
Ну скажем так, для менеджеров и инеженеров по тестированию эти знания естественно важны, ведь они ведущие, а как быть с ведомыми, как быть с monkey?!
четверг, 4 февраля 2010 г.
воскресенье, 31 января 2010 г.
Как добавить Sitemap для Blogger?
Если мы уже зарегистрировались в Google Webmasters Tools и Яндекс.Вебмастер - то мы должны знать о том, что там есть графа "добавить sitemap для сайта".
Что такое "sitemap"? Процитирую Google:
А вот Яндекс пишет: "Невалидный XML". При этом тот сайтмэп что Яндекс автоматически ставит себе для блоггера (говоря что он нашёл его в robots.txt), т.е.
Что такое "sitemap"? Процитирую Google:
Файл Sitemap - это список страниц вашего веб-сайта. Создание и отправка файла Sitemap позволяют обеспечить наличие данных в системе Google обо всех страницах на вашем сайте, включая URL-адреса, которые невозможно обнаружить в ходе стандартного процесса сканирования.Одним словом - это то, что помогает поисковой системе лучше и успешнее индексировать ваш сайт. Ранее некоторые пытались скормить sitemap для Google в виде их RSS потока. Но тут есть нюанс - в этом случае индексируются только 25 (или двадцать, уже не помню точно) последних сообщений. Был и ещё какой-то не особенно эффективный способ - его я тоже не могу сейчас вспомнить. Самый распространённый и действенный способ - это сделать sitemap на сто сообщений. Больше за один sitemap не выйдет. Почему больше не получится уже не помню - кажется из-за того, что больше не получится выдать в канале. Для этого надо дать Google'у sitemap следующего вида:
http://www.bugtrack-online.blogspot.com/atom.xml?redirect=false&start-index=1&max-results=100Этот sitemap будет действовать для первых ста страниц блога. Но можно добавлять сразу несколько карт сайта, поэтому никто нам не мешает добавить, не теряя времени, и на будущее:
atom.xml?redirect=false&start-index=101&max-results=100У Google эти sitemap прекрасно работают и индексируются - я сам этим пользуюсь.
atom.xml?redirect=false&start-index=201&max-results=100
atom.xml?redirect=false&start-index=301&max-results=100
А вот Яндекс пишет: "Невалидный XML". При этом тот сайтмэп что Яндекс автоматически ставит себе для блоггера (говоря что он нашёл его в robots.txt), т.е.
http://www.bugtrack-online.blogspot.com/feeds/posts/default?orderby=updatedИм также не индексируется и выдаёт ту же самую ошибку. Меня ещё позабавило то, что в моём блоге, где сейчас порядка 98 постов, Яндекс насчитал аж 369 страниц, находящихся в его индексе. Это потому, что у нас есть страницы с адресом вида:
http://www.bugtrack-online.com/2008/05/blog-post_28.html?widgetType=BlogArchive&widgetId=BlogArchive1&action=toggle&dir=close&toggle=YEARLY-1199138400000&toggleopen=MONTHLY-1209589200000,MONTHLY-1222808400000А многие об этом даже не подозревают!
суббота, 30 января 2010 г.
Конвертация базы данных MySQL из одной кодировки в другую
Начальным условием является наличие базы MySQL в кодировке latin1 данные из которой криво отображаются при просмотре, такая ситуация, например, возникает при установке Mantis. Кодировка как правило обнаруживается не сразу, но т.к. в базе данных уже есть данные, то выход один - конвертировать. Базу требуется переконвертировать в UTF8 дабы решить вопрос с отображением.
В случае если вам требовалось конвертировать базу из latin1 в cp1251, то соответственно необходимо выполнять шаги с заменой UTF8 на ср1251.
- Создаём бэкап вашей базы выполняя команду: mysqldump -uUSER -Pport -hHOST -pPASSWORD > dump_name.sql
- Открываем, в моём случае Microsoft Office Word 2003
- Открываем в Word'е дамп базы, т.е. dump_name.sql
- Word предлгает выполнить преобразование открываемого файла из формата «Кодированный текст»
- По умолчанию Word предлагает выбрать кодировку Другая -> UTF8. Как правило дамп базы создаётся в кодировке UTF8 в независимости от кодировки данных.
- Соглашаемся
- Документ открылся и мы видим «кракозябру» в тех местах где должны быть кириллические символы
- Переходим в пункт меню Сервис и далее Исправить повреждённый текст...
- В исправленном тексте заменяем все «latin1» на UTF8
- Сохраняем исправленный документ
- Создаём базу выполнив скрипт: CREATE DATABASE `bd_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
- Заливаем наш исправленный дамп в базу выполнением команды: mysql -uUSER -Pport -hHOST -pPASSWORD bd_name < dump_name.sql
В случае если вам требовалось конвертировать базу из latin1 в cp1251, то соответственно необходимо выполнять шаги с заменой UTF8 на ср1251.
пятница, 29 января 2010 г.
CurrPorts - инструмент для мониторинга открытых TCP/IP и UDP портов и соединений
Оригинал описания:
Программа CurrPorts не требует установки и дистрибутив весит всего 61 кб.
CurrPorts is network monitoring software that displays the list of all currently opened TCP/IP and UDP ports on your local computer. For each port in the list, information about the process that opened the port is also displayed, including the process name, full path of the process, version information of the process (product name, file description, and so on), the time that the process was created, and the user that created it.
In addition, CurrPorts allows you to close unwanted TCP connections, kill the process that opened the ports, and save the TCP/UDP ports information to HTML file , XML file, or to tab-delimited text file.
CurrPorts also automatically mark with pink color suspicious TCP/UDP ports owned by unidentified applications (Applications without version information and icons)
Программа CurrPorts не требует установки и дистрибутив весит всего 61 кб.
При всей своей простоте CurrPorts имеет достаточно понятный интерфейс и приличный набор функций
Таблица с информацией по умолчанию имеет, по моему мнению слишком много информации, но это просто решается
Ничего необычного, но приятно, что программа умеет генерировать отчёты в html формате
Особенно понравилось то, что программа имеет достаточно гибкие настройки логирования, а также возможность самостоятельной русификации путём выполнения нехитрых действий:
- Запустите CurrPorts с параметром /savelangfile: cports.exe /savelangfile
- В папке CurrPorts будет создан файл cports_lng.ini
- Откройте файл в текстовом редакторе
- Переведите все необходимые вам пункты на русский
- Перезапустите CurrPorts
- Чтобы запускать CurrPorts с оригинальными настройками языка, нужно либо переименовать, либо удалить файл cports_lng.ini
четверг, 28 января 2010 г.
Денежная мотивация в проектах разработки ПО
Автор: Асхат Уразбаев
Допустим, у вас есть много денег и вы хотите вложить их повышение производительности ваших сотрудников. Есть один простой способ. Платите сотруднику пропорционально производительности. Большой выхлоп - много денег. Малый выхлоп - мало денег. В соответствии с теорией Павлова у сотрудника выработается условный рефлекс и он будет брызгать слюной к каждой выплате. Работает ли это? Конечно! С токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского. А вот с программистами не работает. И проблемы тут такие.
Проблема измеримости выхлопа
Нету линейки для программиста. Аршином общим не измерить. У них особенная стать. Ведь что такое производительность программиста? Кол-во строчек кода за единицу времени? Бред! Копипейст или просто выбор инструментов и подходов может породить практически любое кол-во. Кол-во багов? Не ошибается тот, кто ничего не делает. Ничего не пишем — нету и багов. Кол-во исправленных багов? Так ведь никакого героизма в исправлении багов нет. Смысл в том, чтобы не писать багов. Не хватало еще поощрять за их исправление! Задачка на полчаса — написать утилиту, которая путем внесения багов в код и исправлением их после репорта от тестера максимизирует ваш бонус. В общем, есть только один инструмент — произвол менеджера. Менеджер — это такой мудрый чувак, который знает, кто и как работает. А как он знает? А в этом и есть тайное знание менеджера и за это он получает деньги. А как он меряет своих ребят? У него есть ощущения. Например, если вы менеджеру кажется, что вы тормоз, то вам выставят BE (below expectations). Или, например, сделают вам маленький КТУ (коэффициент трудового участия). А ведь иметь маленький кту стыдно… Или еще как-нибудь вам дадут понять, что вы тормоз. Это называется «предоставить фидбек».
Проблема короткодействия денежной мотивации
Представьте, что у вас с вашим менеджером совет да любовь. Вам дали много денег (тем или иным способом) и вы садитесь за свой стол. Теперь вы, видимо, будете писать больше кода в единицу времени? Ну как же, вас же мотивировали! Раньше вам мало платили и вы нажимали на клавиши с ленцой, теперь такого вы не допустите. Стучать будете как стенографистка. Или может, теперь вы будете меньше багов делать? Да с чего вдруг? В общем, эффект будет сомнительным. Мотивация деньгами действует полчаса. Как только вы похвастались жене в аське — все! Вам уже мало.
Проблема конкурентности
А вот если, например, вас лишили премии. Что характерно, вашего товарища Васю при этом поощрили. Вы, конечно, расстроитесь. Но в то же время как-то соберетесь, мобилизуетесь и будете стараться . Да? Скорее всего - нет. Вы обидитесь на вашего менеджера (вы-то думали он друк!) и вашим любимым сайтом отныне будет hh.ru. Но пусть даже это не так. Ваши чувства к мудрому руководителю не угасли! Вы почувствовали справедливость его слов, и вашей целью отныне является то, чего хотел добиться Коля Остен-Бакен от Инги Зайонц - взаимности. Все лишние мысли - вон! Только работа. Остаемся по ночам. Пишем только качественный код (как, кстати, это делать по ночам?). И вот подходит к вам удачливый соперник Вася и просит помочь. Нет, вы не откажете. Вы не такой. Вы ему поможете — как только у вас появится время. То есть никогда. Вашего менеджера можно поздравить. Его крутая система мотивации уничтожила взаимопомощь и взаимовыручку в команде. А менеджер будет трагически говорить на ежеквартальных отчетах начальству: «Пора уже вам тщательнее подходить к подбору персонала! А то набираете сплошных безответственных уродов! Невозможно работать!» Так почему это работает с токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского? Все просто. Их труд можно легко измерить и от них не требуется командная работа. А денег должно просто хватать. Их уровень должен быть комфортным. Все остальная мотивация — неденежная.
Бонусы бесполезны?
Бонусы бесполезны? Я этого не утверждал. Я только хотел сказать, что с бонусами надо быть очень осторожным. А все дело в том, что деньги — это очень важно. А потому бонусы — очень мощный инструмент воздействия на сотрудников. Беда в том, что он не очень-то точный. А значит в большинстве бесполезный. Это как антибиотик широкого действия. Вы скорее всего зацепите инфекцию, но и убьете все полезные бактерии. Существуют правильные и полезные системы мотивации — и бонусы к ним не относятся. Недаром зарплату, бонусы и соцпакет называют компенсационным пакетом. Компания просто компенсирует вам тот прискорбный факт, что вам приходится ходить на работу вместо того, чтобы заниматься другими интересными штуками. В том числе и работать на более щедрую компанию :-). Вы просто не сможете настроить систему бонусирования достаточно точно. Ну, к примеру, вы выстроили классную схему. По ходу дела вы учли все ошибки и она стала идеальной. Вы решили, что бонусы должны быть высокими, если программисты работают в соответствии со своим планом. Если они отстают - бьем их рублем. Ведь это так прекрасно работает с консультантами! На самом деле у консультантов все супер просто потому, что у них есть нормативы. Известно, сколько времени на самом деле занимает задача. А у нас программисты сами оценивают свою работу. Вскоре выясняется, что люди перезакладываются — дают заведомо завышенные оценки. Вы уточнили формулу. Если человек успевает раньше плана - это тоже понижает бонус. Разумеется, надо учесть, что опередить в два раза — явное разгильдяйство, а сэкономить 10% квалифицируется как трудовой подвиг. Вы не сдерживаетесь и, как человек с высшим техническим образованием, подбираете полиномиальную функцию. Она правильно аппроксимирует бонусное вознаграждение в зависимости от плановых и реальных параметров. Там есть еще и весовые коэффициенты для разных типов задач (багфиксинг!=разработка нового), учет приоритетов проекта и прочие вещи, которые вы посчитаете важными. Ваша формула идеальна. Вы, как творец, испытываете гордость создателя. Вы рассчитываете, что программисты, понукаемые жаждой наживы, будут ответственно относится к оценкам трудозатрат и стараться успевать делать работу в срок, станут учитывать приоритеты работ и правильно вести свои трудозатраты в корпоративной системе учета. На самом деле тут может быть два варианта. Если бонусы в среднем относительно небольшие (ну, скажем, меньше 20% от зарплаты), то большинство людей будут относится к их получению (или потере) как к лотерее. Повезло — не повезло. Дело в том, что вашу систему мотивации просто никто не поймет. Она слишком сложная. На самом деле вам повезло. В этом случае ваша система по крайней мере не нанесет ВРЕДА. Хуже, если бонусы действительно важны для людей. Народ займется оптимизацией выплат. Ваши местные великие комбинаторы довольно быстро придумают 400 сравнительно честных способов отъема денег у руководства. Все мысли будут крутиться вокруг денег. Обсуждения правильных стратегий учета трудозатрат будут самыми вдохновенными и креативными. Они займут львиную часть времени разработчиков. Это негативно скажется на производительности программистов. Бонус — это message. Вы как бы говорите сотруднику — «чувак, ты работаешь за бабло». Люди прекрасно чувствуют такие сообщения, даже если они неявны. Излишне, я надеюсь, говорить, что бонусы ни в коем случае не должны быть отрицательными. Никаких штрафов — это демотиватор. Кстати, если чувак рассчитывает на бонус и не получает его - на практике это равносильно штрафу. Да он уже запланировал купить на бонус новый ноутбук! А тут вы со своими «на самом деле бонусы являются необязательной частью, бла-бла-бла». И заверения в стиле «мамочка тебя все равно любит» тут не исправят ситуацию.
Так что же делать с бонусами?
По моему мнению, есть только один более или менее полезный способ использовать систему бонусирования в нашем с вами бизнесе. Кто нам мешает — тот нам поможет. Можно использовать бонус как способ транслировать правильный message сотрудникам. Мне в голову приходит только один пример. Можно использовать бонусы для того, чтобы сообщить людям, как руководству важно достижение бизнес результатов. Например, отстегивать часть маржи сотрудникам. Сможете ли вы этим повысить их производительность? Навряд-ли. Но они точно станут немного более бизнес-ориентированными. Это просто еще один способ правильно расставить приоритеты. Будет прекрасный повод поговорить с разработчиками о том, что за продукт мы пишем и как мы собираемся захватывать рынок. По моему мнению, размер бонуса не должен превратить сам бонус в предмет культа.
Источник
Допустим, у вас есть много денег и вы хотите вложить их повышение производительности ваших сотрудников. Есть один простой способ. Платите сотруднику пропорционально производительности. Большой выхлоп - много денег. Малый выхлоп - мало денег. В соответствии с теорией Павлова у сотрудника выработается условный рефлекс и он будет брызгать слюной к каждой выплате. Работает ли это? Конечно! С токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского. А вот с программистами не работает. И проблемы тут такие.
Проблема измеримости выхлопа
Нету линейки для программиста. Аршином общим не измерить. У них особенная стать. Ведь что такое производительность программиста? Кол-во строчек кода за единицу времени? Бред! Копипейст или просто выбор инструментов и подходов может породить практически любое кол-во. Кол-во багов? Не ошибается тот, кто ничего не делает. Ничего не пишем — нету и багов. Кол-во исправленных багов? Так ведь никакого героизма в исправлении багов нет. Смысл в том, чтобы не писать багов. Не хватало еще поощрять за их исправление! Задачка на полчаса — написать утилиту, которая путем внесения багов в код и исправлением их после репорта от тестера максимизирует ваш бонус. В общем, есть только один инструмент — произвол менеджера. Менеджер — это такой мудрый чувак, который знает, кто и как работает. А как он знает? А в этом и есть тайное знание менеджера и за это он получает деньги. А как он меряет своих ребят? У него есть ощущения. Например, если вы менеджеру кажется, что вы тормоз, то вам выставят BE (below expectations). Или, например, сделают вам маленький КТУ (коэффициент трудового участия). А ведь иметь маленький кту стыдно… Или еще как-нибудь вам дадут понять, что вы тормоз. Это называется «предоставить фидбек».
Проблема короткодействия денежной мотивации
Представьте, что у вас с вашим менеджером совет да любовь. Вам дали много денег (тем или иным способом) и вы садитесь за свой стол. Теперь вы, видимо, будете писать больше кода в единицу времени? Ну как же, вас же мотивировали! Раньше вам мало платили и вы нажимали на клавиши с ленцой, теперь такого вы не допустите. Стучать будете как стенографистка. Или может, теперь вы будете меньше багов делать? Да с чего вдруг? В общем, эффект будет сомнительным. Мотивация деньгами действует полчаса. Как только вы похвастались жене в аське — все! Вам уже мало.
Проблема конкурентности
А вот если, например, вас лишили премии. Что характерно, вашего товарища Васю при этом поощрили. Вы, конечно, расстроитесь. Но в то же время как-то соберетесь, мобилизуетесь и будете стараться . Да? Скорее всего - нет. Вы обидитесь на вашего менеджера (вы-то думали он друк!) и вашим любимым сайтом отныне будет hh.ru. Но пусть даже это не так. Ваши чувства к мудрому руководителю не угасли! Вы почувствовали справедливость его слов, и вашей целью отныне является то, чего хотел добиться Коля Остен-Бакен от Инги Зайонц - взаимности. Все лишние мысли - вон! Только работа. Остаемся по ночам. Пишем только качественный код (как, кстати, это делать по ночам?). И вот подходит к вам удачливый соперник Вася и просит помочь. Нет, вы не откажете. Вы не такой. Вы ему поможете — как только у вас появится время. То есть никогда. Вашего менеджера можно поздравить. Его крутая система мотивации уничтожила взаимопомощь и взаимовыручку в команде. А менеджер будет трагически говорить на ежеквартальных отчетах начальству: «Пора уже вам тщательнее подходить к подбору персонала! А то набираете сплошных безответственных уродов! Невозможно работать!» Так почему это работает с токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского? Все просто. Их труд можно легко измерить и от них не требуется командная работа. А денег должно просто хватать. Их уровень должен быть комфортным. Все остальная мотивация — неденежная.
Бонусы бесполезны?
Бонусы бесполезны? Я этого не утверждал. Я только хотел сказать, что с бонусами надо быть очень осторожным. А все дело в том, что деньги — это очень важно. А потому бонусы — очень мощный инструмент воздействия на сотрудников. Беда в том, что он не очень-то точный. А значит в большинстве бесполезный. Это как антибиотик широкого действия. Вы скорее всего зацепите инфекцию, но и убьете все полезные бактерии. Существуют правильные и полезные системы мотивации — и бонусы к ним не относятся. Недаром зарплату, бонусы и соцпакет называют компенсационным пакетом. Компания просто компенсирует вам тот прискорбный факт, что вам приходится ходить на работу вместо того, чтобы заниматься другими интересными штуками. В том числе и работать на более щедрую компанию :-). Вы просто не сможете настроить систему бонусирования достаточно точно. Ну, к примеру, вы выстроили классную схему. По ходу дела вы учли все ошибки и она стала идеальной. Вы решили, что бонусы должны быть высокими, если программисты работают в соответствии со своим планом. Если они отстают - бьем их рублем. Ведь это так прекрасно работает с консультантами! На самом деле у консультантов все супер просто потому, что у них есть нормативы. Известно, сколько времени на самом деле занимает задача. А у нас программисты сами оценивают свою работу. Вскоре выясняется, что люди перезакладываются — дают заведомо завышенные оценки. Вы уточнили формулу. Если человек успевает раньше плана - это тоже понижает бонус. Разумеется, надо учесть, что опередить в два раза — явное разгильдяйство, а сэкономить 10% квалифицируется как трудовой подвиг. Вы не сдерживаетесь и, как человек с высшим техническим образованием, подбираете полиномиальную функцию. Она правильно аппроксимирует бонусное вознаграждение в зависимости от плановых и реальных параметров. Там есть еще и весовые коэффициенты для разных типов задач (багфиксинг!=разработка нового), учет приоритетов проекта и прочие вещи, которые вы посчитаете важными. Ваша формула идеальна. Вы, как творец, испытываете гордость создателя. Вы рассчитываете, что программисты, понукаемые жаждой наживы, будут ответственно относится к оценкам трудозатрат и стараться успевать делать работу в срок, станут учитывать приоритеты работ и правильно вести свои трудозатраты в корпоративной системе учета. На самом деле тут может быть два варианта. Если бонусы в среднем относительно небольшие (ну, скажем, меньше 20% от зарплаты), то большинство людей будут относится к их получению (или потере) как к лотерее. Повезло — не повезло. Дело в том, что вашу систему мотивации просто никто не поймет. Она слишком сложная. На самом деле вам повезло. В этом случае ваша система по крайней мере не нанесет ВРЕДА. Хуже, если бонусы действительно важны для людей. Народ займется оптимизацией выплат. Ваши местные великие комбинаторы довольно быстро придумают 400 сравнительно честных способов отъема денег у руководства. Все мысли будут крутиться вокруг денег. Обсуждения правильных стратегий учета трудозатрат будут самыми вдохновенными и креативными. Они займут львиную часть времени разработчиков. Это негативно скажется на производительности программистов. Бонус — это message. Вы как бы говорите сотруднику — «чувак, ты работаешь за бабло». Люди прекрасно чувствуют такие сообщения, даже если они неявны. Излишне, я надеюсь, говорить, что бонусы ни в коем случае не должны быть отрицательными. Никаких штрафов — это демотиватор. Кстати, если чувак рассчитывает на бонус и не получает его - на практике это равносильно штрафу. Да он уже запланировал купить на бонус новый ноутбук! А тут вы со своими «на самом деле бонусы являются необязательной частью, бла-бла-бла». И заверения в стиле «мамочка тебя все равно любит» тут не исправят ситуацию.
Так что же делать с бонусами?
По моему мнению, есть только один более или менее полезный способ использовать систему бонусирования в нашем с вами бизнесе. Кто нам мешает — тот нам поможет. Можно использовать бонус как способ транслировать правильный message сотрудникам. Мне в голову приходит только один пример. Можно использовать бонусы для того, чтобы сообщить людям, как руководству важно достижение бизнес результатов. Например, отстегивать часть маржи сотрудникам. Сможете ли вы этим повысить их производительность? Навряд-ли. Но они точно станут немного более бизнес-ориентированными. Это просто еще один способ правильно расставить приоритеты. Будет прекрасный повод поговорить с разработчиками о том, что за продукт мы пишем и как мы собираемся захватывать рынок. По моему мнению, размер бонуса не должен превратить сам бонус в предмет культа.
Источник
вторник, 26 января 2010 г.
Самый длинный....
Очень часто при тестировании приходится проверять, как система откликнется на максимальное заполнение полей.
Когда нужно просто проверить, что система «скушает» данные, переданные клиентом системе, можно заполнять те или иные формы бредом, но если, например, нужно проверить, как будут выглядеть экранные формы с отданными клиенту системой данными, то дабы избежать споров с разработчиками я предлагаю использовать реальные данные.
Если вы со мной согласны, то я предлагаю Вашему внимаю подборку самых длинных....
Одни из самых длинных улиц России
Самым длинным почтовым доменом является сайт проекта канадской компании Appwalk.com, предлагающий пользователю завести самый длинный адрес электронной почты в мире, например как у меня: makeenkov@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
Самым длинным названием учреждения на территории России долгое время было: «Кафедра гигиены, эпидемиологии, медицинской полиции, медицинской статистики, учения об эпизодических болезнях и ветеринарной полиции». Сейчас кафедра расформирована, название изменено.
Самое длинное слово состоит из 1913 букв - это название химического соединения.
Книга рекордов Гиннеса считает самым длинным русским словом слово «рентгеноэлектрокардиографического». Между первой и последней буквами этого слова, набранного десятым кеглем, пролегает расстояние, чуть большее 9 сантиметров.
А американец Чарльз Берри Таунсенд считает самым длинным русским словом слово "гниль". Хотя основания для этого у него чисто формальные - но они есть: между первой и последней буквой слова "гниль" пролегает слово "Нил", а это самая длинная река в мире, имеющая длину более 6000 км.
Самый длинный заголовок научной статьи на немецком языке содержал 45 слов, самым длинным словом в названии было то, что в переводе на русский требует трёх: десульфуризАция отходящего газа.
Самые длинные названия книг - это названия трудов по проблемам секса, например: «Muliebria Historico-Medico, hoc est Partium Genitalium Muliebrium Consideratio Physico-Medico-Forensis qua Pudendi Muliebris Partes tam externae, quam internae, scilicet Uterus cum Ipsi Annexis Ovariis et Tubis Fallopianis, nec von Varia de Clitoride et Tribadismo, de Hymen et Nymphotomania seu Feminarum Circumsisione et Castratione selectis et curiosis observationibus traduntur. A.D. Martino Schurigio, Physico Dresdensi».
Кстати, в английском языке есть пословица, которую можно перевести как «Длинное название - признак идиота», которая соответствует нашему «Краткость - сестра таланта».
Самое длинное название города - это Бангкок, столица Таиланда. Если не сломать язык, то можно прочесть его полное официальное название на тайском языке: «Krungthepmahanakhon Amornrattanakosin Mahintharayutthaya Mahadilokphop Noppharat Ratchathaniburirom Udomratchaniwetmahasathan Amonphiman Awatansathit Sakkathattiyawitsanukamprasit», что в переводе означает «Город ангелов, великий город, резиденция изумрудного Будды, неприступная крепость, великая столица мира, одаренная девятью драгоценными камнями и изобилующая великолепными королевскими дворцами, напоминающими райские жилища, из которых правит олицетворение Бога, Город, дарованный богом Индрой и построенный Висанукамом», - всего 167 букв.
В книге рекордов Гиннеса есть раздел, посвященный необычным фамилиям. К примеру, корейская фамилия О – одна из самый коротких, а фамилия Zzzzzzzzzzра находится в конце любого телефонного справочника.
Самую длинную фамилию в мире носит один житель города Стамбула: в ней 43 буквы. Этот человек очень гордится своей фамилией, потому что она означает: «Сын героя знаменосца флага с полумесяцем и звездой». Вот как выглядит эта фамилия, если написать ее по–русски: «АИЙИЛЬЦИКЛИКИРМИЦИБАЙРАКТАЗИЙАНКАГРАМАНОГЛУ».
В Великобритании самую длинную фамилию носил Толлмаш-Толлмаш де Ореллана-Плантагенет-Толлмаш-Толлмаш. В настоящее время самыми длинными являются фамилии, состоящие из 4 частей. Примерами могут служить фамилии лорда Терлоу (Хоувелл-Терлоу-Камминг-Брюс) и графа Уорнклиффа (Монтегю-Стюарт-Уортли-Маккензи). Среди фамилий с неповторяющимися составными частями последним примером была фамилия, которую носила леди Каролина Джемайма Темпл-Ньюджент-Чандос-Бриджез-Гренвиль (1858-1946). Самая длинная односоставная английская фамилия Featherstonehaugh состоит из 17 букв и может произноситься по-разному – Федерстонхо, Ферстонхо, Фирсонхей, Феарстонхо или Фэншо. В Шотландии, согласно приходским регистрационным книгам XVIII в., самой длинной была фамилия NinAchinmacdholicachinskerray (Nin-женская форма Маc), состоящая из 29 букв.
«Прекрасный аромат моего дома, расположенного у жемчужной горы, возносится к глазам небесным» - эта фраза позволила некоему господину Джодд, живущему в Гонолулу, установить рекорд, поскольку она является его именем, самым длинным именем по написанию в мире.
Самое длинное название фильма – «Осуждение и убийство Жана Поля Марата, осуществленные пациентами Чарентонской психбольницы под руководством маркиза де Сада» (Великобритания, 1966).
Самое длинное слово в названии фильма – «Шварцхунбраунхуншварцхунвайссхунротхунвайсс одер Пут-Путт» (ФРГ, 1967).
Самое длинное название кинотеатра, который был открыт во французском городе Бордо в 1902 году – «Лентилэлектропластикромомимоколизерпентограф».
Когда нужно просто проверить, что система «скушает» данные, переданные клиентом системе, можно заполнять те или иные формы бредом, но если, например, нужно проверить, как будут выглядеть экранные формы с отданными клиенту системой данными, то дабы избежать споров с разработчиками я предлагаю использовать реальные данные.
Если вы со мной согласны, то я предлагаю Вашему внимаю подборку самых длинных....
Одни из самых длинных улиц России
- улица 1-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 9 домов
- улица 2-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 34 дома
- улица 3-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 61 дом
http://www.public-organization-capital-of-the-world.which-establishes-world-records-welcomes-all-inhabitants.of-the-planet-and-invites-them-to-visit-our-ancient-city.yours-faithfully-chairman-of-government-anatolij-kosjanchuk.epak.infocom.lviv.ua
Самым длинным почтовым доменом является сайт проекта канадской компании Appwalk.com, предлагающий пользователю завести самый длинный адрес электронной почты в мире, например как у меня: makeenkov@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
Хотя вообще, в зонах первого уровня невозможно зарегистрировать домен, название которого превышает 67 символов (включая четыре символа .com)Самое длинное название растения
Скрытоколокольчик (одноголовый).Самая длинная аббревиатура «SKOMKHPHKJCDPWB» - начальные буквы малайского названия кооперативной компании, осуществляющей денежные операции. А самая длинная аббревиатура в России состоит из 55 символов: НИИОМТПЛАБОПАРМБЕТЖЕЛБЕТРАБСБОРМОНИМОНКОНОТДТЕХСТРОЙМОНТ
Самым длинным названием учреждения на территории России долгое время было: «Кафедра гигиены, эпидемиологии, медицинской полиции, медицинской статистики, учения об эпизодических болезнях и ветеринарной полиции». Сейчас кафедра расформирована, название изменено.
Самое длинное слово состоит из 1913 букв - это название химического соединения.
Книга рекордов Гиннеса считает самым длинным русским словом слово «рентгеноэлектрокардиографического». Между первой и последней буквами этого слова, набранного десятым кеглем, пролегает расстояние, чуть большее 9 сантиметров.
А американец Чарльз Берри Таунсенд считает самым длинным русским словом слово "гниль". Хотя основания для этого у него чисто формальные - но они есть: между первой и последней буквой слова "гниль" пролегает слово "Нил", а это самая длинная река в мире, имеющая длину более 6000 км.
Самый длинный заголовок научной статьи на немецком языке содержал 45 слов, самым длинным словом в названии было то, что в переводе на русский требует трёх: десульфуризАция отходящего газа.
Самые длинные названия книг - это названия трудов по проблемам секса, например: «Muliebria Historico-Medico, hoc est Partium Genitalium Muliebrium Consideratio Physico-Medico-Forensis qua Pudendi Muliebris Partes tam externae, quam internae, scilicet Uterus cum Ipsi Annexis Ovariis et Tubis Fallopianis, nec von Varia de Clitoride et Tribadismo, de Hymen et Nymphotomania seu Feminarum Circumsisione et Castratione selectis et curiosis observationibus traduntur. A.D. Martino Schurigio, Physico Dresdensi».
Кстати, в английском языке есть пословица, которую можно перевести как «Длинное название - признак идиота», которая соответствует нашему «Краткость - сестра таланта».
Самое длинное название города - это Бангкок, столица Таиланда. Если не сломать язык, то можно прочесть его полное официальное название на тайском языке: «Krungthepmahanakhon Amornrattanakosin Mahintharayutthaya Mahadilokphop Noppharat Ratchathaniburirom Udomratchaniwetmahasathan Amonphiman Awatansathit Sakkathattiyawitsanukamprasit», что в переводе означает «Город ангелов, великий город, резиденция изумрудного Будды, неприступная крепость, великая столица мира, одаренная девятью драгоценными камнями и изобилующая великолепными королевскими дворцами, напоминающими райские жилища, из которых правит олицетворение Бога, Город, дарованный богом Индрой и построенный Висанукамом», - всего 167 букв.
В книге рекордов Гиннеса есть раздел, посвященный необычным фамилиям. К примеру, корейская фамилия О – одна из самый коротких, а фамилия Zzzzzzzzzzра находится в конце любого телефонного справочника.
Самую длинную фамилию в мире носит один житель города Стамбула: в ней 43 буквы. Этот человек очень гордится своей фамилией, потому что она означает: «Сын героя знаменосца флага с полумесяцем и звездой». Вот как выглядит эта фамилия, если написать ее по–русски: «АИЙИЛЬЦИКЛИКИРМИЦИБАЙРАКТАЗИЙАНКАГРАМАНОГЛУ».
В Великобритании самую длинную фамилию носил Толлмаш-Толлмаш де Ореллана-Плантагенет-Толлмаш-Толлмаш. В настоящее время самыми длинными являются фамилии, состоящие из 4 частей. Примерами могут служить фамилии лорда Терлоу (Хоувелл-Терлоу-Камминг-Брюс) и графа Уорнклиффа (Монтегю-Стюарт-Уортли-Маккензи). Среди фамилий с неповторяющимися составными частями последним примером была фамилия, которую носила леди Каролина Джемайма Темпл-Ньюджент-Чандос-Бриджез-Гренвиль (1858-1946). Самая длинная односоставная английская фамилия Featherstonehaugh состоит из 17 букв и может произноситься по-разному – Федерстонхо, Ферстонхо, Фирсонхей, Феарстонхо или Фэншо. В Шотландии, согласно приходским регистрационным книгам XVIII в., самой длинной была фамилия NinAchinmacdholicachinskerray (Nin-женская форма Маc), состоящая из 29 букв.
«Прекрасный аромат моего дома, расположенного у жемчужной горы, возносится к глазам небесным» - эта фраза позволила некоему господину Джодд, живущему в Гонолулу, установить рекорд, поскольку она является его именем, самым длинным именем по написанию в мире.
Самое длинное название фильма – «Осуждение и убийство Жана Поля Марата, осуществленные пациентами Чарентонской психбольницы под руководством маркиза де Сада» (Великобритания, 1966).
Самое длинное слово в названии фильма – «Шварцхунбраунхуншварцхунвайссхунротхунвайсс одер Пут-Путт» (ФРГ, 1967).
Самое длинное название кинотеатра, который был открыт во французском городе Бордо в 1902 году – «Лентилэлектропластикромомимоколизерпентограф».
пятница, 22 января 2010 г.
На что стоит обращать внимание при тестировании web-риложений
1. Проверка работы элементов
В первую очередь стоит обратить внимание на ссылки. Суть проверки заключается в том, чтобы пройтись по всем ссылкам и проверить целевые страницы, например, соответствует ли заголовок целевой страницы тексту ссылки, по которой вы на эту страницу попали. Также стоит помнить, что подобная проверка сайта поможет выявить ссылки, которые «никуда» не ведут.
Во вторую, очередь, нужно провести даже более важную проверку – это проверку пунктов меню, если они реализованы в виде картинок, то стоит обратить внимание все ли картинки есть на сервере, все ли тексты на картинках написаны, верно, корректно. Опять же не стоит забывать и про проверку ссылок, т.е. проверку, куда ведут пункты меню и проверку целевых страниц пунктов меню.
Проверка форм ввода. Доступны ли для заполнения, ограничены ли они, если после submit’а формы пользователь попадает на страницу просмотра введённых данных, то требуется проверить корректность передачи данных из форм, если же страницы просмотра нет, то проверить корректность передачи указанных данных можно заглянув в базу данных сайта, если таковая имеется. В качестве бонуса, можно проверить такой момент как автозаполнение форм.
2. Разграничение прав
Если сайт подразумевает работу нескольких видов (типов) пользователей, например, меломан и музыкант, или продавец и покупатель, или ещё большее кол-во видов пользователей, то необходима проверка разграничения прав доступа к тем или иным функциям. Суть подобной проверки заключается в том, чтобы проверить, что, например, покупателю не доступны функции продавца.
3. Кросс-браузерности
Проверка кросс-браузерности сайта немаловажный пункт, хотя не стоит забывать и о целевой аудитории сайта, которая, по сути, и определяет наличие и глубину проверок.
4. Система администрирования
Система администрирования – это по большей части наполнение контентом. Следовательно, попробуйте создать новые разделы, переименовать существующие, изменить уровень вложенности раздела, добавить текст, отредактировать текст, добавить картинку, проставить гиперссылку и так далее. Если же система включает в себя набор функций отвечающих например за назначений прав, то соответственно нужно проверять и этот функционал.
5. Общее оформление
Если к началу тестирования на руках вы имеет дизайн-макет и html-версию сайта, то обязательно нужно проверить их соответствие и выяснить причины расхождений. Просмотреть такие, казалось бы, мелочи как оформление ссылок, по которым пользователь уже перешел, и тех, содержание которых он еще не посмотрел.
6. Реализация функционала
Не смотря на то, что уже была проверка разграничения прав и функционал проверялся, всё равно самым главным пунктом тестирования сайта является проверка функционала в принципе, в независимости от прав, т.е. проверка именно работы функций. Также само собой вы проверить то, что тот или иной функционал в принципе реализован.
В первую очередь стоит обратить внимание на ссылки. Суть проверки заключается в том, чтобы пройтись по всем ссылкам и проверить целевые страницы, например, соответствует ли заголовок целевой страницы тексту ссылки, по которой вы на эту страницу попали. Также стоит помнить, что подобная проверка сайта поможет выявить ссылки, которые «никуда» не ведут.
Во вторую, очередь, нужно провести даже более важную проверку – это проверку пунктов меню, если они реализованы в виде картинок, то стоит обратить внимание все ли картинки есть на сервере, все ли тексты на картинках написаны, верно, корректно. Опять же не стоит забывать и про проверку ссылок, т.е. проверку, куда ведут пункты меню и проверку целевых страниц пунктов меню.
Проверка форм ввода. Доступны ли для заполнения, ограничены ли они, если после submit’а формы пользователь попадает на страницу просмотра введённых данных, то требуется проверить корректность передачи данных из форм, если же страницы просмотра нет, то проверить корректность передачи указанных данных можно заглянув в базу данных сайта, если таковая имеется. В качестве бонуса, можно проверить такой момент как автозаполнение форм.
2. Разграничение прав
Если сайт подразумевает работу нескольких видов (типов) пользователей, например, меломан и музыкант, или продавец и покупатель, или ещё большее кол-во видов пользователей, то необходима проверка разграничения прав доступа к тем или иным функциям. Суть подобной проверки заключается в том, чтобы проверить, что, например, покупателю не доступны функции продавца.
3. Кросс-браузерности
Проверка кросс-браузерности сайта немаловажный пункт, хотя не стоит забывать и о целевой аудитории сайта, которая, по сути, и определяет наличие и глубину проверок.
4. Система администрирования
Система администрирования – это по большей части наполнение контентом. Следовательно, попробуйте создать новые разделы, переименовать существующие, изменить уровень вложенности раздела, добавить текст, отредактировать текст, добавить картинку, проставить гиперссылку и так далее. Если же система включает в себя набор функций отвечающих например за назначений прав, то соответственно нужно проверять и этот функционал.
5. Общее оформление
Если к началу тестирования на руках вы имеет дизайн-макет и html-версию сайта, то обязательно нужно проверить их соответствие и выяснить причины расхождений. Просмотреть такие, казалось бы, мелочи как оформление ссылок, по которым пользователь уже перешел, и тех, содержание которых он еще не посмотрел.
6. Реализация функционала
Не смотря на то, что уже была проверка разграничения прав и функционал проверялся, всё равно самым главным пунктом тестирования сайта является проверка функционала в принципе, в независимости от прав, т.е. проверка именно работы функций. Также само собой вы проверить то, что тот или иной функционал в принципе реализован.
четверг, 21 января 2010 г.
IE Collection - ваш помошник в тестировании кросс-браузерности web-приложений
Я уже не раз говорил о тестировании кросс-браузерности сайта и о проблемах связанных с этим процессом. Напомню, основной проблемой является установка нескольких браузеров на один тестовый стенд, особенно это касается Safari и Internet Explorer’а, т.к. один тестовый стенд может нести на своих плечах только одну версию этих браузеров. Но мы ведь живём в эру высоких технологий и на благо тестировщиков и веб-разработчиков другие, сторонние разработчики создают программы позволяющие работать на одном тестовом стенде с несколькими версиями Safari или Internet Explorer’а. Рассмотрим одну из таких программ, это будет IE Collection версии 1603.
О программе
Итак, IE Collection – это программа позволяющая установить на один компьютер несколько версий Internet Explorer’а. Дистрибутив программы версии 1603 имеет размер равный 58 Мб, что, по сути, очень даже не плохо с учётом того, что программа этой версии несёт в себе 13 версий Internet Explorer’а + Developer toolbar. Дистрибутив это стандартный .exe установщик.
Установка
Установка, в общем, не представляет собой ничего примечательного. Одним из этапов установки является выбор версий для установки:
На этапе выбора, для какого пользователя осуществлять установку и что делать с ярлыками мой вам совет, не стоит ставить галку в пункте «Create a Quick Launch icon» ибо это действие приведёт к установке в панель быстрого запуска 13-ти ярлыков, что думаю, вас приятно удивит.
Результатом же установки является наличие на стенде 13-ти независимых версий браузера Internet Explorer, хотя в моём случае их 12, т.к. я такой набор браузеров предпочел.
Итог
В итоге пользователь получает 13 независимых версий браузера Internet Explorer. Не могу сказать, что я много гонял эти браузеры, но в течение получасового использования некоторых версий я не встретил ни одной проблемы. В качестве примера работы и использования приведу два скриншота отображения одной страницы на крайних версиях браузера Internet Explorer – это IE 1.5 и IE 8
Скачать IE Collection можно здесь и здесь.
На скриншотах вот этот сайт.
О программе
Итак, IE Collection – это программа позволяющая установить на один компьютер несколько версий Internet Explorer’а. Дистрибутив программы версии 1603 имеет размер равный 58 Мб, что, по сути, очень даже не плохо с учётом того, что программа этой версии несёт в себе 13 версий Internet Explorer’а + Developer toolbar. Дистрибутив это стандартный .exe установщик.
Установка
Установка, в общем, не представляет собой ничего примечательного. Одним из этапов установки является выбор версий для установки:
На этапе выбора, для какого пользователя осуществлять установку и что делать с ярлыками мой вам совет, не стоит ставить галку в пункте «Create a Quick Launch icon» ибо это действие приведёт к установке в панель быстрого запуска 13-ти ярлыков, что думаю, вас приятно удивит.
Результатом же установки является наличие на стенде 13-ти независимых версий браузера Internet Explorer, хотя в моём случае их 12, т.к. я такой набор браузеров предпочел.
Итог
В итоге пользователь получает 13 независимых версий браузера Internet Explorer. Не могу сказать, что я много гонял эти браузеры, но в течение получасового использования некоторых версий я не встретил ни одной проблемы. В качестве примера работы и использования приведу два скриншота отображения одной страницы на крайних версиях браузера Internet Explorer – это IE 1.5 и IE 8
Скачать IE Collection можно здесь и здесь.
На скриншотах вот этот сайт.
среда, 20 января 2010 г.
Тестирование кросс-браузерности web-приложений
Итак, можете меня поздравить, впервые моя статья вышла в свет и не куда-нибудь, а на крупнейший портал о тестировании software-testing.ru.
Теория
Википедия:
Если же говорить о написании, то зачастую используют термин кросс-браузерность в виде кроссбраузерность, но с точки зрения русского языка это не правильно, т.к. правила написания существительных через дефис русского языка гласят:
Предыстория
Начинающие веб-программисты рано или поздно сталкиваются с тем, что их скрипт, любовно написанный и прекрасно работающий на домашнем компьютере с MSIE, почему-то не работает у соседа или клиента на его Opera, Mozilla, FF или Netscape.
Давайте разбираться. Введение всё более новых стандартов и следование им разработчиков браузеров позволяет добиться высокой степени совместимости, но, несмотря на совершенствование стандартов в области сайтостроения не все браузеры работают с этими стандартами одинаково. Это происходит не столько из-за багов и глюков браузера, сколько из-за того, что разработчики не успевают за совершенствованием стандартов или же попросту пренебрегают ими. Плюс ко всему современные браузеры имеют набор фич, которые тоже накладывают отпечаток на обработку HTML/CSS кода. Также не стоит и забывать о том, что старые браузеры совсем ничего не знают о новых стандартах, следовательно, в большинстве случаев обрабатывают нововведения некорректно.
Зачем?
По данным W3Counter от 1 до 22% пользователей используют 10 браузеров отличающихся как разработчиками, так и версиями.
Каждый из них имеет свои особенности в обработке HTML/CSS кода, да и к тому же не все из наиболее часто используемых браузеров имеют последнюю версию соответствующую последним стандартам. Также не стоит забывать и о том, что сайты по-разному ведут себя при работе под разными разрешениями экрана, а таковых выделяется как минимум 5 наиболее популярных по данным того же W3Counter.
Исходя из всего вышесказанного, создавая сайт, разработчик должен учесть все факторы и сотворить нечто универсальное. Вы спросите: «Зачем же здесь тестирование кросс-браузерности?!», а я вам отвечу: «Неужели вы всерьёз думаете, что разработчик будет устанавливать хотя бы 5 браузеров и под каждым просматривать работу своего творения?!». В общем, тестирование кросс-браузерности необходимо для того же, для чего необходимы любые другие виды тестирования, т.е. для обеспечения качества.
Почему?
Из истории:
В такой ситуации Netscape Navigator сначала рисовал background, а потом всё закрашивал чёрным цветом. Именно поэтому сначала указывали bgcolor, а потом backgorund. Остальные же браузеры, как и сейчас сначала обрабатывают bgcolor, потом background.
Жизнь:
Теория:
В разных браузерах по-разному вызываются такие свойства, как размеры окна, размеры документа, показатели прокрутки и т.д.
Размеры рабочей области окна
Размеры шрифтов не одинаковы в различных системах, а некоторые шрифты могут просто отсутствовать на компьютере пользователя, именно поэтому Firefox в Linux отображает сайты не так, как Firefox в Windows.
Пример:
Главная страница багтрекера в IE 1.5 (0.1.0.10)
Главная страница багтрекера в IE 8.0 (8.00.6001.18702)
Как?
Основные моменты, на которые нужно сделать упор при тестировании кросс-браузерности:
Эффект от внесенных в разметку сайта изменений можно увидеть сразу же несмотря на то, что на вашем компьютере нет множества браузеров, а вот протестировать на одном или двух браузерах всё же не получится. Кроме того, что вы можете просто установить несколько браузеров, существуют веб-сервисы, которые либо предоставляют удаленный доступ к браузеру через VPN либо позволяют просмотреть скриншоты отображения сайта.
Инструментарий
Проблема:
Основной проблемой при тестировании кросс-браузерности является проблема наличия на тестовом стенде множества браузеров и их версий, а также нескольких операционных систем. Конечно, же, в общем случае при тестирование не стоит учитывать, например Netscape или наиболее распространённые браузеры старых версий. Т.е. по сути, для тестирования достаточно FF, IE, Opera, Chrome и Safari последних 2-3 версий. Но всё же сложности возникают, например в Windows предусмотрена возможность установки только одной версии Internet Explorer, а в MacOS только одной версии Safari.
Решение:
Самым полезным, стабильным и в какой-то мере производительным решением по моему скромному мнению является использование виртуальных машин, хотя конечно, это проблематично при первоначальной развёртке. Зато, имея несколько развёрнутых виртуальных машин, Вы приобретаете гибкость и возможность тестировать кросс-платформенность, кросс-браузерность, а также без проблем изменять разрешения экрана. На сегодняшний день, лидерами в сфере производства средств виртуализации являются компании VMware, Microsoft, SWSoft (вместе с принадлежащей ей компанией Parallels), XenSource, Virtual Iron и InnoTek. Помимо продуктов этих вендоров присутствуют также такие разработки как QEMU, Bosch и прочие, а также средства виртуализации разработчиков операционных систем (например, Solaris Containers), которые не получили широкого распространения и используются узким кругом специалистов. В случае с Linux можно использовать Live Linux CD, который, как правило включают в себя Konqueror и Firefox, но это вариант, как правило, означает медленную работу, что не всегда допустимо. Минусом виртуальных машин по-прежнему остаётся «в Windows предусмотрена возможность установки только одной версии Internet Explorer, а в MacOS только одной версии Safari».
Решить проблему с IE и Safari можно с помощью специальных программ, несущих в себе или позволяющих установить сразу несколько версий вышеуказанных браузеров. С IE поможет справиться программа Multiple IEs от TredoSoft. В установке программа очень проста, достаточно следовать инструкциям, а в результате вы получаете IE3, IE4.01, IE5, IE5.5, IE6 абсолютно не зависящие друг от друга, причем установочный файл занимает всего 10Mb. Обратите внимание, что браузеры установленные таким образом работают не очень устойчиво и иногда падают без видимых причин, но, несмотря на это, свои задачи пакет выполняет в полном объеме. Программа конечно не панацея, ибо уже есть и IE6, и IE8, но всё же. К числу программ частично решающих проблему с IE можно отнести IEs 4 Linux и IE Tester. Проблему же с Safari призвана помочь решить программа Multi-Safari позволяет установить более 10 версий Safari, начиная от 1.0 и до 3.2.1. Честно говоря, это программа мной не опробована и поэтому советовать и описывать я её не буду.
Конечно, полное представление об отображении сайта в различных браузерах можно получить, только установив их на свой компьютер, но если нужно быстро и просто проверить все ли в порядке, то онлайновые сервисы могут быть весьма полезны. Ассортимент сервисов достаточно широк, одни просто делают скришоты вашего сайта, другие же дают удалённый доступ к разным операционным системам с установленными браузерами через VNC клиент. К сожалению многие из таких сервисов платные. Вот небольшой список онлайн сервисов:
Немного статистики
http://www.w3counter.com/globalstats.php
http://www.artlebedev.ru/tools/browsers
Источники
http://designformasters.info/posts/browser-compatibility-testing
http://xpoint.ru/know-how/Articles/KrossbrauzernyiyDHTML
http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин
http://ru.wikipedia.org/wiki/Webkit
http://ru.wikipedia.org/wiki/Microsoft_Virtual_PC
http://www.vmgu.ru
http://www.vmgu.ru + http://www.vmgu.ru/articles/Besplatnie-servernie-platformi-virtualizatsii
http://michelf.com/projects/multi-safari
http://tredosoft.com/Multiple_IE
http://ipinfo.info/html/rendering_services.php
http://www.netmechanic.com/products/browser-index.shtml
Теория
Википедия:
«Кросс-браузерность — свойство сайта отображаться и работать во всех популярных браузерах идентично. Под идентичностью понимается отсутствие развалов верстки и способность отображать материал с одинаковой степенью читабельности. Понятие «кросс-браузерность» очень часто путают с попиксельным соответствием, что на самом деле является разными понятиями.»Тестирование кросс-браузерности как сущность является подвидом конфигурационного тестирования. Переведя термин на русский язык, мы увидим громоздкое словосочетание «перекрёстное тестирование под разными браузерами». В действительности же, термин тестирование кросс-браузерности подразумевает не только проверку под разными браузерами, но об этом чуть позже…
Если же говорить о написании, то зачастую используют термин кросс-браузерность в виде кроссбраузерность, но с точки зрения русского языка это не правильно, т.к. правила написания существительных через дефис русского языка гласят:
«§ 79. Пишутся через дефис:т.к. по-русски этот подвид тестирования должен называться «перекрёстное тестирование под разными браузерами», то делаем вывод, что составная часть «кросс» иноязычная, а следовательно термин кросс-браузерность пишется по правилам русского языка через дефис.
13. Слова, первой составной частью которых являются иноязычные элементы обер-, унтер-, лейб-, штаб-, вице-, экс-, например: обер-мастер, унтер-офицер, лейб-медик, штаб-квартира, вице-президент, экс-чемпион.»
Предыстория
Начинающие веб-программисты рано или поздно сталкиваются с тем, что их скрипт, любовно написанный и прекрасно работающий на домашнем компьютере с MSIE, почему-то не работает у соседа или клиента на его Opera, Mozilla, FF или Netscape.
Давайте разбираться. Введение всё более новых стандартов и следование им разработчиков браузеров позволяет добиться высокой степени совместимости, но, несмотря на совершенствование стандартов в области сайтостроения не все браузеры работают с этими стандартами одинаково. Это происходит не столько из-за багов и глюков браузера, сколько из-за того, что разработчики не успевают за совершенствованием стандартов или же попросту пренебрегают ими. Плюс ко всему современные браузеры имеют набор фич, которые тоже накладывают отпечаток на обработку HTML/CSS кода. Также не стоит и забывать о том, что старые браузеры совсем ничего не знают о новых стандартах, следовательно, в большинстве случаев обрабатывают нововведения некорректно.
Зачем?
По данным W3Counter от 1 до 22% пользователей используют 10 браузеров отличающихся как разработчиками, так и версиями.
Почему?
«У меня есть форма с текстовым полем ввода Input вида:
< inрut style="background:url(12.jpg); float:left; border:0; width: 100%; height: 26px; text-align:center; font-family:'Times New Roman'; font-size:18px; vertical-align:middle" name="username" id="login" type="text" class="inputbox" alt="username" size="10" /> В Opera и FF всё работает нормально, текст в любых количествах вводится без проблем, фон стоит на месте. В IE при вводе текста, выходящего за ширину поля Input фон начинается двигаться вместе с текстом. Если поставить background-attachment:fixed – в IE начинает всё работать нормально, а в Opera и FF фон фиксируется и при прокрутке скролинга в браузере - стоит на месте.»
«Сделайте «хак» для IE через CSS: < inрut style="*background-attachment: fixed; ..." .... Свойство со звёздочкой «*» вначале поймут лишь IE, если нужно только для IE6 и ниже, то можно применить _background-attachment: fixed;»
В разных браузерах по-разному вызываются такие свойства, как размеры окна, размеры документа, показатели прокрутки и т.д.
Размеры рабочей области окна
- MSIE — document.body.clientWidth, clientHeight
- Netscape, Mozilla, Opera — innerWidth, innerHeight
- MSIE, Opera 7 — screenLeft, screenTop
- Netscape, Mozilla, Opera 5, 6 — screenX, screenY
- MSIE, Opera 7 — document.body.scrollWidth, scrollHeight
- Netscape, Mozilla — document.width, height
- Opera 5, 6 — document.body.style.pixelWidth, pixelHeight
- MSIE, Opera 7 — document.body.scrollLeft, scrollTop
- Netscape, Mozilla, Opera 5, 6 — pageXOffset, pageYOffset
Размеры шрифтов не одинаковы в различных системах, а некоторые шрифты могут просто отсутствовать на компьютере пользователя, именно поэтому Firefox в Linux отображает сайты не так, как Firefox в Windows.
Главная страница багтрекера в IE 1.5 (0.1.0.10)
Как?
Основные моменты, на которые нужно сделать упор при тестировании кросс-браузерности:
- Тестирование в различных браузерах (семейство Mozilla, Internet Explorer, Opera, Safari, мобильные браузеры);
- Тестирование при различных разрешениях экрана (обычно 640×480, 800×600, 1024×768, 1280×800);
- Тестирование в различных операционных системах (Mac OS, Linux, Win).
Эффект от внесенных в разметку сайта изменений можно увидеть сразу же несмотря на то, что на вашем компьютере нет множества браузеров, а вот протестировать на одном или двух браузерах всё же не получится. Кроме того, что вы можете просто установить несколько браузеров, существуют веб-сервисы, которые либо предоставляют удаленный доступ к браузеру через VPN либо позволяют просмотреть скриншоты отображения сайта.
Инструментарий
Основной проблемой при тестировании кросс-браузерности является проблема наличия на тестовом стенде множества браузеров и их версий, а также нескольких операционных систем. Конечно, же, в общем случае при тестирование не стоит учитывать, например Netscape или наиболее распространённые браузеры старых версий. Т.е. по сути, для тестирования достаточно FF, IE, Opera, Chrome и Safari последних 2-3 версий. Но всё же сложности возникают, например в Windows предусмотрена возможность установки только одной версии Internet Explorer, а в MacOS только одной версии Safari.
Самым полезным, стабильным и в какой-то мере производительным решением по моему скромному мнению является использование виртуальных машин, хотя конечно, это проблематично при первоначальной развёртке. Зато, имея несколько развёрнутых виртуальных машин, Вы приобретаете гибкость и возможность тестировать кросс-платформенность, кросс-браузерность, а также без проблем изменять разрешения экрана. На сегодняшний день, лидерами в сфере производства средств виртуализации являются компании VMware, Microsoft, SWSoft (вместе с принадлежащей ей компанией Parallels), XenSource, Virtual Iron и InnoTek. Помимо продуктов этих вендоров присутствуют также такие разработки как QEMU, Bosch и прочие, а также средства виртуализации разработчиков операционных систем (например, Solaris Containers), которые не получили широкого распространения и используются узким кругом специалистов. В случае с Linux можно использовать Live Linux CD, который, как правило включают в себя Konqueror и Firefox, но это вариант, как правило, означает медленную работу, что не всегда допустимо. Минусом виртуальных машин по-прежнему остаётся «в Windows предусмотрена возможность установки только одной версии Internet Explorer, а в MacOS только одной версии Safari».
Решить проблему с IE и Safari можно с помощью специальных программ, несущих в себе или позволяющих установить сразу несколько версий вышеуказанных браузеров. С IE поможет справиться программа Multiple IEs от TredoSoft. В установке программа очень проста, достаточно следовать инструкциям, а в результате вы получаете IE3, IE4.01, IE5, IE5.5, IE6 абсолютно не зависящие друг от друга, причем установочный файл занимает всего 10Mb. Обратите внимание, что браузеры установленные таким образом работают не очень устойчиво и иногда падают без видимых причин, но, несмотря на это, свои задачи пакет выполняет в полном объеме. Программа конечно не панацея, ибо уже есть и IE6, и IE8, но всё же. К числу программ частично решающих проблему с IE можно отнести IEs 4 Linux и IE Tester. Проблему же с Safari призвана помочь решить программа Multi-Safari позволяет установить более 10 версий Safari, начиная от 1.0 и до 3.2.1. Честно говоря, это программа мной не опробована и поэтому советовать и описывать я её не буду.
Конечно, полное представление об отображении сайта в различных браузерах можно получить, только установив их на свой компьютер, но если нужно быстро и просто проверить все ли в порядке, то онлайновые сервисы могут быть весьма полезны. Ассортимент сервисов достаточно широк, одни просто делают скришоты вашего сайта, другие же дают удалённый доступ к разным операционным системам с установленными браузерами через VNC клиент. К сожалению многие из таких сервисов платные. Вот небольшой список онлайн сервисов:
- browsercam
- browserpool
- browsershots
- browsrcamp
- iCapture
- IE NetRenderer
- Litmus
- lixlpixel
- superscreenshot.com
- Thumbalizr
- WebshotsPro
Немного статистики
http://www.w3counter.com/globalstats.php
http://www.artlebedev.ru/tools/browsers
Источники
http://designformasters.info/posts/browser-compatibility-testing
http://xpoint.ru/know-how/Articles/KrossbrauzernyiyDHTML
http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин
http://ru.wikipedia.org/wiki/Webkit
http://ru.wikipedia.org/wiki/Microsoft_Virtual_PC
http://www.vmgu.ru
http://www.vmgu.ru + http://www.vmgu.ru/articles/Besplatnie-servernie-platformi-virtualizatsii
http://michelf.com/projects/multi-safari
http://tredosoft.com/Multiple_IE
http://ipinfo.info/html/rendering_services.php
http://www.netmechanic.com/products/browser-index.shtml
вторник, 12 января 2010 г.
Что же такое баг?!
Давайте, наконец, разберёмся, что же такое баг.
Теория
Баг (от англ. bug - насекомое, жук; жарг. дефект, ошибка, сбой в аппаратуре, компьютерной программе) - выявленная ошибка в программе или в документации.
Википедия говорит:
Из истории возникновения
По легенде, 9 сентября 1947 года учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле. Именно тогда Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник, с сопроводительной надписью: «First actual case of bug being found» (англ. «Первый фактический случай обнаружения жука»). Этот забавный факт положил начало использованию слова «debugging» в значении «отладка программы».
Слово «bug» в современном значении употреблялось задолго до этого. Так, в течение Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой. Но ещё в 1878 году Томас Эдисон писал: «Это повторялось снова и снова со всеми моими изобретениями. Первым шагом была интуиция, за ней следовала вспышка, затем возникали препятствия — и они исчезали, потом возникали Баги — так называются маленькие недочеты и трудности — и необходимы месяцы постоянного поиска, исследований и тяжелого труда до успеха или неудачи.»
Действительность
Многие рекомендуют использовать термин ошибка, но как быть в случае, если, например, сутью bug report’а, занесённого тестировщиком в систему отслеживания ошибок, является не отчёт об ошибке, а отчёт с дополнением?! Думаю, не стоит приравнивать определения термина баг к определению термина ошибка.
Существует и вариант определения, основанный на этапе нахождения, а именно баг - это ошибка в программе, выявленная при тестировании программы и в процессе ее использования. Но простите, как тогда называется ошибка найденная разработчиком в своём или чужом коде на этапе кодирования?! Проводя аналогию, можно сказать, что если повар до подачи на стол гостям обнаружил, что приготовленный им суп не вкусный, то этот суп не считается не вкусным.
Если же брать определение в виде баг - это когда фактический результат не равен ожидаемому результату, то на защиту этого варианта встаёт ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию» который гласит:
Что касается ожидаемого результата, то не стоит забывать и о «Вообще-то ожидаемый результат, это не результат, который ожидает пользователь, а результат описанного в документации действия, с описанным методом «появления» результата. Если ожидаемый результат противоречит логическому методу решения проблемы, то это баг документации. Т.е. если в документации написано 2+2=6, и метод получение заявлен арифметический результат двух слагаемых, то понятно, что это будет ошибка документации т.к. используя данный метод и слагаемые, примёненные в нем получается другой результат.»
Вы, наверное, скажите: «А если нет ни ТЗ, ни АЗ, ни спецификации, нет принятого верным поведения, и заказчика даже нет…». Если же нет заказчика или разработка ведётся для себя и точность действий системы не критична, то в этом случае при тестировании необходимо пользоваться логикой и тогда баг – это расхождение видения, понимания, подсказок логики тестировщика с реально работой системы. Если же заказчика нет, но систему планируется продавать, то суть определения термина баг будет ясна из цитаты «Всё же видимо рынок как-то изучался, технико-экономическое обоснование прикидывалось. И какое-то (пусть и не формализованное описание) есть. А уж если все готово, и настало время выходить на рынок - какой-то минимальный комплект документов делать придется. Где и будет описание - что продукт делает.»
Итог
Подводя итог всему вышесказанному и исходя из определения термина «качество», сформулированного Филиппом Крухтеном, звучащим так: «Качество - это соответствие продукта ожиданиям пользователя (заказчика)», смею обозначить наиболее приемлемое, по моему мнению, определение термина баг, звучащее так: «Баг - это когда фактический результат не равен ожиданиям пользователя (заказчика)». В подтверждении такого определения цитирую IEEE Std 829-1983
Подискутировав ещё немного, я не то, чтобы поменял своё мнение об определении термина баг, но более чётко определил, по крайней мере для себя такой нюанс
Источники
Теория
Баг (от англ. bug - насекомое, жук; жарг. дефект, ошибка, сбой в аппаратуре, компьютерной программе) - выявленная ошибка в программе или в документации.
Википедия говорит:
«В программировании баг (англ. bug — жук) — жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат.»Зачастую можно услышать и употребление этого термина в женском роде, т.е. бага, но я предпочту этот вариант использования отмести и забыть про него, т.к. считаю режущим при произношение слух.
Из истории возникновения
По легенде, 9 сентября 1947 года учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле. Именно тогда Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник, с сопроводительной надписью: «First actual case of bug being found» (англ. «Первый фактический случай обнаружения жука»). Этот забавный факт положил начало использованию слова «debugging» в значении «отладка программы».
Слово «bug» в современном значении употреблялось задолго до этого. Так, в течение Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой. Но ещё в 1878 году Томас Эдисон писал: «Это повторялось снова и снова со всеми моими изобретениями. Первым шагом была интуиция, за ней следовала вспышка, затем возникали препятствия — и они исчезали, потом возникали Баги — так называются маленькие недочеты и трудности — и необходимы месяцы постоянного поиска, исследований и тяжелого труда до успеха или неудачи.»
Действительность
Многие рекомендуют использовать термин ошибка, но как быть в случае, если, например, сутью bug report’а, занесённого тестировщиком в систему отслеживания ошибок, является не отчёт об ошибке, а отчёт с дополнением?! Думаю, не стоит приравнивать определения термина баг к определению термина ошибка.
Существует и вариант определения, основанный на этапе нахождения, а именно баг - это ошибка в программе, выявленная при тестировании программы и в процессе ее использования. Но простите, как тогда называется ошибка найденная разработчиком в своём или чужом коде на этапе кодирования?! Проводя аналогию, можно сказать, что если повар до подачи на стол гостям обнаружил, что приготовленный им суп не вкусный, то этот суп не считается не вкусным.
Если же брать определение в виде баг - это когда фактический результат не равен ожидаемому результату, то на защиту этого варианта встаёт ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию» который гласит:
«8.3.6 .......отсюда можно сделать вывод, что всякое необъяснимое расхождение между фактическим и ожидаемым результатами и есть баг! Хотя в этом случае возникают вопросы, например «А если расхождение будет объяснимым, то уже не считается багом?»… наверно не стоит буквально понимать слово «необъяснимое», авторами видимо имеется ввиду не задокументированное расхождение, т.е. расхождение которое нельзя объяснить согласно ТЗ и прочей документации на систему. Многие специалисты также говорят: «Не всегда. Пользователь может ожидать от программы всего чего угодно, но это не значит, что если он не нашел этого значит это баг программы. Бывает и такое, что пользователь плохо умеет считать и ожидает, что результат будет 2+2=6, а ему выдает 4 . Разве это баг?». Осмелюсь возразить и в доказательство скажу, что любая система производится для кого-то и для каких-либо нужд, т.е. если систему производят для пользователей считающих, что 2+2=6, то в такой системе результат 4 будет являться багом. Из выше сказанного можно сделать вывод, что баг – это расхождение фактического поведения системы и описанного в ТЗ, АЗ, спецификации и т.д., т.е. верного, принятого верным...
в) результаты тестирования: гарантировать, что результаты тестирования корректны и что расхождения между фактическим и ожидаемым результатами объяснимы»
Что касается ожидаемого результата, то не стоит забывать и о «Вообще-то ожидаемый результат, это не результат, который ожидает пользователь, а результат описанного в документации действия, с описанным методом «появления» результата. Если ожидаемый результат противоречит логическому методу решения проблемы, то это баг документации. Т.е. если в документации написано 2+2=6, и метод получение заявлен арифметический результат двух слагаемых, то понятно, что это будет ошибка документации т.к. используя данный метод и слагаемые, примёненные в нем получается другой результат.»
Вы, наверное, скажите: «А если нет ни ТЗ, ни АЗ, ни спецификации, нет принятого верным поведения, и заказчика даже нет…». Если же нет заказчика или разработка ведётся для себя и точность действий системы не критична, то в этом случае при тестировании необходимо пользоваться логикой и тогда баг – это расхождение видения, понимания, подсказок логики тестировщика с реально работой системы. Если же заказчика нет, но систему планируется продавать, то суть определения термина баг будет ясна из цитаты «Всё же видимо рынок как-то изучался, технико-экономическое обоснование прикидывалось. И какое-то (пусть и не формализованное описание) есть. А уж если все готово, и настало время выходить на рынок - какой-то минимальный комплект документов делать придется. Где и будет описание - что продукт делает.»
Итог
Подводя итог всему вышесказанному и исходя из определения термина «качество», сформулированного Филиппом Крухтеном, звучащим так: «Качество - это соответствие продукта ожиданиям пользователя (заказчика)», смею обозначить наиболее приемлемое, по моему мнению, определение термина баг, звучащее так: «Баг - это когда фактический результат не равен ожиданиям пользователя (заказчика)». В подтверждении такого определения цитирую IEEE Std 829-1983
«Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств программного обеспечения.»Т.е. очевидно, что требуемые свойства - это ожидания пользователя, т.к. всякий продукт делается для кого-то. Но подведя аналогичный итог на форуме с обсуждением проблемы термина баг, я с толкнулся с возражениями выраженными в приведении примера:
«Пусть пользователь требует реализовать функцию тангенс, как известно tg(x)=sin(x)/cos(x). Чем мы и воспользуемся, реализуя сначала sin и cos. Как хорошие разработчики мы проводим модульное тестирование и проверяем функции sin и cos. Но как мы можем найти в них баг если пользователь не высказал и не обозначил другим способом свои ожидания по этим функциям? Никак. Аналогия с реальными системами понятна?»Но эти возражения, по моему мнению, не совсем отражают действительность, т.к. в приведённом примере функции синус и косинус должны работать так, чтобы удовлетворять конечному требованию... т.е. «если пользователь не высказал и не обозначил другим способом свои ожидания по этим функциям», то они должны работать так, чтобы результат операции sin(x)/cos(x) был равен именно tg(x), а не ctg(x) например.
Подискутировав ещё немного, я не то, чтобы поменял своё мнение об определении термина баг, но более чётко определил, по крайней мере для себя такой нюанс
«Баг - это собирательный термин. Это ошибка / дефект / проблема / отказ / сбой / неисправность / повреждение / несоответствие, в результате которого система возвращает некорректный или неожидаемый результат или ведет себя непредусмотренным образом»
Источники
Подписаться на:
Сообщения (Atom)