Профессия тестировщика зародилась не в последние годы, с появлением Python и автотестов, а гораздо раньше. «Дедушка российского тестирования» Александр Александров рассказывает об истоках тестирования в России и о становлении целой отрасли, объясняет, почему отношение к профессии было и бывает неверным, а также дает советы начинающим тестировщикам.
Именно здесь начинался путь российского тестирования (Главное здание МГУ. Фото ТАСС)
В этой статье мы сформулируем основные рекомендации для составления грамотного резюме на позицию QA-инженера и разберемся, чем резюме джуна отличается от резюме мидла. Это небольшой чек-лист, сформированный на основе структуры резюме образца hh.ru, однако все советы адаптивны и будут эффективны для любых форматов самопрезентации. Материал будет полезен главным образом начинающим тестировщикам, однако и более продвинутые специалисты смогут обнаружить здесь что-нибудь интересное. Над статьей работали эксперт по работе с соискателями сервиса "Готовое резюме” Лариса Сазонова и product QA-engineer Полина Ясакова.
Правилом хорошего тона считается резюме, не превышающее 1-1,5 страницы, нет смысла вписывать в резюме все, что вы можете рассказать о себе и своем опыте. Основная цель вашего резюме — дать потенциальному работодателю представление о ваших способностях и уровне компетенций.
Как правило, все знают про severity и priority, но практически никто не говорит об urgency (срочности).
Значения приоритета и критичности
Например, если есть критичный баг S1 и его не нужно срочно исправлять, то у него может быть более низкий приоритет, к примеру - P2, а менее критичный баг S2, но который нужно исправить срочно — может иметь более высокий приоритет P1.
Автор: Марк Уинтерингэм (Mark Winteringham) Оригинал статьи Перевод: Ольга Алифанова
Новички в автоматизации пользовательского интерфейса (UI), как правило, рассматривают фреймворк автоматизации, как крупную единицу ПО. Однако стоит копнуть глубже, и вы обнаружите, что как и в случае с большинством ПО, фреймворк тест-автоматизации UI - это коллекция совместно работающих библиотек.
Привет! Меня зовут Дарина Майорова, я работаю в тестировании в Яндексе, и хочу рассказать, как в Яндекс Афише я за полгода вырастила команду саппорта тестирования.
Весной 2021 года у нас была проблема: в Афише было две команды разработки (Афиша и виджет продажи билетов; далее для простоты я буду часто объединять их в одно понятие Афиша), и был недобор тестировщиков . Мы столкнулись с большой нагрузкой, отсутствием времени на ведение документации, и тестирование выступало в роли “бутылочного горлышка” в командах. А в случае ухода хотя бы одного тестировщика в отпуск (или увольнения) — мы рисковали получить еще больший завал.
Какие решения можно было тут придумать? Желательно — дающие быстрый результат (найм и онбординг нового сотрудника — это не быстро).
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Возможно, вы знаете, что я фанат библиотеки REST Assured для Java – особенно из-за простоты ее использования при создании читабельных, но мощных тестов для HTTP API.
К тому же с тех самых пор, как я работал над SDK Python и C# для платформы TestProject, я размышлял о создании и публикации своей собственной открытой библиотеки. Почему? Отчасти потому, что я люблю сообщество открытого исходного кода, а отчасти – потому что я искренне убежден, что надо благодарить делом и "платить вперед"; а отчасти потому, что я считаю это ценным опытом, а также хорошим способом попрактиковаться и отточить навыки разработки.
Автор: Саймон Томс (Simon Tomes) Оригинал статьи Перевод: Ольга Алифанова
Хорошее исследовательское тестирование требует хорошего навыка ведения заметок. Возможно, достаточным будет “выглядит неплохо” и “я нашел этот баг”. Но что вы упускаете, не ведя заметки, поддерживающие такое резюме? Какая информация останется в тени? Что вы заметили, но не задокументировали? Чем не поделились?
