вторник, 16 октября 2012 г.

Lesson 187

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

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

Что особенно приятно, сегодня ее организовала с моей подачи новенькая. А то чо все я да я?

По результатам победила дружба выяснилось:
1. Что аналитики едят свой хлеб не зря. Некоторые не зря мажут на него икру. Не было ничего сверхъестественного, и в конечном счете, например я бы тоже все нашел. Но за отведенный час именно аналитик нашел больше.

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

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

4. Что не можешь занять первое место — займись лучше организацией.

5. Что некоторые постановки лучше даже не читать. Целее будешь.

Пикрандом.


Слово Канеру

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

Ваша работа состоит из выполнения большого количества задач. Составьте их список (см. Канер, 1996b и любые другие книги по управлению проектами, охватывающие работы по оценке). Некоторые задачи можно описать только в общих чертах; другие можно разбить на мелкие части. По мере возможностей, создавайте отдельные задачи на все, что может занять больше дня. Оцените (предположите) сколько времени займет задача, прибавьте 25 процентов (больше или меньше в зависимости от компании) для совещаний, обучения и других работ вне проекта и используйте полученное значение, как время, необходимое для решения задачи.

Этот метод выглядит проще, чем на самом деле. Составление списка задач — не так тривиально, очень легко пропустить задачи или недооценить их.

Пробуйте и другие методы для оценок:
- Если вы делали и другие проекты, подобные этому, возьмите за основу время, которое они заняли.
- If you have a sense of the length and complexity of the program and a model based on data in your current company that relates length and complexity to duration of testing, apply the model to derive an estimate.
- Если вы чувствуете, что существуют риски, связанные с проектом, оцените время для проверки этих рисков
- Другие факторы, которые вы могли бы оценить. Например, если вы знаете, что программисты особенно хорошо знают этот тип приложений, то, вероятно, потребуется меньше времени на тестирование. Если этот конкретный программист делает много ошибок, чем остальные, то, возможно, понадобится больше времени на тестирование. Если пользовательская документация уже написана четко и ясно, если известен образ действий и входные данные пользователей, то тестировать будет проще.


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

Комментариев нет:

Отправить комментарий