Тестирование.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...