Всем доброго времени суток, мои маленькие (и не очень) любители (и не очень) SQL! На курсе ПОИНТ мы с нуля разбираем построение запросов, обучаемся основным операторам, работе с разными типами данных, но сейчас я хочу с вами поговорить про один из полезных инструментов, увы, оставшихся за рамками ПОИНТ — сегодня я хочу рассказать вам про такую полезную штуку, как подзапросы и показать несколько вариантов их приготовления.
Этот вопрос кричит последнее время из каждого утюга. Интернет изобилует ресурсами, советами и приложениями для самостоятельного изучения английского. И это разнообразие ставит нас перед ужасающим выбором — часто это демотивирует и превращает наше изучение языка в постоянный поиск и хождение по полезным, но тем не менее бесконечным ссылкам. В этой статье я расскажу, какие действия можно совершать тестировщикам самостоятельно или с преподавателем, чтобы подтянуть английский и при этом не заблудиться в океане онлайн ресурсов.
Подкаст от проекта GeekHub с Артемом Ерошенко, менеджером команды разработки инструментов тестирования, и Всеволодом Брекеловым, фулстэк-разработчиком в компании JUG Ru Group.
Поговорили о том, кто такой QA, где учиться на тестировщика, какие скиллы нужны специалистам по тестированию, сколько они зарабатывают, какие к ним требования и как оценить, хорош ли ваш менеджер.
Автор: Джефф Найман (Jeff Nyman) Оригинал статьи Перевод: Ольга Алифанова
Применение современных методик позволяет командам разработки раньше принимать верные решения, обращаясь с требованиями как с тестами – то есть создавая спецификации фич. Об этом и поговорим.
Когда я смотрела фильм «Идиократия», момент с тестом на сообразительность показался мне нереальным. Ни за что не хотелось, чтобы показанные в фильме события могли оказаться правдой, но спустя несколько лет это случилось. Я стала тестировщиком, и моя работа сейчас выглядит примерно так, как показано на главной картинке. Наверно, именно так программисты видят тестировщиков.
Как доказать, что ты хороший тестировщик? Есть много способов это сделать, и один из них – подтвердить свои знания и умения сертификатом ISTQB. В статье будет описан процесс регистрации, предварительной технической подготовки и прохождения онлайн-экзамена, который состоялся 5 декабря 2020.
На просторах русской части Интернета уже есть несколько статей, описывающих процесс сдачи экзамена. Наиболее свежая статья – от 20 мая 2020: Сертификация ISTQB стала доступна онлайн: личный опыт. Есть еще описание очного экзамена от 2016 года: ISTQB Сертификация. Опыт сдачи. Дополню эти статьи своим актуальным опытом от декабря 2020.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
К статьям вроде "Принцип трех А" я часто получаю комментарии вроде таких: "у нас проблемы с пересечением пользовательских данных в тестах", или "как бы вы управились с Х тестами, каждому из которых нужно наполнение данными".
В свое время я обнаружил, что способ настройки данных, выбранный для автоматизированных проверок, может сильно влиять на их производительность, надежность, поддерживаемость и устойчивость, и эта тема заслуживает отдельной статьи.
Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они трактуются как неоспариваемые, и это неявно ведёт к самоцели — удовлетворить требования заказчика. Это часто происходит в аутсорсе, и такой фокус внимания негативно влияет на конечный результат — то, что видят и с чем работают пользователи.
Мы в SmartHead тоже занимаемся заказной разработкой, и я предлагаю рассматривать качество шире. Это не только про соответствие явно озвученным требованиям, но и про сами требования. Про дополнение явных требований своими, ориентированными не на потребности заказчика, а на удобство конечного пользователя. Пользовательский опыт, юзабилити, тексты в интерфейсе, отзывчивость, скорость релизов, их соответствие ожиданиям — всё это тоже относится к качеству.
Качество — это про «сделать классно» с точки зрения многих сторон: разработки, заказчика и конечного пользователя.
Как это сделать? Сложно. Начать стоит с формирования mindset на «встроенное» качество. Расскажу о принципах, которые могут помочь в этом.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Недавно мне задали вот такой вопрос (я его перефразировал для ясности):
Хорошая ли практика – одновременно использовать несколько тест-фреймворков? К примеру, я работаю над Python-проектом. Я хочу применять BDD c behave для фича-тестирования, но pytest лучше подойдет для юнит-тестирования. Можно ли использовать и то, и другое? Если можно, как мне структурировать мой проект?
Краткий ответ: да, нужно использовать фреймворки, наилучшим образом подходящие под конкретные цели. Обычно применение нескольких фреймворков несложно настроить. Разберемся подробнее.
Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинации условий из ТЗ.
Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям ))
В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.
В этой статье решил рассказать о том, что и почему чаще всего спрашивают на позицию автоматизатора в тестировании. Я постараюсь рассказать о как можно большем количестве направлений. При этом не буду придумывать конкретные вопросы - их может быть великое множество. Своей задачей я вижу только наметить области, чтобы у вас осталась своего рода карта знаний.
Само собой, если вы проходите собеседование на позицию junior, от вас не будут требовать опыта и знаний по всем вопросам. Будет круто, если вы разбираетесь хотя бы в ~30% всего этого. От позиции middle я бы ожидал примерно ~50%-60% знаний перечисленных мною тем. Ну и далее по восходящей.
