@alexkrupin
Database Developer

Что делать, когда тестировщиков не устраивает документация, написанная разработчиками?

Я работаю в молодой компании, и мы столкнулись с проблемой.
Разработчики на фичи пишут техническую документацию (требования), которой впоследствии пользуются тестировщики во время процесса тестирования.
Со стороны тимлида тестировщиков есть претензия - требования на фичи "непонятные", "неадекватные", "некоррекные" и все в таком духе. Сформулировать требования к требованиям не может, но может показать, как они должны по его мнению выглядеть. Пример на функцию в базе данных ниже.
Вот то, что написал разработчик:
Для каждого элемента массива Z (массив массивов) выполнить следующее:
- Если у элемента подмассив плейсментов пустой, а подмассив лендингов не пустой:
-- удалить строки из таблицы X по данным лендингам
- Если у элемента подмассив лендингов пустой, а подмассив плейсментов не пустой:
-- удалить строки из таблицы X по данным плейсментам
- Если у элемента подмассивы лендингов и плейсментов не пусты:
-- удалить строки из таблицы X по данным лендингам и плейсментам

Вот как написал тимлид тестировщиков (каким он хотел это видеть):
Каждый элемент массива Z (массив массивов) рассматривается отдельно, и не зависит от другого элемента
В дальнейшем будем использовать название element.Z для указания на элемент массива Z
- Удаляются все строки из таблицы X, в которых лендинги соответствуют лендингам element.Z
-- Условие: В element.Z не указано плейсментов
- Удаляются все строки из таблицы X, в которых плейсменты соответствуют плейсментам element.Z
-- Условие: В element.Z не указано лендингов
- Удаляются все строки из таблицы X, в которых лендинг и плейсмент равен лендингу и плейсменту полученному сочетанием лендингов с плейсментами из element.Z
-- Условие: В element.Z указан хотя бы один лендинг и хотя бы один плейсмент

Это пример на простую функцию.
Итак, разработчик пишет свое видение, тимлид тестировщиков - свое. Тимлид тестировщиков не может сформировать требования к требованиям (т.е. по сути, написанные разработчиком требования не могут быть проверены на "понятность" и "адекватность").

Вопросы:
  1. Справедливы ли замечания тимлида тестировщиков?
  2. Сталкивались ли вы с такой проблемой, и как она решается в вашей компании (тех. писатель)?
  • Вопрос задан
  • 906 просмотров
Пригласить эксперта
Ответы на вопрос 3
@iv_k
Требования должен писать аналитик. Или кто-то, понимающий в написании требований.
Тестировщики должны писать тест-план на эти требования, состоящий из тест-кейсов с полным покрытием каждого требования.
А у вас не требования, а какое-то описание функционала от разработчиков и описание тестирования от тестеров.
Советую прочесть стандарты ieee software requirements
зы.
Да, совсем забыл. перед требованиями надо описать юз кейсы. и из них получить тест-кейсы.
заставьте кого-нибудь изучить документацию по управлению требованиями, чтоб получить нормальный процесс проектирования-тестирования.
Ответ написан
Sanes
@Sanes
  1. Выяснить, по какой причине невозможно вести нормальный документооборот.
  2. Заменить ответственного
  3. Подзрезать зар. плату и заставить переделать. Чем раньше, тем лучше.

Для особо одаренных, прошу писать видео. Немое кино исключенно!
Ответ написан
lxsmkv
@lxsmkv
Test automation engineer
тестирование такой внутренней логики больше подходит для автоматизированного тестирования.
В ручную тестировать базу данных это круто, но сильно трудозатратно. Напишите простую обертку к базе на питоне например, и разработчикам не нужно будет писать иснтрукции, а можно будет писать сразу код. А ручное тестирование должно тестировать действия пользователя и результат работы пользователя. Пользователь не работает с базой напрямую. Если у приложение еще нет морды то, для ручного тестирования думаю еще рано.
Или я что-то не доконца понял..
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы