Перейти к содержимому

Английский для тестировщиков
онлайн, начало 21 июня
Погружение в тестирование. Jedi point
онлайн, начало 21 июня
Тестирование REST API
онлайн, начало 21 июня
Программирование на C# для тестировщиков
онлайн, начало 25 июня

svyatoslav

Регистрация: 26 авг 2011
Offline Активность: 10 дек 2015 14:46
-----

Мои сообщения

В теме: Тестирование программного обеспечения. Базовый курс

10 декабря 2015 - 14:46

Артём,
 

Есть некоторые вопросы:
1.  В рекомендациях по написанию тест кейсов категорически запрещается ссылаться на другие тест-кейсы (их части).
Как вы тогда на практике решаете следующую ситуацию:
 a) Есть несколько довольно объемных блоков данных  (адрес, место работы и т.д.) и эти блоки в разных вариациях встречаются у большого числа пользователей на большом числе шагов, при этом они могут незначительно отличаться по содержимому
 б) При этом требования к блокам дополняются/изменяются в течение спринта.


Пусть и не совсем такая конкретная ситуация, но предпосылки к подобному и пути решения даже описаны в книге (см. "Подробная классификация наборов тест-кейсов", начиная со 139-й страницы). Это можно сделать через т.н. "обобщённый свободный набор", указав для всех тестов в наборе некий эталонный/базовый перечень входных параметров, а уже в каждом тесте разместить "патч" этого набора, приводящий к нужному итоговому результату.
Что до пункта "б" вашего вопроса, то это вечный вопрос и вечная боль. Но тоже решаемо, если знать количественные и качественные изменения -- от подготовки избыточных наборов входных данных (покрывающих все варианты), до элементов исследовательского тестирования в рамках сценариев (как завещал Виттакер).
 

Как я рекомендую поступать:
В одном тесте полностью расписать проверку блока (значения всех полей, редактируемость, обязательность, форматы и т.д.) а в остальных просто ссылаться на этот тест для проверки данного блока, при этом указывая отличия при необходимости.
Этим мы существенно экономим время на обновление всех X тестов при изменении требований к блоку.


А зачем нам в остальных тестах проверка этого блока, если мы его уже проверили одним тестом?
Тут ведь одно из трёх:
а) Если нам надо В ТОЧНОСТИ выполнить некие действия для нескольких тестов -- делаем набор, выносим эти действия в его пригтовления.
б) Если нам надо "примерно" выполнить некие действия (не важно, как именно, но в стиле "указать верные ФИО") -- снова делаем набор, выносим это в общие приготовления и подчёркиваем, что тут нужна вариативность.
в) Если нам надо выполнить некие специфичные для каждого теста действия, от которых зависят дальнейшее развитие теста и его результат -- тут я бы не ленился и писал в каждом тесте заново (да, даже богомерзким копи-пейстом и правками). Если подавляющий набор шагов/данных одинаков, а дьявол кроется в деталях -- см. выше про единые набор + "патчи".

В любом случае я выступаю против ссылок на то, что мы не контролируем (можем забыть перепроверить). Приготовления и единые данные для явно обозначенного набора -- это совсем не то же самое, что чей-то тест, на который мы ссылаемся, наивно полагая, что его не поменяют (незаметно для нас).
 

2. В блоке 'Исходные данные' (стр. 122) вы настоятельно не рекомендуете описывать действия по подготовке, которые выполняются в  самом тестируемом приложении.
a) Пример 1: Как тогда вы будете проверять таблицу на отображение только 10 первых строк (если её наполнение происходит средствами приложения): первые шаги теста будут заключаться в наполнении таблицы данными, а не в непосредственном тестировании требования ?


Персонально я вообще бы напрямую через СУБД накидал в БД то, что мне нужно :). Особенно, если строк не 10, а 10 миллионов.
Но если это невозможно или нежелательно, то:
а) Набор из последовательных тестов.
б) Формулировка приготовления в виде предусловия: "В БД в таблице такой-то должно быть столько-то строк". Тесту ставить "невозможно выполнить", если добавить строки не удалось. Но сам тест, если он направлен на отображение, фейлить из-за невозможности вставки... как-то... не по фен-шую.
в) Если цель теста -- "запихнуть N >> 10 и убедиться, что отображается только 10", да, в шагах теста указал бы добавление. Если бы не добавлялось, зафейлил бы тест с чистой совестью.
 

