19.12.2024 00:00 |
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова По мере роста компаний, разрабатывающих ПО, зачастую возникает необходимость что-нибудь измерять. Если в компании всего пара-тройка десятков человек, легко заметить, хорошо или плохо работает тестировщик. Однако когда компания разрастается до сотен и даже тысяч, все тяжелее и тяжелее отслеживать, как у всех сотрудников дела.
На этом этапе менеджмент растущей компании приходит к выводу, что надо отслеживать метрики, чтобы понимать, как работает команда. Зачастую будет предложено подсчитывать свои баги. Но что означает количество багов? В этой статье обсудим, что эта метрика расскажет вам, а о чем умолчит. |
Подробнее...
|
17.12.2024 00:00 |
Автор: Наталья Баранова, Аурига
В предыдущей части статьи мы рассмотрели общие подходы к тестированию PDF и познакомились с тем, как библиотеки pdfminer и PDFQuery помогают нам получать детальную информацию об объектах. Достаточно ли нам этой информации? Далеко не всегда. В этой статье мы расскажем о решении некоторых интересных технических проблем. |
Подробнее...
|
16.12.2024 00:00 |
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
Недавно я разговаривала с коллективом и предположила, что тестирование – не всегда решение вопроса. Они были озадачены.
Не поймите меня неправильно, я работаю с качеством, это моя страсть, я не буду отговаривать вас от него, но бывают трудные времена, когда стоят другие приоритеты, и, думаю, неправильно советовать просто тестировать, несмотря ни на что.
У тестирования и автоматизации два основных принципа, и если вы меня знаете, то, возможно, уже про них слышали:
1. Тестирование – это про верный баланс.
2. Автоматизация – это про экономию времени.
Оба связаны с издержками: в первом случае, если тестировать дороже, чем продолжать без тестирования, то лучше пропустить этот тест (или тесты).
Во втором случае, если автоматизация займет больше времени, чем общее время на ручное тестирование, автоматизировать не нужно.
Принципы, возможно, звучат очевидно, но в реальности не так-то просто принять решение не тестировать или не автоматизировать. Это контринтуитивно, и в голове звучат панические «А что, если». |
Подробнее...
|
|
11.12.2024 00:00 |
Автор: Евгений Домнин
Представьте – вы разработчик, и тестировщик приносит баг, который найден в ходе регресса. Хочется поправить этот баг и вы просите оформить тикет. Уже представляете как возьмете его в работу, залинкуете к нему пулл реквесты и проставите эстимейты, чтобы не было вопросов у продакт менеджера. Спустя время появляется новый тикет, но внутри лишь пара строчек и скриншот. Вздохнув, вы пробуете воспроизвести баг по этим данным, но ошибки нет. Пробуете несколько раз, но в итоге пишете тестировщику, что баг не воспроизводится и начинается новый цикл уточнений. Тратите время, которое могли потратить на решение новых задач, исправление других багов, просмотр аниме, рефакторинг. Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем. |
Подробнее...
|
10.12.2024 00:00 |
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
В предыдущей статье я утверждала, что тесты не следует делить на тесты черного и белого ящика. Однако многие знакомы с этими терминами, и для них, возможно, «отбеливание тестов черного ящика» будет понятнее, чем «структурирование логических тестов».
Опишу контекст, чтобы пояснить, что конкретно я имею в виду.
Когда тесты создают разные команды, зачастую они хотят убедиться, что все покрыто и все тесты верны – особенно если между командами или их участниками нет доверия, или создатели тестов уже покинули компанию.
Вместо того, чтобы поделиться определениями тестов (в некоторых командах они даже не зафиксированы) и вникать в логику интеграционных и E2E-тестов, некоторые стремятся разработать автоматизированные проверки, верифицирующие, что все покрыто. Тут и начинается структурирование логических тестов: они хотят превратить логические тесты в структурные.
Типичный пример – когда люди хотят узнать покрытие кода интеграционными или end-to-end тестами. Это возможно, но очень сложно и дорого, да и смысла особенного не несет. |
Подробнее...
|
09.12.2024 00:00 |
Автор: Наталья Баранова, Аурига
Некоторое время назад у нас появился интересный проект по созданию сервиса, генерирующего документы в формате PDF. И появилась задача — написать тесты, которые проверят документ в мельчайших деталях, включая и содержимое, и вёрстку. В данной статье мы расскажем, каким образом справились с этой задачей. |
Подробнее...
|
04.12.2024 00:00 |
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова В профессиональных кругах есть расхожая шутка, что консультанта легко опознать – он всегда отвечает на любые вопросы одинаково:
«Зависит от ситуации».
(иногда за этим следует «а если вы хотите более полезный ответ, то карточка к номеру привязана»).
Отставим шутки – в этой конкретной есть доля истины. В тестировании и разработке ПО крайне, крайне мало абсолютных истин.
Однако это не так легко понять, просматривая, скажем, мою ленту LinkedIn. Я где-то даже понимаю. Люди любят мыслить абсолютными категориями и говорить о них. Это простейший способ найти ответ на вопрос или сформулировать его. |
Подробнее...
|
03.12.2024 00:00 |
Оригинальная публикация Автор: Андрей Шушаков
Кэширование — это эффективное архитектурное решение, которое сегодня используется на всех уровнях вычислительных систем, начиная от кэша процессора и жесткого диска до кэша веб-сервера и обратных прокси-серверов. Именно о последних пойдёт речь. В этой статье мы рассмотрим атаки обмана и отравления кэша, сконцентрировавшись на последнем: проследим историю возникновения и развития уязвимости, поговорим про кэш-движки и связанные с ними последние CVE. Также попробуем разобраться, как следует искать отравление кэша на реальных целях. Распишем методологию пентеста, оценим риски и последствия эксплуатации, обозначим общие подходы к защите. Статья написана в рамках стажировки июль-август 2024 в компанию "Бастион". Выражаю благодарность куратору от Бастиона, Тимофею Брылеву, а также моему знакомому, Евгению Чикачёву, за совет |
Подробнее...
|
02.12.2024 00:00 |
Автор: Кассандра Ланг (Cassandra H. Leung) Оригинал статьи Перевод: Ольга Алифанова Что делает тестировщика великим?
Недавно я видела ряд дискуссий, побудивших меня задуматься:
- Что делают тестировщики?
- Чем ISTQB-тестировщик отличается от «гибкого» или «современного»?
- Отвечает ли тестировщик за определение влияния и/или приоритета бага?
- Почему люди используют термин «ручной тестировщик» (а также споры о терминологии, сопутствующие этому вопросу)?
- Насколько широка пропасть между великим и ужасным тестировщиком; кто из них чаще встречается?
Отвечая на один из этих вопросов, я упомянула три вещи, которыми заняты хорошие тестировщики, начиная с буквы “I”. Я вновь и вновь возвращалась к этой мысли, и думаю, что на самом деле великое тестирование состоит из пяти “I”. Если вы тестировщик, не занятый ни одной из “I”, то самое время начать. |
Подробнее...
|
29.11.2024 00:00 |
Опубликован выпуск рассылки за ноябрь.
В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.
Содержание рассылки доступно по ссылке.
Подписаться на рассылку |
28.11.2024 00:00 |
Оригинальная публикация
Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования. Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA. Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы. А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете. |
Подробнее...
|
|
|
|