суббота, 23 марта 2013 г.

Чек-лист сохранения файла (негативные тесты)

Хочу процитировать один из советов в книжке "Lessons Learned in Software Testing" (Cem Kaner, James Bach, Bret Pettichord). Сама книга - это набор из 293 небольших (по большей части) советов, которые даются тестировщику, автоматизатору, менеджеру итд, каждому в своем разделе.

Один из советов содержит в себе чек-лист сохранения файла (негативные сценарии), вольный перевод которого я привожу ниже.


  • Сохранить на заполненный (нет больше свободного места) локальный диск.
  • Сохранить на почти заполненный локальный диск.
  • Сохранить на диск, защищенный от записи.
  • Сохранить на заполненный диск в локальной сети.
  • Сохранить на почти заполненный диск в локальной сети.
  • Сохранить на диск в локальной сети, защищенный от записи.
  • Сохранить на заполненный диск в удаленной сети (VPN, например).
  • Сохранить на почти заполненный диск в удаленной сети.
  • Сохранить на диск в удаленной сети, защищенный от записи.
  • Сохранить в файл, директорию или на диск, к которому у тебя нет прав доступа на запись.
  • Сохранить на поврежденный (I/O error) локальный диск, диск в локальной сети, или "удаленный" диск (диск на другом компьютере).
  • Сохранить на неотформаттированный локальный диск, диск в локальной сети, или "удаленный" диск.
  • Удалить диск после открытия файла (отсоединить его, закрыть удаленное соединение).
  • Восстановление после timeout-та локального / "удаленного" диска.
  • Генерация других отказов во время сохранения на локальный диск, диск в локальной сети, или "удаленный".
  • Выключение локального компьютера во время сохранения на локальный диск, диск в локальной сети, или "удаленный".
  • Выключение соединения с диском , отсоединение диска время сохранения на локальный диск, диск в локальной сети, или "удаленный".
Для составления подобных чек-листов необходимы две сессии мозгового штурма с коллегами.

Во время первой сессии вы задаете тему и накидываете различные варианты тестирования, как позитивного, так и негативного. Пока ничего не отсеивая, выписываете все-все-все варианты. Потом расходитесь и денек отдыхаете.

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

Теперь у нас есть отсортированный список идей. И тогда начинается второй митинг - коллеги снова собираются и генерируют новые идеи, но по темам. Сначала пополняют одну тему, потом вторую, потом третью итд. Нет ничего необычного в том, что после второго митинга каждая из тем пополнится вдвое! Именно потому то он и нужен, новый штурм на структурированной базе...
----------------------------------------------------------------------------

Мне кажется, отлично написано. Интересный чек-лист, к тому же применимый во многих организациях - так или иначе многие из нас в своих программах пытаются что-то куда-то сохранить. Так или иначе составляются чек-лист проверок - заполнение входного поля, числового, для email, символьного итд.

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

Просто помните - одна голова хорошо, а две - лучше! Smile :)

2 комментария:

  1. Вспомнился сервис http://itsfeature.com для хранения базы тест паттернов. Сергей Алпаев делал презентацию сервиса на UATD, там есть видео и слайды http://uatestingdays.com/#fun

    ОтветитьУдалить