Решил опубликовать здесь свою прошлогоднюю заметку о карандаше.
Переступив год назад уровень мидла, я понял насколько ″с подвохом″ вопрос с тестированием карандаша если вакансия на тестирование обычного ПО. Сейчас у меня есть как минимум два пути "как отвечать" на этот вопрос, раскрывая тему, будучи джуном, вообще бы не пришли на ум. И так, озвучу один из них.
-
Объект. В идеале, надо начать с того, чтобы вам показали карандаш или дали карт-бланш на то, как должен выглядеть тестируемый карандаш. Тестирование абстракного карандаша - самое слабое место отвечающего. Его будет легко уличить, в неполноте охвата, не то, что не всё предусмотрено и кучу ещё всего. Тестировщик ДОЛЖЕН знать продукт, который тестирует.
-
Требования. Без контекста мы можем проводить только исследовательское тестирование. В остальных случаях у нас должно быть место, где требования регистрируются - это спецификации, тасктрекеры/багтрекеры, концепты разработок, техдокументация и сами тесты, написанные предшественником. У карандаша есть компоненты, которые не должны быть токсичными (клей между графитом и деревянным корпусом, если это классический деревянный карандаш.). Требования удобно формулировать в одной из двух форм: — тезис, утверждение — сценарии проверки (заделки на UC)
-
Тестирование. А вот тут вы можете развернуться в покрытии тестов на столько, на сколько хватит образования, воображения и дотошности.
-
Результаты. Всё, что имеет начало, имеет и конец. Тестирование должно завершаться подведением итогов в оговоренной с начальством форме. Если формы отсчёта как таковой нет, то можно предложить свою. Я бы предложил следующую структуру: — Условия в которых проводилась проверка. Я иногда публикую информацию об этом делаю перед непосредственным началом тестирования. — Фиксация нового. Описание особенностей продукта. Как правило, особенности нововведения, которые реализованы по факту, т.е. "как теперь работает". Клиент хочет одно, заказчик - рассказал нам другое, у разработчика получилось третье. Кто-то должен зафиксировать, что же получилось по факту. Здесь фокус: "как по факту". — Общий подробный отчёт о проведённой работе и резолюция по проверке каждого сценария и тезиса требований. Здесь фокус: "соответствие требованиям". — Общее резюме. Приветствуется личная оценка специалиста по результатам проверки. Оно должно быть кратким, лаконичный и выражено в нейтрально-профессиональном ключе.
Резюме: Тестирование карандаша, это лучший путь отличить джуна от миддла. Для начинающего тестировщика, который не имеет реального опыта тестирования другого ответа, кроме как перечня типов тестирования — вы не услышите. Хотя многие миддлы тоже могут ограничиться подходами к проверке качества. Но вы вдумайтесь! Задача не про то, какие вы будете применять методики и подходы к тестированию. Задача стоит как это сделать в целом! Когда опытному тестировщику вверяют новый проект, он лезет за документацией и требованиями, а не за списком с видами тестов.
———————— заказчик — тот кто формирует ТЗ от лица клиента непосредственно команде разработки.
