Были ли у вас когда-либо трудности с объяснением возможного бага разработчику, архитектору, проектному менеджеру? Бывает ли, что вас не понимают, или вы не понимаете других участников команды, обсуждая систему проекта или другие абстрактные концепции? Вы не одиноки. Большие и сложные системы влекут за собой возможность абсолютного отсутствия единства их понимания среди коллег. Эта статья рассматривает использование символов и рисунков как инструмента, который поможет вам понимать и объяснять сложные системы.
Приходя на новый проект, команда «Лаборатории качества» всегда закладывает время на первичное знакомство с ПО, даже если клиент уверяет, что «документация полнейшая», а «продукт простейший». Мы вежливо киваем, но предупреждаем, что в течение одной-двух недель наши инженеры по тестированию будут регулярно забрасывать «очевидными» вопросами всех, до кого смогут дотянуться. Потому что никаких «очевидных» вопросов и «само собой разумеющихся» ответов не существует, идет ли речь о стандартном банковском ПО или простом интернет-магазине. Вскоре и сам заказчик начинает понимать, что сервис кажется простым только ему и разработчикам. А вот тем, кто видит его впервые, многие решения могут показаться, мягко говоря, не очень понятными и логичными.
В докладе вы узнаете о проблематичных зонах в тестировании клиентской части мобильного приложения на примере команды звездолета Дискавери, которая тестировала свой новый фичер - споровый двигатель.
А также подумаем, что с ними (зонами) делать, чтобы не повторять ошибки команды и получить приложение наивысшего качества.
Давайте вначале разберемся, что подразумевается под словом "план". Мы с Джеймсом Бахом говорим о планировании (и учим планировать в курсе Rapid Software Testing), понимая план как сумму или пересечение стратегии и логистики. Стратегия – это набор идей, направляющих ваш тест-дизайн. Логистика – это набор идей, направляющих распределение ваших ресурсов. Объедините их, и получится план. Тут очень важно отметить, что план – это не физический предмет - это набор идей. Следовательно, важно различать план и документацию по планированию – то есть документы, содержащие какую-то касающуюся плана информацию.
Вопрос, что должно входить в тест-план, можно интерпретировать двояко – во-первых, как вопрос про "план", а во-вторых, как вопрос о документации планирования. Начнем с плана.
8 недель курса мы объясняли сложные термины простым языком, давали домашние задания, отправляли обратную связь и отвечали на вопросы. Мы сказали всё, что было возможно, во время занятий. А теперь пришло время дать слово нашему первому выпуску ПОИНТ (Первый Онлайн ИНститут Тестировщиков).
1 344 часа обучения. Как это было?
«Я прошла курс ПОИНТ на одном дыхании! Грамотно выстроенный процесс помогает плавно влиться в курс. Всё идёт в порядке возрастания и нагрузка не так ощутима. Преподаватели всегда разъясняют, что к чему, постоянно на связи. В самом курсе много информации, но она структурирована; и даже если кажется, что вы это уже знаете, то обязательно почерпнете для себя что-нибудь полезное. Ставлю курсам твёрдую 5! Вы большие молодцы. Однозначно рекомендую, курсы полезные»
Мария Б.
«Эти 2 месяца были очень насыщенными, интересными и, лично для меня, полны открытий. Придя на курс, я уже имела опыт работы в IT, хоть он был и до декрета, и также имела представление о тестировании (книга Савина и некоторые материалы из рассылки Форума тестировщиков). Основной целью было систематизировать и освежить свои знания.
В результате я получила значительно больше! Мне очень понравилось, что вы дали значительный список инструментов, с которыми я не была знакома. Да и навряд ли я освоила бы некоторые из них самостоятельно. Материал в целом подавался очень доходчиво, но порой его не хватало и хотелось больше».
Только 4 декабрявсе технологии по нагрузочному тестированию из первых уст от Перформанс Лаб, Сбербанк Технологии, Райффайзен банка.
Рады сообщить, что 4 декабря в Москве пройдет V юбилейная конференция по нагрузочному тестированию, организованная компанией Перфоманс Лаб, при поддержке известных вендоров и лидеров в данной отрасли. Из маленькой «дружеской» конференции тестировщиков, мероприятие переросло в марафон от ведущих компаний России, которые готовы открыто поделиться своим опытом.
Конференция не такая, как все. И вот почему:
1. Все практики и технологии только по теме Нагрузочное Тестирование. Ничего лишнего!
2. На конференции выступают спикеры известных IT-компаний России, вендоры. Они делятся реальным практическим опытом. Только технические доклады, никакой рекламы.
3. Материал доносится в понятной и доступной форме.
4. По окончании мероприятия каждый участник получит сертификат участника конференции.
5. Профессиональная среда и новые контакты.
Какие новые знания Вы получите на конференции:
1. Узнаете какие подходы будут использоваться для тестирования распределенных сетей в будущем и зачем нужен блокчейн в нагрузочном тестировании.
2. Узнаете какие выбрать инструменты при работе с высоконагруженными проектами, с примерами и тонкостями использования.
3. Как составлять профиль нагрузки в сложных ситуациях, и как поступить если вы встретились с криптографией в проекте по тестированию.
4. Как автоматизировать нагрузочное тестирование, и применить навыки DevOps.
В данной статье я бы хотел рассказать об особенностях мобильного тестирования и переходе от ручного тестирования к автоматизации на примере одного из наших проектов, в котором мы тестировали приложение для фитнес-девайса.
Специфика проекта
Данный проект был международным и распределенным территориально. Все коммуникации, процессы и артефакты были на английском языке. В проекте участвовали команды из Индии, центральной России, Москвы и Эль–Сальвадора, главный офис заказчика – в Калифорнии.
Мы занимались тестированием приложения, написанного для конкретного фитнес-девайса: приложение нельзя было просто скачать из магазина и приступить к работе. Также требовалось уделить особое внимание взаимодействию девайса с телефоном и приложением.
Наше общение с Заказчиком началось с того, что они не смогли самостоятельно пройти предрелизные проверки для добавления своего приложения в AppStore и Google Play. Как следствие, для начала нам потребовалось провести тестирование по гайдлайнам от Apple и Google.
Как это нередко бывает в мобильной разработке, iOS версия опережала на пару спринтов Android и все новые фичи сначала появлялись для IOS.
На старте проекта не было документации, и она появлялась только на новые фичи.
Оглядываясь на свой опыт работы в тестировании, я осознаю, что получила крупные поучительные уроки, и сейчас они кажутся мне очень понятными и очевидными. Однако все эти годы я писала о своей позиции, и могу оценить, насколько мои взгляды менялись со временем. Поначалу я нервничала, если писала о том, что мне казалось верным (хотя это могло быть абсолютно не так), но блог помог мне справиться с волнением и обращать внимание на положительный эффект от него.
Множество фундаментальных перемен я предсказать не могла – они происходили постепенно в течение длительного времени. Ретроспективно они очень существенны, и их легко воспринимать как то, что я знала всегда. О четырех из них я хочу рассказать подробнее – они резко изменили мою систему ценностей и стимулировали поиск новых возможностей.
SQL injection — это уязвимость, в которой злоумышленник создает или изменяет текущие SQL-запросы для отображения скрытых данных, их изменения или даже выполнения опасных команд операционной системы на стороне сервера базы данных. Атака выполняется на базе приложения, строящего SQL-запросы из пользовательского ввода и статических параметров.
SQLmap — это инструмент с открытым исходным кодом для тестирования на проникновение, который автоматизирует процесс выявления и эксплуатирования уязвимостей SQL-инъекций и захват серверов баз данных.
У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.
На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:
