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

[Shander]

Зато это жизненно и правдиво.

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

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

[Kaluga]

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

Особо талантливые так могут извернуться даже в случае "явных" требований :)

[astik]

ПМ хочет чтобы тестировщики отчитывались о том насколько качественно и в какие сроки протестирована будет программа.
Ja by snachalo by uznl u PM ego predstovlenie o kachestve?
Nu a testirovat' mozhno beskonechno lish by za eto den'gi platili :) No kak testirovat' ne znaja ozhidaemogo rezul'tata?
Tut travite zakazchika zaprosami, i kogda emu nadoest otvechjat' vam. To na vse ego posledujushie pretenzii, chto eto tak ne rabotaet i to ne tak.
Logichnyi otvet : - My vas ob etom sprashivali!

[Diablo]

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

[dlg99]

1. Давить на ПМ чтоб была документация, возможно следует нанять технического писателя.

свеженанятый т.писатель не расскажет тестеру ничего нового о том, как приложение работает. А вот времени на то, чтобы ему/ей рассказать лб этом же потребует.

3. Если документация не предвидиться, а все добавления включаются по ходу, то ЗАСТАВТЕ хотя бы программеров вести примитивный Changelog, пусть указываю, что было изменено/добавленно/пофикшено в данном билде.

Changelog получается из version control system + bug tracker.
Если девелоперы их не используют - то это та проблема, которую нужно решать (при помощи ПМ-а).
Ведение Changelog на клочке бумажки не заменяет нормальные практики разработки ПО.

[dlg99]

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

- Уволен.

Может там работы на: 15 мин - поговорить с developers, 15 мин - написать mini-spec/checklist, и 2 часа на тестирование.

dodging the issue doesn't help to resolve the issue.

[Clauster]

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

А мне интересно тогда, как это же самое делают программисты? Или им всё равно, сколько они будут писать код? Поспрашивайте у них. Самая простая и грубая оценка времени на тестирование это примерно 25-40% (в зависимости от сложности системы) от времени на разработку. Можно ещё добавить время на планирование и документирование и риски.
Оценить качество тестирования вы можете только после завершения тестирования. Тут уже зависит от того какие критерии или метрики выберите. Для грубой оценкиможете отталкиваться от частоты нахождения ошибок. Определяете пороговое значение, рисуете график, когда кривая опуститься ниже порога, значит достигли определённого уровня качества.
В моём предложенном случае никаких тест-кейсов, сьютов, чек-листов и проч. писать не надо, но это временный вариант, лучше это всё впоследствии потихоньку осилить.

[Azart]

свеженанятый т.писатель не расскажет тестеру ничего нового о том, как приложение работает. А вот времени на то, чтобы ему/ей рассказать лб этом же потребует.

Вот это реакция не ожидал. Сомнительно, что фирма живёт одним днём и одной программой. Наверно будут и други проги и каждый раз при её написание будет задаваться вопрос "А зачем нам писатель, он всё равно не успеет что то новое внести". Может стоит заглянуть в будущее??? И понять, что со временем будет нужная документация в нужное время...

Ведение Changelog на клочке бумажки не заменяет нормальные практики разработки ПО.

Даже лучше на туалетной бумажке, идёшь в туает берёш ручку и пишешь, что изменилось. Конечно не заменит, но такой вариант требует мало затрат и даёт помощь в обсуждаемой ситуации.

[Clauster]

Azart, а что вы системного аналитика тогда не посоветовали? И менеджера продукта? Ещё специалистов по качеству можно набрать. Раз уж в будущее заглядываем.

[Azart]

Clauster, это я завтра хотел посоветовать, а то всё сразу мне показалось многоато будет. Ведь придётся наверно ещё HR нанимать для поиска сотрудников.

[Boltick]

Clauster, это я завтра хотел посоветовать, а то всё сразу мне показалось многоато будет. Ведь придётся наверно ещё HR нанимать для поиска сотрудников.

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

[dlg99]

