В своей работе каждый тестер сталкивается с тем, что нужно ограничивать максимальное количество введенных символов. У нас в компании практикой уже выработаны некоторые стандартные значения длины. И вот, читая блог, я обнаружила список самых длинных названий, доменов и т.д.
Я сделала вывод, что нужно пересмотреть наши стандартные значения длины полей - нам-то нетрудно сделать поля длиннее, а короткие поля, как оказалось, могут принести неудобства определенной (хоть и маленькой) части пользователей.
Хочу привести выдержки из статьи, чтоб не потерять главные моменты, которые могут пригодиться:
Одни из самых длинных улиц России = 80 символов без указания дома
улица 1-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 9 домов
улица 2-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 34 дома
улица 3-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 61 дом
Самый длинный домен из Украины = 239 символов (не знаю, как сейчас, а когда я писала, то не могла к нему доступиться)
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
Киррилические домены
http://президент.рф/
правительство.рф
Самый длинный почтовый домен = 68 символов без учета имени пользовтеля
@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
Самая длинная аббревиатура
«SKOMKHPHKJCDPWB»
Самая длинная аббревиатура в России = 55 символов: НИИОМТПЛАБОПАРМБЕТЖЕЛБЕТРАБСБОРМОНИМОНКОНОТДТЕХСТРОЙМОНТ
Самое длинное название = 132 символа
«Кафедра гигиены, эпидемиологии, медицинской полиции, медицинской статистики, учения об эпизодических болезнях и ветеринарной полиции»
Самое длинное название города = 179 символов
Бангкок. На тайском языке: «Krungthepmahanakhon Amornrattanakosin Mahintharayutthaya Mahadilokphop Noppharat Ratchathaniburirom Udomratchaniwetmahasathan Amonphiman Awatansathit Sakkathattiyawitsanukamprasit», что в переводе означает «Город ангелов, великий город, резиденция изумрудного Будды, неприступная крепость, великая столица мира, одаренная девятью драгоценными камнями и изобилующая великолепными королевскими дворцами, напоминающими райские жилища, из которых правит олицетворение Бога, Город, дарованный богом Индрой и построенный Висанукамом».
Самая длинная фамилия = 43 символа
Если написать ее по–русски: «АИЙИЛЬЦИКЛИКИРМИЦИБАЙРАКТАЗИЙАНКАГРАМАНОГЛУ» (в переводе «Сын героя знаменосца флага с полумесяцем и звездой»).
June 4, 2010
UI баги blogspot.com
Вы расстраиваетесь,когда находите баги не в тех приложениях,которые Вы тестируете?
Я вот очень расстраиваюсь, когда вижу такие явные и некрасивые баги в широкоиспользуемых аппликухах или на частопосещаемых сайтах. Вот и мой любимый blogspot.com чудит...
Номер раз. Форма входа, язык интерфейса - Украинский.
Номер два. Метки "облаком" (нижнего скроллбара на экране нет, текст просто обрезан).
Придется использовать метки "списком", но тоже выглядит не фонтан - видны разделители между линками...
Длинные слова тоже выходят за "рамки дозволенного" :)
И отсутсвует нотификация об окончании загрузки файла в блог.
P.S. У меня Opera 10.
Я вот очень расстраиваюсь, когда вижу такие явные и некрасивые баги в широкоиспользуемых аппликухах или на частопосещаемых сайтах. Вот и мой любимый blogspot.com чудит...
Номер раз. Форма входа, язык интерфейса - Украинский.
Номер два. Метки "облаком" (нижнего скроллбара на экране нет, текст просто обрезан).
Придется использовать метки "списком", но тоже выглядит не фонтан - видны разделители между линками...
Длинные слова тоже выходят за "рамки дозволенного" :)
И отсутсвует нотификация об окончании загрузки файла в блог.
P.S. У меня Opera 10.
June 2, 2010
Priority & Severity
Пока в нашей компании жизнь была спокойной и налаженной,я искренне недоумевала, зачем дублировать информацию, имея, кроме поля Priority, еще и обязательное поле Severity. Но теперь, имея массу тикетов перед релизом и не имея поля Severity в кастомерском багтрекере, я понимаю, что мне его не хватает :)
Priority - это приоритет, а Severity - "строгость","жесткость". Я, наконец-то, столкнулась с такой ситуацией, когда приоритет ошибки гораздо выше, чем ее строгость, и наоброт - строгость выше, чем приоритет ошибки.
Например, ГУИ баги у нас обычно имеют низкую строгость и, зачастую, низкий приоритет, однако, перед релизом приоритет внезапно растет, в то время, как строгость остается прежней. :)
Радуюсь тому, что взгляды меняются, причем вполне обоснованно :)
UPD: Сегодня добавила в багтрекер поле Severity.
Столкнулась с тем, что отличие между полями не все понимают, и мне предлагают перед релизом менять приоритет, который у нас ранее обозначал нечто среднее между строгостью и приоритетом. На мой взгляд, ошибка не может изменить свою строгость с течением времени,а вот приоритет вполне может быть изменен и будет меняться.
Поэтому отвоевала оба поля, посмотрим, что выйдет :)
Priority - это приоритет, а Severity - "строгость","жесткость". Я, наконец-то, столкнулась с такой ситуацией, когда приоритет ошибки гораздо выше, чем ее строгость, и наоброт - строгость выше, чем приоритет ошибки.
Например, ГУИ баги у нас обычно имеют низкую строгость и, зачастую, низкий приоритет, однако, перед релизом приоритет внезапно растет, в то время, как строгость остается прежней. :)
Радуюсь тому, что взгляды меняются, причем вполне обоснованно :)
UPD: Сегодня добавила в багтрекер поле Severity.
Столкнулась с тем, что отличие между полями не все понимают, и мне предлагают перед релизом менять приоритет, который у нас ранее обозначал нечто среднее между строгостью и приоритетом. На мой взгляд, ошибка не может изменить свою строгость с течением времени,а вот приоритет вполне может быть изменен и будет меняться.
Поэтому отвоевала оба поля, посмотрим, что выйдет :)
June 1, 2010
Как заставить людей развиватсья?
Стоит ли заставлять людей (читай - подчиненных) развиваться и работать над собой? А,может, не брать таких на работу после испытательного срока? Или позволять им жить в своих раковинах и делать одну и ту же работу, которую они выполняют? Я в тупике.
May 12, 2010
Иди туда, не знаю куда, проэстимейть то, не знаю что
Передо мной встал вопрос эстимейта всего тестирования нового продукта, что для меня впервые. Почитав в интернете об этом нелегком деле, так и не решила, как же мне его эстимейтить. Предлагали много вариантов:
- 0-400% от времени разработки (как-то слишком неопределенно)
- 40-50% от времени разработки (что меня тоже не устроило, потому что продукт будет разрабатывать Джуниор-программист без опыта нормальных эстимейтов)
- рассчитать примерно и умножить на два (хороший метод для больших проектов, однако если сделать так в маленьком - предполагаемый бюджет может испугать кастомера)
- привязываться к модулям и примерному количеству тестов (этот вариант мне понравился больше, однако эстимейты будут очень"примерные", потому что,как правило, тестировщику трудно увидеть все подводные камни,на которые натолкнется программа после ее реализации, а не "на бумаге").
Я проэстимейтила все вручную,разбив задание на более мелкие:
1. Выявление требований
2. Создание спецификации
3. Последующая поддержка спецификации
4. Написание тест плана
на каждый вид тестирования,который будет проводиться, было выделено время отдельно, также как и на написание плана на фичу\модуль
5. Ревью и поддержка тест плана
учитывая,что проект небольшой, для экономии времени я приняла решение, что ревьювер должен сам исправлять и добавлять тесты, просто отмечая их другим цветом, например, в экселе или просто включить Review Changes в мапе)
6. Полное тестирование первого билда
Первый проход всех тестов нвоого проекта составляет больше времени,чем следует выделять на регресионное тестирование одного билда, поэтому я выделила это время в отдельную ветку.
7. Регресионное тестирование
Обсудив с SEO количество билдов, которое предполагается в данном проекте, методом "пальцев в небо" было выбрано количество, которое составляло среднее значение между тем, на сколько рассчитывал SEO, программист и я :) Теперь я знаю, что самый большой оптимист - SEO :))
Так вот,вернемся к эстимейтам. Взяв выбранное количество билдов, я умножила время прохождения тестов по одному модулю\фиче на их количество. Исключение составили такие штуки как Инсталляция и Лицензирование - в нашей компании эти модули не тестируются в каждой итерации, так что время регрессионного тестирования на них я выделила как Время прохождения тестов модуля *Количество билдов\2.
8. Проверка багфикса.
Программист отвел себе на багфикс 1 день, что меня улыбнуло :)
Я же прикинула так - на каждый билд по 3 часа на проверку тикетов (это значение будет зависеть от сложности проекта. Мой, как я уже говорила, маленький и довольно простой).
Ну и, конечно, каждую часть множила не на два, а на 1.25-1.3, из расчета, что проект могу тестировать не я, а падаваны :)
В заключение хочу сказать,что мой эстимейт превысил время разработки проекта, но я никак не могу придумать, где могу сократить. А значит, оставим, как есть и посмотрим через пару месяцев, насколько эстимейт был правильным :)
- 0-400% от времени разработки (как-то слишком неопределенно)
- 40-50% от времени разработки (что меня тоже не устроило, потому что продукт будет разрабатывать Джуниор-программист без опыта нормальных эстимейтов)
- рассчитать примерно и умножить на два (хороший метод для больших проектов, однако если сделать так в маленьком - предполагаемый бюджет может испугать кастомера)
- привязываться к модулям и примерному количеству тестов (этот вариант мне понравился больше, однако эстимейты будут очень"примерные", потому что,как правило, тестировщику трудно увидеть все подводные камни,на которые натолкнется программа после ее реализации, а не "на бумаге").
Я проэстимейтила все вручную,разбив задание на более мелкие:
1. Выявление требований
2. Создание спецификации
3. Последующая поддержка спецификации
4. Написание тест плана
на каждый вид тестирования,который будет проводиться, было выделено время отдельно, также как и на написание плана на фичу\модуль
5. Ревью и поддержка тест плана
учитывая,что проект небольшой, для экономии времени я приняла решение, что ревьювер должен сам исправлять и добавлять тесты, просто отмечая их другим цветом, например, в экселе или просто включить Review Changes в мапе)
6. Полное тестирование первого билда
Первый проход всех тестов нвоого проекта составляет больше времени,чем следует выделять на регресионное тестирование одного билда, поэтому я выделила это время в отдельную ветку.
7. Регресионное тестирование
Обсудив с SEO количество билдов, которое предполагается в данном проекте, методом "пальцев в небо" было выбрано количество, которое составляло среднее значение между тем, на сколько рассчитывал SEO, программист и я :) Теперь я знаю, что самый большой оптимист - SEO :))
Так вот,вернемся к эстимейтам. Взяв выбранное количество билдов, я умножила время прохождения тестов по одному модулю\фиче на их количество. Исключение составили такие штуки как Инсталляция и Лицензирование - в нашей компании эти модули не тестируются в каждой итерации, так что время регрессионного тестирования на них я выделила как Время прохождения тестов модуля *Количество билдов\2.
8. Проверка багфикса.
Программист отвел себе на багфикс 1 день, что меня улыбнуло :)
Я же прикинула так - на каждый билд по 3 часа на проверку тикетов (это значение будет зависеть от сложности проекта. Мой, как я уже говорила, маленький и довольно простой).
Ну и, конечно, каждую часть множила не на два, а на 1.25-1.3, из расчета, что проект могу тестировать не я, а падаваны :)
В заключение хочу сказать,что мой эстимейт превысил время разработки проекта, но я никак не могу придумать, где могу сократить. А значит, оставим, как есть и посмотрим через пару месяцев, насколько эстимейт был правильным :)
April 17, 2010
Планирование неопределенности, или почему задачи с пятницы всегда переносятся на понедельник?!
В силу своих обязанностей я каждую неделю пишу план работы каманды QA на неделю. (Следует сказать,что вместо методологии разработки - только хаос). Столкнулась с тем, что задачи с пятницы редко когда не приходится переносить на понедельник в связи с изменением в расписании.
Переносить задачи приходится потому, что возникают непредвиденные (для меня в момент написания плана) дополнительные задачи, например, баги от юзверей; заказчику предоставилась возможность презентовать свой продукт на конференции или тренинге,и ему срочно нужен новый билд с пофикшенными багами #x, #y, #z ("Да,я знаю,что вы должны были в пятницу выложить билд с пофикшенными 10 тикетами, но мне нужны только 5 и завтра!"); фидбек билда, запланированного на тестирование, а потом его внезапный приход, когда программист справился быстрее,чем ожидал и обещал; и т.д. и т.п, все то,с чем маленькая аутсорсовая компания сталкивается довольно часто.
Я думала о том,что было бы хорошо планировать какое то резервное время (так называемая "неопределенность") с учетом рисков, которые могут возникать, на n часов в неделю в зависимости от проектов, над которыми ведется работа. Такой подход позволил бы выдерживать эстимейты и приходить к концу недели с выполненным планом. Но в плане пустые поля уж точно будут выглядеть странно.
Строгие эстимейты, пожалуй, должны привязываться к итерациям, а не к неделям (в моей компании итерация редко длится неделю), ведь это гораздо критичней. Однако недели складыаются в итерации...
В данный момент ведение плана и организация работы, как есть сейчас, устраивает всех, кроме меня - с такой организацией работы отдел тестирования с трудом проэстимейтит выполнение какой-либо задачи и с еще большим трудом завершит ее в срок.
Думая о том, как решить эту проблему, я нашла несколько вариантов, которые имеют свои плюсы и минусы.
1. Заключение "мирного договора" между программистами и тестировщиками.
Такой договор может быть составлен на основе мастер тест плана или в любом другом виде. Суть в том, что документ должен определять сколько билдов мы ждем на тестирование и примерное время их выдачи. Также могут быть описаны правила поведения обеих сторон при появлении, снова-таки, форс-мажорных обстоятельств - например, время, которое тестировщики готовы дать программистам на переделывание фидбекнутого обещанного ранее билда. Не успел - извини...
Однако такой подход не приемлем для ПМов и вообще пагубно сказывается на фактической разработке, хоть и делает программистов более дисциплинированными.2. Приоритизация задач.
При появляении новой внезапной задачи просить ПМа приоритизировать ее (если реально сложно сделать это самому), при этом обьяснив, что работа над проектами А и В сдвигается на n дней,если делать новую задачу срочно и всеми тестерами. Здесь могут найтись новые варианты распределения людей по задачам :) Пожалуй, у этого метода минус только в том, что необходимо отвлекать ПМа от его обязанностей. А с другой стороны, он ведает всей информацией о приоритетах и планах, так что без него тут не обойтись.
3. Планирование буфера неопределенности на основе имеющейся статистики.
Собрать информацию о подобных факапах за последние n месяцев, посчитать среднее количество часов в неделю (не арифметическое) и планировать работу не на 40,к примеру,часов, а на 40 минус среднее.
Минус - все равно недостаточно точно будет :(
March 15, 2010
Крупная компания vs Маленькая компания
Работая в большой компании (~90 человек), было весело, познавательно, и тем не менее жестко. Большая компания как Голиаф - неповоротливая и негибкая, с четко выраженными характером и наклонностями. К тому же,как правило, в больших компаниях очень много времени уходит ни на что - ненужные отчеты, совещания, снова отчеты... и жесткая иерархия. Директор становится человеком, от которого зависит твоя зп, но который по факту ничего о тебе не знает, кроме имени и проектов, над которыми работаешь. Он также далек от сотрудников, как и президент страны - всегда навиду и делает,вроде,все для нас, для своего народа. :)
В этом плане маленькая компания гораздо эффективней работает: ежедневные отчеты можно заменить планом на день\два\неделю, отмеченную в экселе, мапе или любым наглядным способом. Совещания можно заменить стенд-ап митингами, этакими 15-минутками, а то и убрать вообще. Конечно,важные вопросы все же стоит обсуждать на совещаниях, но это,как правило,бывает редко. Но, на мой взгляд, ДЕЙСТВИТЕЛЬНО ВАЖНЫЕ вопросы не решаются с участием всей тимы\копмании.
Однако, в маленькой компании очень трудно развиваться личностно и профессионально, особенно, если нет кого-то, кто был бы умнее\искусснее тебя.
Рост нашей маленькой компании я воспринимаю как радостное событие, но какая-то грусть на сердце о том, что вместе с количеством новых людей и проектов появляется все больше тех минусов, которые мне не нравились в большой компании.
В этом плане маленькая компания гораздо эффективней работает: ежедневные отчеты можно заменить планом на день\два\неделю, отмеченную в экселе, мапе или любым наглядным способом. Совещания можно заменить стенд-ап митингами, этакими 15-минутками, а то и убрать вообще. Конечно,важные вопросы все же стоит обсуждать на совещаниях, но это,как правило,бывает редко. Но, на мой взгляд, ДЕЙСТВИТЕЛЬНО ВАЖНЫЕ вопросы не решаются с участием всей тимы\копмании.
Однако, в маленькой компании очень трудно развиваться личностно и профессионально, особенно, если нет кого-то, кто был бы умнее\искусснее тебя.
Рост нашей маленькой компании я воспринимаю как радостное событие, но какая-то грусть на сердце о том, что вместе с количеством новых людей и проектов появляется все больше тех минусов, которые мне не нравились в большой компании.
Subscribe to:
Posts (Atom)