Home

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

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

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://testerkiwi.blogspot.ru/2013/12/thoughts-around-test-estimation-irony.html

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

Сарказм просьбы оценить время на тестирование не только в том, что он походит на просьбу оценить, сколько времени понадобится на поиск всех-всех-всех пасхальных яиц на Пасху. Зачастую момент, когда тестирование останавливается, просто от нас не зависит.

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

Автор: Адам Ховард (Adam Howard)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=16

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

Вот экзамен для вас как для тестировщика: научите кого-нибудь тестировать за три дня. Эта задача встала передо мной, Катриной Клоки, Аароном Ходдером, Джорджией Чанн в январе 2014 года. Нас попросили трое суток поучаствовать в выпускной программе Assurity, которая дала миру немало тестировщиков.

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

Мир удивительных открытий

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

Автор: Алексей Потемкин, QA engineer компании "JetRuby Agency"

Оригинальная публикация:https://jetruby.com/ru/blog/kak-napisat-bug-report/

Автор: Фомин Владимир, Инфосеть-С, Senior Javascript Developer

Оригинальная публикация: https://habrahabr.ru/post/336030/

Однажды меня попросили рассказать о юнит тестировании в javascript, но прежде чем рассказывать о тестировании в мире front-end, надо было сделать небольшой обзор юнит тестирования как такового. В результате чего на свет и появилась эта статья, в которой я попытался рассказать о самых важных моментах в юнит тестировании.

Несмотря на различные трактовки юнит тестирования, есть несколько вещей которые объединяют этот термин.

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

Автор: Gerald M. Weinberg

Оригинальная публикация: http://secretsofconsulting.blogspot.ru/2017/10/my-most-challenging-experience-as.html

Перевод: Анастасия Данилкина

Читатели задали мне вопрос: «С каким самым сложным случаем вы столкнулись, работая программистом?»

Мы разрабатывали систему слежения для проекта Меркурий, которая должна была отправлять человека в космос и возвращать его живым обратно. Задача «вернуть живым» была сложной, но не единственной. Были и другие трудности:

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

Автор статьи: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: http://testerkiwi.blogspot.ru/2017/05/phased-vs-threaded-testing.html#more

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

Множество попыток было предпринято для того, чтобы смоделировать различные подходы к тестированию ПО. Большая часть из них наверняка вам известна: исследовательское и скриптованное, традиционное и Agile, тестирование и проверки, стандартное и контекстно-зависимое – а также многое, многое другое.

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

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

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

Автор: Кияшева Екатерина @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
    

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