Заметки тестировщика. Страница 6
4336
@qanote
Авторский канал тестировщика, который ушел в сферу IT с образованием журналиста. Только откровенные заметки про работу в российской и американской компаниях.
-
Заметки тестировщика
Достаточно интересная статья на тему CI/CD. Плавно готовимся к раскрытию новой темы 🦥 https://habr.com/ru/company/otus/blog/515078/ Заметки тестировщика -
Заметки тестировщика
→ Тест: вы уже тестировщик или пока нет? 1️⃣ Тестировщик нашёл баг. Как можно сообщить команде о баге? а) Отправить начальству сообщение в телеграме с описанием бага. б) Написать отчёт — баг-репорт. в) Записать голосовое сообщение и рассказать все детали. 2️⃣ Баг вот такой: «Ожидаемый результат: Логотип Яндекс.Метро. При нажатии на слово «Метро» открывается страница Яндекс.Метро. Фактический результат: Открывается главная страница Яндекса.»Какой заголовок лучше подойдёт, чтобы описать дефект? а) Сломался логотип Яндекс.Метро. б) Не открывается страница Яндекс.Метро. в) При клике на слово «Метро» в логотипе не открывается страница Яндекс.Метро. г) Клик по слову «Метро» в логотипе ведёт на главную страницу Яндекса. 3️⃣ Что такое «окружение» в баг-репорте? а) Что находится вокруг пользователя, когда он заходит на сайт. б) Операционные системы, браузеры или версии приложений, в которых возникает ошибка. в) Тактика устранения багов, когда один баг окружают несколько тестировщиков. А вот и ответы: 1Б, 2Г, 3Б ️ ⭕️Если ошиблись — не переживайте. Познакомиться с основами тестирования можно в бесплатной вводной части базового курса по тестированию → https://practicum.yandex.ru/qa-engineer ✅Если всё правильно — похоже, у вас уже есть опыт! Углубить свои знания можно в полном курсе по тестированию → https://practicum.yandex.ru/qa-engineer -
Заметки тестировщика
🙇🏻♀️ Мой основной инструмент в работе. Поговорим о Jira. Материала было много, пришлось создать целую статью со встроенными ссылками на сторонние ресурсы. Надеюсь, мне удалось покрыть большую часть вопросов тех из вас, кто еще не знаком с этой системой. Содержание: 🔸Что такое Jira? 🔸Особенности системы 🔸Алгоритм работы 🔸Как устроена Jira? 🔹Интерфейс 🔹Задачи 🔹Типы задач 🔹Дорожная карта (расписание) 🔹Релизы 🔹Код и деплой 🔹Pages 🔹Дашборды 🔹Плагины 🔸Как создать задачу в Jira? 🔹Атрибуты задач 🔸Основные принципы повышения производительности в Jira 🔹Делите большие задачи на мелкие 🔹Комментируйте задачи 🔹Записывайте все выполненные действия 🔹Планируйте спринты 🔹Делайте записи на регулярной основе 🔸Стоимость Jira 🔸Аналоги Jira 🔹Trello 🔹Basecamp 🔹YouTrack 🔹ClickUp 🔸Вместо заключения https://teletype.in/@qanote/aboutjira Прошу поддержать пост реакциями ❤️ Заранее спасибо! Заметки тестировщика -
Реклама
-
Заметки тестировщика
Как я всегда говорю, четверг - почти пятница 😄 Завтра выхожу с больничного, но лечиться еще предстоит долго, увы. А пока хочу поделиться новостями автоматизации - 1-й тест готов, ура! Вы уже знаете, что я делаю только первые шаги в этом направлении, но вот, что-то потихоньку получается. В этом посте я описывала свой алгоритм простым языком, так что профессионалов автоматизации прошу не кидать камнями) 👉🏼 Про SSH-ключ 👉🏼 Про редакторы кода и PyCharm А теперь поговорим про Jira и что нам нужно знать об этом инструменте ⬇️ Заметки тестировщика -
Заметки тестировщика
И снова мем вспомнился) Эх, боль.. Ну и на этом сегодня квиз заканчивается, спасибо всем за участие! В ближайшее время постараюсь поубавить свой пыл с теорией 😅 И писать о чем-то более приземленном и наболевшем ❤️ Задать вопрос: @QaNoteBot Заметки тестировщика 
-
Заметки тестировщика
Примерно так проходит мой понедельник на больничном 😅 А вам я желаю приятного начала недели! 🙇🏻♀️ 👉🏼 Квиз устрою ближе к вечеру, надо много чего ещё разгрести -
Заметки тестировщика
Бэкенд, фронтенд или тестирование — что выбрать? В программировании данных много специальностей, в которых можно начать карьеру. Узнайте о них подробнее на вебинаре Яндекс Практикума. → Бесплатно, 31 августа в 19:00 О профессиях в формате дискуссии расскажут эксперты с опытом в сфере: ◾️ Полина Гуртовая, фронтенд разработчик в «Злые Марсиане» ◾️ Евгений Бартенев, python-разработчик в Яндекс Практикуме ◾️ Анастасия Степанова, QA-engineer ◾️ Елена Шлямова, менеджер реферального маркетинга на направлении программирования Вот что вы узнаете о каждой профессии: — как выбрать профессию по душе и не прогадать; — типичные ошибки людей, которые идут учиться в IT; — кто такой идеальный младший специалист и как им стать; — джуны/ мидлы/сеньоры — кто они и чем отличаются; — что происходит с рынком IT и как быть конкурентоспособны: советы от нанимающих разработчиков. Вы сможете задать спикерам ваши вопросы о смене профессии и старте карьеры. → Зарегистрироваться на вебинар 
-
Заметки тестировщика
Это прям про меня, когда пишу о личном опыте и мыслях 😅 Но очень уж соскучилась по этим темам. Со здоровьем лучше, так что подготовлю чего-нибудь интересненького. В комментариях недавно предложили написать про эмоциональное выгорание 🙇🏻♀️ ✍🏼 А какую тему хотели бы вы?❤️ Заметки тестировщика 
-
Заметки тестировщика
💠 Приемочное тестирование или Приемо-сдаточное испытание (Acceptance Testing) Мы уже говорили о нем) Это формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: 🖍определения, удовлетворяет ли система приемочным критериям 🖍вынесения решения заказчиком или другим уполномоченным лицом о приемке системы в эксплуатацию. Выполняется заказчиком или пользователем системы. Поиск дефектов не является целью. - Эксплуатационное тестирование в фазе приемочного проверяет насколько система пригодна для внедрения в конкретном операционном окружении. - Альфа-тестирование (часто используется как форма внутреннего приемочного тестирования перед проведением бета-тестирования) выполняется в стенах компании, которая разрабатывает программный продукт. Бета-тестирование выполняется заказчиком или пользователем на его оборудовании. Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения. Шаблон плана приемо-сдаточных испытаний от RUP можно скачать, кликнув по ссылке: RUP Product Acceptance Plan ‼️Завтра будет квиз по методологиям тестирования, описанной классификации и уровням‼️ Заметки тестировщика -
Заметки тестировщика
💠 Системное тестирование (System Testing) Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. Цель процесса тестирования - проверка, соответствует ли ПО установленным требованиям. Выполняется тестировщиками. Включает тестирование взаимодействие с операционной системой и системными ресурсами, разновидность тестирования методом черного ящика. Можно выделить два подхода к системному тестированию: ✳️ на базе требований (requirements based) Для каждого требования пишутся тест-кейсы, проверяющие выполнение данного требования. ✳️ на базе случаев использования (use case based) На основе представления о способах использования продукта создаются случаи использования системы (use cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест-кейсы, которые должны быть протестированы. Заметки тестировщика -
Заметки тестировщика
💠 Интеграционное тестирование (Integration Testing) проверяет взаимодействие между компонентами системы после проведения компонентного тестирования. Тестирование функциональных и нефункциональных характеристик программы, выполняемое для выявления дефектов в интерфейсах и взаимодействии между интегрированными компонентами. Выполняется разработчиками или тестировщиками. Подходы к интеграционному тестированию: ⬆️ Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули разрабатываемого уровня готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. ⬇️ Сверху вниз (Top Down Integration) Сначала тестируются все высокоуровневые модули и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз. 🔄 Большой взрыв ("Big Bang" Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, а затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест-кейсы и их результаты записаны неверно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования. Заметки тестировщика -
Заметки тестировщика
🙇🏻♀️ А теперь поговорим про уровни тестирования. Что же это такое? Тестирование на разных уровнях производится на протяжении всего жизненного цикла разработки и сопровождения ПО. Уровень тестирования определяет то, над чем проводятся тесты: над отдельным модулем, их группой или системой в целом. Проведение тестирования на всех уровнях системы - это залог успешной реализации и сдачи проекта. 💠 Компонентное или Модульное тестирование (Component or Unit Testing) проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится, вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило, исправляются в коде без формального их описания в багтрекинговой системе. Может выполняться разработчиком. Здесь могут быть использованы заглушки, эмуляторы. 🔀 Один из наиболее эффективных подходов к компонентному (модульному) тестированию - это подготовка автоматизированных тестов до начала разработки ПО. Это называется разработка от тестирования (test-driven development) или подход тестирования test first approach. Разница между компонентным и модульным тестированием По существу эти уровни тестирования представляют одно и то же, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном тестировании - конкретные значения. Заметки тестировщика -
Заметки тестировщика
🙇🏻♀️ Классификация тестирования Ну что ж, вот мы и вернулись к обещанной теме. И довольно сложной, т.к. единой полной классификации попросту нет. Но для старта отлично подойдет и по С.Куликову, кому интересно. В остальном я постаралась собрать все из нескольких источников и объединить в одну большую классификацию по видам тестирования. Квиз будет именно по ней. По целям: ▫️Функциональное: 📍тестирование заявленной функциональности 📍тестирование защищенности 📍тестирование установки (инсталляции) 📍тестирование целостности данных 📍тестирование графического пользовательского интерфейса 📍тестирование настройки и лицензирования ▫️Нефункциональное: 📍тестирование производительности 📍нагрузочное тестирование 📍стрессовое тестирование 📍тестирование стабильности/надежности 📍тестирование на отказ и восстановление 📍тестирование удобства использования 📍тестирование практичности 📍тестирование безопасности 📍тестирование масштабируемости 📍тестирование времени отклика 📍тестирование обеспеченности 📍конфигурационное тестирование 📍объемное тестирование 📍тестирование локализации, глобализации и интернационализации По хронологии выполнения: ▫️Комплексное ▫️Входной тест ▫️Основное ▫️Повторное ▫️Регрессионное ▫️Приемочное По степени подготовки к тестированию самим тестировщиком: ▫️Ad-hoc (cвободное или интуитивное тестирование, выполняется без подготовки к тестам, без определения ожидаемых результатов, проектирования тестовых сценариев) ▫️Тестирование по документации (формальное тестирование) По уровню планирования: ▫️Тестирование по тест-кейсам ▫️Exploratory (исследовательское тестирование, совмещенное с изучением продукта) По позитивности сценария: ▫️Позитивное ▫️Негативное По разработке тестовых сценариев: ▫️На основе требований ▫️По вариантам использования ▫️На основе модели По исполнению кода: ▫️Статическое 📍Статический анализ кода 📍Рецензирование исходного кода ▫️Динамическое По исполнителям тестирования: ▫️Альфа-тестирование (проверка ПО на поздней стадии разработки, проводится разработчиками или тестировщиками) ▫️Бета-тестирование (оценка ПО перед выходом на рынок в фокус-группе или добровольцами) По уровню тестирования: ▫️Модульное (компонентное) ▫️Интеграционное ▫️Системное ▫️Приемочное По знанию системы: ▫️Белый ящик ▫️Серый ящик ▫️Черный ящик По степени автоматизации: ▫️Ручное ▫️Полуавтоматизированное ▫️Автоматизированное По версии функционала: ▫️Тестирование новой функциональности ▫️Регрессионное тестирование По свойствам тестируемого объекта: ▫️функциональность ▫️производительность ▫️совместимость ▫️надежность ▫️удобство Тестирование, связанное с изменениями: ▫️регрессионное тестирование ▫️дымовое тестирование ▫️санитарное тестирование ▫️подтверждающее тестирование ▫️тестирование сборки ▫️повторное тестирование Прочие виды тестирования: ▫️Тестирование файлов cookie ▫️Тестирование потоков ▫️Эталонное тестирование ▫️Тестирование N+1 ▫️Тестировании интерфейса прикладного программирования ▫️Параллельное/многопользовательское тестирование ▫️Фаззинг тестирование ▫️Ramp тестирование ▫️Тестирование на переносимость ▫️Сквозное (E2E - End–to–End) тестирование ▫️Тестирование хранилищ данных (Data Warehouse) ▫️Тестирование на проникновение Заметки тестировщика -
Заметки тестировщика
👩🏻🏫 Вечер пятницы! Предлагаю на выходных вспомнить методологии разработки) А после повторим классификацию тестирования и сделаем еще один квиз 🙇🏻♀️ https://habr.com/ru/company/edison/blog/269789/ Заметки тестировщика -
Заметки тестировщика
⚪️ Часть 2 Один день из жизни тестировщика на удаленке в иностранной компании Всем привет! С вами Валерия 🙇🏼♀️ В прошлый раз я рассказала о том, как стала тестировщиком после 2-х лет работы в журналистике. А сейчас поделюсь, из чего строится мой рабочий день и работа в целом. Конечно, в каждой компании все устроено по-своему. На прошлом месте релиз продукта был каждую неделю. Документации и автоматизации как таковых не было (да и не нуждались в них). Гибкая методология разработки предполагала работу короткими спринтами, а все время команды отнимало планирование, развитие новых фич и работа с багами. А на текущем месте работы используется другая методология, продуктов - несколько, а релизы - раз в месяц. Из этого уже понятно, что команд много, причем из разных городов и стран. В моей идет упор на создание и актуализацию тестовой документации, а также ручное и автоматизированное тестирование. По большей части я занимаюсь именно документацией, здесь не заскучаешь: одних только тест-кейсов больше 5 000. 🕙 10:00 Просмотр почты и чатов, список задач на день и кофе - стандартные атрибуты рабочего утра. Исходя из еженедельных KPI внутри команды я понимаю, чему сегодня стоит уделить больше внимания. Весь личный и командный прогресс отмечается в Jira в виде целой системы wiki страниц. 🕚 11:00 Чуть позже начинается дейлик, в рамках которого обсуждаем, что сделано вчера и запланировано на сегодня. Помимо этого, у нас есть замечательная традиция - каждый день поздравлять друг друга с праздником. И неважно с каким - такая мелочь задает настроение и поддерживает приятную обстановку в коллективе 😏 🕚 11:20 Приступаю к работе. Отталкиваясь от намеченного плана, беру несколько старых тест-кейсов, чтобы актуализировать их. Это основная рутина, но дико необходимая. Именно по ним и будут писать автотесты. Нередко при обновлении тест-кейса возникают "затыки", когда не получается воспроизвести описанные шаги. А, значит, и актуализировать этот тест-кейс. Причинами могут быть: измененный функционал, обновленный дизайн, неправильные входные данные, недостаток/избыток информации в шагах, некорректные формулировки или упущение создателя теста. Да все, что угодно, особенно если продукт связан с облачными решениями. Порой только на поиск причины может уйти немало времени. 👉🏼 На первый взгляд актуализировать тест-кейс кажется простой задачей. Но представьте себе большую систему, например, Booking.com. В нее интегрированы различные услуги - выбор отеля, направления, фильтрация по стоимости, дате и времени заезда, удобствам и т.д. И чтобы разобраться в проблеме с тест-кейсом, придется еще найти человека, который знает, как работает этот функционал. 🕠 17:30 Еще сейчас изучаю автоматизацию. Недавно нашла курсы по Python на Stepik. Практикуюсь в двух местах - на курсе и в нашем проекте. Я взяла один тестовый сценарий в работу, так что открываю PyCharm и пытаюсь писать свою проверку. Нередко приходится выходить за рамки рабочего времени. 🕢 19:00 В конце рабочего дня фиксирую промежуточные данные по задачам. Все в той же Jira. Если необходимо - общаюсь с менеджером в Teams по возникшим вопросам. Как вы уже поняли, каждый мой день основан на рутине. Но в то же время каждый отдельно взятый тест - это целая история, которая не дает заскучать. А автоматизация позволяет развивать свой технологический стек и расти профессионально 👍🏻 -
Реклама
-
Заметки тестировщика
Ребята, всем доброе утро! Вышел пост на новую тему 🙇🏻♀️ поддержите, пожалуйста, реакциями ❤️ -
Заметки тестировщика
Надеюсь, этот небольшой квиз помог вам закрепить знания. Ну или восполнить пробелы) В любом случае, вы всегда можете вернуться к предыдущим постам при необходимости. А я пойду дальше лечиться и работать. Ведь главное - стремление 🐝 -
Заметки тестировщика
👉🏼 Преимущества и недостатки негативного тестирования ➕ Проявляет некорректную обработку ошибок Позволяет избежать сбоев, вызванных неправильной обработкой ошибок. ➕ Идентифицирует слабые места в безопасности Негативное тестирование позволяет гарантировать, что, например, клиент не получит персональный аккаунт в приложении с уровнем допуска, не предусмотренным его организацией. ➕ Поддерживает «чистоту баз данных» Базы данных будут в отличном состоянии, если в них только корректные данные. Негативное тестирование (почти) гарантирует, что там хранятся только корректные данные. ➖ Негативное тестирование может занимать много времени, и бывает достаточно дорогим процессом. 👉🏼 Почему некоторые тестировщики не любят негативное тестирование? Несмотря на то, что подход имеет преимущества, такое тестирование нравится не всем тестировщикам. Они избегают его, потому что считают, что другие методы позволяют добиться лучших результатов — и быстрее. А скорость разработки сейчас крайне важна. А некоторые тестировщики вообще смотрят на этот подход как на бесполезную трату времени и денег. И действуют только в рамках позитивного тестирования. Недостаточность скиллов и знаний о преимуществах такого подхода мешает применять его. А правда в том, что негативное тестирование ведет к высокому качеству софта. Такое тестирование по возможности должно внедряться в процессы QA потому, что: 📍Повышает ответственность в команде Команда становится ответственной, давая клиентам хорошо проверенный софт. Негативное тестирование в качестве дополнения к позитивному бывает незаменимо в повышении стабильности приложения. Невозможно полностью избежать ошибок, но вполне возможно минимизировать их, а негативное тестирование — путь к этому, достаточно прямой, и достаточно короткий. 📍Клиенты довольны Как ни банально звучит, негативное тестирование повысит конечное качество софта, что скажется на customer satisfaction. Особенно это будет заметно в кейсах онлайн-магазинов и вообще е-коммерции. Как мне кажется, в негативное тестирование можно и нужно вкладываться, невзирая на возросшие расходы. А вы как считаете? 😏 Позже устрою небольшой квиз на тему негативного тестирования (вопросы будут как по этим постам, так и по вашим знаниям в целом) ❤️ Задать свой вопрос в бот: @QaNoteBot Заметки тестировщика