Сообщений в теме: 26

[dlg99]

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

А почему не почитать умных дядь из Microsoft? MSF и т.д.?
software projects этих дядь несколько более успешны (по-моему).

А эти дяди тоже интересно пишут. И более приближенно к реальности с которой придется столкнуться в компании, в которой "не слишком хорошо поставлен процесс разработки".

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

RUP (ИМХО, конечно) - хорошая отправная точка в случае если в компании не слишком хорошо поставлен процесс разработки ( в смысле, нет чёткой его методологии), а похоже, что это - именно тот случай :).

Осталось еще послать человека стандарты ISO900x изучать.
Чтобы точно толку от всего этого не было.

[Mike]

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

Не обязательно RUP. Можно и MSF, или та методолгия, которая применяется в компании (XP, например).

Стандарты почтитать, кстати (с чисто общеобразоватьельными целями), тоже не помешает. Как и, скажем, CMMI.

[Clauster]

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

Для этого совсем не обязательно читать RUP. Возьмите любую книгу о тестировании, а лучше статьи на сервере почитать :)

Не обязательно RUP. Можно и MSF, или та методолгия, которая применяется в компании (XP, например).

Стандарты почтитать, кстати (с чисто общеобразоватьельными целями), тоже не помешает. Как и, скажем, CMMI.

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

[Clauster]

А с чего стоит начинать?

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

[Green]

Ребята,

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

Откуда же беруться такие глуп.. извините, простые вопросы?

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

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

Во-первых, есть я (как тестировщик). Мне нужно каждый день что-то делать. Необходимо владеть техникой тестирования - выбора типов тестов, выполнения тест кейсов, подготовки тестовых данных, внесения багов в баг трекинговую систему. За информацией лучше всего обращаться к классикам жанра. Я не встречал пока книги лучше, чем "Тестирование программного обеспечения" г-на Канера и сотоварищей.

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

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

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

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

[Ariokh]

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

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

[Xoroshaja]

Здравствуйте, скажите, пожалуйста, что такое предустановка. Спасибо.