свеженанятый т.писатель не расскажет тестеру ничего нового о том, как приложение работает. А вот времени на то, чтобы ему/ей рассказать лб этом же потребует.

Вот это реакция не ожидал. Сомнительно, что фирма живёт одним днём и одной программой. Наверно будут и други проги и каждый раз при её написание будет задаваться вопрос "А зачем нам писатель, он всё равно не успеет что то новое внести". Может стоит заглянуть в будущее??? И понять, что со временем будет нужная документация в нужное время...

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

А планы на будущее могут и отдел тех.поддердки включать, и много чего другого

[Azart]

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

Не все фирмы хотят оглошать о томи что они ищят сотрудником! Для этого у них есть HR, который обращается в кадровое агенство...

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

Хорошая("правильная") документация всегда помошник.

[mercy]

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

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

[SALar]

Зато это жизненно и правдиво.

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

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

- Уволен.

Может там работы на: 15 мин - поговорить с developers, 15 мин - написать mini-spec/checklist, и 2 часа на тестирование.

dodging the issue doesn't help to resolve the issue.

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

[SALar]

Может там работы на: 15 мин - поговорить с developers, 15 мин - написать mini-spec/checklist, и 2 часа на тестирование.

dodging the issue doesn't help to resolve the issue.

По поводу 2 часов. Чем меньше проект - тем легче оценить время. Если программа класса "Hallo word!", то нормальной оценкой будет: "Сегодня закончу".
Для, хотя бы, среднего проекта (от 100 человекомесяцев) все по-другому. Еще большую неопределенность вносит принадлежность проекта к определенному классу (вернее отсутствие информации о классе проекта).

Пример.
Есть проект. Около 500 прецедентов. 30 человекомесяцев кодирования. Больше ничего неизвестно. Сколько времени нужно на тестирование?

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

2. Добавляем требования:
* Работа в разных окружениях.
* Безопасность и права доступа.
* Конкурентную работу.
* Жесткие требования к юзабилити.
* И т.д.
Временные затраты резко пошли вверх. Это уже 10-20 человекомесяцев.
Но ошибка в оценке запрошенного времени тестирования по-прежнему некритична.

3. Изменим класс проекта. Пусть теперь пропущенная ошибка приводит не к "неудобству пользователя", а "всего лишь" к огромным финансовым потерям. Классический пример - потеря ракетоносителя с дорогостоящим оборудованием. Но мы возьмем другой пример.
Разработана программа для микропроцессора. Разработана "впритык". Исправление ошибки может привести к выходу за пределы данного микропроцессора. Если она обнаружится после крайнего срока, то это: переход на другой процессор (уже закупленные оставляем на складе), выкидывание уже изготовленных плат и т.д..
В этом случае я не буду подписываться под словами "2 часа", без тщательного изучения документации.

PS. Пример взят из неплохого рассказа Истоpия одного байта.

[SALar]

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

Мои пять копеек.
Это не качество продукта, это оттестированность требований, переданных в тестирование.

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

[Guriy]

На Вашем месте я бы организовал процесс подписи модулей. Для этого нужно:
1. Отмашка, что модуль готов (дев лид)
2. Чеклист/тест-кейс (тест дизайнер)
3. Протокол (тестировщик)
4. Резолюция (дев лид)

Что дает такой метод:
1. Все легко согласятся (подписывать ведь круто, не так ли? ;) )
2. Часть ответственности перетечет к девлиду (а кому как не ему знать о том, как работает система, и поэтому контролировать чтобы ничего не забыли протестировать)
3. Очень скоро девлиду надоест подписывать непонятные бумажки (а значит и брать на себя ответственность за непонятно что) и он начнет напрягать девелоперов описывать то, что они накодировали более понятным ему языком.

Ну а от этого уже в принципе один-два шага до спецификаций ;)
А пока
4. У Вас будет пакет бумажек, с которыми Вы сможете подойти к менеджеру и сказать: 87% уже проверено :)

удачи