вторник, 23 августа 2011 г.

Про тест-дизайн и про все остальное...

Когда-то я была еще начинающим тестировщиком, занималась только мануальным тестированием и написание документации меня напрягало: зачем она нужна, если можно спросить у программиста, потом проверить и завести багу? Тест-кейсы еще писать какие-то, чек-листы...
Потом я стала более опытным тестировщиком, начала посещать тренинги... И, конечно, я выбирала "правильные" тренинги: как нагрузить систему, как тестировать безопасность, как автоматизировать... Зачем мне, например, какой-то там непонятный тест-дизайн или стандарты в тестировании?..
А потом я стала еще более опытным тестировщиком и стала задумываться: почему вот я такой уже "более опытный тестировщик", а мой тим-лид сходу в уже проверенном мной функционале находит ошибки?Я старалась запомнить какие именно данные он вводит, но на других частях функционала они работали, а вот именно тут - все валили. А почему?
Нет, я не буду писать историй в стиле "а потом я увидела тренинг "Практикум по тест-дизайну" и это стало панацеей от всех бед". Расскажу пару историй из практики.

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

В теме о том, какие темы было бы интересно услышать на юбилейной SQA Days'10 сходу появилось такое вот мнение:

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

Сейчас я руковожу командой тестировщиков, которые хотят стать автоматизаторами. Для них нет проблем в том, чтобы разобраться в каком-то инструменте или настроить какое-то окружение, они запросто обсуждают инструменты автоматизации. Даже самые неопытные в течение нескольких часов разобрались с git, корректно его установили и подняли проект на локальной машине. Но когда речь заходит о написании тест-кейсов или хотя бы чек листов... А если еще попросить в чек-листах сделать список параметров, которыми будут пользоваться при дальнейшем тестировании...

Почти в каждой вакансии на должность тестировщика выше junior уровня требуется умение писать тестовую документацию. Об этом умении лично меня спрашивали на собеседовании в числе первых вопросов. Я сама спрашивала об этом на собеседованиях у соискателей.

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

Один мой очень хороший друг-программист написал как-то (в ответ на другой вопрос, но все же):
при всем сходстве мышления тестера и кодера, ценность тестера в его особенностях мышления. программер просто не способен найти большинство ошибок в своей программе потому, что ему не придет в голову использовать ее не так, как он задумал - вводить странные данные, фапать по интерфейсу (пунктуация и орфография автора сохранены).
 Собственно, то, что программисты называют "особенностями мышления", есть ни что иное, как страсть к исследованиям + навыки тест-дизайна.
 Господа присяжные, у меня все! ))

10 комментариев:

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

    ОтветитьУдалить
  2. Да, это у меня сыграла эмоциональная составляющая ))) Сначала надо было про построение тестов, а потом - про документацию. А я сразу выплеснула все мысли про документацию (накипело!!), а потом уже - про построение тестов ))

    ОтветитьУдалить
  3. Вот да. У нас в команде тоже все пытаются рваться в автоматизацию, а надо бы еще и понимать, что мы автоматизируем.

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

    ОтветитьУдалить
  5. Lena, вера в серебряную пулю неистребима)

    ОтветитьУдалить
  6. Чо, орфография и пунктуация вполне соответствуют стандартам. Вроде бы =)

    А насчет дизайна то да. Даешь бывало юному падавану калькулятор с тремя кнопками - "2", "+", "=".
    Говоришь:
    - Протестируй.
    Он его грызет, окунает в воду, прыгает на нем, норовит в микроволновку сунуть или перепрошить.

    Отбираешь истерзанный ресурс и интересуешься:
    - А сложить 2 и 2 он может или нет?

    Ну ясно, ага?

    ОтветитьУдалить
  7. Волонтер, а бывает и наоборот: 2+2 сложил и счастлив безмерно... так как считает, что все протестировал...

    ОтветитьУдалить
  8. "Отбираешь истерзанный ресурс и интересуешься:
    - А сложить 2 и 2 он может или нет?"

    "а бывает и наоборот: 2+2 сложил и счастлив безмерно... так как считает, что все протестировал..."

    ну эти два примера прекрасно иллюстрируют только одно: недостаток знаний, вследствие чего или хаотичное тестирование без учета рисков, без какой-то логики в построении тестов; или простой манки-тестинг, где "шаг влево, шаг вправо приравнивается к побегу"...
    Пичалька...

    ОтветитьУдалить
  9. Да тут вопрос не только в дизайне тест кейсов, а еще и в приоритезации их запуска...

    Кейсов можно написать тысячи по всем правилам дизайна, но вот в какой очередности их запускать не все понимают.

    ОтветитьУдалить
  10. По-хорошему, дизайн - это именно искусство сгенерировать максимально полезные тесты при их минимальном количестве, а не бездумное их клепание по каким угодно правилам.

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