б) Пример 2: Есть некоторый длинный бизнес процесс и у нас в конце есть форма, которую нам надо проверить. И есть сквозной смоук тест, проходящий по данному процессу.


Смоук-тест в виде последовательного сценария или нескольких независимых друг от друга последовательных сценариев.
 

Как я рекомендую поступать: в Preconditons делать ссылку на Smoke (т.к. не факт что каждый из тестировщиков, а тем более новичков понимает как дойти до нужного шага) и указывать шаг процесса, который нам нужен для проверки.


И вот однажды тёмной-тёмной ночью кто-то что-то меняет/добавляет/удаляет в "объекте, на который мы сослались" так, что у него всё логично и работает, а у нас получается бред. Что делать тогда?

P.S. Ещё раз суть: если у нас есть гарантия, что без ведома и позволения "ссылающейся части" никто не поменяет ничего в "части, на которую ссылаются" -- в путь и с песней. Но если такой гарантии нет, я бы предпочёл не создавать хитросплетение из перекрёстных ссылок. Т.е. запретить ссылки вообще. Ниче они начинают плодиться как кролики, и через какое-то время получаем "спагетти-тесты", если можно так сказать по аналогии со спагетти-кодом.

В теме: Тестирование программного обеспечения. Базовый курс

14 сентября 2015 - 08:35

А мне понравилось.
Да, согласен, что книга в многом — «расширенный силлабус ISTQB». Но если к ней прилагается тренер и практические задания, то книга — отличный способ запомнить/упорядочить/уточнить/углубить и т.д., эдакий «конспект лекций».


Андрей, спасибо за тёплый отзыв. Во многом для того эта книга и задумывалась.

В теме: Тестирование программного обеспечения. Базовый курс

14 сентября 2015 - 07:58

В каком-то смысле, это задачи спецназа, если будет допустимо такое сравнение, а спецназ — это не массовка. Поэтому за год "привести к присяге" 200 человек — нет, "это не наш метод" :)
Поэтому и подготовка другая, всегда личностная.
[skip]
Итого - пять месяцев обучения для людей, которые приходят в тестирование "с нуля", в условиях, максимально приближенных к боевым.


Интересно то, что у нас очень похожая схема.
1) Отбор на т.н. "внешний тренинг" (на группу в 30 человек приходит от 300 до 800 заявок). Тут проходит отбор с рекрутёрами и техническими специалистами. Тренинг длится около 1.5 месяцев.
2) После внешнего тренинга проходит повторный отбор (в среднем, отбирается 20 человек из 30) с участием технических специалистов и тест-менеджеров. Эти отобранные попадают в т.н. "тест-лабораторию", где 2-4 месяца сидят full-time и обучаются на специально разработанных учебных проектах. С ними работают "специально обученные люди" :), которые в т.ч. могут обеспечить достаточно индивидуальный подход.
3) По мере того, как менеджер лаборатории считает тех или иных ребят "готовыми к бою", их показывают менеджерам с продакшн, проходит ещё одно собеседование. Прошедшие это собеседование попадают в продакшн в должности джуниора, где их показывают заказчику, постепенно включают в настоящий рабочий проект и доучивают (в т.ч. через индивидуальных менторов).

Этот подход вполне позволяет привести за год в компанию пару-тройку сотен человек, реально готовых работать (т.е. успешно проходящих собеседование с заказчиками). Проверено годами, результативность крайне высокая.

В теме: Тестирование программного обеспечения. Базовый курс

14 сентября 2015 - 07:21

Святослав, а есть книга в формате fb2? Хотелось бы с телефона почитать, а в pdf не очень удобно :)

 

Ольга, увы, в fb2 нет. В книге есть некоторое количество картинок и таблиц, которые ну никак не "ужимаются" без потери здравого смысла. Потому даже в бумажной версии оставлен формат А4.


В теме: Тестирование программного обеспечения. Базовый курс

11 сентября 2015 - 08:19

Вывод был основан на том, что для самостоятельного изучения книга будет очень сложной для начинающих. Для небольших групп новичков полезнее будет "пощупать" сначала.


Антон, с этим утверждением скорее склонен согласиться. Хотя меня не покидает ощущение, что под "начинающий тестировщик" кто-то может понимать "человек, только-только услышавший о тестировании", а кто-то -- "нуу... это всего 1-2 года опыта" :).

P.S. Ваше мнение услышал, воспринял и учёл. Спасибо!


Яндекс.Метрика
Реклама на портале