Представьте, что тестирование программного обеспечения можно упростить? Проводить его без многочисленных обсуждений, вопросов, баг-репортов и метрик?
Пользователь
Готовим версионирование API в PHP-фреймворках: разбор способов и работа с организацией кода
Привет! Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше десяти лет, семь из которых пишу на PHP. За плечами десятки разных проектов: e-commerce, финтех, CRM, а недавно добавился и EdTech. Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе. Хочу поделиться, как избежать проблем, как всё структурировать и организовать.
Обсудим:
• Что такое API.
• Зачем версионировать API и нужно ли вообще.
• Какие способы версионирования существуют и как его организовать — и с точки зрения подходов, и с точки зрения кода.
• Разберёмся, когда избавляться от старой версии или как жить с легаси до конца существования проекта.
Тестовая документация: что учитывать при постановке эффективного процесса тестирования
В этой статье мы рассмотрим работу с тестовой документацией при постановке процесса тестирования программного обеспечения. Материал собран исходя из опыта работы на различных проектах и того, с какими сложностями приходилось сталкиваться. Но вначале хочу сделать краткое отступление, которое касается тестовой стратегии, поскольку перед началом разработки тестовых документов должны быть четко определены границы тестирования.
Введение в Postman
“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc
Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом "монстры" наконец-то падут перед тобой!
В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.
Как составить стратегию тестирования: версия настоящих инженеров
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
Мутационное тестирование
Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).
Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert
строки из тестов, или просто заменим их на assertSame(1, 1)
, то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.
Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?
Ответ на этот вопрос даёт мутационное тестирование.
Анна Бояркина, Miro (ранее RealtimeBoard): о продуктовом мышлении, культуре в командах, навыках будущего
Я поговорил с Анной Бояркиной, главой продукта в Miro (ранее известном как RealtimeBoard) — платформе для визуальной коллаборации. Это восьмое в серии интервью с мастерами своего дела о продуктовом подходе, изменении поведения и предпринимательстве.
Сквозное тестирование (end-to-end): что, зачем, почему
Как правильно (не) использовать тестировщиков
Как быть, когда вокруг вроде бы девопсы, аджайлы и скрамы, но разработка и тестирование по-прежнему не живут в одном пайплайне душа в душу?
Из-за того, что необходимо преодолевать эту стену и находить общий язык, мы даже создали конференцию Heisenbug, предназначенную одновременно для тестировщиков и разработчиков. А ещё мы проводим Java-конференции, и осенью Артём Ерошенко выступил там с докладом «Как правильно (не) использовать тестировщиков». На примере Java-проекта он поделился своей болью и рассказал, что считает нужным делать.
И теперь, в преддверии нового Heisenbug и нового JPoint (обе конференции пройдут в формате «офлайн + онлайн»), мы решили сделать хабрапост на основе его доклада. Дальше повествование от имени Артёма.
«Золотой стандарт» или что умеют современные Deception-решения: ловушки и приманки. Часть 1
"Золотой стандарт" или что умеют современные Deception-решения: ловушки и приманки. Часть 1
Идиоматичный Kotlin, набор хороших практик
Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.
Переезд из Java в Kotlin: как забрать коллекции с собой
В течение последних лет Kotlin становится всё более и более популярным. Многие начинают осваивать его, уже имея за плечами какой-то бэкграунд на Java, поэтому в данной статье мне хотелось бы привести сравнение кода на Java и на Kotlin. Чтобы наши примеры были более наглядными, рассмотрим различные операции над коллекциями, потому что без них не обходится ни одно приложение.
Что такое исследовательское тестирование?
И чем оно отличается от тестирования по сценариям (сценарного тестирования)
Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.
Исследовательское тестирование является мощным и приятным подходом к тестированию. В некоторых случаях оно может быть более продуктивным, чем привычное тестирование по сценариям. Я не встречал еще тестировщика, который бы не применял исследовательское тестирование, хотя бы на бессознательном уровне. Тем не менее, мало кто из нас подробно изучал этот подход, и он еще не так признан в нашей области. Пора нам прекратить его отрицание, и публично признать исследовательский подход, таким какой он есть: научным мышлением в режиме реального времени. Друзья, это классная вещь!
Выходим за рамки тестового покрытия
Зачем вы пишете автотесты для проекта? Надеюсь, для того, чтобы с их помощью найти дефекты. Написание тестов — не бесплатная штука, кто-то должен их разработать и поддерживать. Выполнение этой работы стоит недешево, поэтому вложения должны приносить пользу. Как доказать, что ваши автотесты полезны и какую именно ценность они поставляют? И что собой представляет эта ценность? Автотесты, которые всегда проходят или не проходят?
Не автоматизируйте test cases
Как прямая автоматизация тест кейсов приводит к громоздким и раздутым наборам автотестов, которые практически не приносят пользы.
Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.
К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.
В этой статье мы продемонстрируем, почему «фабрики автоматизации» неэффективны и опишем более правильный подход к автоматизации, который гарантирует, что автоматизация тестирования поддерживает и ускоряет скорость разработки.
Издержки и преимущества автоматизации тестирования
Чтобы понять, почему автоматизация существующих тест кейсов настолько проблематична, нам нужно вернуться назад и немного проанализировать теорию автоматизации. В частности, нам нужно изучить издержки и преимущества автоматизации, посмотреть на ожидаемую ценность автоматизированных тестов во времени, а затем оценить, как ожидаемая ценность меняется в различных типах тестов. Затем мы сможем увидеть, как автоматизация тест кейсов с использованием простого подхода «фабрики автоматизации» повлияет на тестирование в целом.
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Можно ли автоматизировать автоматизацию тестирования?
В своем докладе на конференции TestDriven Conf 2022 Станислав Васенков предлагает за минуту создать из ручного теста проект с автотестами в боевой инфраструктуре. О том, как разрабатывался генератор, можно узнать из интервью.
Кроме того, мы обсудили актуальные проблемы современного тестирования и поговорили о том, почему искать тестировщиков для компании должен не HR, а инженер, говорящий с кандидатом на его языке.
Интеграция с Allure: структурировать, упростить, стабилизировать
Если ваш проект с автотестами растет, то рано или поздно ставится вопрос о том, как централизованно управляться с этими тестами. Как найти время на поддержку тестовой документации? Как ее структурировать? Где хранить отчеты? Как избавиться от нестабильных тестов и быстро выявить ответственных за них? В Wrike мы смогли ответить на все эти вопросы и автоматизировать процессы, которые они затрагивают. В статье расскажем, как нам это удалось.
Управление тестами в TestOps: храните информацию, а не выводы
Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать — задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!
Привычно? Да. Но так ли это решение хорошо и универсально? Вопрос подкрепляется существованием исключений: почта, JIRA-тикеты и много чего другого хранится не в папках. Давайте разбираться, почему.
Почему мы провалили Scrum
Антон работает тимлидом в продуктовой компании. Его команда разрабатывает информационно-аналитическую систему для бизнеса и госкомпаний. В проекте много хаоса, команда ничего не успевает, и Антон предлагает внедрить Scrum. Он сталкивается с непониманием процессов в высшем руководстве и чрезмерной нагрузкой на команду. От Скрам остается часть ритуалов, Антон с трудом «вытягивает» проект и уходит из компании. Разберем по пунктам, почему Scrum может провалиться.
Скрам работает в продуктах, где все быстро и часто меняется. Например, начали делать приложение фоторедактор с множеством функций и страниц. Через месяц поняли, что надо выбросить дополнительные функции и сосредоточиться на трех главных. Через два месяца решили добавить редактирование видео. В таком проекте Scrum даст гибкость, поможет безболезненно и быстро внедрять все изменения.
В проектах, где работа идет на поток, а все процессы отлажены, Scrum только мешает. Например, компания выпускает лендинги для бизнеса. Опытный менеджер согласовывает все вопросы с заказчиком, передает дизайнеру понятное ТЗ. Заказчик выдает правки и принимает работу. Дизайнер в спокойном темпе делает по 10-15 лендингов в месяц.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность