Автор:

После многих лет работы в тестировании программного обеспечения можно с уверенностью сказать: почти никто не любит писать документацию. Даже люди, которым нравится писать (как мне), могут полагать, что есть дела и поинтереснее – например, создание тест-планов или автоматизации тестов. Но документация крайне важна! В этой статье я расскажу о пяти причинах этого, а также поделюсь пятью стратегиями, которые помогут вашей команде или компании иметь качественную документацию.

Автор:

Большинство тестировщиков программного обеспечения знает, как проводить граничных значений: например, зная, что текстовое поле должно принимать не более 20 символов, тестировщик проверит ввод 19 символов, 20 символов и 21 символа, а возможно, даже 100 символов. Но я часто сталкивалась с ситуациями, когда тестировщик не проводил тестирование границ, если в критериях приёмки не было явно указано ограничение. Это опасно!

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

Автор:

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

Метод удаления кода предполагает работу с проектом, написанным кем-то другим, с целью его понимания путём постепенного удаления строк кода, пока не останется только базовая функциональность. Вот как это работает:

За 8+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.

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

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

Автор:

Мы живём во времена, когда измерить можно что угодно. Веб-сайты отслеживают посещения пользователей со всего мира; видео на YouTube фиксируют просмотры и лайки; мобильные приложения собирают статистику сбоев. Поэтому логично, что менеджеры по разработке программного обеспечения стремятся замерить качество процессов.

К сожалению, у нас не всегда есть чёткий язык для описания измеряемого. Возможно, вы слышали, как менеджер говорил о достижении «100% тест-покрытия». Но что именно он имеет в виду под этим утверждением? Вот несколько вариантов, что это может означать, и один вариант, чего это значить ни в коем случае не может.

Автор:

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

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

Автор:

Я всегда интересовалась здоровьем и фитнесом, потому что хочу жить долго и полноценно. Но с возрастом я поняла, что методы, которые раньше помогали мне оставаться в форме, перестали работать: я постепенно набрала 30 фунтов (~13,5 кг) и поняла, что нужно что-то менять. Изменения были внедрены, и я вернулась к своему прежнему весу.

В последнее время я много говорила о качестве программного обеспечения и о том, почему командам сложно внедрять хорошие практики. И сегодня меня осенило: между поддержанием здоровья по мере взросления и поддержанием «здоровья» программного обеспечения много параллелей. Давайте рассмотрим распространённые оправдания, которые мешают оставаться «в форме».

Автор:

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

Автор:

Вы — начинающий тестировщик? Работать над приложением в команде из пяти и более разработчиков может показаться надёжным способом создать продукт без багов. Но правда в том, что количество разработчиков в проекте никоим образом не влияет на итоговое число ошибок.
Как бы ни был опытен разработчик — баги всё равно случаются. Не существует такого понятия, как «идеальный продукт».

Со временем разработчики начинают понимать, какие баги вы чаще всего находите, и в продукте становится меньше багов определённого типа — по сравнению с тем, что было ещё пару спринтов назад. Однако это не повод расслабляться. Именно тестировщик должен продолжать искать новые способы находить баги — до того, как они попадут на прод.

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

Вот несколько таких техник, которые, по моему опыту, приносят хорошие результаты.

Начать карьеру в тестировании — задача не из простых, особенно когда за плечами только теория и пройденные курсы, а в портфолио нет ни одного реального проекта. Большинство вакансий требуют опыт, которого у новичка еще нет, и именно на этом этапе часто возникает ступор: где взять кейсы, если тебя еще никуда не взяли.

Я Юлия Ковшова, руководитель группы компонентного тестирования защиты данных в YADRO, поделюсь идеями, где получить опыт, если вы недавно в тестировании и хотите дополнить портфолио практическими работами. В статье есть блок и для более уверенных в себе специалистов — сможете почерпнуть пару практик для развития в профессии.

Автор:

Разговоры о тестировании повсеместно и довольно давно идут наперекосяк. Как любил подчеркивать Джерри Вайнберг, слово «тестирование» перегружено смыслами и сваливает в одну кучу множество идей и видов деятельности. Это слово применяется к различным действиям, выполняемым разными людьми, работающими в разных контекстах, выполняющими разные задачи с различными приоритетами, в разные моменты процесса разработки. Неудивительно, что люди из настолько разных парадигм говорят, не слыша друг друга.

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

Автор:

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

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

Автор:

Есть ли тут проблема? Почему определенные тесты падают, кажется, всегда

Как тестировщики, мы хотим, чтобы тесты говорили нам, если код продукта ведет себя не так, как мы ожидаем. Во многих окружениях непрерывной интеграции и деплоя (CI/CD) мы привыкли ожидать, что упавшие тесты будут «красными» на дашборде результатов. Красный цвет сообщает, что где-то есть проблема.

Тесты, которые падают время от времени, особенно в областях продукта, подверженных регрессионным дефектам, очень полезны, ЕСЛИ становятся красными по веской причине: когда внедрен дефект, или в тест-окружении произошло что-то неожиданное.

Я Михаил Бибик, работаю в СберТехе QA‑automation‑инженером, пишу автотесты для СУБД Pangolin — это целевая СУБД в Сбере и не только. В прошлом году наша команда искала и нанимала QA‑инженеров с различным опытом, в том числе совсем начинающих. Когда я провёл штук 15–20 собеседований, то понял, что могу обобщить некоторые наблюдения и составить простые советы по поводу составления сценариев тестирования для начинающих (скорее, очень начинающих) тестировщиков. В этой статье я покажу, как применить теорию тестирования на техническом собеседовании. Для этого разберу реальную задачу с нашего собеседования.

Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

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

Если в приложении есть возможность открыть одну и ту же форму несколько раз — это обязательно надо проверить:

• Веб — открыть форму в нескольких вкладках браузера.

• Десктоп — там тоже иногда можно открыть в отдельной вкладке форму. Или запустить приложение несколько раз (имитируя разных пользователей).

• Мобилки — открыть с разных устройств.

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

Автор

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

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

Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

В своей книге про тест-дизайн я написала ряд чит-листов, которыми и хочу теперь поделиться. Сегодня поговорим про ролевую модель в GUI и API — это когда у нас есть разграничение прав для отдельных пользователей / целых групп (им назначается роль).

Набор ролей может быть очень обширным — права только на просмотр, на редактирование, на редактирование конкретной сущности или даже одного поля в этой сущности, просмотр конкретной страницы (отчетность или аудит), создание связи…

Но если брать в целом, обычно у нас есть:

• простые пользователи — у каждой группы свой набор прав;

• админ — всесильный пользователь;

• гость — неавторизованный пользователь (это, по сути, проверка на ноль).

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Sun, 10 Nov 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4257-solid-principles-for-testers-the-dependency-inversion-principle https://www.software-testing.ru/library/testing/testing-for-beginners/4257-solid-principles-for-testers-the-dependency-inversion-principle Автор: Кристин Джеквони (Kristin Jackvony)
  Оригинал статьи
  Перевод: Ольга Алифанова

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

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Wed, 25 Sep 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4254-solid-principles-for-testers-the-interface-segregation-principle https://www.software-testing.ru/library/testing/testing-for-beginners/4254-solid-principles-for-testers-the-interface-segregation-principle Автор: Кристин Джеквони (Kristin Jackvony)
  Оригинал статьи
  Перевод: Ольга Алифанова

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

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Mon, 09 Sep 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4234-testing-as-an-entry-gate-to-it https://www.software-testing.ru/library/testing/testing-for-beginners/4234-testing-as-an-entry-gate-to-it Автор: Филип Рик (Filip Hric)
  Оригинал статьи
  Перевод: Ольга Алифанова

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

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

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Tue, 06 Aug 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4227-solid https://www.software-testing.ru/library/testing/testing-for-beginners/4227-solid Автор: Кристин Джеквони (Kristin Jackvony)
  Оригинал статьи
  Перевод: Ольга Алифанова

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

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Sun, 04 Aug 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4229-missing-requirements https://www.software-testing.ru/library/testing/testing-for-beginners/4229-missing-requirements Автор: Майкл Болтон (Michael Bolton)
  Оригинал статьи
  Перевод: Ольга Алифанова

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

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Wed, 24 Jul 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4231-solid-principles-for-testers-the-single-responsibility-principle https://www.software-testing.ru/library/testing/testing-for-beginners/4231-solid-principles-for-testers-the-single-responsibility-principle Автор: Кристин Джеквони (Kristin Jackvony)
  Оригинал статьи
  Перевод: Ольга Алифанова

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

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Mon, 15 Jul 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4226-it https://www.software-testing.ru/library/testing/testing-for-beginners/4226-it Оригинальная публикация

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

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Tue, 25 Jun 2024 20:00:00 +0000 https://www.software-testing.ru/library/testing/testing-for-beginners/4220-2024-05-21-19-54-40 https://www.software-testing.ru/library/testing/testing-for-beginners/4220-2024-05-21-19-54-40

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

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

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

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

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

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

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

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

  Содержание

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

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

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

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

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

  6. Итого

  ]]> barancev@gmail.com (Administrator) Начинающему тестировщику Sun, 26 May 2024 20:00:00 +0000