Совсем скоро стартует очередной запуск тренинга Первый Онлайн Институт Тестировщиков, который рассчитан на специалистов по тестированию, как начинающих, так и с опытом до 1-2 лет. Перед вами - один из эпизодов курса на тему JOIN занятия SQL для тестировщиков.
Буданов Роман, тренер ПОИНТ, автор вебинара "SQL для тестировщика": В эпизоде вебинара продемонстрирован SQL запрос к 3 таблицам.
На конкретном примере тренер разбирает составляющие запроса. JOIN запросы нужны, чтобы быстро находить интересующие вас тестовые данные (пользователей с необходимыми товарами в корзине/правами доступа/ФИО). Какой бы продукт вы не тестировали – будьте готовы к тому, что вся информация хранится в БД. Даже у вашей кофеварки, скорее всего, втайне от вас имеется своя база) Но в БД необходимые именно вам данные могут храниться сразу в нескольких таблицах. И очень удобно, здорово и полезно (для психического здоровья-в первую очередь!) уметь писать запросы на поиск данных по нескольким таблицам сразу.
Совсем скоро стартует очередной запуск тренинга Первый Онлайн Институт Тестировщиков, который рассчитан на специалистов по тестированию, как начинающих, так и с опытом до 1-2 лет. Перед вами - один из эпизодов курса на тему Тест-туры занятия Исследовательского тестирования. Когда для тестирования нет сценария и тестирование необходимо начать сразу, применяются техники исследовательского тестирования. Чтобы сконцентрировать тестировщика и помочь ему не пропускать ошибки, были придуманы "туры" - то есть техники, направленные на поиск ошибок определенного рода и определенным способом.
Техника туров помогает сосредоточиться на одном типе багов. И чтобы легко применять туры, ищут аналогии в реальной жизни и описывают тур с помощью аналогий. В данном видео будет рассказано о том, что такое тест-тур, в каких случаях стоит его применять и на примере нескольких тест-туров Виттакера (“Тур супермодели” и “Тур, отмененный из-за дождя”) показано, как они работают и как с их помощью можно найти до 2500 ошибок GUI за 1 рабочий день. Безусловно туров намного больше, чем представлено.
Совсем скоро стартует очередной запуск тренинга Первый Онлайн Институт Тестировщиков, который рассчитан на специалистов по тестированию, как начинающих, так и с опытом до 1-2 лет. Перед вами - один из эпизодов курса на тему Чек-листы занятия Документирование тестов. В данном фрагменте на бытовых примерах рассказано, что такое чек-лист. Приведен пример чек-листа, показано как можно заполнять чек-лист. Даны четкие инструкции, в каких случаях лучше использовать чек-листы.
"С тестированием все путем". Значит ли это, что продукт в хорошей форме, или что мы добились хорошего покрытия, или нашли много багов? "С тестированием все очень плохо". Продукт хорош? Тестирование заблокировано? Мы ошибочно ставим много багов?
Люди отвечали на него, предлагая собственные интерпретации. Это неудивительно. Их интерпретации различались между собой, что тоже неудивительно. Меня больше удивило количество людей, убежденных, что есть некий общеизвестный базис, на основании которого мы можем оценить наше тестирование как хорошее или плохое – а также неявно предполагающих, что люди автоматически поймут, о чем мы.
5 октября представлен Днем мастер-классов, 6 октября - Днем докладов.
Вас ждет:
- 23 доклада, посвященных автоматизации, ручному тестированию, тестированию производительности, user experience, менеджменту и человеческому капиталу в тестировании;
- 6 мастер-классов, в двух из которых мы поиграем и поучимся основам QA и менеджменту в тестировании и 4 мастер-класса - 100% технические по Автоматизации.
Неформальное общение - важнейшая часть конференции, а значит без after-party никак не обойтись. Мы не ограничиваем себя только “образовательной” программой, цитируя классика “суха теория, мой друг, но зеленеет жизни древо”, поэтому приглашаем всех участников неформально пообщаться со спикерами, насладиться красотами Минска и просто замечательно провести время в кругу единомышленников.
7 октября, воскресенье:
Место встречи: пр. Победителей 59, холл гостиницы Виктория 11-00
Прогулка по Парку Победы вдоль Комсомольского Озера ~11-00 – 12-00
Новый музей Великой Отечественной Войны ~12-00 – 13-00
Я начал этот цикл статей с программирования, и сделал наиболее распространенную ошибку, которую делают все автоматизаторы – углубился в объяснения, как автоматизировать, вместо того, чтобы рассказать, почему это важно и выгодно для нас (спасибо Джиму Хейзену за то, что он обратил на это мое внимание).
На самом деле я рад, что все произошло именно так, потому что это лишняя демонстрация того, как люди, включая меня, подходят к автоматизации – они просто учатся программировать и ныряют в код, не зная, что они, черт возьми, делают. Делаем шаг назад, переосмысляем…
Еще несколько лет назад к организации автоматизированного тестирования предъявлялось, по сути, лишь одно требование — исключить из большинства рутинных проверок труд человека. Активнее всего автоматизацию внедряли крупные компании, для которых производительность и скорость прохождения тестов редко являлись критическими показателями. Они без особых проблем могли «залатать» деньгами любую дыру в структуре тестов, подключив несколько дополнительных мощных серверов или расширив парк тестовых устройств.
Но рынок быстро меняется: число профессиональных автоматизаторов растет с каждым днем, поэтому не удивительно, что у многих QA-компаний появились выгодные предложения для среднего и малого бизнеса. Сегодня заказать создание 100-200 автотестов могут позволить себе владельцы практически любого небольшого приложения или сервиса. А вот заставить их работать эффективно, не «проглатывая» дорогостоящие ресурсы и не тратя десятки часов на выполнение, — и есть настоящий вызов. В этой статье мы поделимся двумя историями из нашей борьбы за производительность, не упуская трудностей, с которыми столкнулись во время путешествия сквозь мрачный лес прожорливых автотестов.
В рамках сдвоенного доклада мы проговорим проблему построения Архитектуры решений Автоматизации «от обратного» - систематизируем классические Архитектурные недочеты, в том числе процессного происхождения, сформулируем варианты решения каждой рассмотренной проблемы, критерии выбора решения, и конечно условия перехода проблемы из не идеальной, но промышленно приемлемой, в потенциально опасный для проекта прецедент.
«Как начать автоматизировать» - первая тема в серии статей. Так как я обещал, я разъясню как для себя, так и для читателей, то, что я знаю про автоматизацию как специфически направленную деятельность со своими целями, поддерживающую тестирование.
Эта серия статей будет:
Короткой, примерно 5 минут на чтение, хотя это очень сложно для меня.
Практической – без воды, только эмпирические, полезные советы.
Основанной на личном опыте и плохих решениях. Я думаю, это очень полезно.
