Русский
Русский
English
Статистика
Реклама

Qa testing

Из песочницы Устрой дестрой, порядок НЕ отстой как я приводил в чувство шкаф для хранения девайсов

03.09.2020 20:17:52 | Автор: admin


Привет! В этой статье я расскажу, как в Лайв Тайпинге один смышленый QA с творческим мышлением и умелыми руками помог своей команде и оптимизировал процесс работы с девайсами.

Рынок мобильной разработки обширен и для поддержания конкурентоспособности необходимо обеспечивать качество продукта на высшем уровне. Команда должна быть уверена в своём продукте, в его безотказности, удобстве, в том, что он выглядит так, как было задумано изначально. Для того чтобы проверить всё это, и существуют QA.

QA это отдел бравых ребят, которые оценивают UI/UX приложения или сайта, а также тестируют приложение на отказоустойчивость и возникновение багов, тем самым обеспечивая качество продукта.

Девайсы (планшеты и телефоны разных моделей) ключевой инструмент каждого QA: именно на них мы тестируем приложения и готовим к релизу.

В процессе тестирования необходимо опираться на постулаты тестировщика свод правил, накопленных многолетним опытом. Они помогают провести качественное тестирование. Хочу подробнее остановиться на двух из них:

  • Парадокс пестицида говорит о том, что тестирование на однообразных кейсах малоэффективно, так как не будет выявлять все возможные баги.
    Парадокс срабатывает так: когда мы тестим приложение только на одном девайсе, мы не можем гарантировать, что на моделях новее или старее оно будет работать стабильно. Поэтому нам нужны разные версии iOS и Android и, соответственно, парк телефонов.
  • Исчерпывающее тестирование недостижимо правило говорит, что программу, сайт или приложение невозможно проверить досконально. Если вы не обнаружили багов, это значит что вы их не обнаружили, а не то, что багов вообще нет.

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

Из этих двух постулатов мы можем сделать вывод: потребность в качественном продукте обосновывает необходимость наличия обширного количества девайсов.

Но тестирование, QA, постулаты всё это было потом. Вернёмся немного назад я расскажу, как начинался мой путь тестировщика

1. Становление. Освоение. Боль


Как я попал в Лайв Тайпинг


Про Лайв Тайпинг я узнал еще в 2014 году на happyDev-lite. Всегда восхищался тем, с каким позитивом и интересом спикеры этой студии погружаются в свои темы, с какими горящими глазами рассказывают и как это сильно выделяет их на фоне остальных компаний.

Помню, как восхитился выступлением Романа Беляева: он рассказывал, что стал дизайнером в ЛТ благодаря soft-скиллам. Его взяли с пустым портфолио сразу после тестового задания, над которым он пахал всю ночь. Меня поразило даже не то, что его брали на ключевую позицию без опыта, а то, что компания увидела потенциал и дала ему возможность раскрыться. На должности в другие команды требуются молодые специалисты с продолжительным опытом работы в перспективных IT-компаниях и набором кейсов в портфолио. Я был восхищён тем, что есть люди, готовые развивать талантливых ребят с нуля.

Изучив основы дизайна и вёрстки, я решил попробовать себя в тестировании. Я был уверен, что эти знания помогут мне лучше понять рабочие процессы, пользовательские сценарии и юзабилити. И не ошибся.

Я окончил школу Тамтек, где получил серьёзную базу в дизайне, и осознал, что таких знаний не даёт ни одна из Омских компаний. И после этого попытал удачу на собеседовании в ЛТ. В компанию я попал, пройдя тестовое задание и два интервью, как QA с опытом в дизайне.

Как освоился


Когда я начал работать в Лайв Тайпинге, я продолжал удивляться тому, какая сложилась уютная атмосфера в студии и как в одном большом домашнем офисе все живут дружно и ладно. Как всё оптимизировано и настроено на комфортный рабочий режим. Как близко и тепло завязаны межличностные отношения коллег. И меня радовало такое окружение.

Работа в такой атмосфере шла сама собой казалось, что всё идеально, но на тот момент я ещё ничего не подозревал

Почему это оказалось больно


На одном из этапов тестирования проекта мне потребовались разнообразные девайсы. Именно тогда и произошло моё знакомство с главным героем истории.

Это был скромный, невзрачный, очень обиженный и обделенный вниманием шкаф в нём хранились все наши тестовые девайсы. Открыв его, я долго рыскал среди кучи мёртвых душ в поисках нужного смартфона, пока мне на помощь не пришла Роза (моя коллега-QA) и не нашла его для меня.

2. Самозабвение


История с долгими поисками девайсов и/или проводов стала касаться меня ежедневно. Такая пустяковая задача, как найти Xiaomi Mi A1, занимала кучу времени и приносила душевные страдания. Спустя некоторое время, я пришёл к мысли, что меня это бесит и на поиск девайса столько времени уходить не должно. Я нашёл узкое горлышко в рабочих процессах и решил его ликвидировать.

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

И пугало меня больше всего то, как люди спокойно относились к этому, хаос никого не удивлял. Ребята просто привыкли к нему.



Постепенно сформировался план того, как можно улучшить уголок девайсов, и я решил попробовать создать маленький Эдем внутри ЛТ сделать не просто шкаф для хранения, а удобное пространство, в котором у каждого телефона будет своё место. Чтобы даже новый человек, пришедший в ЛТ, за несколько секунд нашёл девайс или провод, при этом получив эстетическое удовольствие от процесса. Именно такие цели я и поставил для будущего проекта.

Ну вырежи дырки в пенопласте, разложи девайсы чё ты так запарился, говорили они...


Когда я читал умные статьи и книги про менеджмент, я сталкивался с выводами о том, как правильная организация рабочего места влияет на работоспособность и концентрацию, такие вещи являются фундаментом рабочих процессов.
Если загроможденный стол свидетельствует об упорядоченном уме, тогда о чём свидетельствует пустой стол? Альберт Энштейн
Когда в рабочей зоне огромное количество предметов, внимание рассеивается. На что смотреть? На чем сосредоточиться? В голове творится хаос, чувствуется усталость, раздраженность, неспособность сконцентрироваться на рабочих задачах. По результатам исследований ученых из университета в Пристоне, от организации рабочего места зависит примерно 38% от общего уровня сосредоточенности, а это, согласитесь, немало.

Чтобы сконцентрироваться на чём-то одном, придётся игнорировать всё остальное. Концентрация появляется только тогда, когда мы говорим да одному варианту и нет всем остальным. Другими словами, исключение это необходимое условие для концентрации внимания.
От того, что вы не делаете, зависит то, что вы можете сделать. Тим Феррис, писатель, оратор
Да, безусловно, правильная организация рабочего места повышает продуктивность и для ЛТ это критически важно, на мой взгляд. Я никогда не умел применять это на практике и не понимал ценности этих выводов, возможно бы и не понял, если бы не увидел шкаф.

