Нина Агеева, автор и тренер курса «Погружение в тестирование. Jedi point» подготовила небольшое видео в формате влога про то, что делают крутые тестировщики с таблицами решений, как их строят, как их используют, чтобы не пропускать баги!
Таблицы решений хороши, когда у нас есть зависимость каких-то действий от определенных условий, а ещё — это простой и понятный способ визуализации данных, с которыми работают тестировщики. При правильном построении таблицы решений можно использовать в качестве тест-кейсов и не пропускать баги, которые стоят немалых денег для заказчиков тестирования.
Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.
Размышляя об этом первом десятилетии регулярного получения денег за ввод странных символов в терминал, хотелось бы поделиться некоторыми наблюдениями, как изменилось моё мышление за годы работы.
Возможно, нынешние джуниоры найдут здесь кое-что из своих убеждений и посмотрят на них с другой стороны. Или осознают, что они уже избавились от этого, поэтому зашли гораздо дальше, чем я была на вашем этапе.
Нынешние сеньоры, возможно, захотят тоже поделиться забавными (и немного унизительными) историями о том, какие уроки извлекли из своего джуниорского опыта.
Для ясности подчеркну, что джуниоры потрясающие: просто появляться на работе, чтобы учиться новому, — это уже требует тонны мужества. Это статья о моём собственном опыте и обучении. Я вовсе не обобщаю, что все младшие разработчики так думают или ведут себя.
Надеюсь, пост вам понравится и напомнит что-то из прошлого или настоящего.
Я большой фанат тестирования. Я пишу об этом в блог и почтовую рассылку, я обсуждаю это c другими разработчиками в свободное время, я зашел так далеко, что даже создал обучающий курс по тестированию в Go.
Но несмотря на всю мою любовь к тестированию, я не рекомендую его новичкам.
Звучит дико, правда? В этой статье я собираюсь пояснить свою точку зрения более детально, но весь смысл, в итоге, сводится к двум пунктам:
Начинающим не хватает знаний, чтобы писать что-либо кроме самых простых тестов. Это неизбежно приводит к следующему пункту…
Пытаться тренировать навыки, необходимые для написания реалистичных тестов, одновременно с обучением программированию крайне тяжело
Я понимаю, что это, в принципе, один пункт. В любом случае, я разбил его на два для того, чтобы было проще понять.
Знаю, многие из вас не согласятся со мной, но пожалуйста, прочитайте статью, и, если после прочтения вы останетесь при своем мнении, я буду рад обсудить это с вами. В конце концов, я здесь чтобы учиться
Вопросы на собеседованиях тестировщиков часто походят друг на друга. Один из самых часто задаваемых - задача на тестирование программы, проверяющей существование треугольников. Задача хорошая, но довольно абстрактная, и бывает сложно вспомнить все кейсы, которые стоит провести.
Чтобы сделать задачу более наглядной, мы создали небольшой тренажер: https://playground.learnqa.ru/puzzle/triangle. К нему мы добавили самые популярные кейсы для тестирования, а также несколько багов разной сложности. Можете попробовать найти их все и получить приятные скидки на наши курсы! Ну и конечно похвастаться перед другими тестировщиками, когда найдете все :)
На конференциях, митапах и в социальных сетях тестировщики систематически сообщают мне, что они должны "дать добро" на продукт или деплой перед тем, как продукт выпущен в продакшен, или уйдет на ревью к клиенту. Тестировщики заявляют, что после того, как они проделали какую-то работу по тестированию, они должны "одобрить" или "отклонить" продукт. Вот типичный дословный отчет от одного из них:
"В моем нынешнем контексте, несмотря на мои обоснованные возражения, на меня смотрят как на привратника, и я нахожусь на такой позиции в рабочем процессе, которая буквальным образом предоставляет мне зеленую кнопку "одобрения" и красную кнопку "отклонения". Я должен выбрать нужную кнопку после "проведения контроля качества" рабочего продукта. Отдельным бонусом идет список противоречивых требований заказчика и/или набросок с кучей примечаний (зачастую противоречащих устным запросам, которые нигде не фиксировались)".
Так или иначе, все сталкивались с ситуациями, когда в банальной обстановке вдруг происходило что-то необычное. Примерно такой случай произошел с нами при тестировании нового приложения на проверенном сто раз окружении. Сюрпризом для нас стало использование некоторых возможностей HTML5 в работе front-end’а, а точнее невозможность стандартными средствами Selenium WebDriver автоматизировать тестирование drag&drop операций. Об этом опыте мы хотим рассказать.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Ранее мы обсуждали три способа тестирования на межсайтовый скриптинг. Мы разбирали примеры ручного тестирования XSS и говорили о том, как использовать код для создания XSS-атак. Сегодня мы рассмотрим третий способ тестирования – использование автоматизации. Для этого мы воспользуемся Burp Suite. Этот странно названный, но крайне полезный инструмент доступен бесплатно (есть и платная версия с дополнительной функциональностью). Мы также будем пользоваться Juice Shop и Postman.
Для начала давайте исследуем поле Juice Shop, которое мы будем тестировать. Используя Chrome, перейдите на главную страницу Juice Shop. В верхней части экрана вы увидите окно поиска. Откройте инструменты разработчика Chrome, нажав на многоточие в правом верхнем углу – затем нужно выбрать "Дополнительные инструменты" – "Инструменты разработчика". После того, как вы их открыли, кликните на вкладку "Сеть".
Выбор. Все мы делаем выбор десятки раз за день. Арахисовое масло или сыр (я, как правило, за сыр). Джинсы или слаксы (определенно джинсы). Кофе или чай (хороший кофе со стаканом воды, пожалуйста). А когда вы работаете над автоматизацией или обучаетесь ей, перед вами встает множество вариантов, которые вы можете (а иногда должны) выбирать. Многие из этих вариантов, насколько я могу судить по обсуждениям и решениям людей вокруг, не очень-то хороши. Некоторые из них – вообще ложные дихотомии. Давайте посмотрим, над какими решениями размышляют люди, и какие еще варианты им доступны из тех, что могут дать лучшие результаты и сделать их лучше как специалистов.
Тренер по тестированию Ольга Назина подготовила для читателей нашего портала новогодний подарок — подборку переводов исследовательских туров от James A. Whittaker из книги Exploratory Software testing!
Исследовательское тестирование — серьезная тема, провести его полноценно может только опытный тестировщик. Это ведь не просто «потыкать рандомно», все равно нужен план тестирования.
James A. Whittaker нашел способ проводить исследовательское тестирование даже начинающими тестировщиками. Он составил методику туров, которые может выполнить любой. Фактически каждый тур — это тот самый план, по которому мы будем тестировать. План, уже составленный за нас!
Если вы еще не пользовались методикой, обязательно попробуйте. А Ольга Назина подготовила подборку любимых туров, которые находят баги практически везде:
