Feeds:
Записи
Комментарии

Archive for the ‘Testing like…’ Category

У прошедшую субботу выступал во Львове на QA Meetup от Binary Studio:

14249732_1076818582373714_3118954000420683221_o(1)

14249712_1076818742373698_1207932363929895134_o(1)

14231132_1076818842373688_324068661532505217_o(1)

Вообще намеревался устроить презентацию последовательного применения техник тест-дизайна, но после реакции аудитории на некоторые идеи понял, что если перейду к демонстрации, то всё будет «мельтешить», бо причины действий и выводов будут этой аудитории неочевидны. Поэтому на ходу переключился в другой формат выступления, благо, в слайдах нет нужды. Заодно и взял более медленный темп речи.

Таки тест-дизайн — это глубинная тема, нельзя бросать в неё не умеющих плавать и тонуть, бо нам утопленники не нужны.

Про сам митап: организовано мощно, всё учтено, перекусон вообще блеск!

Что заметил ВООБЩЕ: под meetup подразумевается встреча специалистов какой-то отрасли в неформальной обстановке для обсуждения какой-либо темы или ряда тем. Типа, джем для музыкантов. Но докладание превращает неформальность митапа в мини-конференцию, в которой есть много формальностей, которые всеми соблюдается, уж ничего не поделать. Этот митап тоже выглядит как мини-конференция, разве что действие происходит в офисе

В тот же вечер заглянул в новый львовский склад старых ружбаек и немецких касок — отличное место, там таки ждут вежливых гостей!

Львов, "Залiзна шапка"

Львов, «Залiзна шапка»

PS Если нужон перевод заголовка, то: «Тестдизайн в очумелых руках тестировщика».

Read Full Post »

Таки додумался, почему State Transition testing не вызывает моментального ой-вэй эффекта у большинства увязнувших в тестировании.

State-Transition Testing

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системыДействиеиное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «ДействиеРезультат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the CartProceed to CheckoutCheckout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

  • У нас нет времени на тест-дизайн…
  • На нашем проекте это не используется…
  • Никто на проекте не говорит, какую именно технику надо использовать…
  • Я тестирую только экивалентность и границы значений, и этого достаточно…
  • Пожалуйста, спасите-помогите…
  • Все эти техники — для задротов, реально они ничего не приносят…
  • Я буду это применять, если это реально поможет уменьшать количество тестов…
  • Тест-кейс — это когда надо проверить, что по шагам надо выполнять, и софт работает…
  • Я клоун…

Что надо сделать

  1. определить happy path — их может быть несколько.
  2. определить другие сценарии и ветвления к ним.
  3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
  4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
  5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
  6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.

Read Full Post »

Непременно помре.

Когда все тестировщики помрут, так оно и…

Вы покайтеся да раскайтеся заранее.

Сегодня имел удовольствие поматериццо объяснять начинающему тестировщику, что не существует «автоматизация тестирования» как некий отдельный объект или навык, который нужно учить отдельно от всего; что учить автоматизацию тестирования нужно в комплексе со всем остальным; что не надо «Сперва я выучу html, а затем CSS, потом JS и Selenium IDE», что надо ковырять всё одновременно.

А он не поверил.

Read Full Post »

Если смотреть на мир из черепа обыкновенного заказчика ПО, требования — совершенно лишний артефакт, который отнимает очень много средств и ничуть не гарантирует получение качественного результата. Вам надо — вы их и прописывайте.

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

(далее…)

Read Full Post »

Ну, наконец-то Алексей Баранцев замутил запустил тренинг на тему автоматизации тестирования «Автоматизация функционального тестирования», в ходе которого можно научиться не только автоматизировать, но и тестировать.

Можно ли представить себе хорошего линуксового системного администратора, который не знает общую теорию операционных систем и сетей, не подозревает о существовании Windows и MacOS, не умеет пользоваться для настройки системы консолью так же хорошо, как графической оболочкой? Можно ли считать хорошим инженером-строителем человека, который не владеет сопроматом, не знает про современные строительные материалы и особенности их применения, даже если на текущем объекте строительства они не используются? Можно ли признать хорошим актёром того, кто день за днём играет одну и ту же роль, не знает о современных тенденциях в театральном искусстве и не пытается попробовать себя в других амплуа?

Хороший специалист должен обладать достаточно широкими знаниями. Да, он глубоко изучает какую-то одну тему, специализируется в каком-то направлении, но при этом он должен представлять себе общую картину своей профессиональной области. Если он не будет это делать — мир уйдёт вперёд, его узкая тема окажется устаревшей и невостребованной, а он ничего другого не знает и не умеет.

Умение создавать автоматизированные тесты предполагает владение специализированными инструментами, которые так и называются «инструменты для автоматизации тестирования». Но знания хорошего специалиста должны охватывать всю область автоматизации. Какие вообще инструменты бывают? Для чего они предназначены? В какой ситуации следует (или наоборот не следует) использовать тот или иной инструмент? Как выбрать наиболее подходящий для решения задачи инструмент среди множества похожих?

И конечно же надо уметь делать хорошие автотесты. Да, сначала надо научиться понимать, чем «хорошие» автотесты отличаются от «плохих». А потом — научиться делать «хорошие». Эти правила являются общими, независимыми от конкретного используемого инструмента.

Решение мастера крайне одобряю.

Умиляют заколебали дети, которые уверены в том, что надо «или автоматизировать, или тестировать». Странно, что они не выбирают по утрам «или зубы чистить, или глаза промыть».

Read Full Post »

В LibreOffice можно подключить к документу odb файл (реляционная база данных) с хорошо оформленным списком литературы, например. Сразу плюшки:

  • единый формат хранения данных,
  • единое место хранения,
  • автоматический учет использованных в документе записей из этой базы данных и их автоматическая сборка в виде оглавления списка использованной литературы.

(далее…)

Read Full Post »

Темные подворотни киевского Подола.

Опиумная кальянная мадам Козятиной.

“We know English! Visa accepted! 24h!”

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

Легкая задымленность и маниакальный блеск в глазах говорящего:

…и поэтому я хочу, чтобы вместо тестировщиков на проекте работали автотесты. Тестирование на нашем проекте уже превышает все бюджеты, заказчик оплачивает только треть всей работы, остальное происходит за наш счет. А качества на проекте как не было, так и нет, постоянно находят какие-то баги! Там уже четыре тестировщика фигачат по девять man/hours в день! Это ж деньги впустую уходят! Это же вчерашний день!

— Дык, тестировщики за качество не отвечают… — из глубин кресла. — Это даже бухгалтера знают. Менеджер проекта отвечает за качество всего проекта…

(далее…)

Read Full Post »

« Newer Posts - Older Posts »

%d такие блоггеры, как: