Гибкий подход (эджайл, agile) сегодня у всех на слуху. Все хотят быть гибкими, и – вуаля! – ваша компания уже на полпути к гибкому подходу. Зачем? Все статьи/обсуждения/слухи свидетельствуют о том, как это круто. Однако, бытует мнение, что это темная и грустная история, которую в прошлом году на конференции TestCon Moscow рассказал Антон Зотин.
С 31 марта по 2 апреля ждем вас на четвертом выпуске конференции TestCon Moscow 2020.
В данный момент у нас привлекательные цены на билеты, ну а всем читателям портала мы предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10
Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.
Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
Недоделки. Это ошибки, которые допустили разработчики, пока пилили новый функционал. Такие ошибки находят при исследовательском или приемочном тестировании новых фич на девелоперских стендах команд.
Баги в регрессе. Это дефекты, которые находят ручные регрессионные тесты или автоматические UI и API тесты на стенде для интеграции кода.
Баги с прода. Это проблемы, которые нашли сотрудники или клиенты и обратились в службу технической поддержки.
Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.
Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.
Можно ли автоматизировать всё, что угодно? Потом всех тестировщиков уволим, конечно. Зачем они теперь нужны, «ручного» тестирования не осталось. Правильно ведь?
Это рассказ о будущем тестирования с точки зрения DevOps. Здесь будут конкретные цифры и чисто практические выводы, как так получается, что у хороших специалистов всегда есть работа. (Или нет работы! Глядите на фотографию Шекспира и бойтесь, сейчас будет решаться ваша судьба).
В основе материала — расшифровка доклада Баруха jbaruch Садогурского, Developer Advocate в компании JFrog. Текстовая версия и видео доклада — под катом.
Нина Агеева, Deputy Director at Лаборатория качества.
Думаете, как сэкономить на тестировании вашего ПО? Вы не одиноки. Возникает лишь одно маленькое но: если софт не дотестировать, возможны самые негативные сценарии – от дорогостоящей и крайне невыгодной вам доработки приложения на поздних стадиях до потери репутации и ухода клиентов/заказчиков к конкурентам.
Готовы взять к себе в штат 50 самых опытных тестировщиков, чтобы обеспечить качество продукта? Вот же круто! А зачем? Нужно понимать: если выделите слишком большие ресурсы на тестирование в тех случаях, когда это неоправданно, вы раздуете бюджет и софт будет слишком дорогой. Обрадуются ли этому ваши пользователи и заказчики? Вы снова рискуете.
Да, мы намекаем, что истина где-то посередине. В этой статье мы расскажем об основных принципах, следуя которым вы сможете найти баланс между стоимостью тестирования и качеством своего продукта.
Кирилл Раткин, тестировщик Контур.Экстерна, расскажет как повысить эффективность тестирования с их помощью и не уйти в крайности.
Как часто вам приходится что-либо оценивать? Наверное, каждый день. Хорошая или плохая сегодня погода, сносно ли ведет себя кот, нравится ли вам эта футболка. На работе вы оцениваете свои задачи и результаты: это сделано хорошо, а тут можно было лучше. Такие оценки часто основаны на субъективном ощущении. Но эти оценки не могут повысить эффективность процессов, и нужна более высокая детализация. Тогда на помощь приходят метрики.
Как вы можете охарактеризовать свои рабочие процессы и практики? Они хорошие? Плохие? Насколько? Почему вы так решили?
В этой статье Анастасия Ронжина, тестировщик сервиса Контур.Маркет, расскажет о том, почему стоит пробовать что-то новое, менять свои взгляды, подходы, ошибаться и снова пробовать.
У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.
Эволюционирует место тестировщика в процессе разработки, да и сами процессы. Например, Максим и Ирина из нашей компании рассказывали про эволюцию автотестов, о том, как можно ускорить разработку с помощью тестов и изменении взглядов на то, кто и на каком этапе их должен писать. Лена и Илария рассказывали о том, что можно менять свои инструменты, подключаться к общению с пользователем, к подготовке ТЗ и прототипов, чтобы повысить качество продукта.
Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
Agile в целом заменил модель водопада в качестве «правильной» методологии разработки ПО. Это действительно хороший процесс, если он правильно поставлен, но люди все портят, когда неправильно к нему подходят. О, как мощно он может пойти наперекосяк. У меня много претензий к плохим практикам Agile, и сейчас вы все о них узнаете!
Нарушение правил
Agile очень похож на настольную игру «Монополия». Правила у нее длинные и сложные, но они нацелены на то, чтобы сделать игру эффективной. Однако по какой-то причине все настаивают на изобретение своих собственных правил для игры вместо того, чтобы следовать официальным инструкциям. К примеру, игроки не выставляют собственность на аукцион, перейдя на соответствующую клетку, и отказываются ее покупать, или строят дома, не достигнув монополии. В результате игра продолжается бесконечно и теряет свою привлекательность. Что касается Agile, каждая организация, видимо, стремится пойти своим особенным путем, и это практически всегда выходит им боком. Правила не предназначены для того, чтобы их нарушали. А если их нарушают, последствия не заставят себя ждать.
