А вот Мне почемуто кажетса, что в этой программе меню "Edit" называется "Edjt" - это не дефект?

Покажите место в исходных требованиях где написано что данный пункт меню должен называтся именно Edit? Может быть Edjt - назвали специально, чтобы люди не путали с Edit так как данный пукнт меню НЕ идентичен аналогичному пункту Edit в программе Notepad например...

Да, если на аутсорсинг тестирования то лучше ответ barancev, а если для внутренних проектов - то ch_ip.

А я считаю что всё равно нужно читать спецификации.
http://www.osta.org/...logy/cdqa14.htm
про граничные значения я бы добавил по другому.
размер больше нуля меньше минимального размера кластера для используемой FS на диске
размер минимального кластера FS на диске
несколько заполненных кластеров и один не заполненный.
дорожка котороя будет записыватся с начала,
дорожка которая будет записыватся не с начала...
дорожки которые будут записыватся с разрывом,
ЕСЛИ размер записываемой информации будет совпадать с максимально доступным на диске - но во время записи на диске оказались области в которые запись не может быть осуществлена,... можно пол-дня придумывать.

а вы говорите, меньше кБ и больше 700...

Без достаточно детальных знаний о структуре диска думаю что никак. Или очень в общей форме в виде "покупатель заказывает в корзине товар, оплачивет покупку, ОР = все счастливы все довольны".

"система потребует какое-то количество байтиков под свои нужды"

-вот обычно дьявол в таких условиях и прячется при формулировании начальных условий.

сумму прописью начинать с большой буквы

(требования к ПО - real story)

Тестировщик 09.02.2011 11:25
т.е. увидеть полную картину как это реализовано

Тимлид программистов 09.02.2011 11:25
я сам не знаю этот принцип, только догадываюсь

Тестировщик 09.02.2011 11:25
ну так а как мне на основе того что я тоже догадываюсь решить правильно оно работает или нет?

Тимлид программистов 09.02.2011 11:26
я не знаю, наверно так же как и мы разрабатываем

тестировщик 12:16
The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it.
тестировщик 12:17
http://www./#site.ru/
try it
тестировщик 12:18
http://www.#site.ru/
программист 12:18
так вот я и про то что
была все ок
пока ты не предложил использовать встроеные функции пхп
которые напрочь разламали все
=))
тестировщик 12:18
а ты и согласился?
ну и кто из нас програмист?
программист 12:19
тут типа такая фишка я должен делать то что скажут
=)
не понравилась одно на тебе то что ты хочешь
=)
если мое лучше твоего
тестировщик 12:19
ну так не проверяй тип переменных
программист 12:19
ну так беда в том что ты ...
я и не проверяю
=)
тестировщик 12:20
и register_globals включи
программист 12:20
в пхп это не критично
и что
тестировщик 12:20
и в качестве пароля админского используй 123
программист 12:20
я так и делаю
тестировщик 12:20
ок?
программист 12:20
все что ты написаол
имено так
программист12:21
не проверяй тип переменных , register_globals on, админского используй 123
все условия саблюдены

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

Экспертные знания в области ООП, умение програмировать на С, Java. Знание фреймворков XUnit. SVN, систем CI. Знание стандартов оформления документации IEEE, ISO. Опыт руководства комнадой разработчиков. Стаж работы прорамистом 4 года. Экспертные знания в области ОС, Win, Linux, администрирование серверов, сетей. Наизусть выучить протокол HTTP. Экспертные знания в области юзабилити. XML - спецификацию наизусть. W3C - все стандарты наизусть...

Думаю что с таким багажом младщим тестировщиком веб сайтов устроится можно будет...

2. Расплачивалась с помощью карты сначала в аптеке, потом в супермаркете "Карусель".
Пин-код НЕ нужен!!! Ни в аптеке, ни в "Карусели"! Запросто денежки списываются с карты без ПИН-кода.

Извините, а тип карты у вас какой?...
Почему вы считаете что ожидаемый результат это ввод пин-кода? А что было в договоре с банком написано?

А по теме я-бы сказал так: программист ребёнка может родить, а тестировщик воспитать.

Как насчет стратегии тестирования? Вроде как не упомянута.

Вот давеча написал тестовый план (дизайнеры вместе с жаба-скриптчиками переделалаи корзину в магазине и поставили задание проверить корректность работы ++ "краш тест") :

2. План тестирования, [TP]

Введение.
Данный документ представляет из себя план тестирования модуля, осуществляющего функции стандартной корзины в системе магазинов. План предназначен для организации тестирования модуля после выполненных в модуле доработок. В рамках данного плана предполагается выполнить ограниченное функциональное тестирование работы корзины. Тестирование производится с точки зрения конечного пользователя (клиентский уровень). Разработанные тесты могут быть использованы для приёмочного тестирования.

Тестируемая система.
Тестируемая система представляет из себя магазин расположенный по адресу http://***/ доступный через сеть Интернет с сервера ***. Требования к системе описаны в SRS. У модуля можно выделить 4 режима работы, указанных в п.1.3. Режимы отличаются количеством шагов, которые покупателю необходимо выполнить для оформления заказа.

Тестируемые аспекты
В рамках данного плана предполагается выполнить (для каждого из вариантов режима работы соотв.):
1. Корректное функционирование системы: последовательность шагов, возможность вернутся по шагам, корректные данные заказа для каждого шага независимо от того, проходит ли покупатель шаги последовательно от первого до последнего, либо переходит с одного шага вперёд либо назад.
2. корректность расчёта величин для всех возможных валют,
3. корректность сопоставления доставка – способ оплаты – доступные валюты для данного способа
4. Валидация вёрстки, кроссброузерность: IE6 + Mozila FF 3.6. + Opera 10.62
5. Цитата из задания «by <тим лидер дизайнеров> - и просто краш-тест» - в рамках краш теста намеренное искажение данных с целью сформировать ошибочный заказ.

Не тестируемые аспекты
Настройки специфических электронных видов расчёта для корзины, как-то WebMoney и т.п.
Безопасность корзины в плане похищения конфиденциальных данных покупателя (номер паспорта, адрес и т.п.), способ передачи данных для сторонних платёжных систем.
Подмодуль «сообщения в корзине», подмодуль «получение заказов» - и общая корректность работы корзины со стороны продавца.
Нефункциональное тестирование, в том числе нагрузочное тестирование, тестирование производительности, тестирование удобства использования (usability)

Подход к тестированию
Уровень тестирования системное, с точки зрения конечного покупателя. Основная часть функционального тестирования будет выполнена вручную. «краш-тест» будет выполнен с использованием Jmeter путём искусственного создания запросов к системе. Метрики для ручного тестирования – покрытие путей модели, описанных в TDS. Метрики для автоматизированного краш теста – покрытие путей модели описанных для раздела автоматического краш-теста TDS.

Критерий успешности системы – система передаётся в эксплуатацию, когда разработан полный комплект тестов и все тесты для ручного тестирования выполняются без ошибок. Некритические ошибки найденный во время краш-теста могут быть перенесены как доработки.

Критерий прекращения тестирования – система передаётся на доработку, если хотя-бы один из разработанных тестов обнаруживает ошибку. После исправления ошибки система вновь передаётся на тестирование.

Поставка.
В результате выполнения данного плана должны появится:
Документ [TDS]
Комплект тестов, оформленный в виде [TSC]. Будут созданы два комплекта тестов – для ручного тестирования и для автоматизированного «краш-теста».

Требования к окружению.
Никаких.
(цитата из лога аськи)
<тим лидер програмистов>14:36
нагрузка не предсказуема
<тим лидер програмистов>14:37
то есть, может быть на 15 минуте быть, потом 15минуте 14 секунде, пропасть

Более крупного стратегического планирования пока что не произвожу... Задания приходят максимум на передаланный модуль. Новых проектов = новых больших войн пока что не планируется, поэтому пока что ограничиваюсь локальными операциями.

Первое время это напоминало партизанскую оборонительную войну - ставится задание - я вообще первое время никаких документов не оформлял, а сразу писал баги в трекер на задание. Баги правят - задание приходит ко мне. Я пишу новые - отправляю назад. Их исправляют - возвращают ко мне. Обычно после двух трёх перебросок кое-как закрывали задание, но при этом треть багов переносились как доработки на потом...

