В этой статье мы узнаем о следующем:

- Почему автор, повидав разработку во многих абсолютно разных средах, всегда настаивал на внедрении и использовании unit и функциональных тестов.
- Чем такие тесты нам полезны, а чем - не очень.
- Какие проблемы возникают от отсутствия тестов, а какие - от их наличия.
- Как часто разработчики пишут тесты вообще.
- Что останавливает людей от написания тестов и может ли это быть "уважительной" причиной.
- Почему имеет смысл привить себе привычку писать unit тесты как можно раньше.

Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинатору условий из ТЗ.

Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям.

В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.

Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:

Эти заметки о своём вхождении в тимлидскую должность я решил сделать с самого начала, только когда начал искать должность тимлида. Вероятно, подсознательно мне захотелось побыть героем своего собственного рассказа, который проходит через приключения и в итоге добивается своей цели. Именно так оно и получилось: и цели я добился, и приключений было много. Также я понимаю, что подобный опыт в карьере может быть раз, два, ну три за всё время: когда отношения по работе переходят в совершенно иную форму. Потом, когда прошли первые месяцы, многое естественным образом начинает забываться или превращаться в рутину. Тем более мне хотелось сохранить свежий взгляд на то, как устроена эта должность и какие открытия я сделал, получив её. Предлагаю почтенной публике ознакомиться со своими выводами, которые я старался записывать по горячим следам.

Добро пожаловать в серию статей "Лидерство в тестировании" от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Серия статей предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно тем, кто работает в гибких командах, преуспеть в своих ролях руководителя тестирования и менеджера. 

Начнем с самого начала: что такое «тестирование программного обеспечения»? Мы изучим основные концепции тестирования программного обеспечения, которые сформируют ваше мышление по мере приближения к искусству качественного инжиниринга. 

Когда вы Тест Лид на проекте, очень вероятно, что коллеги будут считать вас экспертом во всем, что связано с тестированием. У других членов команды могут быть свои собственные обоснованные или нет взгляды на тестирование; некоторые могут иметь (или, по крайней мере, говорить, что имеют) больше опыта, чем вы. 

Ожидания от тестирования часто нереалистичны и даже опытные люди занимают некорректную позицию в отношении того, чем может помочь тестирование. Некоторые люди будут сомневаться в вашей компетентности, ценности для команды или даже в вашей мотивации. Это может быть непросто. 

В вашей карьере Тест Лида вам придется адаптироваться к новым и меняющимся обстоятельствам. Вы встретитесь с представителями бизнеса и высокопоставленными заинтересованными сторонами проекта. Вы будете присоединяться к командам разного размера, в которых будут работать разные люди с самым разным опытом работы. У них может быть большой опыт или, на самом деле, совсем немного. 

В этом туториале по JUnit 5 рассказывается о том, как JUnit адаптировал стиль кодирования Java 8 и некоторые другие функции. Узнайте, чем JUnit 5 отличается от JUnit 4.

JUnit 5 - наиболее широко используемая среда тестирования для приложений Java. JUnit долгое время отлично справлялся со своей задачей.

Между тем, JDK 8 привнес в java интересные функции и, в первую очередь, лямбда-выражения. JUnit 5 был нацелен на адаптацию стиля программирования Java 8; вот почему Java 8 является минимально необходимой версией для создания и выполнения тестов в JUnit 5 (хотя можно запускать тесты, написанные с помощью JUnit 3 или JUnit 4 для обратной совместимости).

Привет, Хабр! Меня зовут Александр Старостин, я занимаюсь тестированием биллинговой системы МТС. Тестирование бэкенда — важная часть процесса проверки разработки ПО. Покрытый тестами бэкенд минимизирует ошибки при выкатывании новых фич на прод и в целом делает разработку более предсказуемой. Тесты бэкэнда быстрее разработать, они стабильнее и быстрее в прогоне, в отличии от тестов пользовательского интерфейса. К тому же не у всякого сервиса есть интерфейс, например публичный API для внешних систем. Но ручное тестирование может быть очень трудоемким. И тут нам на помощь приходит ее высочество автоматизация. О ней мы сегодня и поговорим.

Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать?

Предисловие

О нас

Добрый день, меня зовут Никита, я тестировщик программного обеспечения в компании Solit Clouds, мой опыт тестирования более 2,5 лет.

В текущий момент являюсь ответственным за тестирование мобильных приложений на Android.

В данной статье я хочу поделиться опытом с точки зрения непосредственного участника процесса, а именно:

Что может быть более полезно для будущего, чем образование?

Что может быть более полезно для образования, чем интерактивный QA-учебник состоящий из 42 модулей, 42 онлайн-тестов, 500+ страниц от менторов с суммарным опытом 100+ лет?

Что может быть более полезно для кошелька QA-студента, чем когда это всё бесплатно?

Этот учебник появился не потому, что миру нужен был еще один учебник по тестированию. Хороших QA-учебников предостаточно. Он появился, когда стало ясно, что и обучающимся самостоятельно, и, как ни странно, QA-преподавателям нужен несколько другой подход к обучению тестированию. Так появилась трехуровневая модель обучения, результатом которой этот учебник и стал. 

Многие IT-компании до сих пор придерживаются традиционного цикла разработки программного обеспечения. Организации склонны отдавать больший приоритет реализации, чем проектированию и редко уделяют должное внимание вопросам качества приложения. Но что такое качественное приложение? В чем разница между компаниями, ориентированными на качество, и компаниями, нацеленными на конечный продукт?

Обычно тесты не популярны в СНГ. Многие считают их дорогими и тормозящими разработку. Часто это говорят те, кто за разработку принимает написание кода сразу в прод и забывают о нем навсегда

Телеграм забит кучей работных каналов с вакансиями, но только лишь часть постов оформлена внятно. Вот небольшой гайд о том, как можно написать текст объявления, чтобы сократить время поиска и быстрее привлечь специалистов. Давайте посмотрим, как сделать коммуникацию проще и удобнее для всех.

В каком случае зайдёт статья:

• Вы не очень шарите в сфере HR и хотите это исправить.
• Не понимаете, как пользоваться Телеграмом, а надо.
• Не знаете, как составить текст вакансии и что в нём должно быть.

5 дней для погружения и знакомства с командой — про наш новый формат онбординга в формате квеста. Краткое пособие для джунов и лидов: какие задания ждут на старте и как пересмотреть процесс адаптации для команды из 10+ QA.

Привет, Хабр! Меня зовут Ксения, я управляю направлением тестирования в компании ISPsystem. За время работы я столкнулась с задачей найма людей себе в команду. Этот процесс оказался значительно сложнее, чем я думала. Недаром про него написано так много лайфхаков с примерами на собственном опыте. 

Я расскажу, как искала тестировщиков в разработку ISPsystem — от постановки задачи до удачных офферов: про «мамкиных тестировщиков», разгребание горы резюме, осмысленные тестовые задания и интервью со «специальными вопросами». Статья будет полезна как лидам, ищущим тестировщиков в команду, так и соискателям при подготовке к интервью.

О чем эта статья и чем она полезна.

Всем привет! В этой статье пойдет речь о том, как написать простые UI-тесты на языке Java. Это будет интересно тем, кто давно хотел попробовать себя в автоматизации или добавить новенького в свой текущий проект.

В этой статье не будет большой остановки на теории, а также на том, как настроить рабочую среду. Эти темы я упомяну кратко и дам ссылки, которые помогут разобраться в них самостоятельно.

Основная часть статьи будет посвящена практическому разбору теста и нюансам их написания.

Собирайте с собой друзей, хорошее настроение и поехали!

Что такое UI-тесты? Плюсы и минусы.

UI-тестирование – это тестирование пользовательского интерфейса программы/сайта/приложения и др.

Звучит легко, а чем такие автотесты полезны?

1)    Такие тесты используются, чтобы автоматизировать рутинные задачи и однотипные действия, например, проверку товаров в каталогах.

2)    Чтобы ускорить или упростить проверку сложных пользовательских путей. Например, в кейсе, где есть очень много тестовых данных и переходов или для прохождения которого нужна сильная концентрация.

3)     Чтобы снять часть работы с сотрудников, если их мало на проекте, часть проверок можно перенести на автотесты.

С одной стороны, “Постоянство не заслуживает ни похвал, ни порицаний, ибо в нем проявляется устойчивость вкусов” (с) - зачеркнуто “Привычка - страшная сила”. Но с другой, когда ты выпускаешь цифровые продукты, такая ригидность часто ведёт в тупик. В данной статье хотим рассказать, почему мы пошли на риск и решились перетаскивать с привычного инструмента тысячи тест-кейсов, и что из этого вышло.