Pull to refresh

Comments 10

Во всех этих схемах я ощущаю некоторую однобокость - всегда сквозит конкретный стек и конкретная предметная область пищущего.

Например, пропущены регрессионные тесты, тесты апгрейдов и даунгрейдов, вообще не упомянуто существование разных конфигураций и сборок (это не то же самое, что конфигурационное тестирование) и архитектур.

> конкретный стек и конкретная предметная область
Просто тема-то на самом деле необъятная. Скажем, то что тут в одном абзаце называется «статическое тестирование» — это же вполне тема для книжки, если вдуматься.

Вот я бы начал бы с классификации того, что мы тестируем. Потому что скажем те же разные конфигурации и сборки могут вообще не иметь значения, или не существовать вообще для определенного типа софта. Ну так, в качестве примера — софт для телефона под Андроид, коих наверное десятки тысяч моделей, очень разных, на разных версиях ОС, установленный в миллионах и миллиардах копий. Или софт для биллинга, или там ERP, которые покупается единицами штук, устанавливается в внедряется долго, допиливается под себя каждым покупателем, или вообще софт собственной разработки внутри компании, имеющий место в одном экземпляре. Все это будет тестироваться по-разному, вообще говоря.

Мне кажется, что нужно начинать не с максимальной абстракции, а, наоборот, с простейшего описания.

Шаг первый: как проверить, что оно работает? Попробовать, работает ли.

Шаг второй: а что работает-то? Ну, давайте перечислим. (Привет, тестплан).

Шаг третий: а чо, каждый раз проверять? Да.

Шаг четвёртый: у меня всё работает, а они говорят, что нет. Мне что, во всех браузерах проверять? Да.

Шаг пятый: задолбало всё время одно и то же. Может, оно само будет кликать "зарегистрироваться" каждый раз? Да, может.

И т.д.

В большинстве случаев тестированием затыкают известные классы проблем; никто не приносит тестирование во имя тестирования.

Так тоже можно. Но я скорее о том, что «Мне что, во всех браузерах проверять?» для некоторых классов софта не будет иметь смысла, или будет иметь чуть другой смысл. Потому что проверить софт на всех моделях телефонов с андроидом, очевидно просто невозможно физически, и надо придумать что-то другое.
Да, впринципе всю эту «теорию» можно вывести из практических проблем и задач. Просто другая дидактика.

Ок, спс, про регрессию добавлено.

Базовые определения просто вырви глаз (

Количество основных терминов минимализировано (их теперь 11), определения упрощены насколько это можно

90% этого не потребуется ни на одном проекте, как и не будет спрашиваться на собеседованиях

Даже для сертификации ISTQB большая часть не нужна из перечисленного

Такие статьи наоборот могут отпугнуть от прекрасной профессии тестирования и заставить зубрить теорию просто так

Убрано примерно 30% информации, спасибо

Sign up to leave a comment.

Articles