Home

Автор: Шрини Кулкарни (Shrini Kulkarni)

Оригинал статьи: http://shrinik.blogspot.ru/2016/12/test-manager-vs-project-manager.html

Перевод: Ольга Алифанова

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

Как тест-менеджер, я черпаю свою энергию в поиске проблем и сообщении о них наилучшим доступным образом. Честно говоря, когда моя команда видит проблемы в приложении, это нас мотивирует. Мы восхищены, если находим новые, свеженькие баги. Мы отмечаем каждую находку, и я вижу, как блестят глаза у моих подчиненных. Любые известия о странном поведении, крашах, нестабильной работе кода, падении окружения, делают нас счастливыми. Иногда я думаю, что мы просто садисты.

Рядом со мной сидит мой друг и коллега, прожект-менеджер. Он вечно взволнован. Каждый раз, когда кто-то из моей команды просит разъяснений, у менеджера сбивается сердечный ритм, потому что он думает – о боже, нет, они нашли еще один баг! Во время наших встреч, посвященных багам, я гордо говорю, что сегодня мы нашли 40 новых багов, то есть всего за эту неделю – 370, 80 из которых критические! ПМ, придя в себя, отвечает – ок, какие из исправленных багов уже прошли ретест? Какие области приложения относительно стабильны? Что хорошего мы можем сообщить нашим заказчикам?

Автор: Александр Мешков

Оригинальная публикация

Не так давно, буквально три года назад, мир тестирования всполошила новость о том, что теперь наконец появится стандарт в области тестирования программного обеспечения, который будет выпущен как ISO (International Organization for Standardization).

Почему это так важно было для мира тестирования?

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

— Тестирование? Что? Это анкеты заполнять? Программы? Не, не слышали?

И это не просто мнение знакомых, даже такие мировые стандарты в области управления ИТ, как COBIT5 или ITIL пишут всего пару строк о тестировании.

В конце февраля сообществом COMAQA.BY была организована очередная конференция COMAQA Winter 2017. Спикеры из ведущих IT-компаний собрались вместе, чтобы рассказать о своем опыте в тестировании. Конференция проходила в два потока. Сегодня мы хотим поделиться записями докладов, озвученных в первый день, в которых:

1. Роман Сорока рассказал про логические инструменты в арсенале тестировщика.

2. Александр Павлов в своём выступлении “Эволюция браузерных тестов” поделился опытом работы с Selenium.

3.Дмитрий Татти выступил на тему “Тест длиною в паранойю” о рациональности внедрения автоматизации тестирования.

4. Роман Иовлев пытался заглянуть в будущее автоматизации тестирования.

5. Дмитрий Лемешко осветил ряд вопросов по тестированию мобильных приложений

6. Вадим Мустяца представил тему “Alfa-BDD: Как масштабировать BDD и побеждать айсберги”

7. Филипп Кекс поделится собственным опытом и об автоматизированном тестировании в играх.

Автор: Татьяна Бирюкова

Оригинальная публикация: http://quality-lab.ru/cross-browser-compatibility-testing/

Как часто заказчики ПО хотят, чтобы их детище работало у любого пользователя, в любых условиях и окружениях? Здесь будет уместен ответ — всегда. Что же скрывается за этой фразой? Что именно требуется для проверки от тестировщика? И как он будет воплощать требования в жизнь?
Не секрет, что WEB-приложения имеют отличия от десктопных. Самое главное отличие и опасение — это то, что мы не знаем, в каком браузере и уж тем более — в какой версии этого браузера откроет приложение наш пользователь.

На прошедшем Я.Субботнике по тестированию, который проходил в Нижнем Новгороде 28 января, сотрудники компании Яндекс и приглашенные спикеры делились опытом работы в интересующей нас области. Темы докладов были разнообразными и интересными. Убедитесь сами - ниже вы можете ознакомиться с опубликованными материалами:

1. Облачные тестовые среды Яндекс.Маркета, Олег Бекетов, Яндекс

2. Back-to-back автотесты: практические вариации, Максим Свентух, Яндекс

3. 1001 ночь QA-менеджера, Дмитрий Петунин, Intel

4. Тестовые базы данных как сервис, Василий Окунев, Павел Новицкий, Яндекс

5. Десктопные GUI-тесты на Python: Win32 API, MS UI Automation, и немного о будущем, Василий Рябов, Aquantia Rus

6. Анализ логов в тестировании — что объединяет QA, аналитику и DevOps, Ирина Пчелинцева, Яндекс

Автор: Коллин Грин (Collin Greene)

Оригинал статьи: https://medium.com/@collingreene/why-product-security-is-hard-52e3f73178#.l1376jjjv

Перевод: Ольга Алифанова

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

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

Создание ПО – тяжелая работа

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

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

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

На юбилейной пятой международной IT-конференции Стачка в г. Ульяновске прозвучало множество докладов от специалистов в сфере информационных технологий. Ниже представлены доклады тех, кто представлял на конференции тему тестирования ПО.

1. Чернобров Михаил (Rambler & Co) поделился опытом тестирования фронтенда.

2. Ваказов Рамис (SimbirSoft) рассказал о важности внедрения тестирования на начальных этапах проекта.

3. Малейков Алексей (HTML Academy) изучал вопрос о регрессионном тестировании вёрстки.

Автор: Маарет Пиаярви (Maaret Pyhäjärvi)

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/how-to-explore-with-intent-exploratory-testing-self-management

Перевод: Ольга Алифанова

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

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

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

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

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