Comments 27
Смотря какие проекты и о каких продуктах идет речь, конечно, но есть еще полно других видов полезного тестирования, упущенных в статье, хотя бы тестирование безопасности. Статья достаточно поверхностная и капитаноочевидностная, на мой взгляд.
inventos.ru/produkty/#top
Когда начал заниматься организацией, как раз «очевидностных» статей мне не хватало. С остальным согласен, будет продолжение.
Когда начал заниматься организацией, как раз «очевидностных» статей мне не хватало. С остальным согласен, будет продолжение.
Судя по вакансиям тестировщиков вы уже набрали :)
Возможно мне это кажется очевидным, потому что я тестировщик, а менеджеры, особенно не айти-менеджеры или менеджеры не имеющие большого опыта, к тестированию относятся как к некой деятельности, которой если и нужно заниматься, то в одну из последних очередей. Кроме того в СНГ до сих пор есть некоторое предвзятое отношение к тестировщикам — как к людям если не второго сорта (с айти точки зрения), но уж точно как к менее ценным людям, нежели программисты. Впрочем, потихоньку ситуация исправляется.
Впрочем, это лирика. В общем-же случае, таким менеджерам, которые «не в теме», мне кажется, имеет смысл прочитать какую-либо литературу о тестировании (да хотя бы «тестирование dot ком»), прежде чем строить планы и узнать, что же собственно это такое — тестирование.
Возможно мне это кажется очевидным, потому что я тестировщик, а менеджеры, особенно не айти-менеджеры или менеджеры не имеющие большого опыта, к тестированию относятся как к некой деятельности, которой если и нужно заниматься, то в одну из последних очередей. Кроме того в СНГ до сих пор есть некоторое предвзятое отношение к тестировщикам — как к людям если не второго сорта (с айти точки зрения), но уж точно как к менее ценным людям, нежели программисты. Впрочем, потихоньку ситуация исправляется.
Впрочем, это лирика. В общем-же случае, таким менеджерам, которые «не в теме», мне кажется, имеет смысл прочитать какую-либо литературу о тестировании (да хотя бы «тестирование dot ком»), прежде чем строить планы и узнать, что же собственно это такое — тестирование.
Уважаемые коллеги-айтишники!
Пожалуйста не читайте это. Автор все напутал про тестирование.
Пожалуйста не читайте это. Автор все напутал про тестирование.
Уважаемый автор. Статья действительно весьма специфична. И подходит для узкого круга проектов и команд.
Вот если вы добавите в какой команде, на проекте какого типа это работает и какая задача у вашего тестирования, она заиграет новыми красками.
Вот если вы добавите в какой команде, на проекте какого типа это работает и какая задача у вашего тестирования, она заиграет новыми красками.
и да. причем тут отдел тестирования? отдел-это люди, регламенты, оценка, инфраструктуре на тыщитыщ багов, инстансов и тд.
вы говорите о каком-то минимально достаточном тестировании в условиях отсутсвия людей. правильно же понимаю?
вы говорите о каком-то минимально достаточном тестировании в условиях отсутсвия людей. правильно же понимаю?
Веб-проекты, часть из которых высоконагруженные системы. Команда состоит из тестировщиков, автоматизаторов и «нагрузочников», работают во всех проектах, планируя ресурсы. Задачи как и везде — тестирование для исправления и оптимизации, но в единой не хаотичной информационной среде с фиксацией реального состояния проекта.
Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования.Работал в аналогичной структуре руководителем проектов. Отдел тестирования был один, и из него выделялись сотрудники на проекты или отдельные работы. Естественно постоянно шла грызня между РП, кому достанется свободный ресурс тестирования. Для этого была предусмотрена система долгосрочного резервирования ресурсов, но она лишь частично снимала проблему. Как у вас это решается?
И второй вопрос, подчиняются ли тестировщики в рамках проекта руководителю проектов? У нас было так, но здесь возникает проблема: РП обычно замотивирован на сроки релиза, при приближении которых начинает давить на тестировщиков. В результате качество тестирования может снижаться. Как вы с этим боретесь?
А что толку давить?
Отдел рабработки ставит себе due date, а отдел тестирования ставит себе due date и все это на этапе планирования достаточно просто считается.
В стиле команда делает неделю, функционал тестируется день-два. И никто ни на кого не давит. Невовремя отдали в тестирование сами виноваты. Давить тут нет никакого смысла.
Отдел рабработки ставит себе due date, а отдел тестирования ставит себе due date и все это на этапе планирования достаточно просто считается.
В стиле команда делает неделю, функционал тестируется день-два. И никто ни на кого не давит. Невовремя отдали в тестирование сами виноваты. Давить тут нет никакого смысла.
Сделали общий календарь в google, доступный менеджерам (РП) и руководителям групп тестировщиков. Менеджеры заранее проставляют свои релизы, хотя бы приблизительно. Таким образом, все смотрят как бы на общую доску. Но и в этом случае бывают проблемы, но редко, решаются переговорами )
Ясно. Мы дошли до того, что планируется не более 3/4 времени тестировщиков. Остальное на срочные неожиданные задачи.
Самая большая проблема в таких ситуациях — решение через свой авторитет. Т.е. есть какой-нибудь СТО, который «круче» всех в компании и ему нужно, чтобы тестировщик сделал то и то. И он, не пойдя к менеджерам, не пойдя к руководителям, сразу идет к тестировщику и просит его сделать то и то.
Ну и тестировщик же тоже не скажет ему — идите дядя, к моему боссу, очевидно. Для этого нужен некий уровень осознанности и зрелости общей работы в компании. И получается в итоге неудовольствие всеми всех. Менеджеры не видят отчета, который не сделал тестировщик, потому что он был занят на другой задаче, о которой менеджер даже и не в курсе.
Ну и тестировщик же тоже не скажет ему — идите дядя, к моему боссу, очевидно. Для этого нужен некий уровень осознанности и зрелости общей работы в компании. И получается в итоге неудовольствие всеми всех. Менеджеры не видят отчета, который не сделал тестировщик, потому что он был занят на другой задаче, о которой менеджер даже и не в курсе.
Ну и тестировщик же тоже не скажет ему — идите дядя, к моему боссу, очевидно.Это почему не скажет? Именно так и должен говорить всем, вплоть до учередителей, включительно. Мы в свое время именно так эту проблему и побороли. Выбили и согласовали приказ по компании, что никаких задач исполнителям в обход регламентов. Все задачи строго фиксируются.
Были конечно желающие обойти, но руководство прекрасно понимало для чего это сделано, и таких желающих строго наказывало.
Вы конечно скажете что просто повезло с руководством, но это не так. Просто когда сорвался очередной проект, были выложены на стол все ситуации, когда ресурс отвлекался на неплановую работу, из-за которой неуспели плановую. Все осознали и согласились.
Правда есть как всегда и обратная сторона — ни один исполнитель больше не принимает устных заданий. Все через систему учета. Но это меньшее зло.
PS: здесь кстати помогает рассадка тестеровщиков и их руководителя в одном кабинете. Руководитель должен отслеживать несанкционированные «заходы», и разговаривать самостоятельно с таким ходоком.
А ну, так вот именно. У вас это как раз
Возможно это слишком крутое решение. Решение, когда исполнитель принимает задачи от одного непосредственного начальника — вполне разумный вариант.
Хотя, с другой стороны, ваш подход позволяет легко автоматизировать всякую статистику — типа кто как работал, сколько сделал и т.д. было бы любопытно такую статистику увидеть даже самому — узнать, что ты этот месяц собственно делал :) Ну и начальникам очевидно проще мониторинг осуществлять.
Для этого нужен некий уровень осознанности и зрелости общей работы в компании.— т.е. выдали решение, указ компании и строго его придерживались, молодцы. До такого решения еще дорасти надо.
Правда есть как всегда и обратная сторона — ни один исполнитель больше не принимает устных заданий. Все через систему учета. Но это меньшее зло.
Возможно это слишком крутое решение. Решение, когда исполнитель принимает задачи от одного непосредственного начальника — вполне разумный вариант.
Хотя, с другой стороны, ваш подход позволяет легко автоматизировать всякую статистику — типа кто как работал, сколько сделал и т.д. было бы любопытно такую статистику увидеть даже самому — узнать, что ты этот месяц собственно делал :) Ну и начальникам очевидно проще мониторинг осуществлять.
Хотя, с другой стороны, ваш подход позволяет легко автоматизировать всякую статистикуКонечно. На эту статистику еще и KPI завязаны.
Решение, когда исполнитель принимает задачи от одного непосредственного начальника — вполне разумный вариант.Да, но это только в иерархической системе управления возможно. Тестировщики были расшаренным ресурсом — в матричном подчинении у руководителей проектов. Если пускать весь поток задач через их линейного руководителя, он быстро становится узким местом.
Программисты чаще сидели на одном проекте, но некоторые тоже были расшарены.
При нагрузочном тестировании танк куда направляете и чем стреляете?
При тестировании отказоустойчивости прям продакшн роняете?)
При тестировании отказоустойчивости прям продакшн роняете?)
Говорю про крупную кластерную систему:
При предрелизном тестировании на тестовую машину с выкаченными последними правками, чтобы сравнить изменение производительности от релиза к релизу.
После выкатки проверяем в космосе (продакшен), но стреляем на отдельные компоненты и при необходимости выводим машины из балансировки.
В каком-то смысле да ))
Конечно, при тщательном планировании и в часы наименьшей нагрузки выводом отдельных единиц оборудования и моделированием аварийных ситуаций.
PS ни разу не роняли
При нагрузочном тестировании танк куда направляете и чем стреляете?
При предрелизном тестировании на тестовую машину с выкаченными последними правками, чтобы сравнить изменение производительности от релиза к релизу.
После выкатки проверяем в космосе (продакшен), но стреляем на отдельные компоненты и при необходимости выводим машины из балансировки.
При тестировании отказоустойчивости прям продакшн роняете?)
В каком-то смысле да ))
Конечно, при тщательном планировании и в часы наименьшей нагрузки выводом отдельных единиц оборудования и моделированием аварийных ситуаций.
PS ни разу не роняли
>> Часто бывает так, что затраты на поддержание автотестов значительно превышают затраты на ручное тестирование. Поэтому надо действовать без фанатизма.
А приведите пример такой ситуации? Автотесты как раз и придуманы, чтобы уменьшать затраты и улучшать качество
А приведите пример такой ситуации? Автотесты как раз и придуманы, чтобы уменьшать затраты и улучшать качество
Автотесты, конечно, придуманы именно для этого, но в большинстве случаев этого не достигают. Во-первых, автотесты на системе с активным девелопментом — практически нереализуемое занятие. Только ты написал подробный хороший цикл автотестов на тестирование регистрации пользователей, как тут, переместили поля, добавили новое поле, сделали прочтение лицензии дополнительным шагом, добавили картинок и т.д. все тесты нужно переписывать. Не с нуля, конечно, но сам факт.
Так что автотесты имеет смысл писать на том, что не подразумевает меняться довольно продолжительное время. Да и то. Вот у меня есть конкретный пример на моей работе.
Работа связана с программным обеспечением для спутниковых ТВ-ресиверов. Так что, автоматическое тестирование подразумевает анализ видео-потока. И так, прямо скажем, не самая тривиальная задача, так еще нюанс в том, что весь бэкенд с нашей стороны черный ящик, да еще и находящийся на другой стороне земного шара. Так что периодически случаются сбои, дефекты, и т.д. и т.п. Это значит, что потратив кучу времени на создание фреймворка, который позволяет это сделать (времени реально много было потрачено), потратив энное количество времени, чтобы загнать туда тесты (тоже далеко не один месяц дело заняло), мы получили систему, которая может прогнать тесты примерно в десять раз быстрее, чем при ручном тестировании. Но. В том случае если случилась какая-то проблема — нужно просмотреть логи, дампы, что вызывает массу затруднений и отнимает кучу времени и в общем-то временной выигрыш практически нулевой. Так что теперь еще и систему разбора и анализа логов к этому нужно прикручивать.
С моей точки зрения, такая автоматизация вообще бесперспективное дело. Руководство правда считает иначе.
Так что автотесты имеет смысл писать на том, что не подразумевает меняться довольно продолжительное время. Да и то. Вот у меня есть конкретный пример на моей работе.
Работа связана с программным обеспечением для спутниковых ТВ-ресиверов. Так что, автоматическое тестирование подразумевает анализ видео-потока. И так, прямо скажем, не самая тривиальная задача, так еще нюанс в том, что весь бэкенд с нашей стороны черный ящик, да еще и находящийся на другой стороне земного шара. Так что периодически случаются сбои, дефекты, и т.д. и т.п. Это значит, что потратив кучу времени на создание фреймворка, который позволяет это сделать (времени реально много было потрачено), потратив энное количество времени, чтобы загнать туда тесты (тоже далеко не один месяц дело заняло), мы получили систему, которая может прогнать тесты примерно в десять раз быстрее, чем при ручном тестировании. Но. В том случае если случилась какая-то проблема — нужно просмотреть логи, дампы, что вызывает массу затруднений и отнимает кучу времени и в общем-то временной выигрыш практически нулевой. Так что теперь еще и систему разбора и анализа логов к этому нужно прикручивать.
С моей точки зрения, такая автоматизация вообще бесперспективное дело. Руководство правда считает иначе.
А приведите пример такой ситуации?Тестирование интерфейсов, например. Пока напишите скрипт, который тыкает мышкой по кнопкам можно сто раз вручную прокликать. Но если интерфейс не меняется — можно один раз и потратиться.
А выполняться потом этот скрипт будет тысячу раз. И выйгрыш во времени будет в 10 раз минимум в течении от силы первого года.
Решение надо принимать исходя из долгосрочности проекта и рисков что что-то отвалится критичное.
Помню работал в одной компании, которая писала софт для банков. Протестировать всю систему вручную стоило 2 человеко месяца (разработка велась всего лишь год). Команда разработки регулярно раз в месяц делала капитальные изменения в кодовой базе (чисто инфраструктурные изменения). Руководство бледнело, когда надо было фиксы выкатывать на продакшн раз в тот же месяц. Что делали? Выкатывали раз в месяц без тестирования и естественно факапились. Не знаю даже какая репутация потом была у нашей компании…
И я не понимаю, какие проблемы в правке тестов следом за правкой интерфейса — в том же коммите?
Решение надо принимать исходя из долгосрочности проекта и рисков что что-то отвалится критичное.
Помню работал в одной компании, которая писала софт для банков. Протестировать всю систему вручную стоило 2 человеко месяца (разработка велась всего лишь год). Команда разработки регулярно раз в месяц делала капитальные изменения в кодовой базе (чисто инфраструктурные изменения). Руководство бледнело, когда надо было фиксы выкатывать на продакшн раз в тот же месяц. Что делали? Выкатывали раз в месяц без тестирования и естественно факапились. Не знаю даже какая репутация потом была у нашей компании…
И я не понимаю, какие проблемы в правке тестов следом за правкой интерфейса — в том же коммите?
А выполняться потом этот скрипт будет тысячу раз. И выйгрыш во времени будет в 10 раз минимум в течении от силы первого года.
Иногда бывает достаточно одного раза, или 10 раз. А дальше проект не меняется.
И я не понимаю, какие проблемы в правке тестов следом за правкой интерфейса — в том же коммите?Если тестирование интерфейса делается по принципу эмуляции мыши, то такой тест как правило требует длительной отладки, чисто по опыту сужу. Надо же не только прокликать в нужные места в нужном порядке с нужными таймаутами, но и обработать результат. Зато такой тест максимально приближен к действиям пользователя.
Решение надо принимать исходя из долгосрочности проекта и рисков что что-то отвалится критичное.Безусловно! Тут масса факторов влияет, даже перечислять не буду. В первом приближении это актуально для долгосрочных тиражируемых продуктов (или веб-интерфейсов), где UI не слишком часто и не слишком сильно меняется.
Поспорю с глоссарием.
Часто у тест-кейса нет шагов. В том же TMS Testlink, много версий подряд было только поле «Описание» без шагов и ожидаемых результатов. И даже тест-кейсы без описания были тест-кейсами.
Тест-кейс (он же тестовый сценарий или test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Если допустить, что некоторые наборы могут быть пустыми. То тестовый сценарий, состоящий лишь из хорошего заголовка и помещённый в определённую группу, становится полноценным тестовым сценарием, соответствующим определению.
Выделяют сценарии высокого уровня (90% для ручных тестов), и низкого уровня (90% для автоматических тестов). Низкого уровня те, что указывают на конкретные значения входных данных и ожидаемых результатов. Примечание про 90% — сугубо личная оценка, в конкретных случаях может быть не так.
Не уточнено прогон чего, и оказывается, что это про весь план тестирования. Закрепилось в голове, что прогон, это прогон теста.
Прогон теста (test run) — выполнение теста на определенной версии объекта тестирования. [ISTQB]
«Тестирование» — наиболее подходящее общее слово, которое можно раскрыть как выполнение плана тестирования. У понятия тестирование есть и более развернутые определения, не затрагивающие другие определения.
Тест-кейс ‒ шаги по достижению ожидаемого результата.
Часто у тест-кейса нет шагов. В том же TMS Testlink, много версий подряд было только поле «Описание» без шагов и ожидаемых результатов. И даже тест-кейсы без описания были тест-кейсами.
Тест-кейс (он же тестовый сценарий или test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Если допустить, что некоторые наборы могут быть пустыми. То тестовый сценарий, состоящий лишь из хорошего заголовка и помещённый в определённую группу, становится полноценным тестовым сценарием, соответствующим определению.
Выделяют сценарии высокого уровня (90% для ручных тестов), и низкого уровня (90% для автоматических тестов). Низкого уровня те, что указывают на конкретные значения входных данных и ожидаемых результатов. Примечание про 90% — сугубо личная оценка, в конкретных случаях может быть не так.
Прогон ‒ выполнение тест-плана.
Не уточнено прогон чего, и оказывается, что это про весь план тестирования. Закрепилось в голове, что прогон, это прогон теста.
Прогон теста (test run) — выполнение теста на определенной версии объекта тестирования. [ISTQB]
«Тестирование» — наиболее подходящее общее слово, которое можно раскрыть как выполнение плана тестирования. У понятия тестирование есть и более развернутые определения, не затрагивающие другие определения.
Sign up to leave a comment.
Создаем отдел тестирования