Tester's Weekdays

На долю каждого из нас выпадает "удача" выполнять работу в условиях частичной или полной неопределенности. Рано или поздно приходится сталкиваться с проектами, в которых формализованные требования отсутствуют от слова "совсем". Причины могут быть разными: некогда думать и писать, в команде нет аналитиков, в команде есть аналитик и совершенно случайным образом это невеста руководителя проекта, совсем недавно получившая повышение (но это, конечно, выдумка, в жизни так не бывает :). Все эти причины объединяет одно - какими бы глупыми и несправедливыми они ни были, приложение придется поставлять заказчику, придется его тестировать и разрабатывать тесты. И вот тест дизайнер берется за задачу, вот чистый лист и... наступает ступор.

В моей практике приходилось сталкиваться с различными вариантами формализации требований к XML документам, от технически грамотных XSD-схем до экзотических примеров псевдокода. Чаще всего встречаются следующие формы: XSD-схема; Спецификация в виде текстового документа; Примеры XML документов. У каждого из этих представлений есть плюсы и минусы. Они накладывают свой отпечаток на процесс подготовки к тестированию, а так же на сроки выполнения работ. О специфических аспектах работы с различными представлениями требований к XML и пойдет речь в этой статье.

Проверяя описания дефектов, я часто сталкиваюсь с распространенной ошибкой - в конце заголовка (summary) дефекта указана точка. Ради интереса я посчитала сколько сотрудников из моего рабочего окружения имеют такую привычку, в итоге набралось около 40%.  И вот, наконец, холодным и дождливым воскресным днем у меня появилась возможность разобрать данную проблему. Точки в заголовках ставить не нужно и вот почему...

По "счастливому" стечению обстоятельств в основном я занимаюсь тестированием молодых проектов. Назвать этот процесс "выполнением работы" не поворачивается язык, скорее это похоже на постоянную борьбу за выживание в условиях нехватки ресурсов (как времени, так и сотрудников), отсутствия документации, отсутствия процессов, постоянного неожиданного расширения контента поставки срочными задачами и т.д. В таких "спартанских" условиях умелое использование методологий разработки тестов выходит на передний план, т.к. необходимо сократить до минимума затраты на создание и поддержку тестовых сценариев. При этом важно поддерживать приемлемое качество последних, чтобы они не оседали мертвым грузом потраченного впустую времени, а приносили реальную пользу команде тестирования. В этой статье я расскажу о своем опыте применения методологии "Таблицы принятия решений" (Decision Table, далее я буду использовать сокращение DT). Вся необходимая теория изло...

Основы Итак, несколько общих слов о XML.  XML является языком разметки, по сути это означает то, что код написанный на XML не выполняет каких-либо действий (вычислений) и служит только для структурированного представления информации.  Синтаксис XML соответствует используемому в HTML. Основной конструкцией языка является тег, который в свою очередь может обладать множеством атрибутов. Теги и элементы (node) В сети и литературе можно найти большое количество различных трактовок определения тега (более грамотно - дескриптора). Для работы с языками разметки важнее понимать сущность данной абстракции (физический смысл, как любит говорить мой отец), а не знать дословно его определение.

В последнее время, по долгу службы, мне довелось обучать и встраивать в проекты довольно большое количество начинающих тестировщиков. Ситуация на рынке труда складывается не самым лучшим образом и найти сложившегося специалиста, обладающего всем набором необходимых технических навыков не представляется возможным. Поэтому довольно часто приходится сталкиваться с такой проблемой как недостаточное знание сотрудником языка XML. С одной стороны проблема сама по себе не является серьезной, т.к. изучить этот язык и основы работы с ним довольно просто. С другой есть ряд моментов, которые усложняют жизнь молодому поколению: