Home

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

Мы уже изучили больше половины принципов SOLID! Сегодня настало время узнать про букву I: принцип разделения интерфейсов.

Чтобы понять этот принцип, надо сначала разобраться, что такое интерфейс. Интерфейс – это определение набора методов, который можно реализовать в классе. Каждый класс с реализацией интерфейса должен использовать все включенные в интерфейс методы. Так как интерфейс определяет только подпись метода (имя, параметры и тип возвращаемого значения), методы могут варьировать в разных реализациях.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

За эти годы я многократно слышал, что «тестирование – отличный способ вставить ногу в дверь IT». Это значит, что если у вас нет опыта (скажем, ваша предыдущая карьера не связана с технологиями), то тестирование может упростить вам переход. Ожидается, что кривая обучения тут гораздо менее крутая, если сравнивать, скажем, с мобильной разработкой.

Многим это не нравится. Они сопротивляются, говоря, что не любят, когда тестирование рассматривают в таком ключе. Что тестирование – это сама по себе карьера, и нельзя смотреть на него, как на ступеньку в карьере.

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

Автор: Кристин Джеквони (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, но на этом и все. Это, конечно, верно для большей части содержимого социальных сетей в целом, но я не хочу нападать на социальные сети и качество (или его отсутствие) контента там. Возможно, поговорим об этом в другой раз.

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

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

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