3. Семя


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



Да, так было бы удобнее, но, когда первых пыл поутих, я начал трезво оценивать ситуацию. Для ЛТ этот выход не подходил: в нём была масса недостатков от ненадёжного крепления девайсов и кабель-менеджмента до отсутствия солидности.

Точка опоры


Порыскав в интернете, я не нашёл идеального варианта, который бы устроил меня по всем параметрам, и решил реализовать его самостоятельно.

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



Первый вариант мне показался близким к идеальному: он был прост, эстетичен и достаточно удобен. У него был выход под провод, что отчасти решало проблему кабель-менеджмента. Второй вариант я решил использовать для других, более объемных девайсов, т.к. он был в одной стилистике и прекрасно держал планшеты. Другие подставки для них были слишком громоздкими.



4. Первичный расчёт


И вот наконец в голове собралась общая картина я снял все замеры и приступил к исполнению своей задумки. Первая вылазка в Бауцентр за досками, чертежи, визг дрели, скрип сверла, рвущего деревянную стружку и вот уже что-то начало вырисовываться.



Всего в ЛТ 19 действующих девайсов + 6 планшетов, а на полку вмещалось всего четыре подставки с телефонами и это была первая проблема, которая решилась вариативностью крепления: если раньше полки крепились с двух сторон, то теперь они крепятся только с нижней, тем самым вмещая пять подставок на одну полку.

Для того чтобы покрыть весь набор девайсов было решено сделать пять полок:

  1. Верхняя полка под планшеты
  2. Полка для топ-iPhone
  3. Полка для топ-Android
  4. По убыванию новизны Android
  5. По остаточному принципу

5. Сложности в студию!


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

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

Макет это картонка, которая накладывается на деревянную доску, а на картонке равноудаленная точка. Через эту точку просверливается центр будущей окружности и пером в дальнейшем делается окружность, которая и надевается на трубу. Звучит сложно, поэтому вот картинка для понимания.



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

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

Подставки выглядели эстетично, поэтому не хотелось портить их саморезом, термоклей выглядел нелепо и оставлял большие следы, а вот качественный и крепкий двусторонний профессиональный скотч 3М от наших любимых ЧИП и ДИП был самое-то.


Скотч намертво крепит подставки и при этом скрыт от глаз. Супер.



Удобного расположения девайсов на полках для моей цели было недостаточно (это слишком просто), поэтому идея о подсветке девайсов нашла сама себя.

6. Апгрейды


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



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

Далее необходимо было просверлить три дырки в задней стенке каждой полки, да так, чтобы их не было видно и через них проходила охапка проводов.

Две по краям и одна посередине, для отвода проводов от хаба. Сверлил на каждой полке, с учётом возможной смены положения хаба.

Но помимо этого, были и еще проблемы состояние проводов. О да, провода

На старых крыльях новый самолет пролетает недолго


Разве можно было оставлять в шкафу такое?


У всякой проблемы всегда есть решение простое, удобное и, конечно, ошибочное. Генри Луис Менкен
Между решением и проблемой настолько тонкая грань, что можно их приравнять. Что для одной проблемы решение, то основание для другой и так до бесконечности. Надежда лишь на то, что последующая будет меньше предыдущей.

На вышеописанную проблему мне пришла давняя, классная идея магнитных проводов, которыми пользуюсь и по сей день дома. Плюс магнитных проводов в их универсальности и унификации. Они состоят из двух частей: провод + наконечник.



Наконечник бывает трёх типов под каждый разъем: micro, type-c и lighting. Он вставляется в девайс и находится там постоянно, а провод при поднесении к наконечнику примагничивается и держится таким образом продлевается срок службы разъёмов. К тому же девайсы достаточно удобно ставить на зарядку. Выглядит это как-то так.



Выбор был определён, оставалось подсчитать, утвердить, согласовать и, собственно, заказать.
После одобрения я заказал 26 проводов с наконечниками (брал с запасом) и приступил к следующему этапу.

Предметная визуализация залог минимизации ошибок


Фактическая смена шкафа это предпосылка к перераспределению проводов между девайсами и изменению кабель-менеджмента.
Хороший чертёж половина решения(с)
Мне необходимо было минимизировать риски с нехваткой длины провода, т.к. все зарядные провода были длиной метр и рассчитать расположение хабов так, чтобы провода от них дотягивались до всех девайсов.

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



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

Посылка с проводами или чемодан без ручки


Спустя некоторое время пришла заветная посылка. Заказывал я на Aliexpress у официального представителя Floveme, но и тут были свои риски. Несмотря на положительные отзывы и моё доверие к бренду, продавец прислал всё, кроме 15 lighting-наконечников. Жажда денег, обман или случайная ошибка? Непонятно, но паника появилась определенно.

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

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

Я отспорил у продавца часть денег за отсутствие наконечников и перезаказал недостающие у него же под другим аккаунтом на другое имя. И через полторы недели они меня уже ждали в отделении Почты. Проблема решена, ура!

7. Бирки


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

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



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



8. Совершенство, выводы и стратегия развития


На данном этапе я совершил то, что задумал: шкаф прекрасно вписался в уголок LT.

Отец и дитя



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

Раскрою секрет второго этапа разработки, о котором задумываюсь: а что, если у каждого сотрудника будет свой уникальный id на бейджике, а на шкафу планшет с простеньким приложением, подключенным к базе данных? И каждый раз, когда сотрудник захочет взять девайс, ему будет нужно поднести бейджик к сканеру rfid-меток.

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

Любая проблема решабельна, если верить в неё и отдаваться полностью. Всегда приятно внести вклад в общее дело и улучшить какой-то процесс. Я думаю, что в ЛТ появился ещё один повод для гордости.
Подробнее..

Топ-11 лучших систем управления тестированием 2020

07.10.2020 20:16:52 | Автор: admin
Каждый проект уникален и у каждой команды свои запросы. Однако всех нас объединяет желание работать с качественными инструментами, которые экономят время и позволяют QA-специалистам тестировать качественнее и быстрее, в идеале чтобы TMS могла в автотесты.

Мы вновь проанализировали проверенные временем и новые системы управления тестированием, которые сейчас популярны на рынке. Выбрали функции, которые должны быть в Test Management System нашей мечты, сравнили возможности продуктов и изучили отзывы пользователей. Делимся списком инструментов, один из которых точно подойдёт вашей команде.

Здесь нет рейтинга, у каждого инструмента есть свои преимущества и недостатки. В основном инструменты тест-менеджмента платные, однако у каждой из них есть бесплатная пробная версия.

image

Что мы хотим от удобной Test Management System?


Пользователь TMS ожидает увидеть следующее:

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

Зачем нужна TMS?


Решить задачу создания единой TMS для работы со всей документацией проекта можно несколькими способами:

  1. Самый дешёвый способ не заморачиваться и выбрать Google Docs для матрицы трассируемости, а дефекты вести в open-source баг-трекере.
  2. Другой способ использовать одну из популярных TMS-ок, интегрированную с баг-трекером компании.
  3. Next-level способ выбрать Test Management System, исходя из специфики проектов, объемов задач, типов документации и используемых видов тестирования.

Очень важно подойти к вопросу выбора TMS ответственно, ведь для компании цена ошибки может оказаться высокой.

Популярные системы управления тестированием на 2020 г


  • ALM Octane
  • Test IT
  • TestRail
  • Zephyr
  • TM4J
  • Qase
  • PractiTest
  • Testuff
  • Azure
  • MTM TFS
  • Kualitee

Рассмотрим выбранные инструменты подробнее:

1. ALM Octane


ALM Octane долгожитель среди систем управления и жизненным циклом продукта, и его тестировании. Инструмент позволяет осуществлять планирование, создание, тестирование и контроль на всех этапах разработки. Сложен в первоначальном освоении, но незаменим для компании крупной руки, где особое внимание уделяется деталям производства. Поддержана функциональность общих шагов. Работа с автоматизированными тестами. Фактические время прохождения для каждого тестового сценария. Реализована функциональность вебхуков.
Присутствует внутренний баг-трекер. Удобная система конструирования отчетов.

Именно потому, что продукт уже обкатан, в интернете есть великое множество мануалов и видеогайдов по настройке и использованию.

image

Возможности:

  • Общий доступ к библиотекам требований и ресурсов
  • Подробные сведения о коде, тестировании, управлении рисками и их оценке, а также о соответствии требованиям
  • Быстрый доступ к показателям, например к данным о не устранённых дефектах
  • Быстрая настройка лабораторной среды для устранения ошибок конфигурации в средах Agile
  • Работа с автоматизированными тестами
  • Вебхуки
  • Удобная система отчетов
  • Создание требований и отслеживание их выполнения на всех этапах жизненного цикла приложения
  • Аналитика на любой вкус и цвет: гибко настраиваемые отчёты
  • Интеграция с 50+ инструментами

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

2. Test IT


Test IT TMS, которую создают тестировщики для тестировщиков. Этот инструмент отличает продуманный и понятный интерфейс. Внутри системы можно создавать проекты и вести для каждого структурированную библиотеку тестовых случаев и чек-листов, часто повторяющиеся операции выделяются в общие шаги. Инструмент гибкий в каждом проекте создаются дополнительные пользовательские атрибуты/конфигурации, распределяются проектные роли и права, что упрощает настройку TMS под процессы компании. Test IT помогает руководителям групп тестирования равномерно распределять нагрузку между тестировщиками и контролировать исполнение работ с помощью пользовательских запросов и отчётов. Также в рамках самой системы есть возможность общаться с коллегами, не используя сторонние мессенджеры.

Разработчики приложения уделяют большое внимание автоматизированному тестированию, каждый тестовый случай в библиотеке тестов можно линковать с автотестами по API. Правильно настроенная интеграция с автотестами позволяет следить за прогонами и их результатами прямо из TMS в режиме реального времени. Вы сможете видеть, какие автоматические тесты в процессе выполнения, анализировать их результаты и просматривать исходный код прямо из Test IT. При необходимости можно создать тест-ран вне системы и заполнить его своими автотестами без линка с тестовыми сценариями.

image

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

Возможности:

  • Управление тест-планами, тест-кейсами и чек-листами
  • Общие шаги для повторяющихся действий
  • Создание пользовательских атрибутов/конфигураций
  • Автоматическое распределение тестов на QA инженеров
  • Интеграция автоматических тестов с помощью API
  • Создание тест-ранов вне системы с дальнейшим управлением состояния
  • Аналитика как по автоматическим, так и по ручным тестам
  • Внутренний чат и вебхуки во внешние системы
  • Ролевая модель и персонализация
  • Геймификация
  • Двусторонняя интеграция с JIRA
  • Расширенная функциональность API
  • Импорт из других систем управления тестированием

Бесплатная пробная версия: Открытая демо-версия на сайте
Ссылка на скачивание

3. TestRail


Это программное обеспечение удобно как для команд QA, так и для разработки. План тестирования можно выстроить как по сценарию гибкой методологии, так и для более традиционного подхода. Инструмент позволяет получить представление о ходе тестирования в реальном времени. Вы можете строить конфигурированные отчеты по необходимым вам метрикам. В новых версиях появилась интеграция с Assembla. Так же была поддержана функциональность внутреннего чата и оповещений во внешнюю систему.

image

Помимо возможности разложения своих тестовых сценариев по тест-ранам с их дальнейшим помещением в тест-планы, вы можете использовать такую сущность как Milestone, которая позволит удобно настроить процесс прохождения тестирования.

Можно настроить типизации проекта для ведения в нем тестовой документации.

Возможности:

  • Отслеживание состояния и результатов отдельного теста
  • Сравнение результатов нескольких тестов, конфигураций и этапов
  • Типизация проектов для ведения тестовой документации
  • Внутренний чат и оповещения во внешнюю систему
  • Отслеживание рабочей нагрузки команды для корректировки задач и ресурсов
  • Развёрнутые отчёты и метрики
  • Широкие возможности настройки, облачные или локальные варианты установки
  • Интеграция с JIRA, Redmine, YouTrack, GitHub, Jenkins, Selenium и Visual Studio
  • Удобный REST API

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

4. Zephyr


Zephyr это плагин для всем известной JIRA, который интегрирует тестирование в проектный цикл, позволяя вам отслеживать качество программного обеспечения и принимать решения в стиле go / no-go. В новых версиях была поддержана работа с автоматизированными тестами.

image

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

Возможности:

  • Ссылка на user-stories, задачи, требования, дефекты
  • Конфигурации деплоя: в облаке, на сервере, в дата-центре
  • Расширенная информация на дашбордах аналитики и DevOps
  • Интеграция с JIRA, Confluence, Selenium, Jenkins и Bamboo
  • Автоматизированные тесты
  • Создание пользовательских атрибутов
  • Понятная система отчетов.

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

5. TM4J


TM4J он же Adaptavist это приложение для управления тестированием в JIRA, позволяет вести тестовую документацию в JIRA. Линкование тестовых сценариев и issue непосредственно в JIRA. Поддержана работа с автоматизированными тестами. Возможность объединения повторяющихся шагов в общий шаг.

image

