Новые темы форума тестировщиков

Концепция построения процесса тестирования в Agile проектах: 3+1
2016-11-10 10:34

Выступление Елены Саламахи (Test Lead, Luxoft UA) на онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.

Перед многими тест-менеджерами, работающими в аджайл-практиках, стоят следующие задачи:

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

Для решения этих проблем, в своём докладе я расскажу вам о простых и эффективных практиках, накопленных поколениями аджайлистов – трёх основных концепциях построения тестирования в Agile:

1. В битве побеждает тот, кто в ней не участвует.

• Техники предотвращения появления дефектов.

2. Железная гибкость.

• Автоматизация, Непрерывная интеграция.

3. Путь в тысячу шагов начинается с одного шага.

• Концепция постоянного улучшения, «гибкого внедрения гибкости».

+1 бонус-концепция, которая призвана сделать жизнь существенно проще.

Смотреть видеозапись доклада...

Выручайте.

Есть клетка таблице, в которой вписана информация образца "Выполнено 10.11.2016", где 10.11.2016 13:37 - момент времени, в который совершено действие.

Мне нужно научить мой Селениум проверять наличие в клетке текста "Выполнено".

На данный момент я вижу два решения:

- Сторить содержимое клетки, вырезая из него циферки. К сожалению через replace("1", "2", "3", "4", "5", "6", "7", "8", "9", "0", ":", ".") не вышло.

- Время и дату брать как переменную, типа ${data}, таким образом проверяя содержимое как "Выполнено ${data}

Но как это сделать? Прошу совета и помощи.

Доброго всем дня, уважаемые форумчане!
Прошу отозваться тех, кто работает с инструментом PICT для составления тестов с применением техники pairwise.

Исходные данные таковы: файл с моделью (параметрами) содержит русские буквы, сохраняю в кодировке UTF-8

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

Может кто-нибудь подскажет, как обойти эту проблему? В документации по PICT ничего по этому поводу не нашел. Конечно, кто-то может сказать, что сменить PICT на AllPairs - это и есть решение проблемы... Но в PICT можно задавать условия, которыми еще больше ограничиваешь количество тест-кейсов. Поэтому и использую PICT. Или записывать все параметры не русскими, а английскими словами. Так и делал, пока не столкнулся с ситуацией, где нужно использовать именно русские буквы. (например, комбинации А-Я, а-я, А-Яа-я в регекспах)

Буду благодарен за любую помощь. Всем хорошего дня

Ребята, нужен совет

Решил проверить качество тест-плана. Просто один и тот же сайт дается двум тестировщикам на одинаковое время, задача: протестировать четко по плану.
Критерием оценки хочу использовать найденные баги, если будут совпадать на опр. %, то план дает предсказуемые результаты и значит все хорошо.
Вопрос: какой процент пересечения багов должен быть? Придерживаюсь числа 75%, но это число с потолка (опыт). Возможно, посоветуете другой способ проверки тест-плана. Нужно понять, даёт ли тест-план предсказуемые результаты, а не покрытие ПП тест-планом.

Р.S. Понимаю, что еще множество факторов есть, но тестовый сайт - лендинг, там не должны иные факторы оказывать сильное влияние. Производительность обоих тестировщиков примерно одинакова

При авторизации выскакивает капча, и что бы залогинеться нужно ввести в форму ее значения, подскажите, теоретически (если практически то супер) можно получить ее значения и подставить в форму?

Всем привет! Пишу UI тесты на Python с использованием фреймворка py.test + PageObject.
Все как обычно, есть отдельно описание страниц (Page Object) и есть для каждой страницы отдельный класс с тестами элементов страницы (сами проверки)

Возникла следующая идея:

Есть потребность составления тестов в формате пользовательских сценариев (зашел на сайт -> перешел в раздел -> заполнил форму и т.д)

Хотелось бы сделать файлы с проверками отдельных страниц (например: проверка страницы с некой формой, где проверяется наличие верных полей, кнопок и т.д)

и затем использовать эти же проверки в тесте с пользовательскими сценариями.

Пример: Захожу на сайт -> перешел в раздел -> вижу форму: запускаются проверки из файла, где проверяются все элементы формы -> затем еще какие-то действия.

Как думаете, есть ли возможность такое реализовать с помощью py.test или вообще с помощью каких-то тестовых фреймворков?

Автор: Мааике Бринкхоф (Maaike Brinkhof)

