Как раз в вашем примеры смешались пункты 4 и 5:
* нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
* как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
Спасибо тем, кто уже ответил за меня :) Действительно, я допускаю, что есть продукты, у которых только один персонаж. А вот если их несколько — надо либо делить продукт, либо предоставлять разным персонажам возможность настраивать продукт под себя.
Ну тут всегда будет вечный спор, и любые крайности плохи.
Я лично видела ребят, которые 37 signals начитались и решили делать «что-нибудь, лишь бы работало», заказчики видели сырой продукт и говорили «простите, но нам от вас ничего не надо, ни сейчас, ни когда вы ошибки исправите», в итоге люди и бренды теряли репутацию.
Идеальных продуктов не бывает, это очень хорошо Влад Головач описал в своей книге. И стремиться за недоступным идеалом — плохо. Но иногда люди, оправдываясь этим подходом, делают полную фигню, портят репутацию и пишут продукт, который потом поддерживать и развивать не получится.
Сравнительные оценки есть в таблице для разных вариантов входных данных. Примерную оценку можно получить и по ним.
Глубину больше двух, к примеру, из приведённых там утилит поддерживает PICT. Но куча исследований, приведённых на том же сайте, показывает как редко встречаются ошибки в комбинации больше чем 2-х параметро, так что дальше pairwise редко кто заходит в покрытии — просто неоправданные затраты.
Правильно. Всё зависит от конкурентности рынка, т.е. от наличия «нецарапаных» вендоров :)
У майкрософта SDET'ов чуть больше, чем разработчиков (SDE). В некоторых компаниях с известными мировыми именами, в которых я работала, тестировщики зарабатывают больше разработчиков. Т.к. каждый мелкий баг, про который напишут в PC Magazine, стоит сотни тысяч долларов убытков.
Но это исключения, т.к. в основном рынки софта пока что — это рынки царапаных машин :)
Лучше всё-таки машина с царапиной, чем отсутствие и машины, и царапины :)
Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины (а софт у нас обычно не просто царапаный, а битый), разработчики важнее и это ОК.
На высококонкурентных продуктовых западных рынках софта роль тестировщика соответствует значимости разработки.
Но врядли когда-либо тестирование будет важнее, т.к. нет разработки — нет машины :)
В моём опыте обычно на разговоре «жить без них не можем, нужны автотесты» вызываются желающие, которым это интересно и которые понимают, зачем это нужно.
Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
Это иллюстрация в свободном стиле :) Графики основаны на опыте работы ТМом, РМом и консультантом в десятках компаний, и отражают лишь моё субъективное восприятие проблемы.
Я думаю, что самый главный критерий вложений в автоматизацию — это длительность последующей поддержки и развития продукта. Если мы над ним работали 5 лет, а впереди 10, то есть смысл вносить изменения в продукт для улучшения тестируемости и придумывать идеи по совершенствованию фреймворка автотестирования. Если же через полгода мы об этом проекте не вспомним, и на других проектах наработки переиспользовать не сможем, то почти всегда ручного тестирования достаточно и автоматизация будет пустой тратой.
1) Т.е. в вашем продукте не была заложена testability, и теперь вам сложно разрабатывать тесты? Вся статья примерно об этом.
2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?
Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
Ой, это я может не очень понятно выразилась. Когда что-то меняем по требованию заказчика, это всё-таки новая разработка и новый функционал.
Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
1) Не надо делать манкиджоб и нанимать манкилюдей. Манкипроблемы потом расхлёбывает весь проект, об чём и речь.
2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
Тестирование — это задача, которая является следствием невозможности выполнить что-то хорошо и правильно с первого раза, без взгляда со стороны.
Как будут называться люди, её выполняющие — неважно.
Я видела примерно следующую схему работы, результаты которой были просто отличными:
* Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
* Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
* Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.
В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
Это ужасно… я сейчас скажу это ужасное слово, от которого сводит зубы… но своевременно выписывать задачки — это дисциплина :( А потом — привычка.
А про текущие и глобальные: глобальные у меня в красивой майнд-карте и красивой гуглотабличке, с картинками и прочим, я их открываю не чаще раза в месяц. А оперативные — в таск-трекере.
* нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
* как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
Я лично видела ребят, которые 37 signals начитались и решили делать «что-нибудь, лишь бы работало», заказчики видели сырой продукт и говорили «простите, но нам от вас ничего не надо, ни сейчас, ни когда вы ошибки исправите», в итоге люди и бренды теряли репутацию.
Идеальных продуктов не бывает, это очень хорошо Влад Головач описал в своей книге. И стремиться за недоступным идеалом — плохо. Но иногда люди, оправдываясь этим подходом, делают полную фигню, портят репутацию и пишут продукт, который потом поддерживать и развивать не получится.
Глубину больше двух, к примеру, из приведённых там утилит поддерживает PICT. Но куча исследований, приведённых на том же сайте, показывает как редко встречаются ошибки в комбинации больше чем 2-х параметро, так что дальше pairwise редко кто заходит в покрытии — просто неоправданные затраты.
www.software-testing.ru/library/testing/general-testing/1559-pairwise-testing-with-pict
У майкрософта SDET'ов чуть больше, чем разработчиков (SDE). В некоторых компаниях с известными мировыми именами, в которых я работала, тестировщики зарабатывают больше разработчиков. Т.к. каждый мелкий баг, про который напишут в PC Magazine, стоит сотни тысяч долларов убытков.
Но это исключения, т.к. в основном рынки софта пока что — это рынки царапаных машин :)
Вообще, я сильно против проверки вёрстки и отображения автоматизированно, такие вещи всегда лучше смотреть глазками.
Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины (а софт у нас обычно не просто царапаный, а битый), разработчики важнее и это ОК.
На высококонкурентных продуктовых западных рынках софта роль тестировщика соответствует значимости разработки.
Но врядли когда-либо тестирование будет важнее, т.к. нет разработки — нет машины :)
В моём опыте обычно на разговоре «жить без них не можем, нужны автотесты» вызываются желающие, которым это интересно и которые понимают, зачем это нужно.
Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
А вот за некачественные продукты в случаях, когдя я не могу на это повлиять — обидно!
2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?
Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
Как будут называться люди, её выполняющие — неважно.
Я видела примерно следующую схему работы, результаты которой были просто отличными:
* Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
* Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
* Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.
В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
Баблосы и трудовые успехи — это всегда средство реализации тех самых жизненных целей, сами по себе они целями не являются.
А помрём все, и дети от этого не спасут. Вопрос только, как мы свои дни проживём, что после себя оставим.
А про текущие и глобальные: глобальные у меня в красивой майнд-карте и красивой гуглотабличке, с картинками и прочим, я их открываю не чаще раза в месяц. А оперативные — в таск-трекере.