Возможности:

  • Линкование тестовых сценариев и issue не выходя из JIRA
  • Работа с автоматизированными тестами
  • Внутренний багтрекер
  • Понятная система отчетов
  • Использование общего шага
  • Фактическое время прохождения теста
  • Экспорт данных в Excel

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

6. Qase


Qase это облачная TMS, которая поможет вашей команде повысить производительность и организовать удобный флоу тестирования программного обеспечения. Поддержана функциональность объединения постоянно повторяющихся действий в общий шаг, импорт данных из других TMS. Управление ролями и разрешениями для пользователей системы. В новой версии была доработана система отчетов.

image

Возможности:

  • Тестовый репозиторий: выстраивание тестов в логические группы
  • Составление шагов для кейсов, установка приоритета и серьёзности
  • Запуск тестовых прогонов с трекингом времени по каждому тест
  • Хранение документации по проекту
  • Автоматическое заведение дефектов в интегрированные трекеры
  • Интеграция с JIRA, Redmine, YouTrack и Slack
  • Объединение результатов автотестов с REST API

Бесплатно для небольших компаний
Ссылка на скачивание

7. PractiTest


PractiTest это комплексное средство управления тестами. Оно дает полную картину процесса тестирования и более глубокое понимание результатов тестирования. Этот инструмент поможет организовать тест-сьюты в соответствии с вашими циклами и спринтами. Тестовые наборы можно формировать по различным критериям, таким как компоненты, версии или типы. Тул заточен на Agile-тестирование, регрессионное тестирование, тестирование микросервисов и DevOps.

image

В новых версиях была доработана функциональность работы с автоматизированными тестами.

В техподдержке работают обученные QA-сотрудники, которые могут быстро понять вашу проблему.

Возможности:

  • Лёгкое добавление тестов новых фич в регрессионное тестирование
  • Группировка тестов на основе микросервисов, которые они охватывают, даже кросс-сервисные
  • Различное отображение информации для разных групп пользователей
  • Дашборды в реальном времени показывают состояние тестов, прогонов на этапах разработки и при деплое на прод
  • Интеграция с JIRA, Redmine, Jenkins, GitLab и Slack

Бесплатная пробная версия: 14 дней
Ссылка на скачивание

8. Testuff


Команда Testuff делает действительно удобный инструмент, данная TMS старается объединить в себе все методы тестирования, начиная от waterfall model и заканчивая black box testing.
Разработчики Testuff отдельно выделили свой продукт как единственную TMS, которую можно использовать на любом девайсе: смартфоны, планшеты и т.д

image

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

Возможности:

  • Планирование тестов
  • Интуитивный drag-n-drop интерфейс
  • Наглядные отчёты с подробными графиками
  • Два способа интеграции со сторонними инструментами баг-трекинга
  • Возможность тестировать с любого девайса

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

9. Azure DevOps Server


Это мощный инструмент работы с тестами и автотестами, за счет своей комплексности вы можете настроить своё рабочее пространство, как вам необходимо. Работайте напрямую со своими CI/CD сервисами, интегрируйте свои репозитории прямиком в Azure, ведите тестовую документацию по спринтам, которые будете раскладывать по бордам, делайте максимально детальные отчеты по вашей тестовой документации и результатам её прохождения.

image

Отдельно стоит упомянуть возможность интеграции с IDE от компании Microsoft, вы можете редактировать и настраивать свой код прямиком через Azure и интегрироваться со всевозможными системами от компании Microsoft.

Возможности:

  • Интеграция с любым продуктом компании Microsoft
  • Нативный интерфейс
  • Интеграция с любым CI/CD
  • Ведение удобных Dashboards
  • Работа с автотестами
  • Пользовательские атрибуты

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

10. MTM TFS


Team Foundation Server (TFS) комплексное решение от Microsoft, которое включает в себя систему управления версиями, сбор данных, построение отчетов, отслеживание статусов и изменений по проекту.

Microsoft Test Manager часть этого продукта и требует установки Visual Studio. Такое сочетание дает возможность связать задачи, которые поставлены перед тестировщиком, с заведенными дефектами и отчетами о затраченном на работу времени.

image

Планы и результаты тестирования сохраняются на сервере Team Foundation Server.
МТМ включает в себя тест-план, тест-кейс и конфигурации.

Сам TFS является проприетарным ПО, лицензия коммерческая. Работает на трех уровнях: клиентский уровень, прикладной уровень и уровень данных, в зависимости от чего возможна работа или через web, или через десктоп-приложение. МТМ работает только на прикладном уровне, поэтому требуется установка на сервер (если сервер удаленный, работа проводится через VPN).

Возможности:

  • Исследовательское тестирование
  • Планирование и выполнение ручных тестов
  • Кроссплатформенные конфигурации тестов (разные версии одного теста для разных платформ/релизов)
  • Диагностика прохождения теста (логи, видео и т. п.)
  • Импорт-экспорт тестов
  • Межпроектный импорт-экспорт тестов
  • Запись и воспроизведение ручных тестов (рекордер)
  • Автоматизация тестов

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

11. Kualitee


Kualitee продукт Kualitatem, компании по тестированию программного обеспечения и информационной безопасности, специализирующейся на обеспечении безошибочной работы приложений повсюду.

image

Kualitee предлагает функции управления проектами, управления тестированием, управления дефектами с интеграцией с баг-трекерами. Гибкая система пользовательских атрибутов позволяет очень точно настроить необходимое рабочее пространство. Дополнительно есть возможность глубокой настройки профилей пользователя и его прав доступа.

Возможности:

  • Управление проектами
  • Управление дефектами
  • Управление тестовой документацией
  • Персональная панель инструментов
  • Продуманная настройка пользователей

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

Понравился пост? Не забудьте поделиться им!
И помните, только тестировщик стоит между багами и клиентом! :)
Подробнее..

Mind Map в помощь тестировщику

29.01.2021 00:15:15 | Автор: admin

Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. устоявшегося русскоязычного термина пока нет.
Как, зачем, когда и надо ли?

Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.

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

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

Когда (если) структура понятна, можно переходить к электронному варианту.

Интеллект-карта визуализирует структуру связей!

Этот важный момент столь очевиден, что начинающие иногда его упускают, углубляясь в дальнейшие нюансы. И тогда может случиться конфликт (якобы).
Почему на одних курсах учат прорисовать на ассоциативных картах Логику и Интерфейс, но нельзя указывать действия:

А на других призывают рисовать действия-глаголы, но ни в коем случае не Интерфейс:

Какая точка зрения верна?

Обе!
Противоречие только кажущееся, к этому вопросу мы вернемся позже.

Для начала нарисуем карту связей для ситуации бытовой посещение Торгового центра.

Декомпозируем верхнеуровневый Торговый центр до отделов которые нужно посетить.