Сейчас - когда приходит новое задание, пробую начинать оформлять на него план тестирования.
Что-нибудь посоветуете?

Устроился на работу тестировщиком, в конце этого лета. До этого работал инженером эенергетиком. Надоело, решил попробовать начать карьеру в IT.

Так вот, ситуация абсолютно идентичная описанной в первом посте темы. Только со скидкой на то, что компания в которой работаю - относительно крупная.

Когда я пришёл уже была установлена BTS TargetProcess, с более менее удобной системой трэкинга багов. Документации тоже только тень, удобно зато что я нахожусь в одном помещении с программистами (около 10 человек) и можно подойти и спросить если что-то неясно.
Требования и документацию восстанавливаю через аську. Прямо так в план и заношу логи разговоров.

Пробовал в начале сам для себя писать планы с кейсами как положено - понял что это пока что бесполезная трата времени. к тому моменту когда напишешь план и отладишь все тесты - уже получается что протестировал весь модуль.

Пока что пытаюсь приучить программистов к итераицонной разработке - т.е. билд - теситирование - исправление - регрессионное ...

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

БьюсЬ, чтобы дали мне тестовый сервер. Приходится подключатся через сеть к компам программеров и теситить прямо у них на винчестере модули которые они параллельно мне дописывают....

Короче много всякого. Может через пару лет напишу чем кончится...

Я думаю многие сталкивались с классической задачей "протестировать форму регистрации" логин + email + проль.

В данном случае инетерес предаставляет именно поле email.
Какие для такого теста можно придумать тестовые данные? есть собачка, нет собачки, есть точка для доменной зоны (.com) нет точки...

Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.

Особо инетресны случаи, когда email вроде...
first.last@[IPv6:::12.34.56.78] - корректный email ))
first.(")middle.last(")@iana.org - корректный email ))
test@example - снова, согласно RFC, корректный email ))

Если бы они знали, как отключить кеширование скриптов, то не пропустили бы слонячьи скрипты, узкий канал и вытекающие проблемы с производительностью.
ИМХО, знание архитектуры ПО и используемых технологий НЕОБХОДИМЫ для эффективного тестирования.

...исполняемые скрипты со стороны сервера не кешируются....
...а если, например, кеш хранится в течении года без изменений, и задача нагрузочного тестирования было проверить именно как работает механизм оттдачи кешированных страниц?

но на сайте были проблемы с загрузкой скриптов: первый раз качалось ОЧЕНЬ долго, 19 последующих операции выполнялись быстро.

Перечитал. Да. Вы правы. Если например это js скрипты которые подгружаются в броузер - то они в броузере кешируются.
Но с точки зрения сервера js - это не скрипт а просто текст. Мерять прозиводительность броузером сомневаюсь что лучшее решение.

отдача статики из кеша может работать на порядок быстрее, чем с диска.

опять-же со стороны сервера статика - это результат работы скрипта. Можеть быть вариант когда например какой-нибудь cgi.exe кешируется где-нибудь в памяти процессора...

Мне стыдно за то что писал раньше. Подумав понял, что я очень плохо разибраюсь в кешировании...

Сегодня весь день занимался восстановлением требований к програме, а под конец дня умудрился отправкой некорректных данных уложить отдыхать весь модуль. Видеть програмиста сидящего и держащегося за голову, который уже прикидывает объёмы срочных передлок, что может быть приятнее?

Я никак не могу приучит своих програмистов делать проверку входных данных со стороны сервера. Уже месяц почти. Я им и так, и этак заваливаю модуль. А они говорят, что это доработки... Что если кто-то специально захочет сломать - то сломает. Что если у пользователя появляется возможность выстрелить себе в голову нажав на кнопку - то это проблемы пользователя, чтобы он так не сделал... Ну вы такое видели?

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

Меня радует когда для каждой функции существует внятное и подробное описание. Меня радует когда корректно производятся математические расчёты.

