Листал свою тетрадь с записями и нашёл ещё несколько цитат из книги. Пусть и они не потереяются в многочисленных моих тетрадках, а остануются в памяти потомков :)
18. Отвечать на вопросы по спеку - святая обязанность продюсера (автор спека)
НО!
19. Нет email - нет доказательств. АП- я сам теперь стал чаще использовать этот простой приём. Ответ будет всегда у себя в папке. Да и слово не воробей, а тестеру спокойней :)
20. Тестеры на работе используют ту степень детализации, которая нужна в конкретной ситуации. АП - это как раз про тесты напоминание. Тесты нужно писать в соответсвии с достаточной для выполнения детализацией. Мне это близко - поэтому я подчеркнул этот момент.
21. Блок - схемы - визуальные источники идей для тестирования. АП- пока не использовал, но надо обязательно попробовать. Всё равно, для понимания некоторых вещей приходится рисовать схемы в тетрадке.
В качестве анонса: изучал открытую для доступа презентацию Славы Панкратова "Менеджмент тестирования". Сделал ряд пометок и цитат. Скоро выложу.
суббота, 29 августа 2009 г.
Тестирование.com Part 3 (Final)
Продолжаю цитировать Тестирование.com.
15. Количество багов до релиза ничего не говорит об эффективности тестирования. Баги найденные после релиза - вот это важно. АП- "Качество продукта - количество багов найденных клиентом и его реакция на них." На одном из докладов по тестированию в Agile labs 2009 про тестирование услышал это определение. ( Для подробностей отсылаю к Александру Орлову )
Мне оно очень понравилось, теперь я тоже смотрю на вещи шире. Идеального продукта не было и не будет, задача тестирования найти максимум проблем.
16. АП- Спецификация конечно мать или отец всех тестов, но можно и просто воспользоваться здравым смыслом. Далее я привожу список примеров ожидаемых результатов тестов из книги Романа.
а) жизненный опыт
б) здравый смысл
в) общение ( с разработчиками в том числе)
г) устоявшиеся стандарты
д) статистические данные
е) авторитетное мнение
17. Тест- смета создаётся после чтения спека. Факторы анализа при составлении тест-сметы *10% (примерно всё посчитать и накинуть минимум 10 процентов)
а) предполагаемая сложность новых фич
б) есть ли опыт тестирования похожих фич
в) опыт работы на прошлых проектах с теми же продюссером ( автор спецификации) и программистами.
г) Будет ли интеграция нашего ПО с ПО наших бизнес партнёров
д) Нужна ли автоматизация.
АП- Не всегда все эти элементы удаётся посчитать, поэтому я в текущем своём проекте просто прикинул по срокам, которые пришли сверху и составил свою смету в рамках текущих сроков.
После написания всех тестов, успешной настройки всей нетривиальной системы и 1-го прогона тестов буду править текущих план.
Итого: Книга Романа мне понравилась, написана бодро и весело. Несколько интересных моментов я отметил цитатами выше. Ещё много осталось за кадром. Жаль что я пришёл к ней только через 4 года тестирования, до этого у меня было много здравого смысла, интуиции. А теперь есть ещё и знания. А мог бы уже быть выше по карьерной лестнице :)
15. Количество багов до релиза ничего не говорит об эффективности тестирования. Баги найденные после релиза - вот это важно. АП- "Качество продукта - количество багов найденных клиентом и его реакция на них." На одном из докладов по тестированию в Agile labs 2009 про тестирование услышал это определение. ( Для подробностей отсылаю к Александру Орлову )
Мне оно очень понравилось, теперь я тоже смотрю на вещи шире. Идеального продукта не было и не будет, задача тестирования найти максимум проблем.
16. АП- Спецификация конечно мать или отец всех тестов, но можно и просто воспользоваться здравым смыслом. Далее я привожу список примеров ожидаемых результатов тестов из книги Романа.
а) жизненный опыт
б) здравый смысл
в) общение ( с разработчиками в том числе)
г) устоявшиеся стандарты
д) статистические данные
е) авторитетное мнение
17. Тест- смета создаётся после чтения спека. Факторы анализа при составлении тест-сметы *10% (примерно всё посчитать и накинуть минимум 10 процентов)
а) предполагаемая сложность новых фич
б) есть ли опыт тестирования похожих фич
в) опыт работы на прошлых проектах с теми же продюссером ( автор спецификации) и программистами.
г) Будет ли интеграция нашего ПО с ПО наших бизнес партнёров
д) Нужна ли автоматизация.
АП- Не всегда все эти элементы удаётся посчитать, поэтому я в текущем своём проекте просто прикинул по срокам, которые пришли сверху и составил свою смету в рамках текущих сроков.
После написания всех тестов, успешной настройки всей нетривиальной системы и 1-го прогона тестов буду править текущих план.
Итого: Книга Романа мне понравилась, написана бодро и весело. Несколько интересных моментов я отметил цитатами выше. Ещё много осталось за кадром. Жаль что я пришёл к ней только через 4 года тестирования, до этого у меня было много здравого смысла, интуиции. А теперь есть ещё и знания. А мог бы уже быть выше по карьерной лестнице :)
Тестирование.com Part 2
Продолжаю цитировать книгу Романа Савина Тестирование.com.
8. Тестировать пограничные значения. АП - Думаю все знакомые с тестированием хорошо представляют о чём идёт речь. Но я всё же расшифрую. Мы имеем какое либо поле, которое поддерживает значения от 1 до 99. Соответсвенно, чтобы хорошенько проверить это нужно ввести следующие значения: 0,1, 50,99,100,-1
-1,0 и 100 не должны приниматься системой, как выходящие за рамки требований.
9. Тестирование процесс творческий. АП - Баги находят не тесты, а люди. Значит проверять можно не просто напрямую по тесту, но и всё что хочется рядом. Да и вообще, если потянуло что-то проверить, не стоит себя ограничивать. Но при этом надо себе помечать шаги, чтобы сразу можно было бы проверить воспроизводимость баги и радостно отрапортавать в виде баг-репорта.
10. MRD (marketing requirements document) АП- я это пометил, тк для самого стало сюрпризом, что основа требований для разработчиков и тестеров является документ от маркетинга. В своей практике я пока такого не встречал. В моём текущем проекте требования пишет разработчик уже после создания программы и то только потому, что мне нужно писать тесты по требованиям. :)
11. Спецификации должны иметь уникальный ID. AП - Я конечно это знал давно, но просто отметил для себя, это действительно важный момент. Если спек поменяют и удалят требование, а на его место поставят другое, то сложно будет для тестеров понять. Почему в тесте ссылка на спек, который описывает совсем другую функциональность.
12. Излишняя детализация тестов усложняет поддержку, а излишнее абстрагирование ведёт к непониманию. АП - Часто вопрос выбора стратегии написания тестов, вопрос времени, денег и ресурсов. При наличии всего в достатке, можно писать очень подробные тесты. А при отсутствии оного, просто следовать в тестировании некому чек-листу, списку наиболее важных моментов для тестирования. Я сам на данный момент нахожусь в промежуточной ситуации, поэтому тесты пишу, но без лишних подробностей.
13. Шаги и настройки повторяющихся сценариев можно вынести в отдельный документ.
АП - Чувствую, что очень полезная вещь. Но пока в практике у меня не было такого, попробую в текущем проекте.
14. Два и более ожидаемых результата в тесте - нормальная практика. АП- При написании тестов я часто пользуюсь таким приёмом, это сокращает время на создание теста. Но начинающим тестерам, это не всегда понятно, почему тут сразу несколько результатов.
To be concluded
8. Тестировать пограничные значения. АП - Думаю все знакомые с тестированием хорошо представляют о чём идёт речь. Но я всё же расшифрую. Мы имеем какое либо поле, которое поддерживает значения от 1 до 99. Соответсвенно, чтобы хорошенько проверить это нужно ввести следующие значения: 0,1, 50,99,100,-1
-1,0 и 100 не должны приниматься системой, как выходящие за рамки требований.
9. Тестирование процесс творческий. АП - Баги находят не тесты, а люди. Значит проверять можно не просто напрямую по тесту, но и всё что хочется рядом. Да и вообще, если потянуло что-то проверить, не стоит себя ограничивать. Но при этом надо себе помечать шаги, чтобы сразу можно было бы проверить воспроизводимость баги и радостно отрапортавать в виде баг-репорта.
10. MRD (marketing requirements document) АП- я это пометил, тк для самого стало сюрпризом, что основа требований для разработчиков и тестеров является документ от маркетинга. В своей практике я пока такого не встречал. В моём текущем проекте требования пишет разработчик уже после создания программы и то только потому, что мне нужно писать тесты по требованиям. :)
11. Спецификации должны иметь уникальный ID. AП - Я конечно это знал давно, но просто отметил для себя, это действительно важный момент. Если спек поменяют и удалят требование, а на его место поставят другое, то сложно будет для тестеров понять. Почему в тесте ссылка на спек, который описывает совсем другую функциональность.
12. Излишняя детализация тестов усложняет поддержку, а излишнее абстрагирование ведёт к непониманию. АП - Часто вопрос выбора стратегии написания тестов, вопрос времени, денег и ресурсов. При наличии всего в достатке, можно писать очень подробные тесты. А при отсутствии оного, просто следовать в тестировании некому чек-листу, списку наиболее важных моментов для тестирования. Я сам на данный момент нахожусь в промежуточной ситуации, поэтому тесты пишу, но без лишних подробностей.
13. Шаги и настройки повторяющихся сценариев можно вынести в отдельный документ.
АП - Чувствую, что очень полезная вещь. Но пока в практике у меня не было такого, попробую в текущем проекте.
14. Два и более ожидаемых результата в тесте - нормальная практика. АП- При написании тестов я часто пользуюсь таким приёмом, это сокращает время на создание теста. Но начинающим тестерам, это не всегда понятно, почему тут сразу несколько результатов.
To be concluded
вторник, 25 августа 2009 г.
Тестирование.com Part 1
Вот я и начинаю активничать на своём блоге. Сразу оговорюсь, собственные комментарии я даю с позиции рядового инженера по тестированию, коим пока и являюсь.
Когда я читал книгу, я подчёркивал фломастером интересные и важные мысли. Поэтому я буду просто делиться тезисами из книги Романа Савина в своей интерпретации, прикладывая к этому свои мысли.
Мысли будут начинаться с АП(Антон Пирогов)
1. Источник ожидаемого результата теста - СПЕЦИФИКАЦИЯ. АП - это всё конечно правильно, но у меня в практике столько раз было и сейчас есть, что тестировать уже надо, а спецификация ещё в зародыше или примерно отражает версию продукта в лучшем случае годовой давности. В таком случае разработка спецификации и тестирование идут параллельно, взаимно дополняя друг друга.
2. В запасе на регрессионное тестирование должно быть минимум 3 дня. АП - как я понимаю, желательно просто к основному плану добавлять эти дополнительные дни на случай задержки или осложнений при тестировании( отлавливание редкого бага или что-то другое)
3. Приоритезация тестов и test suits (тестов, сгруппированных по объекту тестирования) - наиважнейшее из задач в условиях дефицита времени, человеческих ресурсов или денег
АП - в моем пока самом большом проекте (2.5 года) мы совсем этим не занимались. При хорошем финансировании из-за океана у нас было много времени, чтобы и все тесты поделать и просто погонять систему под любым углом. Лишь в кризисные времена стали заниматься отсевом тестов для финального регрессионого тестирования.
4. Необходимо примерно знать время выполнения каждого теста и соответсвенно test suit.
АП - думаю тут без комментариев.
5. Негативаное тестирование находит больше багов, чем test to PASS.
АП - Как тестер в большим опытом манульного тестирование не могу не согласится с этим утверждением и даже больше. Это моё любимое занятие - пытатться сломать систему
6. Severity - категория абсолютная, оценка бага с точки зрения функционирования программы.
Priority - категория относительная, важность бага с точки зрения бизнеса.
АП - тут будет ссылка на статью про Severity and Priority ( забыл где прочитал). Основная идея статьи была, что severity ставит инженер, а Priority выставляет менеджер.
7. Перед тем как занести баг в систему трэкинга багов, вопроизведи его!
АП - Ой какой важный принцип, иногда так хочется сразу написать и отрапортавать. Мол,вон какой я молодец, как здорово работаю. Сам иногда натыкаюсь на эти грабли, увы.
to be continued...
Когда я читал книгу, я подчёркивал фломастером интересные и важные мысли. Поэтому я буду просто делиться тезисами из книги Романа Савина в своей интерпретации, прикладывая к этому свои мысли.
Мысли будут начинаться с АП(Антон Пирогов)
1. Источник ожидаемого результата теста - СПЕЦИФИКАЦИЯ. АП - это всё конечно правильно, но у меня в практике столько раз было и сейчас есть, что тестировать уже надо, а спецификация ещё в зародыше или примерно отражает версию продукта в лучшем случае годовой давности. В таком случае разработка спецификации и тестирование идут параллельно, взаимно дополняя друг друга.
2. В запасе на регрессионное тестирование должно быть минимум 3 дня. АП - как я понимаю, желательно просто к основному плану добавлять эти дополнительные дни на случай задержки или осложнений при тестировании( отлавливание редкого бага или что-то другое)
3. Приоритезация тестов и test suits (тестов, сгруппированных по объекту тестирования) - наиважнейшее из задач в условиях дефицита времени, человеческих ресурсов или денег
АП - в моем пока самом большом проекте (2.5 года) мы совсем этим не занимались. При хорошем финансировании из-за океана у нас было много времени, чтобы и все тесты поделать и просто погонять систему под любым углом. Лишь в кризисные времена стали заниматься отсевом тестов для финального регрессионого тестирования.
4. Необходимо примерно знать время выполнения каждого теста и соответсвенно test suit.
АП - думаю тут без комментариев.
5. Негативаное тестирование находит больше багов, чем test to PASS.
АП - Как тестер в большим опытом манульного тестирование не могу не согласится с этим утверждением и даже больше. Это моё любимое занятие - пытатться сломать систему
6. Severity - категория абсолютная, оценка бага с точки зрения функционирования программы.
Priority - категория относительная, важность бага с точки зрения бизнеса.
АП - тут будет ссылка на статью про Severity and Priority ( забыл где прочитал). Основная идея статьи была, что severity ставит инженер, а Priority выставляет менеджер.
7. Перед тем как занести баг в систему трэкинга багов, вопроизведи его!
АП - Ой какой важный принцип, иногда так хочется сразу написать и отрапортавать. Мол,вон какой я молодец, как здорово работаю. Сам иногда натыкаюсь на эти грабли, увы.
to be continued...
понедельник, 24 августа 2009 г.
Стартую!
Всем привет!
Вот в мой 28-й день рождения я наконец созрел для блога. Тк вот уже 4 года я работаю в тестировании, то думаю можно наконец о нём писать.
Опыт практический уже накоплен, но теоретическая база всё же хромает. Поэтому я решил для начала прочитать книги, которые советуются начинающим тестерам и прорезюмеривать и может прокомментировать.
Путём создания блога я хочу простимулировать себя к изучению теории и порадовать читателей небольшими краткими выкладками из трудов классиков тестирования.
В блоге я также буду делиться резензиями и краткими резюме из книг по
самосовершенствованию и ит-менеджменту, тк для хорошего тестирования нужно
всё!
"Начинать всегда трудно..." Гришковец "Как я съел собаку"
Поэтому засим откланиваюсь и готовлю материал для первого поста.
А это был блин, чувствую всё-таки комом :)
Подписаться на:
Сообщения (Atom)