Декомпозиция до отделовДекомпозиция до отделов

Теперь добавляем цель посещения (декомпозируем до товарных позиций, которые предстоит купить).

Декомпозиция до товарных позицийДекомпозиция до товарных позиций

А теперь смотрим на симпатичную карту и честно отвечаем на два вопроса:

Она вам поможет в ТЦ?

Стали бы рисовать такую для себя?

Полагаю что для 99,99% это избыточная красивая картинка для отчета не несущая реальной пользы.
В реальной жизни вы воспользуетесь максимум списком нужных товаров, сгруппированным по отделам. Потому что все эти связи у вас уже давно прописаны в виде готовых шаблонов, нет необходимости их визуализировать, лишние картинки вас будут только сбивать.

Так что немного тормозим и хорошо запоминаем:

визуализация призвана помогать, не стоит рисовать картинки ради картинок.

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

Декомпозиция до базовых действий (индивидуальная юзер стори)Декомпозиция до базовых действий (индивидуальная юзер стори)

И запоминаем второе правило:

Имеет значение: вы готовите рабочие документы для себя или для команды. Во втором случае учитывайте уровень подготовки/знаний о продукте тех кто будет работать с этими документами.

А если надо протестировать весь ТЦ?
Очевидно, что вносить все товарные позиции в карту совсем не вариант.
Здесь нужен уже другой подход.
Предположим, вам на проверку достался Цветочный павильон и у вас на руках есть макеты как это должно выглядеть. Нарисуем карту Интерфейса, она поможет проверить GUI, убедившись, что ничего не упущено и все соответствует требованиям.

ИнтерфейсИнтерфейс

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

С GUI разобрались, но Логику (прописанную в спецификации) нам тоже надо проверить.
В этом случае первый шаг декомпозиции будет по типу объектов (либо по зонам) с которыми взаимодействует пользователь.
Второй шаг декомпозиции: либо действия возможные с этими объектами (или в этой зоне), либо следующий уровень элементов для взаимодействия.

ЛогикаЛогика

А еслиспецификации нет или она представлена как небольшие юзер-стори?
Тогда удобно использовать карту сценариев, начав декомпозицию с тех самых глаголов, продолжив детализацией конкретных действий.

Карта сценариев / юзер сториКарта сценариев / юзер стори

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

И, возвращаясь в начало публикации: наставники, уточняячто должно присутствовать на карте, а что нет, озвучивают требования не к майнд-карте как таковой, а применительно к конкретной ситуации.

В первом случае это работа по прописанному подробному ТЗ, где важно проверить нюансы содержащиеся в спецификации к конкретному модулю кроссплатформеного сервиса, здесь важно проверить на соответствие спецификации и GUI и логику. Во втором случае проверка сайта без документации, где удобно оперировать действиями пользователя.

Контекст определяет подходы к тестированию и содержание конкретной интеллект-карты

И, как следствие, правы оба наставника.

Если говорить про ограничения, пожалуй надо упомянуть и про Карту (диаграмму) состояний и переходов (State & Transition).
Это конкретная техника тест-дизайна!
Не путайте ее с Интеллект-картами, невзирая на то, что Карту состояний вполне можно отрисовать в том же XMind (либо другой программе которой вы пользуетесь).

В карте состояний и переходов мы отслеживаем состояние одного объекта (!!!) в рамках одного процесса по шагам переходов.
В оригинале ("A Practitioner's Guide to Software Test Design" Lee Copeland) карта начинается с точки и ей же заканчивается.
В моем примере вместо начальной точки (вход) используется верхнеуровневая плашка с названием объекта Заказ букета, анализируем не букет, а именно заказ, прописывая его состояние, обязательно указывая действие на линии перехода. Постоянно задавая себе вопрос а что если. Это позволит не пропустить проверку сценариев передумал покупать, не хватило денег, не буду оплачивать и обнаружил брак, хочу вернуть.

НЕ путать с Картой состояний и переходов (State&Transition)НЕ путать с Картой состояний и переходов (State&Transition)

Возвращаемся к Mind map.

Интеллект-карты в тестировании бывают большими и подробными, такие я называючтоб не забыть.
Вот хороший пример мнемоник мобильного тестирования I SLICED UP FUN

и LONG FUN CUP

Хотите еще больше?
Смотрите шикарную карту Тестирование новой фичи от Катерины Спринсян из Badoo (публикацию читать! там же можно посмотреть карту "ближе")

Интеллект-карта также может быть и последовательной, применимо, например, при составлении тест-плана

С другой стороны, небольшие рабочие Интеллект-карты бывает полезно использовать для решения каких-то конкретных небольших задач. Особенно если у вас доминирует визуальный канал восприятия.

Для примера можно посмотреть вот здесь я писала пару задач по тест-дизайну для начинающих, с объяснениями и вариантами решений, один из вариантов Интеллект-карта.
В статью скрин не ставлю, чтоб не спойлерить ответы по конкретным цветочкам из все того же цветочного павильона ).

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

Говорят даже что работа с картами положительно сказывается на мыслительных процессах :)


Ну и немного ссылок:
.

Mind Mapping, или как заставить свой мозг работать лучше http://personeltest.ru/aways/habr.com/ru/company/devexpress/blog/291028/

Вебинар для Аналитиков от Натальи Руколь, о пользе MindMap https://www.youtube.com/watch?v=-kPdHMBz-so

А еще карты можно рисовать фломастерами. Состояния и переходы от Натальи Руколь https://www.youtube.com/watch?v=8H9HgjrwQHA

Как нарисовать карту приложения http://okiseleva.blogspot.com/2020/01/mind-map.html

Mind map вместо тест-кейса http://personeltest.ru/aways/habr.com/ru/company/badoo/blog/418353/

MindMaps для груминга задач http://personeltest.ru/aways/habr.com/ru/company/avito/blog/437952/

Ps Бонусом для начинающих две задачи по тест-дизайну с ответами, комментариям, вариантами решений. / Совет: вначале решаете сами, потом уже листаете на ответ. https://drive.google.com/file/d/1bUoYe6KeNO8bR3hhv-9ChuNPo0CwG1PX/view

Подробнее..

Перевод Как тестировали в 2020 технологии QA, общемировая статистика и тренды

19.03.2021 16:09:40 | Автор: admin

Тренды явление зыбкое, особенно если речь идет о разработке и тестировании программного обеспечения. В условиях быстрого развития трудно давать долгоидущие предсказания, поэтому важно хотя бы попытаться зафиксировать то, что происходит прямо сейчас. Это поможет определить, какие практики и методологии будут востребованы завтра. Опираясь на последние отчеты и опросы, рассказываем о наиболее актуальной статистике для вас и вашей команды QA.

