1 сентября стартовал длинный тренинг компании Лаборатория Качества «Первый Онлайн ИНститут Тестировщиков», который содержит 17 уроков по самым разным темам тестирования.
Мы получили много писем, нас часто спрашивали: “Курс большой, 17 вебинаров, а мне срочно нужно 2 занятия по тестированию мобилок”, или “Можно ли получить доступ только к вебинару “SQL для тестировщика?”, а то и “Как попасть к вам на карьерное консультирование или получить фидбек на мое резюме?”, и даже “Я еще не знаю, точно ли мне нужен курс и хочу ли я быть тестировщиком, как получить доступ к 3 первым вебинарам?”
Мы решили дать вам такую возможность.
Только один раз в рамках новогодней акции с 10.12 по 20.12 можно будет купить любой урок курса ПОИНТ всего за 1500 рублей или два урока за 2400 рублей или три урока за 3100 рублей.
Что вы получите:
доступ к урокам по выбранным темам и домашнее задание
возможность задавать тренеру вопросы в скайп-чате
возможность получать обратную связь по результатам выполнения домашней работы
Если после покупки вы решите пройти весь курс ПОИНТ, то сможете при оплате зачесть сумму, потраченную на отдельные уроки.
А ещё мы решили предложить вам новый формат — оплати и начни немедленно!
Доступ к учебным материалам вы получите уже на следующий день после оплаты! Чем раньше вы оплатите, тем больше у вас будет времени на общение с тренером и выполнение домашней работы.
Выберите свои любимые темы уроков прямо сегодня! Акция проводится только до 20.12 включительно.
На первый запуск нового тренинга действует специальная льготная цена!!!
Начало: 26 декабря
Тестировщик всегда работает в условиях недостатка времени: беклог не уменьшается, релиз на носу, а протестировать нужно еще многое. Чтобы обеспечить качество продукта, нужно постоянно повышать эффективность собственной работы. Один из способов - освоить некоторые инструменты, облегчающие рутинные действия в тестировании.
В веб-тестировании часто требуется работать с изнанкой страницы: смотреть локаторы, определять время загрузки, выделять отдельные элементы. Де-факто стандартом в индустрии стал инструмент Chrome DevTools, встроенный прямо в браузер Chrome. Разработчики используют его для отладки кода, но этот инструмент широко распространен и в тестировании. Более того, основные паттерны работы, заданные Chrome DevTools, используются как в других веб-инструментах, так и в работе с мобильными устройствами. Естественно, хорошее знание такой утилиты будет плюсом для любого тестировщика.
Курс «Chrome DevTools: Инструменты тестировщика» создан для быстрого погружения в специфические для тестирования навыки работы с этим инструментом. Курс — практический, теория дается в минимально необходимом для понимания объеме. Знания, приобретенные на этом курсе, помогут вам эффективно работать с Chrome DevTools сразу по окончании занятий.
На днях меня вновь спросили "Когда заказчик спрашивает, сколько времени займет тестирование нашего проекта, что мне ему отвечать?"
Простейший ответ, который я могу предложить, таков: если тестирование – часть процесса разработки, то оно займет ровно столько же времени, сколько разработка. Это связано с тем, что эффективное и продуктивное тестирование не разделено с разработкой – оно встроено в разработку.
Когда мы разрабатываем программный продукт или услугу, мы создаем дизайны, прототипы, функции, модули, компоненты, интерфейсы, интегрированные компоненты, сервисы, системы целиком… С каждым созданным нами элементом ассоциируется какой-либо уровень риска – возможности возникновения проблем. Дабы преуспеть, каждый элемент системы должен вписываться в общую картину совместно с другими элементами, и удовлетворять запросам тех, кто использует и создает систему.
Многие организации планируют тестирование, не осознавая всей ценности такого планирования. Тестировщики зачастую создают тест-планы просто потому, что всегда это делали (или процессы гласят им, что так надо). Если тест-план грамотно составлен – это мощное оружие в вашем тест-арсенале.
Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:
В какой форме тест-план должен быть?
Какую информацию он должен включать?
Для кого он предназначен?
Это ценные вопросы, заслуживающие подробных и взвешенных ответов. Их задают очень часто, и их необходимо задавать, чтобы убедиться, что план дает внятные ответы на различные вопросы бизнеса – к примеру, связанные с наглядностью, контролируемостью, передачей знаний или управлением изменениями.
Публикуем запись доклада Антона Малев-Ланецкого "Postman и Newman — автоматизация API для бедных" с прошедшего в Новосибирске QA DevDay.
Антон привык работать в условиях ограниченных сроков-бюджетов и с радостью делится своими лайфхаками. В докладе рассказывает, как подружить Postman и Newman, уйти от запуска руками и получить отчёт в удобном виде. Бесценный навык и бесплатная реализация.
Когда я слышу вопрос "У меня большой набор ручных тестов, какие из них (или, что еще хуже, "какие тест-кейсы") мне стоит автоматизировать", я беспокоюсь сразу о нескольких вещах.
Во-первых, концентрация на тест-кейсах сигнализирует о довольно убогом образе мыслей в отношении тестирования. Это связано с тем, что тест-кейсы зачастую формулируются как четкое следование явной процедуре с целью получения специфического результата. В лучшем случае следование процедуре подтвердит, что продукт может работать, а также предполагает, что любой не наблюдаемый в ходе процедуры и после нее результат не так уж важен.
Проблема тут в том, что процедуру можно варьировать потенциально бесконечным множеством способов, и множество факторов могут повлиять на сам тест или его результат. Будут ли люди пользоваться продуктом одним и только одним способом? Выявят ли эти специфические данные проблему? Могут ли другие данные выявить проблему, которую не найдешь при помощи имеющихся? Будет ли баг возникать каждый раз при следовании этому сценарию? Тест-кейсы зачастую активно подавляют исследовательскую жилку. Тест-кейсы – это не тестирование, а баги не следуют за тест-кейсами.
Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
Большинство руководителей в IT-сфере выросли из технарей. Нам комфортнее работать с программами, чем с людьми, а слово “сервер” нам ближе и понятнее, чем слово “мотивация”. Чтобы решить эту проблему, биг-боссы компаний приглашают сторонних коучей и экспертов по мотивации, а IT-менеджеры пытаются ломать себя и следовать правилам с тренингов: хвалить, давать обратную связь, мотивировать и стимулировать. Такие натянутые действия тоже не приводят ни к чему хорошему!
Оказывается, люди мотивированы всегда, и их не надо пинать! Вопрос не в том, мотивированы они или нет, а в том, что мешает раскрытию их максимального потенциала.
В своём докладе Виктория расскажет о том, как решили эту задачу в Лаборатории качества, внедрив новую парадигму Менеджеров Счастья. В числе тех инструментов, которые помогли им, и которыми автор поделится с вами:
* анализ проблем, хотелок и пожелалок наших любимых сотрудников; * обучение линейных руководителей менеджменту счастья; * совместная проработка общих целей; * решение не поверхностных, а корневых проблем.
Не нужно создавать созданное, нужно научиться применять имеющееся. Все проще, чем кажется.
Если поискать в Интернете список мнемоник тестирования, можно найти более 30 мнемоник, связанных с тестированием. Одна из наиболее известных эвристик (мнемоник)– это SFDPO (San Francisco Depot), созданная Джеймсом Бахом. Мнемоники не только помогают держать в голове важные разделы, которые нужно покрыть во время тестирования – они также могут поспособствовать генерации новых идей.
Мнемоника MOBILE APP TESTING
Тестируя мобильные приложения, я в основном пользуюсь мнемоникой I SLICED UP FUN, созданной Джонатаном Колом. Она помогает мне сконцентрироваться на различных областях наших приложений. Сегодня я хочу поделиться своей собственной мнемоникой – она называется MOBILE APP TESTING. Правда, легко запомнить? Ниже – подробное описание мнемоники с объяснениями, подсказками и ресурсами, которые помогут вам тестировать мобильные приложения.
