- Форум тестировщиков
- → Публикации Yarilo
Публикации Yarilo
57 публикаций создано Yarilo (учитываются публикации только с 12 мая 2023)
По типу контента
По пользователю
#7911 тестирование web-сайтов
Отправлено автор:
19 ноября 2004 - 07:31
в
Тест-дизайн и ручное тестирование
После тестирования функционала, если версия продукта уже стабильна, можно проводить нагрузочное тестирование.
#8342 создание и описание test case'ов
Отправлено автор:
30 ноября 2004 - 05:02
в
Автоматизированное тестирование
Здравствуйте :)
Если вы новичок вообще в тестировании, а не только в автоматизированном тестировании, то рекомендую почитать книгу:
"Тестирование программного обеспечения" Сэм Канер, Джек Фолк, Енг Кек Нгуен.
В частности, там рассматриваются вопросы какие тесты стоит автоматизировать в первую очередь. Описана методология разработки и проведения тестирования.
Чтобы что-то автоматизировать, нужно знать что это и ЗАЧЕМ - с какой целью, и стоит ли это автоматизировать. Это первые вопросы, на которые стоит найти ответы.
Про вопросы актуальности внедрения автоматизированного тестирования читайте на этом же форуме:
Automated Testing: Actuality Issues
Если вы хотите использовать UML для описания test cases, то подойдут диаграммы последовательности действий (sequence) или диаграммы деятельности (activity). Правда, зачем вам такое тяжеловесное (на мой взгляд) описание, не знаю.
А какие книги по автоматизации читать - смотря какие инструменты/подходы вы собираетесь использовать.
Если вы новичок вообще в тестировании, а не только в автоматизированном тестировании, то рекомендую почитать книгу:
"Тестирование программного обеспечения" Сэм Канер, Джек Фолк, Енг Кек Нгуен.
В частности, там рассматриваются вопросы какие тесты стоит автоматизировать в первую очередь. Описана методология разработки и проведения тестирования.
Чтобы что-то автоматизировать, нужно знать что это и ЗАЧЕМ - с какой целью, и стоит ли это автоматизировать. Это первые вопросы, на которые стоит найти ответы.
Про вопросы актуальности внедрения автоматизированного тестирования читайте на этом же форуме:
Automated Testing: Actuality Issues
Если вы хотите использовать UML для описания test cases, то подойдут диаграммы последовательности действий (sequence) или диаграммы деятельности (activity). Правда, зачем вам такое тяжеловесное (на мой взгляд) описание, не знаю.
А какие книги по автоматизации читать - смотря какие инструменты/подходы вы собираетесь использовать.
#9418 Язык общения на форуме
Отправлено автор:
22 декабря 2004 - 11:08
в
Idea Box!
Кому нибудь знакомо ощущение ужасной беспомощности когда не можешь чего-то понять? :(
Я за то, чтобы понимать - за русский!
Я за то, чтобы понимать - за русский!
#7839 Форумы для наших коллег: разработка, постановка?
Отправлено автор:
18 ноября 2004 - 08:13
в
Idea Box!
А может здесь же и вырастем во всеобщий ресурс?
Вот бы здорово было! :D
Вот бы здорово было! :D
#7826 Форумы для наших коллег: разработка, постановка?
Отправлено автор:
18 ноября 2004 - 07:49
в
Idea Box!
Привет!
Для обсуждения будут интересны проблемы и подходы к интеграции процессов разработки и тестирования (с точки зрения кто, когда, в каких случаях, в каком виде предоставляет какие артефакты - от разработчиков к тестировщикам и наоборот) - это наверняка будет интересно:
группе, разрабатывающей процессы в компании,
для подготовки к сертификации,
разработки единой схемы описания артефактов, которые можно будет использовать как разработчикам так и тестировщикам одновременно (для того, чтобы в быстрых проектах или при нехватке ресурсов разработать приемлемую минимальную проектную документацию).
Соответственно, контингент заинтересованных лиц - тестировщики ПО, разработчики процессов в компании, разработчики ПО (для обсуждения вида и содержания единой документации/описания системы, например), начальство (в некоторой мере).
Можно это организовать (как мне видится) отдельной корневой веткой в форуме (но не разделять тестировщиков от остальных лиц), сделать отдельную рассылку только для этой ветки, назвать рассылку заманчиво для ВСЕХ заинтересованных лиц (это чтобы целенаправленно привлечь нужную аудиторию). И в рамках ветки действовать :)
Идея разместить эту тему на rsdn или других форумах хороша, я не знаю только, возможно ли так сделать, чтобы там ее разместить, а оттуда на наш форум перекидывать пользователя - было бы хорошо. Или там разместить и помещать список топиков (ответвлений), и перебрасывать по любой из них.
Для обсуждения будут интересны проблемы и подходы к интеграции процессов разработки и тестирования (с точки зрения кто, когда, в каких случаях, в каком виде предоставляет какие артефакты - от разработчиков к тестировщикам и наоборот) - это наверняка будет интересно:
группе, разрабатывающей процессы в компании,
для подготовки к сертификации,
разработки единой схемы описания артефактов, которые можно будет использовать как разработчикам так и тестировщикам одновременно (для того, чтобы в быстрых проектах или при нехватке ресурсов разработать приемлемую минимальную проектную документацию).
Соответственно, контингент заинтересованных лиц - тестировщики ПО, разработчики процессов в компании, разработчики ПО (для обсуждения вида и содержания единой документации/описания системы, например), начальство (в некоторой мере).
Можно это организовать (как мне видится) отдельной корневой веткой в форуме (но не разделять тестировщиков от остальных лиц), сделать отдельную рассылку только для этой ветки, назвать рассылку заманчиво для ВСЕХ заинтересованных лиц (это чтобы целенаправленно привлечь нужную аудиторию). И в рамках ветки действовать :)
Идея разместить эту тему на rsdn или других форумах хороша, я не знаю только, возможно ли так сделать, чтобы там ее разместить, а оттуда на наш форум перекидывать пользователя - было бы хорошо. Или там разместить и помещать список топиков (ответвлений), и перебрасывать по любой из них.
#7829 Форумы для наших коллег: разработка, постановка?
Отправлено автор:
18 ноября 2004 - 07:53
в
Idea Box!
Добавлю, что в этом форуме мне очень нравится то, что по e-mail мне приходят списки уведомлений о новых открытых темах, без них я бы не стала лазить по форуму. А если бы и стала, то очень редко и по нужде, т.к. не все темы меня интересуют.
#7838 Форумы для наших коллег: разработка, постановка?
Отправлено автор:
18 ноября 2004 - 08:12
в
Idea Box!
Вот-вот! (про постановщиков)
В свое время столкнулась с нехваткой информации по конкретной проблеме (из области именно постановки) и подумала - вот по тестированию такой класный ресурс есть, можно спросить совета у опытных коллег, а тут и спросить не у кого.
И подобного ресурса (не только форум) по тематике бизнес анализа не знаю. Может кто чего-нибудь подскажет (ресурс)? :rolleyes:
В свое время столкнулась с нехваткой информации по конкретной проблеме (из области именно постановки) и подумала - вот по тестированию такой класный ресурс есть, можно спросить совета у опытных коллег, а тут и спросить не у кого.
И подобного ресурса (не только форум) по тематике бизнес анализа не знаю. Может кто чего-нибудь подскажет (ресурс)? :rolleyes:
#4775 Формирование отдела тестирования с нуля
Отправлено автор:
12 августа 2004 - 06:46
в
Управление тестированием
Привет!
Согласна с Олешкой, что нужно уточнить цели создания отдела.
Мы в своей компании пробовали создать отдел тестирования, но в конце концов мы его расформировали - как работали тестировщики по проектам так все и осталось :)
Согласна с Олешкой, что нужно уточнить цели создания отдела.
Мы в своей компании пробовали создать отдел тестирования, но в конце концов мы его расформировали - как работали тестировщики по проектам так все и осталось :)
#4717 Уровень тестировщиков.
Отправлено автор:
10 августа 2004 - 06:43
в
Работа для тестировщика/QA
На мой взгляд, чтобы привлечь хорошего тестировщика (или сманить из другой смежной прфессии), необходимо тщательно продумать реальную достижимую стратегию профессионального развития тестировщика, его карьерного роста в ДАННОЙ КОНКРЕТНОЙ КОМПАНИИ (куда хотите его привлечь).
Если эта перспектива вам самим нравится, то можно надеяться, что подходящий человек найдется.
Но когда найдется, не стоит расслабляться, т.к. он может легко уплыть наткнувшись на непонимание и недостаток уважения к его работе со стороны сотрудников компании.
А чтобы понимали и ценили, надо самим разработчикам посоставлять тест планы и потестировать ручками с фидбэком от заказчика ПО о качестве тестирования.
Если эта перспектива вам самим нравится, то можно надеяться, что подходящий человек найдется.
Но когда найдется, не стоит расслабляться, т.к. он может легко уплыть наткнувшись на непонимание и недостаток уважения к его работе со стороны сотрудников компании.
А чтобы понимали и ценили, надо самим разработчикам посоставлять тест планы и потестировать ручками с фидбэком от заказчика ПО о качестве тестирования.
#5109 Требования для тестирования
Отправлено автор:
23 августа 2004 - 09:13
в
Управление тестированием
Да и по крупным проектам может не быть детализированных требований, хотя я совсем не сторонница такого подхода!
#5108 Требования для тестирования
Отправлено автор:
23 августа 2004 - 09:12
в
Управление тестированием
Я имела в виду, что требования, разумеется, есть, но они могут быть не документированы, цель составления требований - достигнуть одинакового понимания вИдения системы заказчиком и проектной командой, для мелких проектов никаких формальных спецификаций может не быть - работа будет вестись по подписанным в контракте бизнес требованиям (а они, как правило, не детализированы до нужд тестирования).ПРикольно - а я думал, что требования к системе один из основных документов с которыми работают люди, когда пытаются понять, насколько то что сделано, соответсвует пожеланиям заказчика.По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО.
Если нет требований - то по большому счёту будет сделано что-то, а не система.
Сделано будет то, что нужно заказчику, т.к. в любом случае ведутся переговоры о том, что и как надо сделать.
#5212 Требования для тестирования
Отправлено автор:
25 августа 2004 - 09:39
в
Управление тестированием
Undi, вы, видимо, не согласны с тем, что стоит внедрять описанный мной подход в работе над проектом. Но я это и НЕ ПРЕДЛАГАЮ!Не соглашусь.
Первая ситуация:
Контракт подписывался с генеральным директором, переговоры "что и как" велись с ИТ-директором. ИТ-директор увольняется. Берут другого, который читает контракт, понимая его абсолютно по-своему. Что дальше?
Вторая ситуация:
Вы успешно сдаете проект, проходит полгода. Вдруг :) оказывается, что какая-то деталь, очень важная с точки зрения заказчика, не реализована. Заказчик приходит к вам. Грозится подать на вас в суд, если вы не допишите бесплатно нужную "деталь". Вы понимаете, что это противоречит всей архитектуре системы. Что дальше?
ИМХО требования всегда нужны и если их нет, то тестировщику лучше написать их самому или требовать у лидера проекта. Иначе возможны проблемы именно у тестировщика :)
Я описала реальную ситуацию, когда Software Requirements МОГУТ БЫТЬ НЕ ОПИСАННЫМИ (а они действительно МОГУТ быть недокументированы), и как в этом случае строится работа команды, включая тестировщика; я отнюдь не призываю к внедрению такого подхода в IT компанию.
По поводу неожиданностей:
У нас так принято:
Заказчик участвует в официальном бета тестировании продукта, обнаруженные в результате дефекты и недоработки будут исправлены. И никаких пол года вдруг B) К тому же, все фичи заявляются в контракте. Архитектурно значимые варианты использования тоже выявляются в стадии presale, так что неожиданных кардинальных деталей не может возникнуть.
Про увольнение сотрудников, владеющих информацией:
А аналитик может уволиться и сразу после устных переговоров с заказчиком, когда ничего не еще документировано.
Но связь с заказчиком не обрывается и не ограничивается одним разом.
Обычно разговоры "что и как" происходят постепенно, а не всё в один раз, при этом вопросы и предложения о работе системы задаются в письменной форме и ответы тоже (или в устной, но тогда передаются команде разработчиков, иначе все равно всего в деталях не запомнить), тогда аналитик владеет приватно (если он расшаривает переписку) только концепцией построения системы и способами ее осуществления, а не собственно информацией о системе.
А вот если не расшаривает, и модель водопадная,то всяко может быть, тут я согласна с Undi :) - но это тоже решаемо - смотря как в компании процессы налажены :P
#5038 Требования для тестирования
Отправлено автор:
20 августа 2004 - 06:58
в
Управление тестированием
Привет!
По поводу требований - use cases выражают требования к поведению системы.
Требования составляет аналитик (роль). Роль аналитика может выполнять человек, привлеченный к этой задаче (как программист, так и тестировщик, может быть и менеджер проектов).
По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО. Обычно с заказчиком обсуждаются бизнес-требования (т.н. features, функции системы, ее характерные особенности). Также с заказчиком обсуждаются use cases. Требования к ПО (Software Requirements) получаются в результате детализации бизнес-требований и use cases.
Вы, Алексей, видимо задавали вопрос именно о Software Requirements. Их в проекте строго оформленных может и не быть, особенно, если сроки разработки быстрые/проектная команда маленькая (просто разработчики между собой договариваются, а заказчику сразу предоставляются версии программы, прототипы, раскадровки и т.п.). В этом случае отсутствия спецификаций Software Requirements тестировщик сам исследует поведение системы, выясняя и уточняя поведение системы непосредственно у разработчиков. Можно попросить написать спецификакии на особо критические области программы - запрос адресовать к менеджеру проектов, чтобы он поручил разработчикам (или сам написал).
(Это из моего опыта)
Надеюсь, поможет... :)
По поводу требований - use cases выражают требования к поведению системы.
Требования составляет аналитик (роль). Роль аналитика может выполнять человек, привлеченный к этой задаче (как программист, так и тестировщик, может быть и менеджер проектов).
По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО. Обычно с заказчиком обсуждаются бизнес-требования (т.н. features, функции системы, ее характерные особенности). Также с заказчиком обсуждаются use cases. Требования к ПО (Software Requirements) получаются в результате детализации бизнес-требований и use cases.
Вы, Алексей, видимо задавали вопрос именно о Software Requirements. Их в проекте строго оформленных может и не быть, особенно, если сроки разработки быстрые/проектная команда маленькая (просто разработчики между собой договариваются, а заказчику сразу предоставляются версии программы, прототипы, раскадровки и т.п.). В этом случае отсутствия спецификаций Software Requirements тестировщик сам исследует поведение системы, выясняя и уточняя поведение системы непосредственно у разработчиков. Можно попросить написать спецификакии на особо критические области программы - запрос адресовать к менеджеру проектов, чтобы он поручил разработчикам (или сам написал).
(Это из моего опыта)
Надеюсь, поможет... :)
#10750 Требования в StarTeam
Отправлено автор:
03 февраля 2005 - 04:59
в
MicroFocus (Borland, Segue) - Functional testing
Caliber - удобный инструмент для управления требованиями, мне в нем больше всего пригодились функции группировки требований, представление требований в виде дерева и подсистема публикации - можно настроить Word - шаблон и на его основе сделать экспорт требований в формате Word - документа.Я тоже, может, чего не понял, но в StarTeam есть вкладка Requirements. Я так думаю, это как-то связано с требованиями.
Caliber в этом плане больше подходит? Вы его используете?
#4790 Тестировщики из других профессий?
Отправлено автор:
12 августа 2004 - 11:36
в
Круглый стол о работе в тестировании ПО
Я имела в виду разработчика в широком смысле слова - и аналитик, и архитектор, и дизайнер, и кодер.Наверное, потому что спецификации это не документ, который должны составлять разработчики ;)Спецификации от разработчиков далеко не идеальны.
Мысль у меня была такая, что закодирована неполная модель (независимо от того как она специфицирована), поэтому тестировщик выстраивает с нуля модель (у себя в голове, выражая ее в тестах), пользуясь спецификациями, достраивая модель. То есть, тестировщик должен принять аксиому о том что даже специфицированная модель от разработчика (или неспецифицированная модель) не идеальна.
#4716 Тестировщики из других профессий?
Отправлено автор:
10 августа 2004 - 06:32
в
Круглый стол о работе в тестировании ПО
Русские шрифты заработали :)
Согласна с ex-dani в том, что тестировщик должен быть терпеливым, потому что если это не так, то он недолго будет тестировщиком.
Это такая профессия, что важнее человеческие качества, чем начальные умения.
Но даже и терпения мало:
если тестировщика в компании коллеги не уважают как профессионала (относятся несерьезно, типа не программирует, просто тыкает по готовому), пусть даже и начальство понимает его необходимость и важность, то тестировщик, при всем изначальном желании тестировать, переквалифицируется в ряды тех, кого уважают как профессионала коллеги.
А про творчество могу так сказать - зачастую разработчики не продумывают все варианты поведения системы, поэтому, когда тестировщик планирует тестирование, то он сам создает модель системы, возможно (и в большинстве случаев это так) более полную и адекватную,чем ее построили разработчики. Спецификации от разработчиков далеко не идеальны.
Согласна с ex-dani в том, что тестировщик должен быть терпеливым, потому что если это не так, то он недолго будет тестировщиком.
Это такая профессия, что важнее человеческие качества, чем начальные умения.
Но даже и терпения мало:
если тестировщика в компании коллеги не уважают как профессионала (относятся несерьезно, типа не программирует, просто тыкает по готовому), пусть даже и начальство понимает его необходимость и важность, то тестировщик, при всем изначальном желании тестировать, переквалифицируется в ряды тех, кого уважают как профессионала коллеги.
А про творчество могу так сказать - зачастую разработчики не продумывают все варианты поведения системы, поэтому, когда тестировщик планирует тестирование, то он сам создает модель системы, возможно (и в большинстве случаев это так) более полную и адекватную,чем ее построили разработчики. Спецификации от разработчиков далеко не идеальны.
#4789 Тестировщики из других профессий?
Отправлено автор:
12 августа 2004 - 11:19
в
Круглый стол о работе в тестировании ПО
Олешка, на уровне это детского сада или нет, но на себе испытала - я была первая девушка, которую взяли на работу в IT компанию как технического специалиста - тестировщика. Так вот, может про уважение было громко сказано, но относились ко мне со снисхождением пока я в анализ требований не ударилась от безысходности ;)Разборки на уровне - "не программисты - поэтому не профессионалы" - это на уровне детского сада.
По-моему, не будут уважать тогда, когда тестировщик не выполняет свою работу - не находит баги, или не может их внятно объяснить и качественно задокументировать, а не в стиле "у вас что-то где-то не работает". ;)
#9225 Тестирование в свете Экстремального Программирован
Отправлено автор:
20 декабря 2004 - 08:30
в
Портал Software-Testing.Ru
Привет!
У меня вопрос - в экстремальном программировании применяется только unit-тестирование или еще какие-нибудь типы применяются?
У меня вопрос - в экстремальном программировании применяется только unit-тестирование или еще какие-нибудь типы применяются?
#9417 Тестеры всегда идут в рай
Отправлено автор:
22 декабря 2004 - 11:02
в
Свободное общение
Что верно - то верно
:D
:D
#9416 Совмещение должностей
Отправлено автор:
22 декабря 2004 - 10:58
в
Управление тестированием
Мне выпало кроме тестирования бизнес-аналитиком быть и проектную документацию вести.
#8168 Скрытые свойства базовых объектов
Отправлено автор:
25 ноября 2004 - 09:44
в
IBM Rational - Functional Testing
Как мне видится решение задачи, которую Serega обозначил:
1.Определить типы контролов, которые нужно тестировать именно на значения private полей.
2.Составить список контролов для каждого из типов. (Это можно сделать по-разному, наверное и скорее всего, можно автоматически).
3.Для каждого из типов разработать процедуру, извлекающую значения всех нужных полей и сравнивающую их с эталоном.
4.Разработать главную процедуру, запускающую перебор контролов и вызывающую соответствующую процедуру сравнения с эталоном. (Тоже решается по-разному).
1.Определить типы контролов, которые нужно тестировать именно на значения private полей.
2.Составить список контролов для каждого из типов. (Это можно сделать по-разному, наверное и скорее всего, можно автоматически).
3.Для каждого из типов разработать процедуру, извлекающую значения всех нужных полей и сравнивающую их с эталоном.
4.Разработать главную процедуру, запускающую перебор контролов и вызывающую соответствующую процедуру сравнения с эталоном. (Тоже решается по-разному).
#8161 Скрытые свойства базовых объектов
Отправлено автор:
25 ноября 2004 - 09:17
в
IBM Rational - Functional Testing
Serega, а тебе действительно все еще надо эти private поля "доставать"? :DТема вызвала бурные обсуждения, с огромным интересом слежу
2Yarilo не сдавайся, твой ход:))
#8164 Скрытые свойства базовых объектов
Отправлено автор:
25 ноября 2004 - 09:26
в
IBM Rational - Functional Testing
Согласна :)Это зависит от того, что понимать под ящиком :) Если ящиком является функция (в смысле программного кода), то все так и есть. Если же ящиком является GUI, с которым пользователь работает, то тут все несколько иначе.
Нам Serega не сказал, как именно он хочет автоматизировать - копаться в исходном коде или работать исключительно с GUI :)
#8158 Скрытые свойства базовых объектов
Отправлено автор:
25 ноября 2004 - 09:14
в
IBM Rational - Functional Testing
А я думала, что "черный ящик" - это когда тестирование по типу когда знаем что должна функция принимать на входе и что на выходе соответственно, а вот когда пути охвата тестируем, тогда и смотрим как непосредственно функция написана, а в предложенном способе не требуется знать, как функция внутри реализована, поэтому это как раз по типу "черного ящика" :PКакой же это "черный ящик", когда вы точно знаете какой метод должен отработать? :)
#8144 Скрытые свойства базовых объектов
Отправлено автор:
25 ноября 2004 - 08:31
в
IBM Rational - Functional Testing
Я не очень поняла, что Вы имеете в виду под тестированием на уровне кода.... Конечно, при автоматизации придется возиться с исх. кодом проекта (если не написать своего обнаружителя объектов :) )Вообще все эти статьи - о тестировании на уровне кода, что не имеет ничего общего с тестированием "черного ящика", для чего собственно Robot и предназначен.
Статья про тестирование GUI - автоматизируется как раз тестирование по типу черного ящика: автор предлагает только ПОДХОД к тому как имитировать действия пользователя с GUI и сравнивать реакцию системы с ожидаемой.
Может быть я Вас не правильно поняла, тогда поправьте меня :)