Кому будет полезно: QA-лидам, тест-дизайнерам, тест-менеджерам, другим неравнодушным.

Тенденции инструментов тестирования

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

  • Согласно отчету PractiTest, 47% опрошенных тестировщиков используют инструменты для тестирования или обеспечения качества, такие как HP ALM, Team Foundation Server, PractiTest или Xray.

  • Согласно отчету JetBrains, 44% разработчиков регулярно используют баг-трекинговые инструменты, а 10% используют инструменты для проверки кода, такие как Collaborator, Review Assistant или CodeScene.

  • Самым распространенным баг-трекером остается Jira (68%). На втором месте GitHub Issues (26%).

В исследовании Russia Quality Report от Performance Lab за 2020 год говорится, что Jira в качестве TMS используют 73% российских компаний, 29% применяют Excel. Свои разработки в этой сфере применяют 13% опрошенных.

Что касается инструментов автоматизации, в совместно подготовленном исследовании QATestLab и Test IT говорится о том, что наиболее популярными для веб-тестирования являются Selenium и Apache JMeter, для API Postman.

К слову, у Test IT есть своя одноименная разработка система управления тестированием, в которой удобно вести документацию, а также создавать, запускать и анализировать ручные и автотесты. Ребята активно завоевывают российский и зарубежный рынок.

Тенденции методик тестирования

Быстрота выпуска продукта на рынок остается приоритетным критерием для оценки тестирования и одной из главных целей QA. Без методологии тестирование похоже на бесцельное блуждание в направлении релиза вы думаете, что куда-то идете, но не можете ни к чему приблизиться, потому что не можете отслеживать прогресс. Обратите внимание на нижеперечисленные тенденции методик тестирования ПО, чтобы выбрать подходящую.

  • Самая распространенная модель тестирования разработки программного обеспечения Agile или нечто похожее на Agile: 87% компаний использовали этот подход в 2019 году. Следующим шагом был DevOps с показателем 36% по сравнению с 28% в 2018 году (по данным PractiTest).

  • 82% компаний используют исследовательское тестирование в качестве методологии тестирования программного обеспечения, а 61% используют обычную проверку на основе сценариев (по данным PractiTest).

  • 78% организаций используют автоматизацию тестирования для функционального и регрессионного тестирования. Только 11% компаний не автоматизируют тесты (по данным PractiTest).

Рост популярности Agile в России, впрочем, не означает, что отечественные компании перестали сталкиваться с проблемами при внедрении в практику гибких методологий разработки. Согласно исследованию Russia Quality Report, чаще всего опрошенные указывали на невозможность применения автоматизации тестирования в необходимом объеме. Еще 17% респондентов отметили недостаточное понимание подходов Agile к тестированию.

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

Тенденции разработки ПО

Тестирование неотъемлемая часть жизненного цикла разработки ПО, поэтому тенденции разработки сильно влияют на тестирование. Понимание последних трендов разработки сильно помогает тестировщикам и руководителям QA сузить поиск ошибок. Если вы тестировщик, то приведенные ниже современные тенденции в разработке программного обеспечения помогут вам стать еще более эффективными.

  • Наиболее востребованным языком программирования на сегодняшний день является Rust (83,5%), за ним следует Python (73,1%). Разработчики больше всего не любили VBA (75,2%), а Python хочет изучить 25,7% опрошенных программистов (StackOverflow).

  • 25% сотрудников мировой IT-индустрии считают, что самая большая проблема, стоящая перед стартапами, приоритизировать разработку ПО (CodingSans).

  • Безопасность горячая тема: 69% респондентов отметили, что разработчики должны уметь писать безопасный код, но 68% считают, что добрая половина разработчиков не может самостоятельно обнаружить уязвимые части кода, которые обнаруживаются позже (GitHub).

Тенденции тестирования ПО

Известно, что процесс обеспечения качества включает в себя все от стратегического планирования и общения с разработчиками до документирования ошибок и других проблем; тем не менее главная часть QA это непосредственно тестирование.

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

  • Тестировщики часто выполняют работу за рамками своей роли в компании. 74% тестировщиков также пишут сценарии и делают автоматизацию, 57% также выполняют тесты управления данными (PractiTest).

  • В 35% компаний тестирование может проводить кто угодно, кроме тестировщиков, но 55% компаний все же используют профессиональных тестировщиков для подавляющего большинства тестов (PractiTest).

  • Web по-прежнему является самой популярной платформой для тестирования, 77% тестировщиков работали над web-тестированием в 2019 году. Это меньше, чем 79% в 2018 году (PractiTest).

Также важной частью QA-процесса является нагрузочное тестирование.

Тенденции QA-команд

Работать в команде всегда лучше, чем поодиночке вспомните притчу про веник и прутья. Четыре человека могут найти больше багов (и быстрее), чем один, и зачастую неважно, насколько этот один крут. Если вы являетесь QA-лидом, приведённые ниже тенденции возможно помогут вам в оптимизации вашей команды для достижения наилучших результатов.

  • Сложности: 44% тестирующих команд назвали сложным или невозможным участие в проектах своей компании в начале процесса, в то время как 43% командам трудно работать с данными и тестовыми средами (PractiTest).

  • Состав: 48% QA-команд состояли из 1-5 сотрудников, а 24% имели от 6 до 15 тестировщиков в 2019 году (PractiTest).

  • Задачи: по статистике, 63% задач команд по тестированию связаны с анализом требований, 55% задач связаны с ретроспективными встречами по проектам.

Карьерные тенденции в QA

Если вы читаете этот текст, скорее всего, вы работаете в области обеспечения качества, либо заинтересованы в этом. Если вы в поиске работы, вам следует кое о чем знать, прежде чем приступить к активным действиям. Как люди приходят в QA? Некоторые оказываются в профессии далеким от привычного способом.

  • Только 18% тестировщиков планировали стать тестировщиками ПО и изучали процессы. 24% стали тестировщиками случайно (PractiTest).

  • 65% получили знания о тестировании ПО в процессе самого тестирования. 58% читали книги по тестированию, а 44% закончили курсы и получили профильные сертификаты (PractiTest).

  • 75% отметили важность коммуникативных навыков, 63% назвали необходимым умение писать тестовые сценарии и умение автоматизировать тесты (PractiTest).

Тенденции дефектов ПО

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

  • Баг-репорты являются наиболее распространенной тестовой документацией, используемой компаниями 79% пользователей отмечают их использование (PractiTest).

  • 76% тестировщиков использовали баг-трекеры, такие как Jira Bugzilla или Redmine, что делает их наиболее распространенным инструментом управления тестированием. Следующим по популярности инструментом был Agile Workflow tools (59%) (PractiTest).

  • Наиболее распространенной ошибкой на проде было выкатывание непроверенного или сломанного кода более чем на 60%. Второй наиболее распространенной ошибкой была удаленная база данных (HackerRank).

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

