Комментарии 71
Все что описано в статье, мне, как разработчику, очевидно. Надеюсь, для некоторых тестировщиков тоже.
А чек-листы лучше составлять по каждому модулю, если система модульная. Это удобно. Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.
Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.
Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.
«Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.»
Такая логика предполагает, что изменения в одном модуле никак не скажутся на функциональности другого — что, к сожалению, далеко не всегда верно.
Такая логика предполагает, что изменения в одном модуле никак не скажутся на функциональности другого — что, к сожалению, далеко не всегда верно.
В идеале так и должно быть — изменения в одном модуле не должны сказываться на функциональности другого.
На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».
А вообще, в основной чеклист может быть занесено по одному — два не сложных теста каждого модуля, чтобы тестировщик хотя бы зашел в них и проверил живые ли они.
На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».
А вообще, в основной чеклист может быть занесено по одному — два не сложных теста каждого модуля, чтобы тестировщик хотя бы зашел в них и проверил живые ли они.
«Модули» — это хорошо, но обычно нет ничего настолько удалённого друг от друга. Когда разработчик исправляет ошибку, которая относится с точки зрения пользователя (и чаще всего тестировщика) к функционалу Х, логично проверять работу фичи Х. Только исправление могло вноситься в какую-то системную библиотеку, и проверить на самом-то деле важно сквозные моменты использования этого кода во всех фичах.
Поэтому я всегда стараюсь вместе с разработчиками, архитекторами, нарисовать карту взаимосвязей в продукте. Тогда после слов разработчика «я правил это здесь» я сразу по карте вижу, что могло быть затронуто и что нужно проверять. Постепенно эта карта расширяется и становится ОЧЕНЬ полезной: мы экономим время, не тестируем лишнее, быстрее находим свежие дефекты.
Поэтому я всегда стараюсь вместе с разработчиками, архитекторами, нарисовать карту взаимосвязей в продукте. Тогда после слов разработчика «я правил это здесь» я сразу по карте вижу, что могло быть затронуто и что нужно проверять. Постепенно эта карта расширяется и становится ОЧЕНЬ полезной: мы экономим время, не тестируем лишнее, быстрее находим свежие дефекты.
А как выглядит ваша карта взаимосвязей? Это случайно не импакт анализ имеется ввиду?
Для «некоторых» — да, но к сожалению далеко не для всех :(
Все правда, но только тестер это обычно намного менее оплачиваемая должность, чем разработчик, и времени на их развитие уделяют меньше, что очень печально. И при критическах багах с продакшена вопрос «а это вообще как тестировалось?» задается далеко не в первую очередь.
А работать с хорошим тестером, который знает бизнес процесс и может докопаться до далеко не очевидных багов очень и очень приятно.
PS. Чую, скоро в теме будут тонны баттхерта от разрабов на тестеров и наоборот.
А работать с хорошим тестером, который знает бизнес процесс и может докопаться до далеко не очевидных багов очень и очень приятно.
PS. Чую, скоро в теме будут тонны баттхерта от разрабов на тестеров и наоборот.
Насколько я сталкивался — зарплаты примерно равны. Нередко хороший синиор тестировщик получается больше среднего синиор программиста.
В хороших компаниях, с грамотным отношением к качеству и грамотными тестировщиками, это действительно так. Но 80% компаний берут на работу «студентов, потому что тестировать — это просто».
также студентов берут и в программисты, потому что программировать — это просто.
Но на деле оказывается, что для того чтобы создать команду нужно с этими студентами выпустить не один релиз. А сколько граблей можно встретить по дороге…
Но на деле оказывается, что для того чтобы создать команду нужно с этими студентами выпустить не один релиз. А сколько граблей можно встретить по дороге…
Ну к программистам вменяемые требования значительно чаще предъявляются. А в тестировщики я лично видела как берут людей, которые на вопрос «что такое тестирование?» отвечают «а вот прийду работать к вам тестировщиком и заодно узнаю».
Программистов можно хорошо проверить на собеседовании, т.к. от программиста требуется умение писать код, знать определенные фреймворки, подходы, алгоритмы — все это можно проверить задав вопрос: «А напиши ка мне...»
А что спрашивать у тестировщика, тем более начинающего? Прособеседовав парочку тестировщиков, я уже сам выучил какие бывают виды и типы тестирования, как можно протестировать ручку, чашку, окно, форму..., какое тестирование нужно проводить в первую очередь. Такими вопросами не проверишь сколько ошибок может найти тестировщик на реальном проекте. Можно только выяснить мыслит ли человек логически, мыслит ли нестандартно, проверить знает ли он теорию.
Так что вполне нормальная ситуация, когда говорят «а вот прийду работать к вам тестировщиком и заодно узнаю». Главное, чтобы было у кого узнавать и чтобы качество продукта не страдало.
А что спрашивать у тестировщика, тем более начинающего? Прособеседовав парочку тестировщиков, я уже сам выучил какие бывают виды и типы тестирования, как можно протестировать ручку, чашку, окно, форму..., какое тестирование нужно проводить в первую очередь. Такими вопросами не проверишь сколько ошибок может найти тестировщик на реальном проекте. Можно только выяснить мыслит ли человек логически, мыслит ли нестандартно, проверить знает ли он теорию.
Так что вполне нормальная ситуация, когда говорят «а вот прийду работать к вам тестировщиком и заодно узнаю». Главное, чтобы было у кого узнавать и чтобы качество продукта не страдало.
Ну я всегда даю задачки по тестированию :) И сразу вижу, делит ли человек продукт на составные части, декомпозирует ли функционал, как приоритизирует тесты и т.д. Тестирование чашек и карандашей показывает, как человек умеет ломать продукт. Знание терминологии — лишь его заинтересованность и готовность полистать статьи или книжки перед собеседованием.
А вот тестирование маленького продукта (на бумаге) показывает очень много: умение задавать вопросы для выяснения требований, определение граничных значений, приоритизация, вспомнит ли человек про нефункциональные тесты и т.д.
Теоретические вопросы «а что такое вот это?» и «а как делать вот то?» плохи тем, что на них человек отвечает «как написано в книжке/статье». А в реальной жизни он зачастую будет делать по-другому.
А вот тестирование маленького продукта (на бумаге) показывает очень много: умение задавать вопросы для выяснения требований, определение граничных значений, приоритизация, вспомнит ли человек про нефункциональные тесты и т.д.
Теоретические вопросы «а что такое вот это?» и «а как делать вот то?» плохи тем, что на них человек отвечает «как написано в книжке/статье». А в реальной жизни он зачастую будет делать по-другому.
Наталья, а не поделитесь ли парочкой таких «задачек» на бумаге? было бы очень интересно и весьма полезно!
Вот здесь будет веб-конференция, посвящённая поиску людей в ИТ: itbrunch.com.ua/it-recruitment/
Я на ней планирую как раз об этом рассказать. Участие абсолютно бесплатное, так что регистрируйтесь :)
Я на ней планирую как раз об этом рассказать. Участие абсолютно бесплатное, так что регистрируйтесь :)
Я думаю, что 80% компаний по этому же принципу и программистов набирают
Наверное, потому что руководство 80% компаний считает, что в принципе писать софт — это просто.
Особенно если сравнивать со строительством )
Особенно если сравнивать со строительством )
с точки зрения компаний, студенты будут работать за еду и писать тот же продукт, что и матерые программисты. А т.к. зачастую интересует только внешний вид, а не внутренности, то и сталкиваемся с тем, что эти компании нанимают неопытных джуниоров. К строительству тоже подойдет — штукатурка ляжет одинаково на кирпич и на пеноблоки и гипсокартонные перегородки от кирпичных внешне не будут отличаться после обработки. Только в таком строительстве и в таком ИТ проекте получится один исход: «Стоит нормально, только лучше не трогать, чтоб не поломать».
Чего вы на студентов так понаехали??? Проблема не в студентах, а в организации их работы — в нормальных конторах студентов доверяют опытным наставникам, которые и задачу грамотно поставят, и проверят выполненную работу указав на ошибки. Многие студенты уже после полугода работы набираются достаточно опыта и качественно делают свою работу.
>… времени на их развитие уделяют меньше, что очень печально
Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.
Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.
О! Это бич отрасли тестирования!
Сколько я уже видела младших тестировщиков, которые занимают эту роль лет этак пять и «хотят быть программистами» или аналитиками. И в разработке на развиваются, и в тестировании. А толку?
Главное правило тест-менеджера: брать на работу сотрудников, которые мечтают развиваться именно в тестировании.
Сколько я уже видела младших тестировщиков, которые занимают эту роль лет этак пять и «хотят быть программистами» или аналитиками. И в разработке на развиваются, и в тестировании. А толку?
Главное правило тест-менеджера: брать на работу сотрудников, которые мечтают развиваться именно в тестировании.
Тестирование разное бывает, — устроился человек на работу тестировщиком веб-сайтов в студию, которая делает эти сайты. А за душой у него 3 года пентеста, мозг у него работает на определенном уровне, на своих оборотах и шаблонах. Естественно, что он сквозь пальцы пропустит различие в пиксель или изменение курсора при наведении на ссылку, а поставит в приоритет blackbox и пентест. Как быть с такими тестерами? Разрывать им шаблоны и переучивать, либо держать в штате в роли личной армии? палка о двух концах.
Ну всё зависит от ваших целей и что от тестирования нужно. Если такие результаты не устраивают — очевидно, что нужно что-то менять. Либо мышление этого тестера, либо самого тестера.
Полностью согласен с Вами, но не вижу смысла переучивать тестера, если только забить определенные шаблоны в голову. А что обычно требуют от тестирование? — заказчик нашел баг, ага, надо тестера попинать за него. Не учитывая того факта, что заказчик баг нашел не в продукте и вообще это просто не реализовано и не прописано в ТЗ. За это по голове получают и ПМ и тестеры, ведь клиент всегда прав. А то, что они сами не додумали (ПМ и тестеры) функционал, это языковой барьер. Тут глубже копать надо, дело не в найденных багах. дело в отношении к разработке.
Вообще тестирование — это измерение качества продукта. Задача QA не в поиске ошибок и не в пропускании их в как можно меньшем количестве, а в предоставлении менеджменту или руководителю проекта актуальной и достоверной информации о его качестве. Качество продукта это очень многогранная характеристика. Туда входит и количество ошибок и их приоритеты, удобство им пользования, качество документации и много чего еще
Теоретически да, за несколькими поправками:
1) тестирование это не только предоставление информации, но и предоставление её в правильной последовательности, в нужные сроки, требуемом объёме и подходящем формате
2) информация «мы нашли такие-то баги» и формирование 25-ти разных диаграм из баг-трекера не принесёт много пользы, если в этом самом баг-трекере нет половины критичных багов.
1) тестирование это не только предоставление информации, но и предоставление её в правильной последовательности, в нужные сроки, требуемом объёме и подходящем формате
2) информация «мы нашли такие-то баги» и формирование 25-ти разных диаграм из баг-трекера не принесёт много пользы, если в этом самом баг-трекере нет половины критичных багов.
На моей практике, критические баги от заказчика — У меня не печатает на принтер! По факту в принтере — отсутствует бумага. Как определить эти критические моменты? Когда тестировщик не знает, что у заказчика в принтере нет бумаги? Естественно, такой баг (тестироващиком) описывается как не критичный, а потом возникает проблема — откуда знать заказчику, что у него нет в принтере бумаги, ведь вы же тестировали? а? не? Частенько так получается, когда ПМы все свешивают на тестеров, а тестеры с надеждой закрывают глаза.
в текущей практике QA engineer и software tester стали почему-то синонимами
хотя смешивать тестирование с QA — обеспечением качества — не совсем правильно
в задачи QA включаются например такие далекие от тестирования
процессы для обеспечения качества:
— внедрение систем continuous integration
— внедрение систем для code review
— проведение статического анализа кода
— внедрение систем проверки лицензионной чистоты кода
— build and release активности
хотя смешивать тестирование с QA — обеспечением качества — не совсем правильно
в задачи QA включаются например такие далекие от тестирования
процессы для обеспечения качества:
— внедрение систем continuous integration
— внедрение систем для code review
— проведение статического анализа кода
— внедрение систем проверки лицензионной чистоты кода
— build and release активности
Это да. Но qa звучит солидней и оплачивается выше, оттого самопровозглашают себя тестеры qa специалистами, забывая, что полномочия qa настоящего лежат недалеко от руководителя проекта.
звучит солидней — есть такое
хотя тут рекрутеры тоже постарались — вакансии с заголовком qa engineer через одну по факту требуют скилов мануальных мышкотыкателей и\или админов
хотя тут рекрутеры тоже постарались — вакансии с заголовком qa engineer через одну по факту требуют скилов мануальных мышкотыкателей и\или админов
Недавно у меня был необычный опыт, я очень удивилась.
Мы предоставляем услуги по аутсорсу тестирования. Я на проект выделяю ведущего тестировщика, прошу добавить его в чат разработчиков на проекте. Нас добавляют с комментарием «познакомьтесь, это наши тестеры». Мой тестировщик мне лично пишет: «Наташа, а тебе не обидно, что тебя назвали тестером?».
ОБИДНО??? Вот так я невзначай узнала у ТЕСТИРОВЩИКА, что его это оказывается может задеть. Да я горжусь что меня тестером назвали, я ж тестер как-никак! А многие бодаются, стесняются, не любят таких слов.
И вот что я вам точно скажу: в том небольшом количестве компаний, где работают правильные тестировщики и где к качеству относятся тоже правильно, слова «тестер» и «тестировщик» — это очень хорошие слова :)))
Мы предоставляем услуги по аутсорсу тестирования. Я на проект выделяю ведущего тестировщика, прошу добавить его в чат разработчиков на проекте. Нас добавляют с комментарием «познакомьтесь, это наши тестеры». Мой тестировщик мне лично пишет: «Наташа, а тебе не обидно, что тебя назвали тестером?».
ОБИДНО??? Вот так я невзначай узнала у ТЕСТИРОВЩИКА, что его это оказывается может задеть. Да я горжусь что меня тестером назвали, я ж тестер как-никак! А многие бодаются, стесняются, не любят таких слов.
И вот что я вам точно скажу: в том небольшом количестве компаний, где работают правильные тестировщики и где к качеству относятся тоже правильно, слова «тестер» и «тестировщик» — это очень хорошие слова :)))
в диалогах это замечал тоже когда-то
Слово «тестер» могут исправлять вовсе не потому, что обижаются,
а если например в компании (обычно характерно для больших >1000 человек бодишопов)
принята внутренняя градация квалификации тестеров и где QA-engineer квалифицируется и соответственно оплачивается выше тестера
Тот факт, что персонаж, занимающий позицию QA-engineer, может не знать что такое вообще qa и по факту заниматься тестированием — никого не волнует
Но если вы скажите такому перцу, что он тестер — он вас поправит
потому, что в терминах компании, где он работает, он просто называется по-другому
В таком контексте объяснять человеку, что у него позиция называется неправильно — т.к занимается он вовсе не внедрением процессов обеспечения качества, а контролем качества — причем в ухком контексте — уже как-то и глупо
Товарищ мой стебал меня, говоря:
— как ты сказал, кем ты там работаешь?.. амперметром?.. а ну да — тастером
Слово «тестер» могут исправлять вовсе не потому, что обижаются,
а если например в компании (обычно характерно для больших >1000 человек бодишопов)
принята внутренняя градация квалификации тестеров и где QA-engineer квалифицируется и соответственно оплачивается выше тестера
Тот факт, что персонаж, занимающий позицию QA-engineer, может не знать что такое вообще qa и по факту заниматься тестированием — никого не волнует
Но если вы скажите такому перцу, что он тестер — он вас поправит
потому, что в терминах компании, где он работает, он просто называется по-другому
В таком контексте объяснять человеку, что у него позиция называется неправильно — т.к занимается он вовсе не внедрением процессов обеспечения качества, а контролем качества — причем в ухком контексте — уже как-то и глупо
Товарищ мой стебал меня, говоря:
— как ты сказал, кем ты там работаешь?.. амперметром?.. а ну да — тастером
Тут еще частенько возникает проблема в том что народ иногда забывает про четыре Q и месит вме в одну кучу: Quality assurance, Quality Approval, Quality Control, Quality check. (Я даже не лезу в ITIL, там веселее).
В общем виде: обеспечение качества продукта (не только ПО) состоит в контроле производственного процесса (Quality assurance при производстве элементной базы должно контролировать даже уровень загрязнения воздуха в рабочих зонах, а при разработке ПО в эти процедуры как раз входит code review и сверка накарябанного кода с проектной документацией), проверке работоспособности полученного продукта (Quality Approval), Quality Control отлавливает недокументированный функционал типа нажатия 144 раза на вершний правый угол кнопки в IE 2.0 когда Луна в тротике Рака, и элементарная операция это Check (Quality Check), эта операция имеет свой номер и лицо ответственное за ее проведение, которое можно бить если в заданном чеке у клиента чтото вылезло.
Так вот… К чему это я. QA engineer — это лицо занимающееся инженерной деятельностью (в идеале), то есть планирование операций по Quality Assurance, Approval & Control для технического персонала, а технический персонал это либо tester, либо QA-tech.
Хотя это не идеал к сожалению. Введение адекватных процессов тестирования и отладки продукта в IT сфере это мечты :) Так как требуется адекватное начальство, адекватный HR, адекватные разрабы(как инженеры-планировщики, так и техники-кодеры) и адекватные тестеры(опять же как и постановщики-планировщики, так и эмуляторы клацательных скриптов). Одновременно все эти люди в одной компании резко работают :)
В общем виде: обеспечение качества продукта (не только ПО) состоит в контроле производственного процесса (Quality assurance при производстве элементной базы должно контролировать даже уровень загрязнения воздуха в рабочих зонах, а при разработке ПО в эти процедуры как раз входит code review и сверка накарябанного кода с проектной документацией), проверке работоспособности полученного продукта (Quality Approval), Quality Control отлавливает недокументированный функционал типа нажатия 144 раза на вершний правый угол кнопки в IE 2.0 когда Луна в тротике Рака, и элементарная операция это Check (Quality Check), эта операция имеет свой номер и лицо ответственное за ее проведение, которое можно бить если в заданном чеке у клиента чтото вылезло.
Так вот… К чему это я. QA engineer — это лицо занимающееся инженерной деятельностью (в идеале), то есть планирование операций по Quality Assurance, Approval & Control для технического персонала, а технический персонал это либо tester, либо QA-tech.
Хотя это не идеал к сожалению. Введение адекватных процессов тестирования и отладки продукта в IT сфере это мечты :) Так как требуется адекватное начальство, адекватный HR, адекватные разрабы(как инженеры-планировщики, так и техники-кодеры) и адекватные тестеры(опять же как и постановщики-планировщики, так и эмуляторы клацательных скриптов). Одновременно все эти люди в одной компании резко работают :)
(материализовался в привычный толсто-зеленый образ):
А есть ли действительная польза от code review? Насколько я испытал на своей шкуре, это сталкивание двух (или более) взглядов на код, чаще всего только тормозящий разработку.
Лично я вижу профит в этом только в обучении менее опытного кодера матерым.
Наконец, если выразить уж совсем субьективное имхо — мое фи код-ревью!
А есть ли действительная польза от code review? Насколько я испытал на своей шкуре, это сталкивание двух (или более) взглядов на код, чаще всего только тормозящий разработку.
Лично я вижу профит в этом только в обучении менее опытного кодера матерым.
Наконец, если выразить уж совсем субьективное имхо — мое фи код-ревью!
Код-ревью — это хорошо, особенно когда есть ответственный за модуль, и он делает ревью всех коммитов, и всегда в курсе что в его модуле происходит и не допускает бардака.
И да, ошибок на этапе код-ревью тоже много отлавливается, если проводить его не для галочки.
И да, ошибок на этапе код-ревью тоже много отлавливается, если проводить его не для галочки.
> А есть ли действительная польза от code review?
> это сталкивание двух… взглядов на код, чаще всего только тормозящий разработку.
примерно то же можно сказать о тестировании
к слову о толсто-зеленом образе
известен очень эффективный способ обойтись без код-ревью, тестирования, как отдельной активности,
и без qa/тестировщиков как таковых: просто начать штрафовать дэвов за баги, отданые заказчику в релизах
после внедрения такой практики обычно отношение и к код-ревью, и к тестированию может поменяться
> это сталкивание двух… взглядов на код, чаще всего только тормозящий разработку.
примерно то же можно сказать о тестировании
к слову о толсто-зеленом образе
известен очень эффективный способ обойтись без код-ревью, тестирования, как отдельной активности,
и без qa/тестировщиков как таковых: просто начать штрафовать дэвов за баги, отданые заказчику в релизах
после внедрения такой практики обычно отношение и к код-ревью, и к тестированию может поменяться
— Взглянуть на код и логику свежим взглядом (как своим, так и чужими)
— Когда сам расскажешь другим людям про свой код (особенно про алгоритмически или логически сложные места) — сам можешь понять в чем могут быть проблемы
— Познакомиться с кодом и логикой, которая происходит в параллельном компоненте/классе
— Научиться у гуру и научить недогуру
— Получить фидбек на свою работу у коллег
— Синхронизировать понятия хорошего кода с коллегами (ведь хорошо когда код в проекте хороший не только ИМХО)
— Найти баги
— Найти забытые грязные хаки
— Найти забытые закоментированые участки кода и прочий мертвый код
У нас на ревью (чаще, правда, не кода) порой была практика аля «до конца недели каждый должен найти по 5 уникальных проблем и описать их в трекере» — мотивирует почитать не для галочки. :)
— Когда сам расскажешь другим людям про свой код (особенно про алгоритмически или логически сложные места) — сам можешь понять в чем могут быть проблемы
— Познакомиться с кодом и логикой, которая происходит в параллельном компоненте/классе
— Научиться у гуру и научить недогуру
— Получить фидбек на свою работу у коллег
— Синхронизировать понятия хорошего кода с коллегами (ведь хорошо когда код в проекте хороший не только ИМХО)
— Найти баги
— Найти забытые грязные хаки
— Найти забытые закоментированые участки кода и прочий мертвый код
У нас на ревью (чаще, правда, не кода) порой была практика аля «до конца недели каждый должен найти по 5 уникальных проблем и описать их в трекере» — мотивирует почитать не для галочки. :)
Сейчас работаю над такой задачей: Завести как можно меньше багов, те есть находить дефекты, которые исправят сейчас. Желательно, без трекеров и прочей волокиты. На те, что не признают подлежащими фиксу времени не тратить.
Искать баги просто чтоб менеджер знал, имел информацию и мог принимать решения не вижу ни смысла, ни радости.
Как-нибудь напишите об одном месяце и миллионе строк кода. Любопытно и полезно, я думаю.
Еще хотелось бы услышать ваше мнение о разнице в тестировании проектов и продуктов, b2b и b2c, чует мое сердце, разница есть и приличная, а на b2c поработать не довелось.
Искать баги просто чтоб менеджер знал, имел информацию и мог принимать решения не вижу ни смысла, ни радости.
Как-нибудь напишите об одном месяце и миллионе строк кода. Любопытно и полезно, я думаю.
Еще хотелось бы услышать ваше мнение о разнице в тестировании проектов и продуктов, b2b и b2c, чует мое сердце, разница есть и приличная, а на b2c поработать не довелось.
Про «отсутствие трекеров и волокиты» — сталкивалась с таким, но редко. Обычно всё-таки нужны баги, которые и через месяц не грех исправить, но прямо сейчас времени нет.
Опять же, всё зависит от контекста, тестирование везде разное и цели у него разные. Возможно, в вашем случае именно так и должно быть, именно это — самое подходящее тестирование. Каждый второй шаблонизированный тестировщик будет пускать ахи и охи, говоря, что «баги надо заносить все!». Но умение подстраиваться под нужды конкретного проекта — искусство.
Про тесты на миллион строк кода как-нибудь напишу, а про b2b и b2c врядли. Опыт большой и там и там, но магических отличий я не вижу. Между 2-мя проектами b2b или 2-мя b2c зачастую отличия больше, чем между b2b и b2c. Это как отличия в ДНК: между мужчиной и женщиной их больше, чем между мужчиной и обезьяной-самцом или женщиной и обезьяной-самкой :)))
Опять же, всё зависит от контекста, тестирование везде разное и цели у него разные. Возможно, в вашем случае именно так и должно быть, именно это — самое подходящее тестирование. Каждый второй шаблонизированный тестировщик будет пускать ахи и охи, говоря, что «баги надо заносить все!». Но умение подстраиваться под нужды конкретного проекта — искусство.
Про тесты на миллион строк кода как-нибудь напишу, а про b2b и b2c врядли. Опыт большой и там и там, но магических отличий я не вижу. Между 2-мя проектами b2b или 2-мя b2c зачастую отличия больше, чем между b2b и b2c. Это как отличия в ДНК: между мужчиной и женщиной их больше, чем между мужчиной и обезьяной-самцом или женщиной и обезьяной-самкой :)))
> Искать баги просто чтоб менеджер знал, имел информацию и мог принимать решения не вижу ни смысла, ни радости.
А смысл в этом следующий. Тестирование — работа с качеством продукта, то есть со степенью соответствия продукта его назначению и требованиям (а менеджер ведет продукт от идеи до деплоя). И результат тестирования — заключение о качестве конкретного релиза. Хотя бы потому, что тест — это проверка (чего? соответствия чего чему? какой уровень соответствия?). В конечном итоге решение о выпуске принимает менеджер, поэтому если он не знает уровня качества, решение он принять не может. А радость для тестировщика заключается в следующем — если менеджер выпускает продукт с отрицательной визой тестирования — тестирование не несет ответственности.
Что касается, как называть QA или тестирование, проверку качества продукта, то QA больше работает с процессами и на предупреждение дефектов, нежели с конкретным продуктом.
А смысл в этом следующий. Тестирование — работа с качеством продукта, то есть со степенью соответствия продукта его назначению и требованиям (а менеджер ведет продукт от идеи до деплоя). И результат тестирования — заключение о качестве конкретного релиза. Хотя бы потому, что тест — это проверка (чего? соответствия чего чему? какой уровень соответствия?). В конечном итоге решение о выпуске принимает менеджер, поэтому если он не знает уровня качества, решение он принять не может. А радость для тестировщика заключается в следующем — если менеджер выпускает продукт с отрицательной визой тестирования — тестирование не несет ответственности.
Что касается, как называть QA или тестирование, проверку качества продукта, то QA больше работает с процессами и на предупреждение дефектов, нежели с конкретным продуктом.
Лирика.
А на практике менеджеру не интересно, сколько некритичных для выпуска дефектов есть в продукте.
Решение по выпуску зависит от того, есть ли критичные для выпуска баги. На них и стоит тратить время.
А на практике менеджеру не интересно, сколько некритичных для выпуска дефектов есть в продукте.
Решение по выпуску зависит от того, есть ли критичные для выпуска баги. На них и стоит тратить время.
Не лирика, некоторые так живут. Что касается что неинтересно, сколько некритичных дефектов — вообще-то интересно, но конечно не настолько, насколько про критичные. Кстати решение о критичности — бывает и совместным решением, менеджера и тестировщика, а то и менеджера и тестировщика и аналитика.
В общем смысл моего предыдущего поста в том, что измерение качества продукта — отдельное дело, и результат измерения — вход для процесса определения дальнейших действий. То есть результат тестирования не баг в трекере, а картина по продукту, желательно в разрезе корневых причин. Сам по себе баг не очень-то нужен, нужно исследование о работоспособности продукта в некоторых условиях (например, в условиях платного MS SQL, и может не волновать, работает ли на SQL Express, пусть там хоть падает — менеджер например знает, что в такие места поставляться не будет).
В общем смысл моего предыдущего поста в том, что измерение качества продукта — отдельное дело, и результат измерения — вход для процесса определения дальнейших действий. То есть результат тестирования не баг в трекере, а картина по продукту, желательно в разрезе корневых причин. Сам по себе баг не очень-то нужен, нужно исследование о работоспособности продукта в некоторых условиях (например, в условиях платного MS SQL, и может не волновать, работает ли на SQL Express, пусть там хоть падает — менеджер например знает, что в такие места поставляться не будет).
К счастью, не всегда. Практика «не выпускать релиз с больше чем N некритичных багов на KLOC» достаточно популярна. Но естественно всё зависит от проекта и его текущих приоритетов.
Всегда думал, что правильно составленый список тест-кейсов — залог качественного тестирования продукта.
Тестирование — это не поиск ошибок, это процесс разработки системы. Чтобы понятна была мысль, вот риторический вопрос (разработчикам): сколько времени вы проводите, отлаживая код? правильно, 80% минимум.
Так что, тестирование — это не работа тестировщика (точнее, не только его), но работа разработчика.
Соответственно, в ход пущены автоматизированные средства: юнит-тесты, автоматические, интеграционные, реже — стресс-тесты, и это все ДО того, как готовый модуль попадет в беспощадные лапы тестировщиков.
При таком подходе тестировщики скорее выявляют не столь явные ошибки, а скорее, логичное с точки зрения ТЗ, но не очень понятное человеку, поведение системы, юзабилити-проблемы, реже — баги из области «проявляются при особом расположении звезд», а также те, на которые чел с обычными девелоперскими мозгами ни за что не обратит внимания проверить, но зато очень часто натыкаются те юзеры, которые всю жизнь провели за бумажками, а тут их обязали использовать эти страшные и коварные консервные банки с непознанной душой.
Так что, тестирование — это не работа тестировщика (точнее, не только его), но работа разработчика.
Соответственно, в ход пущены автоматизированные средства: юнит-тесты, автоматические, интеграционные, реже — стресс-тесты, и это все ДО того, как готовый модуль попадет в беспощадные лапы тестировщиков.
При таком подходе тестировщики скорее выявляют не столь явные ошибки, а скорее, логичное с точки зрения ТЗ, но не очень понятное человеку, поведение системы, юзабилити-проблемы, реже — баги из области «проявляются при особом расположении звезд», а также те, на которые чел с обычными девелоперскими мозгами ни за что не обратит внимания проверить, но зато очень часто натыкаются те юзеры, которые всю жизнь провели за бумажками, а тут их обязали использовать эти страшные и коварные консервные банки с непознанной душой.
Автору могу порекомендовать ознакомиться с ACC от Google — очень помогает в распределении приоритетов в тестировании, и создании общей картины потенциальных проблем в приложении.
Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает.
Хм, так почитаешь и начинаешь думать, что сможешь работать тестером, причём будешь хорошим тестером. :) А если серьёзно, то не понимаю а как можно тестировать по другому? Я хоть и не тестер, но автоматические тесты разного уровня пишу постоянно, просто чтобы зафиксировать поведение унаследованного кода, о котором толком ничего неизвестно, вплоть до того, что фиксируя что-то тестом не понимаешь баг это или фича. А через некоторое время получаешь багрепорт, пишешь на него тест, фиксируешь баг, исправляешь и видишь другой свалившийся тест, думаешь «приплыли, опять ночь не спать», смотришь тест, а он инверсия к бажному :) Но, отвлёкся, по мне так самое естественное зафиксировать основной поток выполнения, самую штатную операцию. Если говорить, например, о переводе средство с одного счёта на другой, то сначала делаю перевод с одного аккаунта на другой имеющейся на первом суммы, и только когда увижу зелененький начинаю продумывать «а если денег не хватит» и т. п., и только потом лезу в код чтоб покрыть ветвления и переполнения. Как может быть по другому просто не представляю.
Так вот, фиксируя тестом
Хм, так почитаешь и начинаешь думать, что сможешь работать тестером, причём будешь хорошим тестером. :) А если серьёзно, то не понимаю а как можно тестировать по другому? Я хоть и не тестер, но автоматические тесты разного уровня пишу постоянно, просто чтобы зафиксировать поведение унаследованного кода, о котором толком ничего неизвестно, вплоть до того, что фиксируя что-то тестом не понимаешь баг это или фича. А через некоторое время получаешь багрепорт, пишешь на него тест, фиксируешь баг, исправляешь и видишь другой свалившийся тест, думаешь «приплыли, опять ночь не спать», смотришь тест, а он инверсия к бажному :) Но, отвлёкся, по мне так самое естественное зафиксировать основной поток выполнения, самую штатную операцию. Если говорить, например, о переводе средство с одного счёта на другой, то сначала делаю перевод с одного аккаунта на другой имеющейся на первом суммы, и только когда увижу зелененький начинаю продумывать «а если денег не хватит» и т. п., и только потом лезу в код чтоб покрыть ветвления и переполнения. Как может быть по другому просто не представляю.
Так вот, фиксируя тестом
1. если денег не хватит
2. если денег слишком много
3. не потерялось ли по дороге
4. отменяется ли в случае ошибки (разрыва связи, выкл. сервера и т.д.) и правильно ли отменяется
5. корректна ли сумма? (только цифры, только положительна)
6. нет ли накапливающейся ошибки округления?
7. а если кнопочку нажали два раза?
8. а если забыли нажать и закрыли окно?
9. а если параллельно два перевода на\с один из счетов?
10. если валюта разная и в те мс, пока идет перевод, курс валют поменялся?
и т.д.
многие ошибки ой как неочевидны, а еще многие и вовсе заставляют идти на компромисс с человеческим пониманием процессов конкретной области.
2. если денег слишком много
3. не потерялось ли по дороге
4. отменяется ли в случае ошибки (разрыва связи, выкл. сервера и т.д.) и правильно ли отменяется
5. корректна ли сумма? (только цифры, только положительна)
6. нет ли накапливающейся ошибки округления?
7. а если кнопочку нажали два раза?
8. а если забыли нажать и закрыли окно?
9. а если параллельно два перевода на\с один из счетов?
10. если валюта разная и в те мс, пока идет перевод, курс валют поменялся?
и т.д.
многие ошибки ой как неочевидны, а еще многие и вовсе заставляют идти на компромисс с человеческим пониманием процессов конкретной области.
Андрей, отличный тест-набор!!!
Только не хватает ПЕРВОГО пункта — «а что если всё хорошо?» :)
То есть и эти 10 прогнать надо, и самый основной. И НАЧАТЬ нужно с ОСНОВНОГО, когда всё хорошо. Но ведь основное редко ломается, поэтому тестировщики часто начинают сразу с негативных сценариев. А критичность негативного в разы меньше, чем самой стандартной ситуации.
Только не хватает ПЕРВОГО пункта — «а что если всё хорошо?» :)
То есть и эти 10 прогнать надо, и самый основной. И НАЧАТЬ нужно с ОСНОВНОГО, когда всё хорошо. Но ведь основное редко ломается, поэтому тестировщики часто начинают сразу с негативных сценариев. А критичность негативного в разы меньше, чем самой стандартной ситуации.
Это всё потом, сначала убедиться, что фича в штатном случае работает именно как я её понимаю. Иначе можно попасть в ситуацию вроде такой: при переводе автоматически списываются проценты с отправителя и получателю приходит уже уменьшая на, скажем, 0,8% сумма. Не сделав этот тест первым я многие остальные тесты напишу неправильно и буду искать ошибку там где её нет.
Да, это самый глубокий корень багов — недостаточно формализированное или непонятое ТЗ.
Отчасти эту проблему помогает решить методика BDD.
Отчасти эту проблему помогает решить методика BDD.
Ну, в моём случае всё ещё хуже. Есть исходники, которые как-то работают. Ни ТЗ, ни внятной документации нет, автора не найти, да и вряд ли он что помнит. Собственно и пытаюсь привести проект к виду как будто он разработан с помощью BDD/TDD (толком разницу между ними не понял), восстановвить ТЗ так сказать.
Ну это вы как обычный человек отвечаете :)) А не как тестировщик ;))
Где-то так, да. Причем чем больше проект тем ближе это к истине.
НЛО прилетело и опубликовало эту надпись здесь
> И да пребудет с вами сила!
Логика, не магия.
Логика, не магия.
Обожаю выковыривать нестандартные баги. Это такая форма айтишношго троллинга. Типа, " а вот если я в вот тут вот нажму четыре кнопки, то вот там вот шнурки развязываются, а не должны".
Может вы и правы, имея ввиду тестирование вебсайтов, которые все равно через полгода будут переделаны и ненайденные баги пропадут необнаруженными.
Но есть и другие продукты, с другими требованиями. например, Java компилятор и JVM. Казалось бы, прогнали компилятор через себя, работает, что еще надо? Но нет, при тестировании ставилась задача проверить все утверждения из спецификаций. Написано, что размер кода метода должен быть больше нуля и меньше 65536 — значит надо сделать методы длиной 0, 1, 65535 и 65536, и если 65536 машиной не отвергается — файлишь баг. Но это самай простая ситуация. А есть еще правила вывода типов переменных при слиянии ветвей исполнения, поведение volatile переменных (до появления нынешней memory model) и многие другие пыльные углы. И если бы тестировщики и разработчики относились к тестированию также как Вы, то Java никогда не стала бы столь популярной как сейчас.
Но есть и другие продукты, с другими требованиями. например, Java компилятор и JVM. Казалось бы, прогнали компилятор через себя, работает, что еще надо? Но нет, при тестировании ставилась задача проверить все утверждения из спецификаций. Написано, что размер кода метода должен быть больше нуля и меньше 65536 — значит надо сделать методы длиной 0, 1, 65535 и 65536, и если 65536 машиной не отвергается — файлишь баг. Но это самай простая ситуация. А есть еще правила вывода типов переменных при слиянии ветвей исполнения, поведение volatile переменных (до появления нынешней memory model) и многие другие пыльные углы. И если бы тестировщики и разработчики относились к тестированию также как Вы, то Java никогда не стала бы столь популярной как сейчас.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование — это не поиск ошибок!