XPath - язык запросов, позволяющий обращаться к элементам XML-документа.
XPath активно используется в мире автотестов веб (ибо веб-страница - частный случай XML-документа).
В целом XPath штука несложная, если разобраться с двумя основными концепциями: осями и предикатами.
воскресенье, 23 сентября 2018 г.
пятница, 22 апреля 2016 г.
Качественный субъективизм
Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.
При желании каждый участник процесса разработки легко найдёт оправдания и объяснит, почему налажал не он. Бизнес-аналитик честно подумал, но не смог учесть все нюансы многолетней архитектуры. Разработчик честно реализовал требования, а тестировщик честно их проверил. Оба - как поняли. Ну а что, если требования не полны - вопросы к аналитику. Он ещё и менял их постоянно, чего удивляться. Техлид недоучёл энтузиазм джуниора, а джуниор не в курсе, чем отзывается взмах крылом в этом конкретном компоненте системы.
В общем, все молодцы, а на выходе какашка. Нормальный процесс переработки сырого продукта.
И да, отмечу, фраза "каждый легко найдёт оправдания и объяснит, почему налажал не он" не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.
При желании каждый участник процесса разработки легко найдёт оправдания и объяснит, почему налажал не он. Бизнес-аналитик честно подумал, но не смог учесть все нюансы многолетней архитектуры. Разработчик честно реализовал требования, а тестировщик честно их проверил. Оба - как поняли. Ну а что, если требования не полны - вопросы к аналитику. Он ещё и менял их постоянно, чего удивляться. Техлид недоучёл энтузиазм джуниора, а джуниор не в курсе, чем отзывается взмах крылом в этом конкретном компоненте системы.
В общем, все молодцы, а на выходе какашка. Нормальный процесс переработки сырого продукта.
И да, отмечу, фраза "каждый легко найдёт оправдания и объяснит, почему налажал не он" не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.
четверг, 10 декабря 2015 г.
SUT с человеческим именем
Допустим я тестирую продукт, который работает [в том числе] с "человеческими данными".
Где-то для чего-то указываются и хранятся имена, емейлы, логины, телефоны и тому подобное. Есть формы, где можно данные редактировать, потом эти данные где-то показываются и используются. Есть и прочие вещи, слабо связанные с этими данными, например, возможность давать пользователю разные права: тут не обойтись без объекта "пользователь", но всякие атрибуты вроде имени/телефона обычно не важны. Другими словами, при тестировании можно указать любую белиберду, которую система согласна принять.
Так я и делал. Тестируя формы - вводил произвольный текст, лишь бы пройтись по классам эквивалентности, потыкать во все границы. Тестируя прочие фичи - указывал минимальный допустимый набор символов, потому что неважно же какое там имя. И пользователь a12 взаимодействовал с ttt, и всё, в общем, у них получалось.
Но с некоторых пор я стал чаще использовать данные похожие на настоящие имена, фамилии и адреса. Ибо не фиг. И это таки немножко помогает в тестировании.
Где-то для чего-то указываются и хранятся имена, емейлы, логины, телефоны и тому подобное. Есть формы, где можно данные редактировать, потом эти данные где-то показываются и используются. Есть и прочие вещи, слабо связанные с этими данными, например, возможность давать пользователю разные права: тут не обойтись без объекта "пользователь", но всякие атрибуты вроде имени/телефона обычно не важны. Другими словами, при тестировании можно указать любую белиберду, которую система согласна принять.
Так я и делал. Тестируя формы - вводил произвольный текст, лишь бы пройтись по классам эквивалентности, потыкать во все границы. Тестируя прочие фичи - указывал минимальный допустимый набор символов, потому что неважно же какое там имя. И пользователь a12 взаимодействовал с ttt, и всё, в общем, у них получалось.
Но с некоторых пор я стал чаще использовать данные похожие на настоящие имена, фамилии и адреса. Ибо не фиг. И это таки немножко помогает в тестировании.
пятница, 13 ноября 2015 г.
Уважение к старшим
С легаси кодом не просто.
Это такой специальный код, который был написан в доисторические времена (кажется, в прошлую пятницу). В нём много всего занятного, но мало понятного с первого взгляда. Он что-то делает, но как ему это удаётся - поди разберись. В нём немало странностей, а то и багов, но эти странности благополучно пережили уже несколько версий продукта.
Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой - лучше к нему не прикасаться.
Так вот знаешь, что? Уважай его.
Он не просто так появился в системе, и он честно работает уже несколько лет. Продукт работал всё это время благодаря ему - и приносил деньги. Он, может, странно выглядит, но в свое время это было лучшее из доступных решений (или просто достаточно неплохое). Он дожил до сегодняшнего дня, значит он вполне работоспособен и решает свою задачу: он не так уж плох. Он спокойно работал и давал возможность развивать другие стороны продукта.
Серьёзно, без него у тебя не было бы этой работы.
Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде - это следы древних багов. Будешь небрежен - и те же баги повторятся уже в новом коде.
Это легаси. Уважай его.
Это такой специальный код, который был написан в доисторические времена (кажется, в прошлую пятницу). В нём много всего занятного, но мало понятного с первого взгляда. Он что-то делает, но как ему это удаётся - поди разберись. В нём немало странностей, а то и багов, но эти странности благополучно пережили уже несколько версий продукта.
Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой - лучше к нему не прикасаться.
Так вот знаешь, что? Уважай его.
Он не просто так появился в системе, и он честно работает уже несколько лет. Продукт работал всё это время благодаря ему - и приносил деньги. Он, может, странно выглядит, но в свое время это было лучшее из доступных решений (или просто достаточно неплохое). Он дожил до сегодняшнего дня, значит он вполне работоспособен и решает свою задачу: он не так уж плох. Он спокойно работал и давал возможность развивать другие стороны продукта.
Серьёзно, без него у тебя не было бы этой работы.
Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде - это следы древних багов. Будешь небрежен - и те же баги повторятся уже в новом коде.
Это легаси. Уважай его.
четверг, 29 октября 2015 г.
Сказка о неразобранных автотестах
Жил был проект, а в проекте делали продукт, а у продукта была веб-морда, и нужно было ту веб-морду тестировать, и были автотесты ("Selenium" - подумал Штирлиц) для всех и всяческих сценариев. Автотесты регулярно запускали на свежих билдах, они достаточно быстро выполнялись и радовали всех "зелёными" результатами. "Красные" результаты быстро исследовали, чинили проблему, и каждый следующий запуск был "зеленее" предыдущего. Скоро сказка сказывается, да не скоро дело делается.
У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?
Сразу хочется задать кучу уточняющих вопросов, что же именно не работает и почему не работает и какой мир считается реальным и т.п., но не могу: не коллегу же спрашивать про чужие проблемы (слышал я эти Битлз - мне друг по телефону напел). Но понятно, что если на результаты автотестов не смотреть, то можно тогда автотесты и не использовать вообще. С точки зрения бездушной математики это то же самое.
С другой стороны, если сесть и вспомнить, то - ну да, всё так. Разбирать автотесты - это не вдохновляет. Как возникает эта задача, так сразу хочется чем-то другим заняться. На такой случай всегда найдётся Важное Дело, Которое Надо Сделать. То есть проблема не совсем выдуманная, и как-то же её решают те, кто живёт в нереальном мире.
Итак, возможные решения, только здесь и сейчас, спешить узнать.
Возможны противопоказания, проконсультируйтесь со своей командой.
У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?
Сразу хочется задать кучу уточняющих вопросов, что же именно не работает и почему не работает и какой мир считается реальным и т.п., но не могу: не коллегу же спрашивать про чужие проблемы (слышал я эти Битлз - мне друг по телефону напел). Но понятно, что если на результаты автотестов не смотреть, то можно тогда автотесты и не использовать вообще. С точки зрения бездушной математики это то же самое.
С другой стороны, если сесть и вспомнить, то - ну да, всё так. Разбирать автотесты - это не вдохновляет. Как возникает эта задача, так сразу хочется чем-то другим заняться. На такой случай всегда найдётся Важное Дело, Которое Надо Сделать. То есть проблема не совсем выдуманная, и как-то же её решают те, кто живёт в нереальном мире.
Итак, возможные решения, только здесь и сейчас, спешить узнать.
Возможны противопоказания, проконсультируйтесь со своей командой.
вторник, 13 октября 2015 г.
Разработка и Продажи
Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь): Вот черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес
P.S. Основано на вымышленных событиях
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь): Вот черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес
P.S. Основано на вымышленных событиях
суббота, 25 октября 2014 г.
Связанные многочисленными ниточками
В больших компаниях и проектах, тем более распределенных, часто трудно согласовать работу между несколькими людьми и/или командами. Команда А ждет чего-то от команды Б, а та ожидает чего-то от А и от В, а В делает нечто важное, после чего нужно будет потрудиться еще нескольким командам. Это дополнительно усугубляется временными поясами, ролевыми разделениями, иерархией, личными отношениями им много чем еще.
Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.
Стоит потратить пять минут на чтение.
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.
Стоит потратить пять минут на чтение.
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
среда, 3 октября 2012 г.
100500 конфигураций.
Знакомая многим проблема: тестируя, мы настраиваем продукт и окружение не совсем так, как это делают пользователи. Причин для этого масса – нет того оборудования, недостаточно времени, неучтенные сочетания настроек, более приоритетные задачи и так далее.
Сопутствующая проблема: если покупателей продукта сколько-то больше, чем один, приходится проверять огромный комбинаторный массив конфигураций продукта. Конечно, далеко не все параметры влияют друг на друга, зато порой бывают неочевидные зависимости.
В результате мы рискуем пропустить баги, а пользователи получают шанс их найти, что всегда неприятно.
Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).
Итак, мы хотим тестировать продукт в таких же условиях, в каких он будет работать, или хотя бы в похожих. Одновременно мы хотим проверять допустимые настройки продукта, но не утонуть в многообразии их сочетаний. Как приблизиться к этой цели?
Сопутствующая проблема: если покупателей продукта сколько-то больше, чем один, приходится проверять огромный комбинаторный массив конфигураций продукта. Конечно, далеко не все параметры влияют друг на друга, зато порой бывают неочевидные зависимости.
В результате мы рискуем пропустить баги, а пользователи получают шанс их найти, что всегда неприятно.
Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).
Итак, мы хотим тестировать продукт в таких же условиях, в каких он будет работать, или хотя бы в похожих. Одновременно мы хотим проверять допустимые настройки продукта, но не утонуть в многообразии их сочетаний. Как приблизиться к этой цели?
понедельник, 10 сентября 2012 г.
4k+ знаков про ТО
Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.
Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).
Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).
понедельник, 16 апреля 2012 г.
Привет, Аноним в поисках вопросов
Внезапно мне пришёл комментарий:
Анонимный прокомментировал(а) ваше сообщение:
Добрый день, Павел.
Решил себя попробовать в тестировании, как мне казалась вещь очень интересная (знания брал из знаменитой для тестировщиков книги Савина), устроился в компанию, которая разрабатывает свой програмный продукт, проработав меньше месяца сбежал, т.к.было настолько скучно (тестирование - черный ящик, метод назывался "свободный поиск").
О чем спрашивать работодателя, когда принимают на работу? какие вопросы задавать по тестированию (чтобы потом не было так скучно)?
Комментарий к комментарию получился длинноват, так что публикую его отдельным постом.
Подписаться на:
Сообщения (Atom)