Появилась задача тестирования веб-приложения, что являтся необычным для моей компании, ориентированной на десктоп-приложения.
Заказчик хотел тестирование на разных браузерах, так что передо мной встала еще и задача выбора тестируемых браузеров. Всерьез задумавшись над проблемой, наяндексила хорошие ссылки на сайты подсчета статистики (регулярно обновляются).
Для мира:
http://www.w3schools.com/browsers/browsers_stats.asp
Для стран СНГ:
http://www.liveinternet.ru/stat/ru/browsers.html?period=month
Для Украины:
http://index.bigmir.net/users?&d=0&y=2
Обратите внимание, насколько отличается статистика мира и Украины :)
Также интересно распределение используемых ОСей (есть на тех же сайтах). Оказалось, что больше всего времени мой отдел тестирования уделяет системе, которая стоит на втором месте в списке! Так что мне пришлось рассказать коллегам о таком классном сервисе и попросить их переделать таблицы приоритетных окружений в проектах, с которыми они работают.
Вывод: перед тестированием ЛЮБОГО приложения, тестировщику обязательно стоит основательно изучить статистику возможного использования окружения для тестируемого приложения, чтобы максимально ориентироваться на потребителя (здесь следует учитывать регион предполгагаемых пользователей). Также следует периодически мониторить изменение используемого пользователями ПО для эффективного реагирования на изменение нужд пользователей.
P.S. Теперь понятно, почему я вижу эти баги - у Оперы недостаточно процентов использования в мире, чтобы проверять под ней приложения и исправлять ошибки :)
June 10, 2010
Ограничение количества символов в текстовых полях
В своей работе каждый тестер сталкивается с тем, что нужно ограничивать максимальное количество введенных символов. У нас в компании практикой уже выработаны некоторые стандартные значения длины. И вот, читая блог, я обнаружила список самых длинных названий, доменов и т.д.
Я сделала вывод, что нужно пересмотреть наши стандартные значения длины полей - нам-то нетрудно сделать поля длиннее, а короткие поля, как оказалось, могут принести неудобства определенной (хоть и маленькой) части пользователей.
Хочу привести выдержки из статьи, чтоб не потерять главные моменты, которые могут пригодиться:
Одни из самых длинных улиц России = 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 символа
Если написать ее по–русски: «АИЙИЛЬЦИКЛИКИРМИЦИБАЙРАКТАЗИЙАНКАГРАМАНОГЛУ» (в переводе «Сын героя знаменосца флага с полумесяцем и звездой»).
Я сделала вывод, что нужно пересмотреть наши стандартные значения длины полей - нам-то нетрудно сделать поля длиннее, а короткие поля, как оказалось, могут принести неудобства определенной (хоть и маленькой) части пользователей.
Хочу привести выдержки из статьи, чтоб не потерять главные моменты, которые могут пригодиться:
Одни из самых длинных улиц России = 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 минус среднее.
Минус - все равно недостаточно точно будет :(
Subscribe to:
Posts (Atom)