Публикации Yarilo

57 публикаций создано Yarilo (учитываются публикации только с 03 мая 2023)

По типу контента

По пользователю

Вперед

Сортировать

Порядок

#7849 План для автоматизированных тестов

Отправлено автор: Yarilo 18 ноября 2004 - 09:06 в Автоматизированное тестирование

Что ты имеешь в виду под тестированием на основе моделей?

В двух словах:
строится модель системы (возможно, с помощью специального программного языка описания), потом описывается схема/правила тестирования, использующая модель системы и тестовые данные (описываеться может тоже программно). Потом, когда все это автоматизировано, запускается главная процедура и тестирование идет автоматически по схеме/правилам по модели.

Более подробно можешь поискать в инете, посмотри также подход UniTesK.

#7839 Форумы для наших коллег: разработка, постановка?

Отправлено автор: Yarilo 18 ноября 2004 - 08:13 в Idea Box!

А может здесь же и вырастем во всеобщий ресурс?
Вот бы здорово было! :D

#7838 Форумы для наших коллег: разработка, постановка?

Отправлено автор: Yarilo 18 ноября 2004 - 08:12 в Idea Box!

Вот-вот! (про постановщиков)
В свое время столкнулась с нехваткой информации по конкретной проблеме (из области именно постановки) и подумала - вот по тестированию такой класный ресурс есть, можно спросить совета у опытных коллег, а тут и спросить не у кого.
И подобного ресурса (не только форум) по тематике бизнес анализа не знаю. Может кто чего-нибудь подскажет (ресурс)? :rolleyes:

#7834 План для автоматизированных тестов

Отправлено автор: Yarilo 18 ноября 2004 - 08:04 в Автоматизированное тестирование

Вид описания варианта тестирования завист, кроме всего, от подхода к тестированию. Если вы хотите построить тестирование на основе моделей, то расписывать каждый конкретный flow не стоит.

#7829 Форумы для наших коллег: разработка, постановка?

Отправлено автор: Yarilo 18 ноября 2004 - 07:53 в Idea Box!

Добавлю, что в этом форуме мне очень нравится то, что по e-mail мне приходят списки уведомлений о новых открытых темах, без них я бы не стала лазить по форуму. А если бы и стала, то очень редко и по нужде, т.к. не все темы меня интересуют.

#7826 Форумы для наших коллег: разработка, постановка?

Отправлено автор: Yarilo 18 ноября 2004 - 07:49 в Idea Box!

Привет!

Для обсуждения будут интересны проблемы и подходы к интеграции процессов разработки и тестирования (с точки зрения кто, когда, в каких случаях, в каком виде предоставляет какие артефакты - от разработчиков к тестировщикам и наоборот) - это наверняка будет интересно:
группе, разрабатывающей процессы в компании,
для подготовки к сертификации,
разработки единой схемы описания артефактов, которые можно будет использовать как разработчикам так и тестировщикам одновременно (для того, чтобы в быстрых проектах или при нехватке ресурсов разработать приемлемую минимальную проектную документацию).

Соответственно, контингент заинтересованных лиц - тестировщики ПО, разработчики процессов в компании, разработчики ПО (для обсуждения вида и содержания единой документации/описания системы, например), начальство (в некоторой мере).

Можно это организовать (как мне видится) отдельной корневой веткой в форуме (но не разделять тестировщиков от остальных лиц), сделать отдельную рассылку только для этой ветки, назвать рассылку заманчиво для ВСЕХ заинтересованных лиц (это чтобы целенаправленно привлечь нужную аудиторию). И в рамках ветки действовать :)

Идея разместить эту тему на rsdn или других форумах хороша, я не знаю только, возможно ли так сделать, чтобы там ее разместить, а оттуда на наш форум перекидывать пользователя - было бы хорошо. Или там разместить и помещать список топиков (ответвлений), и перебрасывать по любой из них.

#7353 Подготовка к сертификации.

Отправлено автор: Yarilo 03 ноября 2004 - 04:06 в Управление тестированием

Фирме в которой я работаю необходимо пройти сертификацию по ISO 9001:2000

1.Как подготовить фирму к сертификации (я не знаю, готова она или нет).
2.Если есть, какие то критерии, которым надо соответствовать (что-то на подобии того, как в CMM), то где их можно найти (скачать, купить).

Первым шагом видится прочитать документы по ISO 9001:2000,
тогда станет понятно, насколько фирма готова и чего ей не хватает, следовательно прояснятся задачи, из задач вытекает и время для подготовки :)

#7297 Парочка...

Отправлено автор: Yarilo 01 ноября 2004 - 09:15 в Ошибки в работе форума

По-моему, тестер = тестировщик, только тестер - это русифицированный английский вариант слова tester. То есть, по английски tester, по русски тестировщик - это одно и то же. :)

#7267 Из программиста в тестировщики

Отправлено автор: Yarilo 29 октября 2004 - 12:55 в Свободное общение

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

Интересно, а где это так доплачивают (ну хотя бы город скажите)? :rolleyes:

#5274 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 27 августа 2004 - 09:00 в Автоматизированное тестирование

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

Я бы добавила, что если посмотреть на ситуацию из отдаленного будущего, то не только не все не потеряно, но даже такая ситуация полезна:

1)заниматься только ручным тестированием длительное время без переключения на другие виды деятельности оооочень утомительно ;) , поэтому лет через n нужно было бы все равно искать других тестировщиков...

2)теперь тестировщики имеют шанс углубить свои знания в технологиях программирования, архитектурных вещях;

3)разработчики должны будут изменить подход к разработке, чтобы предупреждать ошибки;

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

#5272 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 27 августа 2004 - 08:36 в Автоматизированное тестирование

Спасибо, уважаемый Barancev (даже как-то неудобно по фамилии называть :unsure: ) за совет, я так и настраиваюсь на борьбу за качество, теперь изнутри команды, а не снаружи :)

#5242 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 26 августа 2004 - 10:27 в Автоматизированное тестирование

Если я не ошибаюсь - то пора делать ноги.

Отказ от обеспечения качества для своих программных продуктов говорит о кризисе в компании.

Ну, скажем, стресс, мы переходим из инкубаторного состояния на рынок :rolleyes:
Мы (тестировщики) сейчас пробуем переквалифицироваться, получится (я надеюсь!) - будем девелоперы на все руки, не получится - сделаем ноги :D

#5212 Требования для тестирования

Отправлено автор: Yarilo 25 августа 2004 - 09:39 в Управление тестированием

Не соглашусь.
Первая ситуация:
Контракт подписывался с генеральным директором, переговоры "что и как" велись с ИТ-директором. ИТ-директор увольняется. Берут другого, который читает контракт, понимая его абсолютно по-своему. Что дальше?

Вторая ситуация:
Вы успешно сдаете проект, проходит полгода. Вдруг :) оказывается, что какая-то деталь, очень важная с точки зрения заказчика, не реализована. Заказчик приходит к вам. Грозится подать на вас в суд, если вы не допишите бесплатно нужную "деталь". Вы понимаете, что это противоречит всей архитектуре системы. Что дальше?

ИМХО требования всегда нужны и если их нет, то тестировщику лучше написать их самому или требовать у лидера проекта. Иначе возможны проблемы именно у тестировщика :)

Undi, вы, видимо, не согласны с тем, что стоит внедрять описанный мной подход в работе над проектом. Но я это и НЕ ПРЕДЛАГАЮ!

Я описала реальную ситуацию, когда Software Requirements МОГУТ БЫТЬ НЕ ОПИСАННЫМИ (а они действительно МОГУТ быть недокументированы), и как в этом случае строится работа команды, включая тестировщика; я отнюдь не призываю к внедрению такого подхода в IT компанию.

По поводу неожиданностей:
У нас так принято:
Заказчик участвует в официальном бета тестировании продукта, обнаруженные в результате дефекты и недоработки будут исправлены. И никаких пол года вдруг B) К тому же, все фичи заявляются в контракте. Архитектурно значимые варианты использования тоже выявляются в стадии presale, так что неожиданных кардинальных деталей не может возникнуть.

Про увольнение сотрудников, владеющих информацией:
А аналитик может уволиться и сразу после устных переговоров с заказчиком, когда ничего не еще документировано.

Но связь с заказчиком не обрывается и не ограничивается одним разом.

Обычно разговоры "что и как" происходят постепенно, а не всё в один раз, при этом вопросы и предложения о работе системы задаются в письменной форме и ответы тоже (или в устной, но тогда передаются команде разработчиков, иначе все равно всего в деталях не запомнить), тогда аналитик владеет приватно (если он расшаривает переписку) только концепцией построения системы и способами ее осуществления, а не собственно информацией о системе.

А вот если не расшаривает, и модель водопадная,то всяко может быть, тут я согласна с Undi :) - но это тоже решаемо - смотря как в компании процессы налажены :P

#5198 Кто как хранит рабочие документы по тестированию?

Отправлено автор: Yarilo 25 августа 2004 - 06:22 в Управление тестированием

4) Вся документация хранится в системе версионного контроля совместно с рабочими документами по разработке ПО

Храним как все остальные документы и файлы с кодом.

#5194 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 25 августа 2004 - 05:15 в Автоматизированное тестирование

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

#5110 Кто мы (1)

Отправлено автор: Yarilo 23 августа 2004 - 09:42 в Свободное общение

Жаль, нельзя несколько галочек наставить. По жизни, приходится многим заниматься :).

Точно!

Может быть завести чек-боксы вместо радио-буттонов на форме голосования? :rolleyes:

#5109 Требования для тестирования

Отправлено автор: Yarilo 23 августа 2004 - 09:13 в Управление тестированием

Да и по крупным проектам может не быть детализированных требований, хотя я совсем не сторонница такого подхода!

#5108 Требования для тестирования

Отправлено автор: Yarilo 23 августа 2004 - 09:12 в Управление тестированием

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

Если нет требований - то по большому счёту будет сделано что-то, а не система.

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

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

#5104 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 23 августа 2004 - 07:35 в Автоматизированное тестирование

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

Да уж, точно не играют!

У нас в компании в некоторых проектах сами разработчики пишут автоматизированные тесты для конкретных функций кода (unit-тестирование), а тестирование как процесс заключается в прогоне системы по вариантам использования (иногда нигде не документированным) с различными тестовыми данными вручную, причем регрессионное - большая редкость, т.к. жизнь проекта - от 2-х недель до 3-4-х месяцев.... А теперь и вообще, отмирает тестирование :( - говорят и без него жить можно.

Нам, тестировщикам, изначальна была установка от руководства - чтобы все автоматизировать, на ночь запускаем тестирование, а утром все готово и так каждый день для новых билдов, так вот, я раньше думала, что наверное где-то (в далекой Австралии :lol:

) есть такие супер-специалисты которые так смогут автоматизировать тестирование и это зависит от квалификации и т.п., но вот сейчас, в результате этой дискуссии (по большей части), мне стало понятно насколько бессмысленно даже думать что в наших условиях возможно автоматизировать тестирование (особенно при соотношении разработчиков к тестировщикам примерно 8:1)....

Хочу поблагодарить всех участников этой дискуссии за столь полное освещение вопросов автоматизированного тестирования, этот тред точно кому-нибудь поможет разобраться что к чему, и мне, может быть тоже в будущем :)

#5040 Rights Managent Models In Systems

Отправлено автор: Yarilo 20 августа 2004 - 07:21 в Тест-дизайн и ручное тестирование

Привет!

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

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

#5038 Требования для тестирования

Отправлено автор: Yarilo 20 августа 2004 - 06:58 в Управление тестированием

Привет!

По поводу требований - use cases выражают требования к поведению системы.
Требования составляет аналитик (роль). Роль аналитика может выполнять человек, привлеченный к этой задаче (как программист, так и тестировщик, может быть и менеджер проектов).

По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО. Обычно с заказчиком обсуждаются бизнес-требования (т.н. features, функции системы, ее характерные особенности). Также с заказчиком обсуждаются use cases. Требования к ПО (Software Requirements) получаются в результате детализации бизнес-требований и use cases.