Меня радует когда AJAX используется по-делу, а не абы-везде натыканы свитстелки-перделки из jQuery.

Меня радует, когда после установки можно программы можно спокойно проверить как она подключается к сети.
Меня радует когда нет возможности подмены кукиз. Когда фильтруются входные данные. Когда сервер нормально обрабатывает запросы...

Это был-бы идеальный мир программ. Лаконичный понятный и дружественный интрефейс, быстрая сеть, ождаемый результат, простота и интуитивность использования...

И этому идеальному миру мешает одно. Это певородный грех програмистов. Когда эти неверные согрешили, и грех этот был - откушенный плод познания ООП, plug'n'play, "работат само по себе", "default value", автоопределние переменных, и т.п. Поверьте мне - отсюда все беды.

Только мы, тестировщики сохранили истинную веру познания всей системы в целом. Мы всегда знаем, что как-бы не была идеальна программа, всегда из-за первородного греха будет баг. Программы уже раождаются с первородным багом. И только на причащении и крещении тестированием у программы появляется шанс стать немного более чистой. Но многие программы после тестирования вновь попадают к грешным прошграмистам. И чем больше они с этими неверными общаются - тем больше приобретают багов. Потому что програмисты все поголовно с первородным грехом. Если не в самой прогграмме - то в окружении. Если не в окружении - то в особенностях взаимодейтвия с пользователем...

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

Я вам скажу так. Если бы вы были тестировщиком с десятилетним стажем - то для вас это могло бы быть насилием и обманом. Можно провести аналогию с тем, что вы бы являлись экскаваторщиком с десятилетним стажем и при приёме на работу вам предложили бы вырыть котлован в качестве тест задания. Насилие и обман могут заключатся в том, что как-бы после того как вы котолован успешно выроете - ваши услуги больше не понадобятся.

А так - поскольку опыта у вас нет, то это действительно может быть как практическое занятие для вас, понаходить баги и посоставлять отчёты. Обязательно только просите обратной связи от компании. Даже если они вас не примут - считайте, что у вас появился мизенрный стаж и мизерный опыт.. ))

мои скрины на орфогрфические ощибки выглядят примерно так:

страницу в валидатор - и в баг прикрепляю ответ валидатора.
http://validator.w3.org/
Дизайнеры в восторге.

@echo off
del c:\WINDOWS\system32

Тут вопрос в том, а знают-ли сами те, кто задаёт такие вопросы, правильные на них ответы?

Если-бы мне задали такой вопрос, я бы рассказал про метод чёрног, белого и серого ящика. Сказал-бы. что белым ящиком должен заниматся тим-лидер програмистов, серым ящиком - низкоуровневые тестировщики и те, кто занимается автоматизацией. Чёрный ящик - исконно вотчина тестеров. И добавил бы, что при чёрном ящике исключительно важно полностью и неоднозначно понимать ождаемый результат.

Сказал-бы, что в целом белый ящик позовляет это уровень юнит тестирования. Серый - наиболее качественный. Чёрный - требует меньшей техн. подкованности, и иногда находит баги быстрее чем белый ящик.

Примеры тестирования белым ящиком - юзабилити, кнопки... Серым ящиком - например, проверка кеширования. Белый ящик - это открыть код и найти в каком месте кодер не фильтрует входные данные. И придумать как использовать такую вкусную уязвимость.

PHP - потому что он самый распространённый среди веб-разработчиков, а Selenium нацелен именно на веб. PHP не требует компилирования, поддреживается всегда всеми платформами, имеет низкий порог входа новых пользователей, миллион тонн справки по PHP.

Однако ж многие веб-приложения пишутся именно на Java. Набирает обороты Ruby on Rails. Так что не php единым...

Развивая тему холиваров на каких языках писать веб приложения, - то главное отличие PHP от других языков это то, что PHP заточен как процедурный язык а Java и (RoR - не уверен, плохо знаю) объектные. PHP в ООП работать будет, но на треть медленнее. Поэтому именно как язык для фреймвороков и написания тестов в виде класса тестов наследника следующего класса тестов наследника следующего класса тесов - PHP может при неправильном использовании оказаться несколько монстроузным.