Home

Автор: Кияшева Екатерина @ekiyasheva

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

Не секрет, насколько молоды профессии контроля и особенно обеспечения качества. Их значимость для IT индустрии давно обоснована. Но и сейчас, по мнению многих соискателей, это проходная ступень, которая не требует особых знаний и навыков. В моем багаже опыт работы с ПО из разных областей — ЖКХ, платежные терминалы, интернет-провайдер, retail и наконец игры. Во всех компаниях, на разных позициях, раньше и теперь я ручаюсь за качество продукта. Казус в том, что нигде я не получила убедительного ответа к какому именно «качеству» мы стремимся. Сегодня, на должности руководителя QA, я отвечаю на этот вопрос сама и хочу провести ликбез как можно шире.

Отмечу самые популярные требования к качеству.

— «Функционал должен соответствовать требованиям»
наличие настоящих требований и спецификаций роскошь, доступная не всем компаниям. И если требования есть, они целиком зависят от опыта аналитика, который к тому же может ошибиться в их структурировании и акцентировании из-за сыгравшего человеческого фактора. Не говоря уже о том, насколько шире и многообразней системы по сравнению со своими спецификациями.

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

— «После выпуска должно быть все хорошо/ удовлетворять пользователя»
по моему мнению это требование точнее остальных, проблема только в его неточности. В погоне за симпатией пользователя, тестирование становится необъятным, никогда не достаточно времени, чтобы убедиться в качественности и выпустить достаточно хороший продукт. Приходится выбирать наиболее критичное и смиряться с «кое-какерством». Это довольно грустно. И в этих условиях появляется привычка противопоставлять качество скорости.

Оригинал статьи: https://www.qasymphony.com/blog/5-trends-future-software-testing/

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

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

За ответами на эти вопросы мы обратились к 12 уважаемым, опытным лидерам мнений в области тестирования:

1. Джо Колантонио, основатель TestTalks & GuildConferences
   
2. Энджи Джонс, ведущий инженер по тестированию Twitter
   
3. Бобби Смит, директор R&D в QASymphony
   
4. Кит Клайн, исполнительный директор и руководитель QA-подразделения Tekmark Global Solutions
   
5. Пол Меррил, ведущий инженер по тестированию и основатель Beaufort Fairmont
   
6. Кевин Данн, вице-президент по бизнес-разработке и стратегии QASymphony
   
7. Брэндон Ципес, вице-президент DevOps в CPrime
   
8. Джозеф Ауэрс, Руководитель QA и тестирования в Centric Consulting
   
9. Райан Якель, директор продуктового маркетинга в QASymphony
   
10. Маш Хонда, вице-президент по тестированию в KMS Technology
    
11. Сума Дэниэл, тест-аналитик в Forty8fifty
    
12. Сунил Сегал, партнер TechArcis Solutions
    

За кулисами перемен в индустрии тестирования стоят как внешние, так и внутренние, отраслевые факторы. Давайте разберемся подробнее.

Автор: Джеймс Бах (James Bach)

Оригинал статьи: http://www.satisfice.com/blog/archives/1728

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

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

Путаница вокруг тестирования приводит к неэффективным обсуждениям, концентрирующихся на неважных вещах и игнорирующих важное. К примеру, вот когда нет смысла развивать беседу:

1. Когда вы говорите о том, сколько у вас тест-кейсов, вместо того, чтобы говорить о том, чем занимаются ваши тестировщики. Количество кейсов (500, 257, 39345) никому ни о чем не говорит и не демонстрирует, "сколько" вы на самом деле тестируете. Разработчики не хвастаются количеством созданных за рабочий день файлов – глупо считать файлы, буквы и строки кода. По той же причине глупо подсчитывать тест-кейсы. Одна и та же деятельность тестировщика может быть представлена как одним кейсом, так и миллионом их. Что, если тестировщик напишет программу, автоматически создающую сотню тысяч вариаций одного и того же кейса? Получится сто тысяч кейсов, или один большой кейс, или вообще не кейс? Впредь, услышав о точном количестве кейсов, попрактикуйтесь – напомните себе, что оно ни о чем вам не говорит. Затем уточните, что эти тесты делают. Что именно ими покрыто? Какие баги они могут найти? Какие риски привели к появлению этих кейсов?

Ранее мы уже публиковали подборки видео докладов со SQA Days 21 по темам автоматизации тестирования, тестирования мобильных приложений, тестирования производительности, тест-дизайна и тест-менеджемента.

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

1. Тестирование Нейронных сетей, Mikhail Chumakov, TechOps, Москва

2. Функциональное тестирование с ориентацией на пользователя, Виктория Юркевич, ООО Лаборатория Качества, Минск

3. Как аналитика помогает тестировщику, Егор Васильев, Trucker Path, Москва

4. 50 оттенков тестирования, Алексей Петров, ООО «Мэйл.Ру», Москва

Автор: Илья Ивасюв, тестировщик компании "Лаборатория качества"

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

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

Что такое локализация?

Языковая локализация – это процесс адаптации продукта, который ранее был переведен на несколько языков, для определенной страны или региона.

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

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: https://techbeacon.com/how-tech-giants-test-software-theres-no-one-way-qa

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

Команды и организации, стремящиеся наладить (или улучшить) усилия по тестированию своих продуктов, могут извлечь полезные уроки, наблюдая, как тестируют "взрослые" компании. Логично предположить, что такие корпорации, как Google, Microsoft, Amazon не смогли бы добиться успеха, не обращая пристального внимания на качество своих продуктов.

Однако если посмотреть на то, как эти компании подходят к обеспечению качества, можно отметить, что "серебряной пули" не существует. Вот как тестируют пять наиболее известных компаний:

Google: в поисках лучших практик

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

Чтобы этого добиться, Google использует четырехступенчатый процесс внедрения изменений в поисковик:

1. Тестирование внутренними силами (сотрудники Google).
2. Тестирование на crowdtesting-платформе.
3. Использование продукта сотрудниками Google в повседневной жизни.
4. Бета-тестирование: выпуск продукта для использования небольшой группой конечных пользователей.

Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/why-it-is-important-to-start-testing-as-early-as-possible/

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

Эксперты выделяют несколько этапов развития продукта:

• идея;
• стратегия;
• требования;
• дизайн;
• прототип и верстка;
• разработка и тестирование;
• поддержка.

Как правило, процесс тестирования начинается на предпоследнем этапе. Но правильно ли это? И в какой момент тестирование становится актуальной проблемой?

Оригинал статьи: http://katrinatester.blogspot.ru/2017/04/introducing-testers-to-developers.html

Автор: Катрина Клоки (Katrina Clokie)

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

Когда я заканчивала учебу на программиста, я создавала ПО без помощи тестировщиков. Под конец обучения я начала искать позицию разработчика, плохо разбираясь, с какими еще профессионалами мне придется сотрудничать в IT. Я не знала, кто такие тестировщики, чем они занимаются, и чем именно могут мне помочь. Думаю, я не одинока: в том же положении оказываются многие начинающие разработчики.

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

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

Автор: Брэд Томпсон (Brad Thompson)

Оригинал статьи: http://thinktesting.com/articles/role-of-confidence-in-software-testing/

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

Уверенность: "Твёрдая вера в кого-что-н., убеждённость". (http://dic.academic.ru/)

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

Оригинал статьи: https://beaglesays.wordpress.com/2017/07/16/the-illusion-of-quality-assurance/

Автор: Пол Симан (Paul Seaman)

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

Когда я только начинал тестировать, моя должность обозначалась как "Тестировщик". С тех пор прошло много лет, и я побывал как тестировщиком, так и QA-специалистом. Моя предыдущая должность называлась "Старший QA-аналитик", а нынешняя – "Старший инженер по тестированию". В официальных коммуникациях я всегда использую точное название своей должности, но вне их я представляюсь как тестировщик. Я горжусь этим званием и тем, что оно для меня значит. Уже долгое время я протестую против "QA-специалиста", потому что это название кажется мне глуповатым. К сожалению, его популярность растет. К еще большему сожалению, мне кажется, что люди, представляющиеся как QA, ставят QA выше и главнее тестирования. Проблема в том, что когда они описывают, что же такое "обеспечение качества", они на самом деле говорят о добросовестном, компетентном тестировании.

Не пошла ли мода называть тестировщиков "специалистами по обеспечению качества" из Agile? Я, если честно, понятия не имею. Не думаю, что Agile стоит у истоков переименования тестировщиков в QA-специалистов, но судя по разговорам тестировщиков на конференции LAST, Agile-методология внесла в эту проблему свой вклад. Не будем называть имен, вот краткое содержание диалогов тестировщиков:

• Если вы ждете, когда же начинать тестировать, сдвигаться влево уже поздно.
• Тестировщики – привратники на пути качества благодаря образу своего мышления.
• Мы обеспечиваем качество, тестировщики этого не делают. Мы убеждаемся, что все сделано правильно.