Вы, Алексей, видимо задавали вопрос именно о Software Requirements. Их в проекте строго оформленных может и не быть, особенно, если сроки разработки быстрые/проектная команда маленькая (просто разработчики между собой договариваются, а заказчику сразу предоставляются версии программы, прототипы, раскадровки и т.п.). В этом случае отсутствия спецификаций Software Requirements тестировщик сам исследует поведение системы, выясняя и уточняя поведение системы непосредственно у разработчиков. Можно попросить написать спецификакии на особо критические области программы - запрос адресовать к менеджеру проектов, чтобы он поручил разработчикам (или сам написал).

(Это из моего опыта)
Надеюсь, поможет... :)

#5033 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 20 августа 2004 - 04:05 в Автоматизированное тестирование

Вот так, два ответа в совокупности дали ясную реалистичную картину из мира автоматизированного тестирования и прояснили мои догадки и вопросы.

Спасибо, Darkus, за подробный ответ и, в особенности, за пример!

#4990 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 19 августа 2004 - 07:39 в Автоматизированное тестирование

Вот это да!!!
Вот так Dmitry_NJ!
Спасибо за ваш развернутый ответ!!!

Теперь у меня нету сомнений в том, что автоматизация тестирования GUI систем в нашей компании в текущей ситуации - несбыточная мечта (и можно спокойно принять этот факт :) )!

#4905 Automated Testing: Actuality Issues

Отправлено автор: Yarilo 17 августа 2004 - 07:14 в Автоматизированное тестирование

Привет!

Вот пишут используйте то, сё средство для написания скриптов, люди задают конкретные вопросы по автоматизации (то есть люди автоматизируют тестирование), на работу зовут чтобы автоматизировали тестирование с помощью скриптовых тулзов, при этом, изучая многие (ну, может и не сильно их много было :)) источники про автоматизацию (в том числе с этого сайта), я пришла к таким выводам:

- окупаться будет только автоматизированное тестирование, основанное на моделях системы, причем если только тестировать таким образом критические системы (типа системы жизнеобеспечения, компиляторы и пр.);

- затраты на тестирование, основанное на скриптах, при малейших изменениях функций системы будут расти в геометрической прогрессии => слишком дорого, чтобы применять в проектах с неводопадным жизненным циклом разработки;

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

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

В связи с этим у меня вопроы давно такие:

1.Для небольших проектов (4-5 разработчиков, 1-3 месяца работы) стоит ли автоматизировать тестирование, если стоит, то:

- какой тип тестирования нужно автоматизировать (модульное? системное?)?

- какой тип автоматизации использовать (скрипты для use cases? скрипты для функций имплементации самого нижнего уровня? тестирование на моделях - относительно use cases? тестирование на моделях - относительно функций имплементации самого нижнего уровня?)?

2.Какое должно быть соотношение тестировщиков по отношению к разработчикам чтобы можно было вообще думать о возможности автоматизации?

3.Обязательно ли начинать работы по подготовке и разработке автоматизированного тестирования с самого начало разработки самой системы? (если нет, то когда начинать)

4. Чего вы вообще автоматизируете?! (отчаянно) Имеется в виду, какие типы приложений (бизнес-приложения с клиент-серверной архитектурой, web-приложения с архитектурой клиент-web сервис..., сайты на PHP писанные и пр. виды).

Люди, пожалуйста, откликнетесь!!!!

#4804 Lessons Learnt & Best Practice Analysis

Отправлено автор: Yarilo 13 августа 2004 - 07:23 в Управление тестированием

Привет!
В нашей компании мы после каждого проекта не проводим собраний, но когда ценная идея (или полезный опыт) возникает по организации работы, мы ее обсуждаем.

Эффективность тестирования проекта коллективно не обсуждаем, но могу за себя сказать, что полезно вести запись последовательности выполнения работ по тестированию (порядок выполнения конкретных задач) с краткими описаниями, а потом обдумывать и записывать (забывается!) как можно было оптимизировать работу, что было лишним, чего не хватало и над чем нужно дополнительно подумать. Окончательные решения по поводу оптимизации работы стоит записывать отдельно - как рекомендации, потом полезно перед новым проектом перечитывать эти заметки.

Вперед

Реклама на портале