Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Ошибка апелляции к невежеству – интересная штука: она утверждает, что нечто истинно, потому что не доказано, что оно ложно.

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

В тестировании эта ошибка тоже очень распространена. Возьмем, например, такое утверждение: «Мы знаем, что наше ПО безопасно, потому что у нас никогда не было проблем с безопасностью». Отсутствие этих проблем НЕ означает, что в ПО нет уязвимостей. Возможно, там их десятки, но компания недостаточно велика и не представляет для злоумышленников никакого интереса. Некоторые компании могут также заявить, что никогда не находили в своем ПО никаких уязвимостей. Возможно, это действительно так, но, возможно, они и не пробовали их искать. Это плохая логика и очень плохая практика – заявлять, что чего-то не существует, только потому, что вы и не пробовали это найти.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Я уже говорил об этом, многие высказались еще до меня, и я надеюсь, что множество людей будет вновь и вновь говорить об этом в будущем:

«Тест-автоматизация – это разработка ПО».

По сути это правда, но мне кажется, что в отрыве от контекста эта фраза ничего не значит. Она хорошо смотрится в качестве твита или поста в LinkedIn, но на этом и все. Это, конечно, верно для большей части содержимого социальных сетей в целом, но я не хочу нападать на социальные сети и качество (или его отсутствие) контента там. Возможно, поговорим об этом в другой раз.

Я хочу поговорить о том, что мало кто действительно глубоко разбирается в последствиях того, что тест-автоматизация – «это разработка ПО». Я немного затрагивал эту тему ранее – в основном рассуждая о том, почему было бы неплохо изучить базовые принципы программирования.

Сегодня я хочу развить ёмкую фразу «тест-автоматизация – это разработка ПО» далее; если конкретно, поговорить об одном следствии из нее. Если тест-автоматизация – это разработка ПО, то вы, работая над созданием автоматизированных тестов, становитесь разработчиком.

Да-да, вы всё верно прочитали. Вы. Разработчик. ПО.

Оригинальная публикация

Введение

Всем привет, меня зовут Никита, и я QA-инженер в компании Bimeister.

Мы помогаем промышленным предприятиям с цифровой трансформацией. Грубо говоря, помещаем завод с детализацией до каждой балки в окно браузера.

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

Для начала расскажу, как у нас устроен процесс автоматизации и наш фреймворк.

В автоматизации тестирования у нас участвуют SDET-ы и непосредственно QA-инженеры. У нас нет отдельных автоматизаторов, все QA — full stack. SDET-ы занимаются непосредственно фреймворком (развитием, поддержкой, интеграцией) и архитектурной частью автоматизации. QA-инженеры — самим покрытием продукта автоматизированными тестовыми сценариями (тут необходимо уточнить, что QA-инженеры автоматизируют UI-тесты, а Unit- и Integration-тесты пишут разработчики).

Паттерны и инструменты используются классические: PageObject, Fluent of invocations, C# + Selenium, MSTest.

Оригинальная публикация

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

Если говорить про тестирование Java-приложений, то первым на ум приходит JUnit. Этот фреймворк часто используется в Test-Driven Development (TDD) подходе, при котором сначала пишутся тесты на ожидаемое поведение системы, а затем код, который обеспечивает указанное поведение. В качестве альтернативы JUnit выступает Spock Framework, использующий подход Behavior-Driven Development (BDD). Его суть заключается в том, чтобы создавать читаемые, продуктивные и понятные спецификации поведения системы.

BDD сценарии, в отличие от TDD, обычно более доступны для понимания и использования всеми участниками команды разработки, включая нетехнических участников команды, таких как бизнес-аналитики. BDD помогает фокусироваться на бизнес-требованиях и легче сопровождать код в долгосрочной перспективе.

Оригинальная публикация

Сделать сервис автоматического создания пользователей и прикрутить Redis, конечно же.

Привет, меня зовут Евгений Шайкин, я ведущий специалист по тестированию в команде Цифрового Рубля, майнтейнер одного из проектов автотестов, состою в команде развития автотестов в Альфа-Мобайл, где, собственно, и веду свою активную бурную деятельность. Я расскажу, как две небольшие «доработки» помогли сэкономить время и повысить эффективность автотестов.

Статью условно можно разделить на две части: сначала я расскажу про оптимизацию автотестов или как мы создаём тестовые данные, а потом — о кэшировании.

Автор: Триша Четани (Trisha Chetani)
Оригинал статьи
Перевод: Ольга Алифанова

Уроки

Хорошие практики разработки ПО пересекаются и приносят пользу на разных уровнях проекта разработки.

Хорошая практика разработки ПО не принимает на веру информацию о пользователях или их потребностях.

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

Автор: Куо Динг (Kwo Ding)
Оригинал статьи
Перевод: Ольга Алифанова

Как правило, для интеграционного тестирования базы данных используется расположенная в памяти база вроде H2. Это, однако, не гарантирует, что приложение правильно работает с боевой базой данных, которая в памяти не расположена. База данных H2 имеет множество перечисленных тут ограничений, а также ограничена в режимах совместимости (описано здесь). Это означает, что простой DDL-скрипт для реальной базы данных не всегда сработает на H2 в режиме совместимости.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Двусмысленность – это техника, позволяющая заморочить людям голову при помощи неточного языка. В английском языке множество слов, имеющих несколько значений – скажем, «light» может означать «светлый», а может «легкий». Двусмысленность можно также применять, будучи намеренно неоднозначным, говоря о времени или количестве. Дети отлично пользуются двусмысленностью, как мы увидим в примере ниже.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

На этот раз мы продолжим изучать логические ошибки на примере Циклических Рассуждений. Циклические рассуждения можно объяснить так:

• X верно, потому что верно Y.
• Y верно, потому что верно X.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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