Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Те, кто не первый год читает мой блог, возможно, заметили, что если я хочу что-то изучить – я ставлю себе задачу написать об этом статью. В 2020 году я читала по книге о тестировании в месяц и писала отзывы на них. В 2023 я изучала по одной логической ошибке в месяц, и писала объясняющие эти ошибки статьи (и в результате написала книгу о логических ошибках для тестировщиков).

Ближайшие пять месяцев у меня новый челлендж: изучить принципы чистого кода (SOLID). Я много лет хотела в них разобраться, но меня всегда пугала терминология («принцип подстановки Лисков» звучит, как что-то сложное). Я, однако, сделаю все, чтобы изучить эти принципы и объяснить их на примерах, полезных тестировщикам. Начнем с принципа единственной ответственности – буквы S в акрониме SOLID.

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

Изначально планировала в этой статье сравнить работу с ментором с курсами, однако, поскольку это будет сильно не объективно (курсов сейчас много, как и менторов), решила провести небольшое исследование на тему того, откуда люди изначально получали знания перед тем, как пойти в тестирование. В этой статье я постаралась собрать опыт 55 человек, заполнивших мой опрос или согласившихся провести со мной интервью, большая часть которых устроилась на свою первую работу в период с 2021 по 2024г. (т.е. когда конкуренция на стартовых должностях уже начала принимать серьезные обороты).

Автор: Ольга Назина (Киселёва)

Очень насущный вопрос для многих — можно ли найти работу в тестировании сразу после курсов? Да! (сказал автор курсов, хе-хе-хе)

Я вам больше скажу — можно и БЕЗ курсов устроиться ????. Более того, грамотные самоучки очень ценятся! Но для такого эффекта надо пахать =))

Об этом и поговорим в статье:

• как устроиться без курсов — чем запоминаются самоучки (расскажу истории из своей практики), 

• зачем тогда вообще курсы, что они дают и как помогают трудоустройству,

• вспомним и про ситуацию "наоборот": курсы есть, знаний нет (вот и не берут!),

• подведем итоги
  

Содержание

1. Как устроиться без курсов — чем запоминаются самоучки

2. Что дают курсы

3. Ситуация наоборот: курсы есть, знаний нет

4. Ситуация: знания есть, работы нет

5. План по эффективному обучению

6. Итого

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

Как вы уже знаете, я целый год концентрируюсь на логических ошибках. Мы узнали о множестве ошибок, от наведения на ложный след до апелляции к невежеству! Настало время последней статьи в этом году, посвященной ошибке скользкого склона.

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

Этой ошибке часто подвержены родители, запрещающие подросткам что-то делать. Представьте себе отца и дочь. «Если я разрешу тебе пойти на рок-концерт и стоять на ушах до двух ночи посреди школьной недели, то вскоре ты будешь болтаться по ночам каждый день, будешь опаздывать на уроки, пострадают твои оценки, и ты не поступишь в хороший колледж».

Автор: Кристин Джеквони (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, конечно же.

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

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