Когда-то я была еще начинающим тестировщиком, занималась только мануальным тестированием и написание документации меня напрягало: зачем она нужна, если можно спросить у программиста, потом проверить и завести багу? Тест-кейсы еще писать какие-то, чек-листы...
Потом я стала более опытным тестировщиком, начала посещать тренинги... И, конечно, я выбирала "правильные" тренинги: как нагрузить систему, как тестировать безопасность, как автоматизировать... Зачем мне, например, какой-то там непонятный тест-дизайн или стандарты в тестировании?..
А потом я стала еще более опытным тестировщиком и стала задумываться: почему вот я такой уже "более опытный тестировщик", а мой тим-лид сходу в уже проверенном мной функционале находит ошибки?Я старалась запомнить какие именно данные он вводит, но на других частях функционала они работали, а вот именно тут - все валили. А почему?
Нет, я не буду писать историй в стиле "а потом я увидела тренинг "Практикум по тест-дизайну" и это стало панацеей от всех бед". Расскажу пару историй из практики.
Почему некоторые автотесты отрабатывают корректно функционал, а при ручном прохождении того же функционала находятся ошибки? Почему некоторые тестировщики находят больше багов, чем другие? Потому что эти "некоторые" знают где искать или, как минимум, откуда начать искать.
В теме о том, какие темы было бы интересно услышать на юбилейной SQA Days'10 сходу появилось такое вот мнение:
Сейчас я руковожу командой тестировщиков, которые хотят стать автоматизаторами. Для них нет проблем в том, чтобы разобраться в каком-то инструменте или настроить какое-то окружение, они запросто обсуждают инструменты автоматизации. Даже самые неопытные в течение нескольких часов разобрались с git, корректно его установили и подняли проект на локальной машине. Но когда речь заходит о написании тест-кейсов или хотя бы чек листов... А если еще попросить в чек-листах сделать список параметров, которыми будут пользоваться при дальнейшем тестировании...
Почти в каждой вакансии на должность тестировщика выше junior уровня требуется умение писать тестовую документацию. Об этом умении лично меня спрашивали на собеседовании в числе первых вопросов. Я сама спрашивала об этом на собеседованиях у соискателей.
А как можно нормально подготовиться к процессу тестирования, если о тест-дизайне тестировщик если и слышал, то краем уха? Написать чек-лист по позитивным сценариям и успокоиться? Так умеет любой программист, зачем же тогда нужны мы?
Один мой очень хороший друг-программист написал как-то (в ответ на другой вопрос, но все же):
Господа присяжные, у меня все! ))
Потом я стала более опытным тестировщиком, начала посещать тренинги... И, конечно, я выбирала "правильные" тренинги: как нагрузить систему, как тестировать безопасность, как автоматизировать... Зачем мне, например, какой-то там непонятный тест-дизайн или стандарты в тестировании?..
А потом я стала еще более опытным тестировщиком и стала задумываться: почему вот я такой уже "более опытный тестировщик", а мой тим-лид сходу в уже проверенном мной функционале находит ошибки?Я старалась запомнить какие именно данные он вводит, но на других частях функционала они работали, а вот именно тут - все валили. А почему?
Нет, я не буду писать историй в стиле "а потом я увидела тренинг "Практикум по тест-дизайну" и это стало панацеей от всех бед". Расскажу пару историй из практики.
Почему некоторые автотесты отрабатывают корректно функционал, а при ручном прохождении того же функционала находятся ошибки? Почему некоторые тестировщики находят больше багов, чем другие? Потому что эти "некоторые" знают где искать или, как минимум, откуда начать искать.
В теме о том, какие темы было бы интересно услышать на юбилейной SQA Days'10 сходу появилось такое вот мнение:
Очень интересно было бы слышать больше о тест-дизайне. Потому что все такие модные автоматические тестировщики и так далее, а хороший кейс днем с огнем не найдешь (пунктуация и орфография автора сохранены).Эту фразу я прочитала уже очень давно, но она все не идет у меня из головы. Потому что ею одной выражено почти все состояние отрасли тестирования! Я вспоминаю проекты, на которых я занималась тестированием. Написание тестовой документацией всегда было проблемой как минимум для нескольких человек в команде.
Сейчас я руковожу командой тестировщиков, которые хотят стать автоматизаторами. Для них нет проблем в том, чтобы разобраться в каком-то инструменте или настроить какое-то окружение, они запросто обсуждают инструменты автоматизации. Даже самые неопытные в течение нескольких часов разобрались с git, корректно его установили и подняли проект на локальной машине. Но когда речь заходит о написании тест-кейсов или хотя бы чек листов... А если еще попросить в чек-листах сделать список параметров, которыми будут пользоваться при дальнейшем тестировании...
Почти в каждой вакансии на должность тестировщика выше junior уровня требуется умение писать тестовую документацию. Об этом умении лично меня спрашивали на собеседовании в числе первых вопросов. Я сама спрашивала об этом на собеседованиях у соискателей.
А как можно нормально подготовиться к процессу тестирования, если о тест-дизайне тестировщик если и слышал, то краем уха? Написать чек-лист по позитивным сценариям и успокоиться? Так умеет любой программист, зачем же тогда нужны мы?
Один мой очень хороший друг-программист написал как-то (в ответ на другой вопрос, но все же):
при всем сходстве мышления тестера и кодера, ценность тестера в его особенностях мышления. программер просто не способен найти большинство ошибок в своей программе потому, что ему не придет в голову использовать ее не так, как он задумал - вводить странные данные, фапать по интерфейсу (пунктуация и орфография автора сохранены).Собственно, то, что программисты называют "особенностями мышления", есть ни что иное, как страсть к исследованиям + навыки тест-дизайна.
Господа присяжные, у меня все! ))
Хорошая заметка. Вот только немного (или даже много) смущает, что речь вроде бы идёт о тест-дизайне, но при этом упор делается на тестовую документацию. Но ведь тест-дизайн - это не обязательно тестовая документация; тест-дизайн - это в первую очередь, как мы мыслим и как строим свои тесты; а фиксирование на бумаге - это уже немного другой вопрос.
ОтветитьУдалитьДа, это у меня сыграла эмоциональная составляющая ))) Сначала надо было про построение тестов, а потом - про документацию. А я сразу выплеснула все мысли про документацию (накипело!!), а потом уже - про построение тестов ))
ОтветитьУдалитьВот да. У нас в команде тоже все пытаются рваться в автоматизацию, а надо бы еще и понимать, что мы автоматизируем.
ОтветитьУдалитьВероятно, много всего сразу накипело :)
ОтветитьУдалитьИ про автоматизацию, кстати, да - наболевшее, и с red_foks соглашусь - сейчас такая мода на автоматизацию, как будто это панацея какая-то, но при этом словно бы совершенно упускается из виду, что автоматизация - это по сути только инструмент (пусть даже и мощный и классный, хотя это смотря в чьих руках, как обычно)...
Lena, вера в серебряную пулю неистребима)
ОтветитьУдалитьЧо, орфография и пунктуация вполне соответствуют стандартам. Вроде бы =)
ОтветитьУдалитьА насчет дизайна то да. Даешь бывало юному падавану калькулятор с тремя кнопками - "2", "+", "=".
Говоришь:
- Протестируй.
Он его грызет, окунает в воду, прыгает на нем, норовит в микроволновку сунуть или перепрошить.
Отбираешь истерзанный ресурс и интересуешься:
- А сложить 2 и 2 он может или нет?
Ну ясно, ага?
Волонтер, а бывает и наоборот: 2+2 сложил и счастлив безмерно... так как считает, что все протестировал...
ОтветитьУдалить"Отбираешь истерзанный ресурс и интересуешься:
ОтветитьУдалить- А сложить 2 и 2 он может или нет?"
"а бывает и наоборот: 2+2 сложил и счастлив безмерно... так как считает, что все протестировал..."
ну эти два примера прекрасно иллюстрируют только одно: недостаток знаний, вследствие чего или хаотичное тестирование без учета рисков, без какой-то логики в построении тестов; или простой манки-тестинг, где "шаг влево, шаг вправо приравнивается к побегу"...
Пичалька...
Да тут вопрос не только в дизайне тест кейсов, а еще и в приоритезации их запуска...
ОтветитьУдалитьКейсов можно написать тысячи по всем правилам дизайна, но вот в какой очередности их запускать не все понимают.
По-хорошему, дизайн - это именно искусство сгенерировать максимально полезные тесты при их минимальном количестве, а не бездумное их клепание по каким угодно правилам.
ОтветитьУдалить