Home

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

Оригинал статьи: http://katrinatester.blogspot.ru/2016/12/the-testing-pendulum-finding-balance-in.html

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

Насколько детальным должно быть исследовательское тестирование?

Я наткнулась на этот вопрос в темах Cambridge Lean Coffee, которые Джеймс Томас собирает в своем блоге. Этот вопрос я слышу достаточно часто, и регулярно использую одну и ту же аналогию в моем ответе: маятник тестирования.

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

Автор: Юлия Бурматова

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

При разработке нового продукта рано или поздно появляется вопрос «Нужно ли тратить деньги и время на тестирование?» Не буду говорить, что оно нужно всегда — это не так. На мой взгляд, есть ситуации, в которых тестирование нецелесообразно.

Когда стоит отказаться от тестирования

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

Автор: Вероника Латипова

Перед каждым разработчиком ПО рано или поздно встает задача оценки качества выпускаемого продукта. Зачастую руководители небольших проектов считают непозволительной роскошью прибегать к услугам профессиональных тестировщиков. Ведь, на первый взгляд, кто, если не сам разработчик или пользователь может наилучшим образом найти недостатки в программе? По сути, в этом случае все исследование сводится к бета-тестированию («Бе́та-тести́рование (англ. betatesting) – интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю»).

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

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Do You Need More Testers? A Context-Driven Exercise
Перевод: Сергей Высоцкий и RA

Эта дискуссия о лучших практиках в отрасли началась недавно на comp.software.testing:

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

Мой (слегка отредактированный для этого блога) ответ был...

• Если вы собираетесь найти все баги, то 100 тестеров на программиста будет куда лучше чем полтора. Ваши клиенты могут счесть это впечатляющим (если они захотят за это платить), но ваш финансовый директор взбесится. И все еще не будет никакой гарантии, что вы найдете все баги.
• Если вы хотите сэкономить, то 0 тестировщиков будет куда лучше, чем полтора на программиста. Это даже может сработать, но будет ли вы уверенны в том, что все важные вопросы о вашем продукте были заданы, а ответы на них были получены?
• Если уж вы собрались действительно сэкономить, то 0 тестеров на 0 программистов будет самым лучшим решением.

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

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2016/12/14/raise-problems-not-bugs/

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

Недавно я написал в своем твиттере примерно следующее:

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

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

Автор: Виктор Славчев (Viktor Slavchev)

Оригинал статьи: http://mrslavchev.com/2017/01/09/the-non-manual-unautomated-tester/

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

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

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

Автор: Джоэл Монтвелиски (Joel Montvelisky)

Оригинал статьи: http://qablog.practitest.com/complexity-also-a-bug/

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

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

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

Вот что там было написано:

Сложность – это тоже баг. Сложность повышается и будет продолжать повышаться.

Под этим предложением были заметки о презентации этого спикера.

Он был основателем/программистом/гиком/директором из Силиконовой Долины, и он рассказывал, как, с его точки зрения, повышается сложность программных продуктов, и как она будет повышаться в будущем.

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

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

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

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

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

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

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

Оригинал статьи: https://saucelabs.com/blog/dont-be-the-grinch-or-cross-browser-compatibility-problems-and-how-to-avoid-them

Автор: Майк Макрори (Mike Mackrory)

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

Как я стал поклонником онлайн-коммерции

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

Этого не было.

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

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

Ожидания от онлайн-опыта постоянно растут

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

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

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

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

Оригинал статьи: http://katrinatester.blogspot.ru/2016/12/take-control-of-your-test-environment.html

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

На конференции CAST 2015 Иоана Сербан читала доклад про "Взять под контроль ваше тестовое окружение". Это захватывающая и интересная история ее личного опыта с тест-окружениями. Посмотрите запись доклада, если еще ее не видели.

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

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

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2016/12/13/testing-without-requirements/

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

Этот вопрос звучит частенько: что же делать, вот приходишь ты на работу, или на проект, и должен тестировать, а ТРЕБОВАНИЙ НЕТ!

Для некоторых из нас крайне трудно представить себя в подобной ситуации.

Если вы работали только в местах, где тест-кейсы были документированы, а спецификации присутствовали, то сама мысль об этом выглядит для вас дикой.

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

На то есть множество причин – и очень хороших причин, хотя плохие среди них тоже присутствуют.

Но несмотря на причины, возможно, в какой-то момент вы обнаружите себя в этой ситуации и вас попросят протестировать то, для чего нет требований и, возможно, НИКТО не знает, как оно на самом деле должно работать.

Сейчас я объясню, что это вполне посильная задача – и вы не просто справитесь с ней, но справитесь блестяще, и улучшите свой навык тестировщика.