Как правило, все знают про severity и priority, но практически никто не говорит об urgency (срочности).
Значения приоритета и критичности
Например, если есть критичный баг S1 и его не нужно срочно исправлять, то у него может быть более низкий приоритет, к примеру - P2, а менее критичный баг S2, но который нужно исправить срочно — может иметь более высокий приоритет P1.
Автор: Марк Уинтерингэм (Mark Winteringham) Оригинал статьи Перевод: Ольга Алифанова
Новички в автоматизации пользовательского интерфейса (UI), как правило, рассматривают фреймворк автоматизации, как крупную единицу ПО. Однако стоит копнуть глубже, и вы обнаружите, что как и в случае с большинством ПО, фреймворк тест-автоматизации UI - это коллекция совместно работающих библиотек.
Привет! Меня зовут Дарина Майорова, я работаю в тестировании в Яндексе, и хочу рассказать, как в Яндекс Афише я за полгода вырастила команду саппорта тестирования.
Весной 2021 года у нас была проблема: в Афише было две команды разработки (Афиша и виджет продажи билетов; далее для простоты я буду часто объединять их в одно понятие Афиша), и был недобор тестировщиков . Мы столкнулись с большой нагрузкой, отсутствием времени на ведение документации, и тестирование выступало в роли “бутылочного горлышка” в командах. А в случае ухода хотя бы одного тестировщика в отпуск (или увольнения) — мы рисковали получить еще больший завал.
Какие решения можно было тут придумать? Желательно — дающие быстрый результат (найм и онбординг нового сотрудника — это не быстро).
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Возможно, вы знаете, что я фанат библиотеки REST Assured для Java – особенно из-за простоты ее использования при создании читабельных, но мощных тестов для HTTP API.
К тому же с тех самых пор, как я работал над SDK Python и C# для платформы TestProject, я размышлял о создании и публикации своей собственной открытой библиотеки. Почему? Отчасти потому, что я люблю сообщество открытого исходного кода, а отчасти – потому что я искренне убежден, что надо благодарить делом и "платить вперед"; а отчасти потому, что я считаю это ценным опытом, а также хорошим способом попрактиковаться и отточить навыки разработки.
Необходимость рационального использования средств очевидна всем, но вот про необоснованную экономию часто умалчивают. А зря, ведь это в конечном итоге приводит к повышенным тратам. Например, бизнес нередко считает, что за качество должны отвечать разработчики, а QA-специалистов иногда можно и не привлекать.
«Пока не накопилось достаточного объема кода для тестирования, подключение QA-специалистов некритично».
«Зачем тестировать то, что уже протестировано?»
«Зачем нужен тестировщик, если проверить код и реализацию может сам разработчик или его тимлид?»
«Тестовая документация – это неоправданная трата времени и можно тестировать ПО без нее».
Знакомо?
Если вы тоже сталкивались с желанием сэкономить на тестировании программного продукта, тогда приглашаем вас послушать наших экспертов-практиков, которые на конкретных примерах продемонстрируют, к каким последствиям и потерям это может привести.
28 июня в 17.00 (по МСК) руководитель QA-направления SimbirSoft Анастасия Леонтьева и ведущий QA-специалист Андрей Подгорнов разберут наиболее популярные сценарии экономии или отказа от некоторых видов тестирования. В прямом эфире эксперты расскажут, как избежать повышения затрат и срыва сроков на IT-проектах, а также ответят на ваши вопросы.
Мероприятие будет полезно CEO, CTO, руководителям проектов, лидам разработки и QA-командам, которым оно позволит правильно обосновывать своим руководителям и заказчикам необходимость тестирования.
Речь, конечно, пойдет не о харизматичных ящерках, а о нашем собственном инструменте автоматизированного тестирования. Представляем вашему вниманию кейс создания фреймворка «Хамелеон» и рассказ о его функциональности.
Его появлению предшествовало 15 лет практики тестирования в компании IBS AppLine* (лидера российского рынка аутсорсинга услуг тестирования по версии TAdviser за 2018 год на минуточку!). На базе этих знаний и экспертизы мы задались целью ускорить старт проектов, повысить качество тестирования, упростить введение в работу новичков. Решение должно позволить автоматизировать функциональное тестирование веб, мобильных, десктоп-приложений и различных видов API.
Автор: Саймон Томс (Simon Tomes) Оригинал статьи Перевод: Ольга Алифанова
Хорошее исследовательское тестирование требует хорошего навыка ведения заметок. Возможно, достаточным будет “выглядит неплохо” и “я нашел этот баг”. Но что вы упускаете, не ведя заметки, поддерживающие такое резюме? Какая информация останется в тени? Что вы заметили, но не задокументировали? Чем не поделились?
Я очень люблю тесты и считаю, что любой код должен быть покрыт ими, желательно качественными :)
Поэтому хочу поделиться с вами опытом внедрения мутационных тестов в проект, рассказать зачем оно нужно и какую ценность несет. Рассмотрим пример внедрения Infection в приложение на Laravel. Но сначала немного теории.
