С мудростью предков тоже все неоднородно - есть вещи, уже используемые всеми и всегда (как анализ эквивалентных классов и граничных значений), есть просто опыт каких-то других тестировщиков - как чек-листы и чит-листы.
Анализ эквивалентных классов строится на том, что мы ищем то, что не похоже на все остальное. Мы не можем проверить все значения, поэтому считаем, что на любое значение из выбранного набора система реагирует одинаково. Главное найти эти наборы) Если не учтем что-то - то можем пропустить проблему.
Анализ граничных значений исходит из того, что люди часто ошибаются на границе. Было бы хорошо, если бы нам в требованиях сразу писали а-ля а>=b. Так нет, обычно там бывает "не превышая", " не менее" и прочие конструкции естественного языка. Поэтому мы берем границу и проверяем это значение, значение до и после.
Идея pairwaise строится на том, что у нас есть куча параметров и мы не можем проверить их все. Зато можем так построить проверки так, чтобы проверялись все пары значений. Говорят, что это дает до 98% процентов эффективности, хотя свои нюансы здесь есть тоже есть. Техника строится на математических моделях, но обычно достаточно просто описать модель и сгенерить набор в специальной программе. Я рекомендую PICT, потому что там можно в модели задать условия. Потому, что в реальных системах далеко не все сочетания параметров могут существовать на самом деле.
Идея туров Виттакера в том, что система - это незнакомый город, а тестировщик - это турист с каким-то определенным планом. Например, идти строго по путеводителю (по справочным материалам сайта) или найти все денежные функции своего продукта и проверить их. Мне кажется, что это дает новый взгляд на свой продукт.
А еще есть куча разнообразных эвристик - про то, что у кого-то получилось и было полезным, а мы можем вдохновиться и попробовать у себя. Например, моя любимая про регрессию - http://software-testing.ru/library/testing/general-testing/992-2010-04-20-20-05-53. Вроде бы все очевидно, но все равно полезно.
#база_тестирования
Анализ эквивалентных классов строится на том, что мы ищем то, что не похоже на все остальное. Мы не можем проверить все значения, поэтому считаем, что на любое значение из выбранного набора система реагирует одинаково. Главное найти эти наборы) Если не учтем что-то - то можем пропустить проблему.
Анализ граничных значений исходит из того, что люди часто ошибаются на границе. Было бы хорошо, если бы нам в требованиях сразу писали а-ля а>=b. Так нет, обычно там бывает "не превышая", " не менее" и прочие конструкции естественного языка. Поэтому мы берем границу и проверяем это значение, значение до и после.
Идея pairwaise строится на том, что у нас есть куча параметров и мы не можем проверить их все. Зато можем так построить проверки так, чтобы проверялись все пары значений. Говорят, что это дает до 98% процентов эффективности, хотя свои нюансы здесь есть тоже есть. Техника строится на математических моделях, но обычно достаточно просто описать модель и сгенерить набор в специальной программе. Я рекомендую PICT, потому что там можно в модели задать условия. Потому, что в реальных системах далеко не все сочетания параметров могут существовать на самом деле.
Идея туров Виттакера в том, что система - это незнакомый город, а тестировщик - это турист с каким-то определенным планом. Например, идти строго по путеводителю (по справочным материалам сайта) или найти все денежные функции своего продукта и проверить их. Мне кажется, что это дает новый взгляд на свой продукт.
А еще есть куча разнообразных эвристик - про то, что у кого-то получилось и было полезным, а мы можем вдохновиться и попробовать у себя. Например, моя любимая про регрессию - http://software-testing.ru/library/testing/general-testing/992-2010-04-20-20-05-53. Вроде бы все очевидно, но все равно полезно.
#база_тестирования