Мыслетрекер

Джеймс Бах и Майкл Болтон периодически пишут и рассказывают о такой штуе, как Test Framing (а вот здесь есть перевод оригинальной статьи). В рамках этой модели они предлагают всегда держать в голове множество ключевых факторов, влияющих на тестирование (среда, продукт, цели, риски и т.д.). В описанном Майклом Болтоном формате мне такой подход показался очень правильным, но при этом слишком сложным. Методом проб и ошибок я выработала более простую схему для фрейминга тестирования, которая не путает своей сложностью, и при этом добавляет осознанности в тестирование. Read more

Жили-были в 2 параллельных вселенных 2 тестировщика: Нина и Гриша. Тестировали они одинаковое ПО в одинаковых командах, и был это калькулятор.

Гриша был раздолбаем редкостным. Кнопки потыкает, что заметит заведёт, и продолжает смотреть fishki.net

А Нина была девушкой гиперответственной. Ходила на курсы, скупала весь ассортимент книг по тестированию на amazon’e, читала статьи, внедряла новое на практике. Старалась ничего не пропустить: везде анализировала классы и границы, выявляла зависимые параметры, комбинировала проверки, готовила себе таблички с тест-анализом, помечала результаты проверок, оценивала покрытие кода, — в общем, делала всё, лишь бы не пропустить ошибки.

Тестировали они тестировали, и вот, наступил день финального тестирования предрелизной сборки. У Нины заранее был подготовлен тестовый набор для проверок: все возможные типы чисел, из различных классов эквивалентности (положительные и отрицательные, целые и дробные, состоящие из разных цифр и разного количества знаков, большие и маленькие). И она стала проверять все эти значения на всех операциях. Результат: всё работает! Довольная, показала это руководству, и продукт ушёл в релиз.

Гриша не знал, как правильно тестировать, да и не очень хотел в это вникать. Потыкал все кнопки — вроде работают. Сложил 2 числа — вроде работает. Умножил 15 на 42 — и получил огромный страшный краш системы. Завёл багу: оказалось, при умножении любого числа на 42 (и только на 42) продукт падает — вот такое пасхальное яичко было от уволенного разработчика. Багу поправили и выпустили продукт.

Чем всё закончилось? Тем, что во вселенной Нины краш нашли пользователи, а во вселенной Гриши критикалов пропущено не было.

Какие выводы?

Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно. Read more