Home

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

В этом месяце мы продолжим изучение принципов SOLID, разбираясь с буквой «О» - принципом открытости/закрытости. Этот принцип гласит, что класс должен быть открыт для расширения, но закрыт для изменения.

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

Автор: Майкл Болтон (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 помогает фокусироваться на бизнес-требованиях и легче сопровождать код в долгосрочной перспективе.