Форум Сообщества Аналитиков
Дисциплины => Тестирование => Тема начата: Deva от 25 Января 2014, 21:26:04
-
На новом месте работы (системным аналитиком) мне говорят, что программист конечно должен проверить работу программы, но я должна ему подготовить тестовый пример. Если результат совпадет с тестовым примером, то считается, что программист выполнил задачу верно.
Получается полная безответственность программиста, и полная ответственность системного аналитика, т.к программист даже не проверяет правильность работы формул.
Может я не права ? Прошу высказать свое мнение...
-
Все зависит от точки зрения. Следуя V модели, действительно, ставя задачу, вы как аналитик должны понимать и представлять как проверять корректность ее выполнения. Если вы не понимаете, то как это поймет программист. Прием исполнения задачи - важная часть работы аналитика.
Можете подробнее рассказать о предмете разговора, чтобы поставить более точный диагноз?
-
Например: необходимо выгрузить в текстовый файл данные, удовлетворяющие определенным условиям. Источник данных, условия выборки и перечень выводимых данных задаются.
От меня требуют, чтобы я подготовила текстовый файл, с которым бы программист сверялся.
Я за то, чтобы была 2-х этапная проверка:
1) программист проверяет своими методами соответствие прописанного им алгоритма заданным условиям;
2) системный аналитик проверяет своими методами и готовит контрольные примеры для своей проверки.
В этом случае вероятность обнаружения ошибки увеличивается, т.к. скорее всего у нас будут разные контрольные примеры.
А если я свой контрольный пример буду передавать программисту, мы можем не обнаружить ошибку в программном коде :(
-
Например: необходимо выгрузить в текстовый файл данные, удовлетворяющие определенным условиям. Источник данных, условия выборки и перечень выводимых данных задаются.
От меня требуют, чтобы я подготовила текстовый файл, с которым бы программист сверялся.
Я за то, чтобы была 2-х этапная проверка:
1) программист проверяет своими методами соответствие прописанного им алгоритма заданным условиям;
2) системный аналитик проверяет своими методами и готовит контрольные примеры для своей проверки.
В этом случае вероятность обнаружения ошибки увеличивается, т.к. скорее всего у нас будут разные контрольные примеры.
А если я свой контрольный пример буду передавать программисту, мы можем не обнаружить ошибку в программном коде :(
Одно не противоречит другому. Вы как СА совершенно не обязаны знать как реализуется ваша задача. Для вас программный код = черный ящик. На вход подается А, на выходе выдается Б.
Вы как СА должны точно понимать ожидаемый из черного ящика результат и готовите свой тестовый кейс, исходя из своих рассуждениях, проверяя их логичность и непротиворечивость.
Программист отлаживая свою программу, должен ориентироваться на ваш тестовый кейс.
Вопрос можно? В вашей команде имеется тестировщик?
-
А если я свой контрольный пример буду передавать программисту, мы можем не обнаружить ошибку в программном коде :(
Если вы не будете передавать контрольный пример, то пропуск ошибки также может случиться. Нет единственно верного рецепта. Все зависит от конкретного проекта. В каких-то проектах принимают подход, когда тест-кейсы и тестовые данные готовятся до разработки и называют этот подход Test Driven Development. В других проектах начинают это делать вместе с разработкой, чтобы по окончанию разработки можно было провести качественное тестирование. Подготовкой тест-кейсов, данных и тестированием в разных проектах занимаются разные люди. В небольших - аналитики, в больших тестировщики, а в некоторых даже сами разработчики. Все по разному и причин может быть много. Так что ваш случай не уникальный и не самый плохой. Как говортт один очень умный человек: "не смотрите на названия ролей в методологиях. Кого назначат, тот и будет делать."
-
Наверное, у меня очень непрогрессивный подход, но он заключается в том, что каждый отвечает за свою работу.
И подход из мультика: "и так сойдет"- меня не устраивает !
Иы скатываемся до того, что "я написал код" (неважно как), а твоя задача "найти мои ошибки".
И дело здесь не в способах тестирования, а в ответственности каждого за свою работу !!!
У нас нет тестировщика. В этом случае задачи тестирования должны распределиться на 2 части: одна - за программистом, другая - за системным аналитиком.
Возьмем простой пример: реализовать алгоритм таблицы умножения
A*B=C
Контрольный пример: 2*2=4
А в программном коде ошибка: C=A*B-A+B
Контрольный пример проходит!
-
программист конечно должен проверить работу программы, но я должна ему подготовить тестовый пример.
...
каждый отвечает за свою работу
По-моему, все верно. С учетом:
У нас нет тестировщика.
Получается, что контрольные примеры готовить Вам. Программист этим не должен заниматься ни в коем случае. Ибо напишет так же, как понял постановку и реализовал ее в коде.
-
Все зависит от людей. В одной компании в одном проекте бывает, что программист проверяет свой код и требует контрольный пример вместе с ТЗ (идеальный вариант), другой просто "реализует" алгоритм (сойдет и так), не вдаваясь в результат. Всегда стараемся найти компомисс, выходим на руководство, распределяем задачи в зависимости от исполнителя, повышаем зп только ценным кадрам и т.д. Могу сказать что и у аналитиков такая же проблема, кто-то не хочет принимать функционал у прогеров и сразу передает тестеровщикам, кто-то не отвечает на вопросы программистов и т.д.
Если бы все были ответственными.....
-
В этом случае задачи тестирования должны распределиться на 2 части: одна - за программистом, другая - за системным аналитиком.
Я не спорю, что каждый должен отвечать за собственную работу. Разработчик должен выдать качественный код. Он может это делать и не тестируя. Хотя если есть печальный опыт, то можно ввести методы повышения качества кода: ревью кода, БЫСТРАЯ проверка тестовым примером, обучение и т.д. Но это не значит, что полномасштабное тестирование это работа именно разработчика. Это должен делать тот, кого назначат.
Я за то, чтобы не разделять полномасштабное тестирование на две части. Тестировать должны те, кто эффективнее это делают. По убыванию эффективности это тестировщик (потому что специализируется на этом) или аналитик (потому что лучше всех из команды разработки знает как ПО должно работать).
-
Программа и методика испытаний является очень хорошим вариантом записи требований. Передача ее программисту позволяет предотвратить часть ошибок. Предотвращение ошибок является более выгодной стратегией по сравнению с их поиском.
И не пожалейте 45 минут, посмотрите: http://vimeo.com/13803733
-
Благодарю всех за ответы !
Никого не хочу "обидеть", но понял меня Elf - именно "качественный код".
И сейчас мне предстоит разговор с руководителем и программистами на эту тему.
Я хочу донести еще один момент:
Системный аналитик - дает задание и принимает работу (он не тестировщик).
Тести́рование програ́ммного обеспе́чения — процесс исследования, испытания программного обеспечения (ПО) с целью получения информации о качестве продукта. Тестировщик заведомо считает, что в коде есть ошибки и его задача их обнаружить.
Задача системного аналитика - принять выполненную работу. Системный аналитик заведомо считает, что ему сдается качественный код и проверяет функционал на соответствие поставленной задачи в целом.
Ну вот, как то так ... :)
SALar, я обязательно посмотрю ссылку.
-
Задача системного аналитика - принять выполненную работу. Системный аналитик заведомо считает, что ему сдается качественный код и проверяет функционал на соответствие поставленной задачи в целом.
Когда глухарь токует, он никого не слышит.
-
Системный аналитик заведомо считает, что ему сдается качественный код...
Без обид, но по моему это допущение граничащее с наивностью:)
В любом сдаваемом коде заведомо есть ошибки, если это не программа уровня "Hello world!"
Если отталкиваться от такого допущения, то все сразу встанет на свои места. Т.к. тестировщика нет, то кроме как вам, разработчику некому сдавать свой код с ошибками:)
По хорошему, конечно, когда не тестировщика, лучше работать по TDD, но сам я не знаю российских компаний где эта практика хорошо развита, по этому это скорее пожелание чем совет:)
-
Когда глухарь токует, он никого не слышит.
Мне понравилось это выражение ! Возьму на заметку !
Но кроме "себя", я получила ваши мнения и ссылку :D
А это для меня важно !
-
В любом сдаваемом коде заведомо есть ошибки, если это не программа уровня "Hello world!"
И то сделали ошибку :)) Hello, world!
-
И то сделали ошибку :)) Hello, world!
В английском обращение во время приветствия не выделяют запятой на практике.
http://brejestovski.livejournal.com/30472.html
-
Тести́рование програ́ммного обеспе́чения — процесс исследования, испытания программного обеспечения (ПО) с целью получения информации о качестве продукта.
IMHO: "Очень распространенное заблуждение."
Опровержение данного заблуждения смотри: http://blog.shumoos.com/archives/281
PS. Если найдете ошибку в логическом построении - буду благодарен. Но пока никто не нашел.
-
IMHO: "Очень распространенное заблуждение."
Опровержение данного заблуждения смотри: http://blog.shumoos.com/archives/281
PS. Если найдете ошибку в логическом построении - буду благодарен. Но пока никто не нашел.
Я не буду утверждать, что определение верное. Но логика статьи мне представляется натянутой. Пример с картой не ясен. Что такое качество в случае с этой пластиковой дуальной картой? Типа прошла сертификационные испытания за 20 кило у.е. И оказалось, что карта не рабочая. Вопрос, а причем тут карта. По-моему нужно вернуть 20 тыс у.е., а контору по сертификации посадить на 20 лет за фальсификацию!
Когда я работал тестировщиком, то я естественно искал ошибки, однако цель мне ставила вышестоящая системы - мой руководитель проекта. Для него, думаю, я как раз и предоставлял информацию о качестве ПО. Только он естественно решал, насколько оно качественное это ПО и можно ли выпускать релиз с ошибками или нет, ибо всех ошибок отловить нельзя, по определению!
-
Если найдете ошибку в логическом построении - буду благодарен. Но пока никто не нашел.
Очень много и витиевато написано. Я всегда теряюсь в таких текстах ???
По-моему, основная фраза текста: «… информация о расхождении системы и ожиданием заинтересованных лиц …»
В рассматриваемом примере: Система 1 в Системе 2.
И Система 1 и Система 2 по отдельности могут быть качественными.
А есть ли ТЗ на их симбиоз ? Каким условиям должна соответствовать «Система 1 в Системе 2» ?
У меня был жизненный пример. Некто получил задание запустить цепочку:
3D-модель – Программа для станка с ЧПУ – Станок с ЧПУ
Ожидания: цепочка должна работать !!!
Купили Pro\Engineer, купили японский станок… а не работает !
Потому что забыли заказать постпроцессор :(
-
IMHO: "Очень распространенное заблуждение."
Опровержение данного заблуждения смотри: http://blog.shumoos.com/archives/281
PS. Если найдете ошибку в логическом построении - буду благодарен. Но пока никто не нашел.
Не нашел в статье опровержения. Да и пример там несколько... притянут за ушки.
"Заблуждение" не в самом утверждении, а в его трактовке (части "информации о качестве"). Особенно если помнить, что один из наиболее популярных подходов к определению качества - это сравнение фактических характеристик объекта с ожидаемыми.
"Но для процесса тестирования, проводимого исполнителем, информация о расхождении между поведением системы и ожиданием заинтересованных лиц является основным производимым артефактом"
Вот это и будет для исполнителя "информацией о качестве" системы (сведениями, уменьшающими неопределенность).
Заключение сертифицирующего центра из примера для исполнителя не более, чем "данные".
С этой точки зрения фраза "Несмотря на наличие информации о качестве, проект невозможно было завершить успешно." ложна. Информации не было.
-
Потому что забыли заказать постпроцессор
На самом деле "не забыли", а не знали.
Не было соответствующего обследования, анализа и требований.
Считалось, что все должно работать.