Нина Агеева, автор и тренер курса «Погружение в тестирование. 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, нажав на многоточие в правом верхнем углу – затем нужно выбрать "Дополнительные инструменты" – "Инструменты разработчика". После того, как вы их открыли, кликните на вкладку "Сеть".
Автор: Майкл Болтон (Michael Bolton).
Автор: Кристин Джеквони (Kristin Jackvony)