Другие тенденции QA

Границы между тем, где заканчивается разработка и начинается тестирование, зачастую размыты. Если вы достигли в своих поисках того плана по обеспечению качества программного продукта, считайте, вам очень повезло. Сравните общемировые тенденции QA с процессами в вашей компании.

  • В 2019 году 36% тестировщиков были подотчетны PM, по сравнению с 43% в 2018. 34% тестировщиков отчитывались перед руководителем отдела разработки (PractiTest).

  • 73% разработчиков заявили. что научились программированию самостоятельно, чуть меньшее количество училось разработке на курсах или в университете (69%) (HackerRank).

  • На 100 тыс. человек приходится 5,2 тестировщиков. В Ирландии самый высокий процент тестировщиков на душу населения 61,2 на 100 тыс. человек. Далее следуют США и Канада, затем в списке Израиль (QualiTest Group).

Согласно исследованию Russia Quality Report, в России большинство работодателей не считает, что профильное образование в сфере IT или дополнительные сертификаты так уж необходимы тестировщику. Значение придается наличию у соискателя опыта работы (в среднем - 1-3 года) и таким личным качествам, как внимательность, ответственность и дотошность.

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

Помните, баги всегда прячутся в самых неожиданных местах. Удачи!

Перевод статьи

Автор: Nuala Turner

Также при подготовке использовался источник RQR2020 и исследование QATestLab и Test IT

Подробнее..

Полезные функции DevTools для тестировщиков

21.05.2021 18:18:17 | Автор: admin

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование - я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков).

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией :), решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

P.S.: Очередность пунктов в списке не говорит об их важности.

  1. Эмуляция android и ios, подключение android при отладке.

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

    Второй подпункт позволяет без всяких эмуляторов отследить все запросы и поведение Вашего продукта на устройствах android, просто подключив его к компьютеру и произведя небольшое количество манипуляций. Также плюс этого способа заключается в том, что можно настроить доступ к локальным серверам через такой тип подключения.

  2. Переопределение геолокации и подмена User-Agent.

    Продолжим рассматривать возможности DevTools для мобильных устройств. В вышеуказанных двух пунктах говорится о возможности изменять (подменять) геолокацию нахождения устройства и параметры юзер агента. Думаю, что многим тестировщикам частенько приходится воспроизводить какие-либо баги, которые были выловлены клиентами продукта не имея на то соответствующих технических возможностей. Подмена User-Agent поможет воспроизвести тот или иной баг, который был воспроизведен из какой-либо версии браузера или ОС. Закончив тестирование, никогда не забывайте возвращать данные User-Agent в исходное положение.

    Подмена User-AgentПодмена User-Agent
  3. Определение JS пути к строке.

    Этот пункт будет больше интересен тем, кто занимается автоматизацией тестирования. Скопировав полный путь к определенной строке в формате JS, можно ссылаться на него в автоматизированном тесте. Безусловно, данный способ не самый популярный для автоматизаторов, потому что этот путь может часто меняться, но на первых порах, когда еще не будет выработан скилл, помогающий с закрытыми глазами строить нужные селекторы для тестов, то эта возможность в DevTools может Вам помочь.

  4. Изменение стилей CSS у элементов.

    Считаю очень полезным умением для тестировщика представлять, как может выглядеть та или иная кнопка на сайте или какое-либо поле. В данном пункте рассматривается добавление фонового окраса для поля. Помимо этого, для элементов можно изменять и другие параметры (шрифт, размер, цвет и т.д.), для того чтобы можно было сразу указать разработчику или дизайнеру, как Вы видите этот элемент в контексте страницы либо, по просьбе заказчика изменить кнопку в live режиме.

    Пример изменения размера поля элементаПример изменения размера поля элемента
  5. Неиспользуемые CSS и Javascript в вёрстке.

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

    Отчет о покрытии кодаОтчет о покрытии кода
  6. Немного интересного про debug JavaScript.

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

  7. Сохранение изменений в Chrome при перезагрузке страницы.

    Такую возможность добавили в DevTools относительно недавно (с 65 версией). Она позволяет сохранять все изменения, которые были внесены в те же CSS стили, о которых я говорил выше. И при перезагрузке страницы они сохранятся, чтобы, например, была возможность посмотреть, как ведет себя измененная кнопка при загрузке страницы.

  8. Имитация медленного сетевого соединения.

    Эффект DevTools, который демонстрирует, как ведет себя страница при её загрузке на мобильных устройствах. Разработка, в 90% случаев, ведется при хороших условиях, связанных со скоростью интернета и его стабильностью, также как и тестирование, в связи с чем выловить баг, который воспроизводится у пользователя, становится возможным только полностью воспроизведя все окружение, в котором этот баг проявился. С появлением нового высокоскоростного интернета для мобильный устройств, возможно эта проблема будет не совсем актуальной, но пока этого не происходит. По крайней мере не во всех странах .

    Выбор скорости соединенияВыбор скорости соединения
  9. Настройка столбцов на вкладке Network.

    Тоже очень полезная вещь, которую я не смог найти ни в одной статье про DevTools для тестировщиков. Здесь можно настроить именно те столбцы, которые необходимы для анализа запросов на сайте в Вашем конкретном случае.

    Список возможных столбцов в NetworkСписок возможных столбцов в Network
  10. Снимки экрана при загрузке страницы.

    Думаю, этот пункт было бы логично связать с восьмым в этом списке. Тоже очень полезная вещь, как мне кажется, которая может помочь уловить плавающий баг, либо отследить ненормальное или нелогичное поведение во время загрузки страницы.

  11. Блокирование запросов.

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

  12. Все о cookies во вкладке applications.

    Cookies - очень важная вещь для анализа пользовательских сессий, соответственно, так как мы (тестировщики) воспроизводим пользовательские сценарии, нам необходимо знать, как можно улучшить тест-кейсы, используя работу с куками. В статье описаны все сценарии (поиск, удаление, изменение данных).

Бонусы:

Здесь я бы хотел оставить те ссылки (с небольшими пометками), которыми я лично еще не пользовался, но которые, по моему мнению, были бы полезны для изучения и последующего применении тестировщиком на практике:

Безусловно DevTools не ограничивается тем функционалом, который я описал выше. Есть очень интересные вкладки, которые называется performance и audit, но я не стал нагружать еще этой информацией, так как считаю это темой для отдельной статьи, если в целом это интересно будет прочитать и познакомиться с этими вкладками в DevTools.

Всем спасибо за внимание!

Подробнее..

Из песочницы О чем поговорить на собеседовании с выпускником онлайн-курсов по тестированию

03.08.2020 00:21:10 | Автор: admin

Немного о себе


Всем привет, меня зовут Лилия, я QA lead и преподаватель, последние лет 10 читаю курсы по тестированию в, так сказать, ведущих компаниях отрасли. И конечно, мне очень интересно, как преподают мои коллеги на онлайн-курсах и какие специалисты получаются в результате ведь собеседовать джунов, в том числе и после курсов, тоже приходится частенько.

Об этой статье


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

А статья будет о том, что можно спросить на собеседовании у выпускника онлайн-курсов для тестировщиков, как анализировать ответы и почему. Статья может быть интересна как техническим интервьюерам, так и HR. Вопросы технического и нетехнического собеседования намеренно не разделены ведь процесс найма в компании может быть устроен как угодно.
Итак, представим себе на минутку, что к вам на позицию стажера или джуна пришел соискатель с дипломом онлайн-курсов, но без опыта работы, и вы начинаете задавать вопросы

Вопрос: какова была продолжительность курсов?


Первый вариант ответа: две-три недели


Если вы получили такой вариант ответа, задайте соискателю пару простых теоретических вопросов. Ответил отлично, а теперь предложите практическое задание из повседневной жизни. Скорее всего, на этом этапе начнутся сложности, ведь за две-три недели можно выучить чуть-чуть теории, но вот с практикой обычно дело обстоит хуже.

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

Второй вариант ответа: 9 месяцев год


Уже интереснее. Обязательно спросите соискателя, что конкретно он изучал на курсах, если вдруг он забыл указать это в своем резюме. Годичные курсы обычно покрывают все, что есть и не учитывают специализацию, и на выходе получается этакий full-stack QA, который понемногу умеет и тест-кейзы писать, и автоматизацию, а еще чуток мобильное тестирование, и SQL немножко, и Git издалека видел, и WebUI, а еще английский, и на машинке, и вышивать. Пройдитесь по каждому пункту, используя тот же принцип: несколько теоретических вопросов, а после задачи из практической жизни. Идеально, если они будут напоминать реальные задачи того проекта, на который вы собеседуете вашего соискателя, и позволят применить вот это всего понемножку системно.

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

На самом деле вам нужен мидл, а студент снова поверил маркетологам и считает себя таковым, показывая сертификат годичных курсов?

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

Третий вариант ответа: 3-4 месяца


Не стоит бояться такой, казалось бы, небольшой продолжительности. В нашей практике чаще всего бывали курсы трехмесячные, но интенсивные. Чем же это лучше? спросите вы. Стайеров, готовых регулярно заниматься целый год без выходных, праздников, отпусков и прокрастинации среди представителей человеческой расы не так уж много. А вот собраться и позаниматься 3 месяца, посулив себе в конце ведро шоколада или трехдневный отрыв с друзьями смогут гораздо больше людей.

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

Стоит ли нанимать студента после трехмесячных курсов? спросите вы. Почему бы и нет. Если было достаточно практики, а знания подтверждены сданным экзаменом, а еще лучше тестовым собеседованием с экспертом. Во всяком случае, мы принимали на работу лучших студентов нашей школы и ни разу об этом не жалели: джуны приходили с горящим взором, готовые учиться, работать и развиваться.

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

Вопрос: Вы слушали запись лекций или занимались с преподавателем в реальном времени?


Первый вариант ответа: запись лекций


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

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

Если нет, читал ли студент дополнительные материалы, искал ли в интернете разъяснение непонятных терминов? (конечно, попросите привести несколько примеров, ведь социально значимый ответ в данном случае очевиден)

Если общаться было можно, то использовал ли студент эту возможность? Как часто? (ну, и примеры, разумеется).

Думаю, в данном случае излишним будет подчеркнуть, что внимание студента к деталям и желание прояснить непонятные места это прекрасные качества, необходимые каждому тестировщику.

Второй вариант ответа: лекции читал преподаватель в реальном времени


Очевидно, что для понимания материала такой вариант является более правильным. Однако для некоторых студентов прослушивание живой лекции может ничем не отличаться от просмотра видео, ведь они, как на скучной паре, спят или переписываются с другом по поводу весело проведенных выходных.

А значит, дополнительные вопросы тоже не помешают.

Как часто студент задавал вопросы во время лекции? (с примерами, разумеется)
Все ли было понятно из объяснений преподавателя? интересно, что ответ все понятно в 99% случаев вовсе не означает, что перед вами гений. Скорее, такой ответ говорит о том, что или курс выбран неправильно и он слишком прост для студента, или что студент просто невнимательно слушал лекции.

Читал ли студент дополнительные материалы, искал ли в интернете разъяснение непонятных терминов? независимо от способа подачи, чтение дополнительных материалов к лекции говорит о вдумчивости студента и желании разобраться во всем досконально.

Вопрос: как выглядела ваша домашняя работа?


Первый вариант ответа: задания на повторение материала или тесты


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

Дополнительные вопросы:


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

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

Второй вариант ответа: практические задания, жизненные ситуации


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

Какое практическое задание понравилось Вам больше всего? Почему? так вы сможете узнать, насколько ваш кандидат любит сложные задачи. Загорелись глаза, с увлечением рассказывает, как полночи гуглил и писал преподавателю или сокурсникам, уточняя непонятные места? Или говорит, что вот такую задачку решить было просто, поэтому и понравилось?

Ну, и конечно, предложите соискателю свой вариант практических задач. Без этого никак

Вопрос: был ли экзамен или дипломная работа? Что от вас требовалось?


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

Первый вариант ответа: экзамена или диплома не было


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

Второй вариант ответа: экзамен или диплом был


Что включать в экзамен и достаточно ли простого теста, который предлагают некоторые курсы? На наш придирчивый взгляд, экзамен или диплом должен максимально имитировать ситуацию, с которой столкнется незадачливый студент, когда сядет за настоящий рабочий стол. Давайте же дадим студентам на экзамене настоящий проект и настоящие требования к нему и сыграем роли тест-лида, бизнес-аналитика и заказчиков? Ну, разумеется, в том случае, если мы на курсах об этом рассказали. Такие жизненные случаи обязательно пойдут в зачет вашему гипотетическому соискателю ведь он не только способен заученно отвечать на теоретические вопросы, но и практики не испугается. Разумеется, такой вариант может и не встретиться в практической жизни, поэтому можно сымитировать ситуацию прямо на собеседовании, предложив будущему тестировщику проанализировать требование заказчика в том виде, как это принято в вашей компании, позадавать вопросы вам как ИО бизнес-аналитика или продакт овнера, после чего рассказать, как он собирается это протестировать и так далее словом, проверить, понимает ли соискатель, как ему предстоит работать. (Конечно, если время, отведенное на собеседование, позволяет это сделать).

Итоги


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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru