Сознательное проектирование: эквивалентность vs границы

Я не отрицаю спонтанность и озарение в тестировании. Вдохновение и интуицию.

Однако, считаю что полагаться только на них при создании тестов неразумно.

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

При этом я:
- не всегда понимала что именно проверяю данным тестом
- часто выполняла несколько (или даже много) однотипных тестов

Ну, вы знаете, когда случайным образом комбинируешь разные входные параметры, играешь с настройками, в точности даже не планируя свои действия. А вдруг что сломается?

Самое важное делаем в первую очередь

 В тестировании, как и везде, самое важное надо делать в первую очередь. Сначала важные фичи, потом все остальные. Сначала важные тесты, потом остальные.


Во front-office проектах времени на итерацию иногда бывает очень мало, либо оно внезапно (смена приоритетов, неожиданные другие задачи, проблемы с окружением и пр.) сокращается.

Поэтому целесообразно обращать внимание не только на содержание тестов, но и на порядок их написания. А после написания - на порядок их выполнения.

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

Тестирование в Украине

Дорогие друзья и коллеги,

Я хотела вернуться к работе в этом блоге, начав с поста о метриках в тестировании, рассказать, что такое Testersity, о видеоконференции с Майклом Болтоном, о том, что произошло в моей тестерской жизни за последние полтора года.

Но вынуждена писать о другом.

ChiefConfeT&QA - как это было

   Вчера завершилась онлайн конференция ChiefConfeT&QA 2012. Отгремели последние доклады, затих Твиттер и к вечеру на форуме все ушли спать. И только чат в Скайпе глубокой ночью передавал пульс жизни отрывочными сообщениями...
 
Как это было?

Это было обалденно! Ребята, я многого ждала от этой конференции, но результаты превзошли мои самые смелые ожидания. Практически каждый доклад рассказывал о чем-то, что для меня сейчас актуально или может пригодится в обозримом будущем. Некоторые били прямо в проблему, вокруг которой я хожу последние две-три недели. Судите сами:

Идея для парного тестирования

      Уже некоторое время ношусь с идеей для парного тестирования, но пока нет возможности опробовать ее на практике. Делюсь - может кому пригодится.
      Сразу уточним: под парным тестированием в данном случае имеется в виду не то тестирование, когда двое сидят за одним компьютером и один тестирует, а другой смотрит.
Тогда о чем это мы? А вот о чем:

Заметки об управлении дефектами

      Это набор отрывочных наколенных заметок об управлении дефектами. За куцыми скупыми строками, которые вы видите перед собой, скрываются целые пласты истории разных проектов и пестрые клубки обстоятельств, приведших к появлению каждой из этих заметок.

     Как следствие, все нижеперечисленные рецепты не универсальны и сфомированы на основе нашего с коллегами глубоко субъективного опыта. И специфики наших команд и проектов. Поэтому, прежде чем их внедрять у себя, подумайте. Но если уж надумаете, то в комментариях можно написать, что из этого вышло.

     Некоторые вещи общеизвестны, но я все равно их перечислю, чтобы не упустить ничего важного.

     Итак, список полезностей в управлении дефектами:

Зачем нужны тестировщики? Презентация

- А как вы развлекаетесь?

- Графики рисуем.

(один известный фильм)

      Как развлекается на досуге настоящий тестировщик? А вот, например, создает замечательные презентации, посвященные вопросам тестирования! Автор проекта: Анна Дорофиевская - в тестировании уже около 5 лет, профессионал и просто замечательный человек! Вдохновенно сочетает строгое техническое мышление с художественным взглядом на вещи. Презентация предназначена для просвещения программистов, менеджеров, заказчиков и вообще всех, кто не понимает, кто такие тестировщики и зачем они нужны. Презентация со звуком, качаем и наслаждаемся :)