Публикации Yarilo

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

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

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

Вперед

Сортировать

Порядок

#3747 Новости тестирования?

Отправлено автор: Yarilo 28 мая 2004 - 03:29 в Портал Software-Testing.Ru

Привет!
Мне было бы удобнее, если бы новостная рассылка выходила раз в неделю в рамках рассылки 'Тестирование и качество', т.к. я уже подписана на три рассылки по тестированию и качеству и, если честно, иногда в них путаюсь :huh:

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

#4716 Тестировщики из других профессий?

Отправлено автор: Yarilo 10 августа 2004 - 06:32 в Круглый стол о работе в тестировании ПО

Русские шрифты заработали :)
Согласна с ex-dani в том, что тестировщик должен быть терпеливым, потому что если это не так, то он недолго будет тестировщиком.

Это такая профессия, что важнее человеческие качества, чем начальные умения.

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

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

#4717 Уровень тестировщиков.

Отправлено автор: Yarilo 10 августа 2004 - 06:43 в Работа для тестировщика/QA

На мой взгляд, чтобы привлечь хорошего тестировщика (или сманить из другой смежной прфессии), необходимо тщательно продумать реальную достижимую стратегию профессионального развития тестировщика, его карьерного роста в ДАННОЙ КОНКРЕТНОЙ КОМПАНИИ (куда хотите его привлечь).

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

#4775 Формирование отдела тестирования с нуля

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

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

#4789 Тестировщики из других профессий?

Отправлено автор: Yarilo 12 августа 2004 - 11:19 в Круглый стол о работе в тестировании ПО

Разборки на уровне - "не программисты - поэтому не профессионалы" - это на уровне детского сада.
По-моему, не будут уважать тогда, когда тестировщик не выполняет свою работу - не находит баги, или не может их внятно объяснить и качественно задокументировать, а не в стиле "у вас что-то где-то не работает". ;)

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

#4790 Тестировщики из других профессий?

Отправлено автор: Yarilo 12 августа 2004 - 11:36 в Круглый стол о работе в тестировании ПО

Спецификации от разработчиков далеко не идеальны.
Наверное, потому что спецификации это не документ, который должны составлять разработчики ;)

Я имела в виду разработчика в широком смысле слова - и аналитик, и архитектор, и дизайнер, и кодер.

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

#4793 Деструктивное мышление - 2

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

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

#4804 Lessons Learnt & Best Practice Analysis

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

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

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

#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 писанные и пр. виды).

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

#4990 Automated Testing: Actuality Issues

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

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

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

#5033 Automated Testing: Actuality Issues

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

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

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

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

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

Привет!

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

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

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

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

#5040 Rights Managent Models In Systems

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

Привет!

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

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

#5104 Automated Testing: Actuality Issues

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#5110 Кто мы (1)

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

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

Точно!

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

#5194 Automated Testing: Actuality Issues

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#5242 Automated Testing: Actuality Issues

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

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

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

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

#5272 Automated Testing: Actuality Issues

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

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

#5274 Automated Testing: Actuality Issues

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вперед

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