Оригинал статьи: http://blog.xebia.com/mapping-biases-to-testing-confirmation-bias/

Перевод: Ольга Алифанова

Часть 1, где объясняется используемая терминология

Начну с плохих новостей: предубеждения подтверждения невозможно избежать, но это даже хорошо – если вы им страдаете, то вы живой нормальный человек. Наша "Система 1" позволяет сразу перейти к выводам, если наши предположения, скорее всего, верны, и ошибка не приведет к страшным последствиям. К примеру, встречая нового человека, вы делаете выводы о нем, основываясь на своих стереотипах, одежде, которая на нем надета, осанке, и т. п. Это происходит настолько быстро, что вы не успеваете с этим бороться.

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

Предубеждение подтверждения – это "зонтичный" термин для целого семейства когнитивных искажений: например, это гала-эффект, "то, что видишь – это все, что там есть", эвристика доступности (для полного списка см. книгу Дэвида Канемана "Думай быстро, думай медленно"). Мы также разберемся, почему эвристики – важная часть нашей работы – напрямую связаны с предубеждением подтверждения.

Читать статью полностью...

тренер: Наталья Руколь

Онлайн-тренинг с практической работой, 10 занятий

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

Именно для вас – наш курс «Школа Успешных Тестировщиков v2.0». С этим курсом вы:

• Получите широкий кругозор в сфере тестирования
• Научитесь основным техникам и познакомитесь с основными инструментами тестировщиков
• Узнаете, как построен процесс тестирования в ведущих компаниях
• Пройдёте профильный тест, чтобы узнать, какие области и специализации в тестировании для вас ближе всего
• Узнаете, как получать от работы максимум удовольствия
• Создадите план развития на год, чтобы стать успешным тестировщиком

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

Подробная программа и условия участия

Онлайн-тренинг (4 занятия) с домашней работой

Тестирование веб-приложений интересно тем, что оно требует наиболее широкого владения различными видами тестирования. Одно из ключевых мест занимает тестирование защищенности (security testing) или проверка отсутствия известных уязвимостей.

Почему тестирование защищенности имеет такое большое значение именно для веб-приложений?

1. Веб-приложения ориентированы на массовое использование, поэтому сбои в работе, вызванные действиями злоумышленника, могут оказать негативное воздействие на большое количество ни в чём неповинных пользователей.
2. Веб-приложения могут хранить конфиденциальную информацию, утечка этих данных может иметь очень серьёзные последствия.
3. Доступ к веб-приложению имеет множество “недоверенных” пользователей, при этом владельцы или разработчики приложения как правило не могут контролировать или ограничивать их действия.
4. Обмен информацией между браузером и сервером происходит по открытым каналам с использованием открытых протоколов, поэтому сложно контролировать данные, передаваемые клиентами.
5. Разработка веб-приложений не всегда ведётся с должным вниманием к обеспечению защищенности и надёжности, потому что рынок в первую очередь требует “быстро”!

Разумеется, тестирование защищенности не ограничивается тестированием самого веб-приложения. Уязвимость может находиться в веб-сервере, операционной системе, почтовой системе, ftp-сервере или ещё где-то. Но задача создания защищенного окружения в большей степени находится в зоне ответственности системных администраторов, а вот защищенность вашего собственного веб-приложения -- целиком на совести его разработчиков и тестировщиков.

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

Подробная программа и условия участия

Привет.

Ищу бумажные копии классных книг по тестированию. Не обязательно новые :) Цену предлагайте.

Точно нужны:

• Канер С., Фолк Дж., Енг Кек Нгуен. Тестирование программного обеспечения — одну копию, а лучше две :)
• Элфрид Дастин, Джефф Рэшка, Джон Пол. Автоматизированное тестирование программного обеспечения - тоже хочется несколько
• Савин. Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах
• Rex Black. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование

Интересны и любые другие по тестированию, разработке ПО и вообще. Но там надо смотреть.

Зачем: мы в компании собираем библиотеку книг и оказалось, что люди читают бумажные книги гораздо охотнее электронных.

Если вы знаете, где можно достать редкие книги в бумаге, буду рад любому совету.

24-26 ноября я буду на SQA Days в Минске. Если вы хотите продать книжку, но не хотите заморачиваться с почтой, то можем обменяться там.

Мои контакты:

• личка на на форуме
• vitalya.cookie@gmail.com
• telegram @twenty_four_twelve

Коллеги, добрый день! Я сейчас попал на молодой проект в роли руководителя тестирования и столкнулся с проблемой выбора технологий и ПО.  Есть похожая тема (http://software-testing.ru/forum/index.php?/topic/33949-upravlenie-komandoj-chek-listy-zhelatelno-sviaz/?hl=testlink) но немного иные входные данные, поэтому решил создать новую. Возможно вы поможете и наведете на мысли. Итак, кратко по ситуации:

-Есть некий проект в формате веб. 

-Проект на базе методологии скрама: 2х недельные спринты, нет привзки к датам по задачам, используется система очков и на ее базе строится скоуп. 

-Как трекер для ведения документации и разработки используется JIRA

-Документация на проекте в формате  user story в JIRA Confluence

-Работать будет как внутренняя команда тестирования так и привлеченные внешние + возможно часть ФТ будут гонять бизнес представители проекта(некий смоук тест и ЮАТ) 

Итого стоит следующая задача: 

Выбрать По и организовать все виды тестирования(для начала хотя бы фанк и интеграцию, позднее в планах авто и нагрузка).

Я ранее работал в основном с MS TFS, но он в данном случае на мой взгляд не совсем оптимален для такого проекта. Мои мысли на этот счет: TFS хорош для десктоп приложений,но не для веб. Не уверен, что TFS можно как то связать адекватно с JIRA -опыта у меня по крайней мере такого не было. Ну и такой формат скрама так же не особо удобно вести в ТФС. 

Присматриваюсь к TESTLINK - с ним не работал ранее, но смотрится весьма неплохо и судя по найденной информации в инете вроде как дружит с JIRA. Zephyr по найденным в инете описаниям не понравился.  Средства HP после совещания в компании отвергли как идею. 

Как то так в итоге. Если есть спецы, кто уже подобное проходил, подскажите, стоит ли начинать процесс на базе TL или есть иные более удобные средства? И стоит ли пробовать в такой ситуации развернуть все таки TFS? Заранее благодарен за советы и комментарии по вопросу.   

UPD - на текущий момент не стоит вопрос интеграции старых наработок по тестированию - их пока элементарно нет и в этом плане проект с чистого листа. 

Добрый день. 2-3 недели назад начал заниматься автоматизацией,

Python 3.4 + PyCharm + Webdriver selenium + chrome

Стал вопрос. По прочтению и вытаскиванию данных из DOM,

У меня есть поле с данным текстом, который тянется из бд.

Нашел его в DOM

Собственно вопрос, как теперь из дум вытащить эти данные в переменную.

Нашел вроде мануал http://internetka.in.ua/selenium-webdriver-normalization/

Но у меня что то не заработало.

System.out.println("getAttribute(\"href\"): " + 
                            slider.getAttribute("href"));

при попытке вставить такой под. System и slider подчеркиваются красным, и я не очень понял что делать. Импорта Систем я не нашел.

Подскажите в чем дело ?

Приветствую всех. 

Хотел уточнить, может кто-нибудь знает, как получить данные из dropdowns с помощью Jmeter и выбрать рандомное значение и подставить его в тест? 

Суть в следующем: на сайте есть два dropdown поля и нужно получить значения из них и выбрать в каждом поле по рандомному значению. 

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

Всем здравствуйте.

Есть вопрос по такой ситуации. Разрабатываем систему управления делопроизводством (если кто сталкивался с Lotus, то немножко похоже с т.з. пользователя). Система очень большая, всего много: есть права пользователей (причем они разные для разных сущностей), есть проекты, папки с проектами, папка с документацией, занесение времени, еще целая куча разного функционала. Соответственно, когда внедряется какая-либо new feature, то затрагивается многое из этого. И нередко при тестировании оказывается, что какую-то область (процесс, сущность... ) просто забыли протестировать, ну вот не вспомнили, что у нас еще вот такой функционал есть, и все.

Собственно, вопрос - как избежать такой ситуации обеспечить надежное покрытие тестами? Если кто тоже работает на проекте с такой сложной штукой, поделитесь, пожалуйста, как вы пишете тест-кейсы для NFT? И где тут у нас корень проблемы?
 

Немного деталей:

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

- тестировщики работают на этом проекте примерно 70% своего времени, но гонки нет (это к тому, что времени на тестирование достаточно, хотя переключения и мультизадачность присутствуют).

Спасибо.

© 2010 | Software-Testing.Ru