Автор: Александр Зырянов
Оригинальная публикация

На протяжении последних шести лет я занимаюсь разработкой и приёмочным тестированием самых разных по сложности и размеру приложений для проведения и сопровождения клинических исследований. Big data, огромное количество визуализаций и представлений, хранилища данных, ETL и тому подобное. Продуктом пользуются врачи, менеджмент и люди, которые участвуют в контроле и наблюдении за исследованиями.

Для приложений, которые оказывают или могут оказать прямое влияние на жизнь и здоровье пациентов, обязателен формальный процесс приёмочного тестирования. Результаты приёмочного тестирования вместе с остальным пакетом документации предоставляются для аудита в FDA (Food and Drug Administration, США). FDA выдаёт разрешение на использование приложения в качестве инструмента контроля и проведения клинических исследований. В общей сложности в моей команде разработано, протестировано и отправлено в продакшен более тридцати приложений. В данной статье я коротко расскажу о приёмочном тестировании и развитии инструментов в одной отдельно взятой маленькой группе.

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

Дорогие читатели и подписчики, поздравляем вас с 23 февраля, днем защитника Отечества! Пусть ваши проекты будут защищены от проблем лучше любой крепости. Баг не пройдет!

Авторы: Джейкоб Каллин и Ирен Лобо Валбуэна (Jakob Kallin, Irene Lobo Valbuena)
Оригинал статьи
Перевод: Ольга Алифанова

Руководство по XSS, часть 1
Руководство по XXS, часть 2
Руководство по XSS, часть 3

Валидация

Валидация – это фильтрация пользовательского ввода таким образом, что все вредоносные участки удаляются, но при этом не происходит удаления всего кода целиком. Один из самых распространенных типов валидации в веб-разработке разрешает ряд HTML-элементов (например, <em>, <strong>), но запрещает прочие (такие, как <script>).

Автор: Дмитрий Абузяров
Оригинальная публикация

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Аналитическая ^[1]часть тест-дизайна отвечает на вопрос, что нам надо протестировать. Это включает идентификацию и изучение различных информационных источников, а также искусство выяснения, что важно или может быть важным.

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

1С производит инструменты для быстрой разработки кросс-платформенных бизнес-приложений и рантайм для их работы. Бизнес-софт, разработанный на платформе 1С, работает на  Windows, Linux, macOS, Android, iOS, использует СУБД MS SQL, Oracle, IBM DB2, PostgreSQL.

Тестирование такого ПО – нетривиальная задача и большая ответственность. О подводных камнях такого тестирования рассказал на прошлой конференции Петр Грибанов.

А мы ждем вас и в этом году на четвертом выпуске конференции TestCon Moscow 2020.

Всем читателям портала традиционно предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10.

Обсудить в форуме

Автор: Назина Ольга

Что такое предварительные шаги тест-кейса

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

Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация.

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

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