Отсутствие силы воли у наших людей породило огромное количество тренингов. Людям нужен толчок, чтобы отказаться от надоедливой работы, нелюбимого человека и серых будней. Однако запала надолго не хватает. В конце концов они вернутся за новой порцией мотивации. Относишь ли ты к ним или можешь оставаться счастливым самостоятельно? Сейчас проверим!
Добро – это то, чего не хватает современному обществу. Убедиться в этом можно пролистав ленту новостей. Позитивного и доброго там мало. Мы поддерживаем мнение, что начинать всегда надо с себя. Пусть этот тест будет твоим первым шагом.
Интуиция - это то, что мы привыкли называть "совпадением" и "случайностью". На самом деле именно шестое чувство приводит нас к тому самому совпадению, которое способно поменять ход событий. Старая, как мир, игра "Орел или Решка" - прекрасный способ проверить свою интуицию. Казалось бы, нет ничего сложного угадать, ведь шанс предельно высок - 50%! Как бы не так. Мы сделаем 8 бросков, попробуй дать столько же правильных ответов.
Союза нерушимых республик свободных уже давно нет, но это не означает, что можно забыть историю великой державы, которая оставила такой яркий след в истории. Сегодня мы подготовили тест, состоящий из вопросов, с которыми справится лишь выпускник советской школы, так как они требуют глубокие знания. Если ты считаешь, что справишься, то скорее приступай!
Биологический возраст - это далеко не самый важный показатель в жизни. Существуют куда более весомые цифры. Например, сколько лет вашей душе или мозгу. Наш поток мыслей - это невероятно сложная система, она развивается и растет вместе с нами. С точки зрения психологии, каждому возрасту соответствуют определенные мысли и выбор. Давайте разберемся, вы преуспеваете или отстаете в своем развитии.
Магистр клуба "Что? Где? Когда?" скандально отстранен от участия в программе. Теперь у него больше нет права своими знаниями и логикой зарабатывать деньги, популярность и уважение. Но, как говорится, на корабле всегда должен быть капитан, предлагаем тебе попробовать занять его место. Используй свой жизненный опыт, логику и смекалку!
Работа – твой второй дом, и весь мир крутится вокруг неё? Или же, работа – способ выжить и приобрести желаемое? Как хорошо ты работаешь и выполняешь свои обязанности, по достоинству ли тебе платят за неё, а может быть, ты заслуживаешь повышения? Пройди наш тест и узнай, какой зарплаты ты, действительно, заслуживаешь. И не забудь показать результат своему начальнику!
Классический набор блюд в России - это пельмени, яичница, жареная картошка, борщ и макароны по-флотски. Это меню закрепилось за нами ещё с советских лет, когда выбор продуктов был скудным. Но так продолжаться больше не может, поэтому предлагаем тебе пройти наш просветительный тест.
Нет проблемы в том, чтобы узнать на фото Альберта Эйнштейна или Михаэля Шумахера. Но мало кто знает, что во всех сферах жизни есть женщины, заслужившие не меньшего внимания. Восстанавливаем справедливость и знакомим тебя с ними.
Сегодня мы подготовили необычайно интересный тест! Он уникален тем, что тут собраны психологические задачи, для решения которых потребуется не ум и логика, а фантазия и внимательность. Если ты считаешь, что справишься, то скорее приступай! Безусловно, твои знания тебе тоже очень помогут!
Знаменитая игра «Кто хочет стать миллионером?» годами собирает целые семьи перед телевизором. Волнение и азарт, которые испытывают участники игры, жаждущие выиграть заветные миллионы, передаются и телезрителям. И не расстраивайся, если по ту сторону экрана ты еще не оказался, ведь сегодня у тебя есть отличная возможность потренироваться! Проверь свои знания!
Любовь – это очень непростое чувство. Некоторым для выражения своих чувств достаточно нескольких дней знакомства, другие же не осмеливаются о них сказать годами, боясь всё испортить. Возможно, наш тест подскажет вам того, кто уже давно не спит по ночам, ломая голову над тем, как вам понравится. И, кто знает, может это перевернёт вашу жизнь!
Самые сумасшедшие и неадекватные люди всегда оказывались примерными семьянинами и работниками. Окружающие могут не замечать, но агрессия внутри переполняет их сердца. Если не проверяться у специалиста, то рано или поздно это выйдет наружу. Наш тест как раз должен помочь разобраться. Точного диагноза не поставим, но о проблеме намекнем.
) записал видео для демонстрации быстрого стресс-тестирования. В его примере подход заключался в подаче на вход визарда приложения огромного объема данных, по существу заставляя приложение нагружать само себя.
Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.
Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software ». По этому поводу мы с Джеймсом устроили транспективную беседу . Колонку вы можете найти . Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.
Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.
В общем, сейчас я расскажу все эвристики, которые мы нашли. Я подчеркиваю, что эти эвристики для остановки являются именно эвристиками . Эвристики – это быстрые, недорогие способы решения проблемы или принятия решения . Эвристики подвержены ошибкам , то есть они могут как сработать, так и не сработать. Эвристики недостаточно абстрактны , они могут перекрываться и пересекаться друг с другом. Также эвристики зависят от контекста , поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Ниже я перечислил эвристики и для каждой из них указал некоторые вопросы, при помощи которых можно проверить правомочность её использования.
1. Эвристика «Время вышло !» . Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время.
Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не был ли срок искусственным , произвольным ? Будет ли выполняться дополнительная разработка , которая потребует дополнительного тестирования ?
Когда-то тест Джозефа Сакса впечатлил меня способностью структурировать мои хаотичные представления об окружающем мире, о себе и других.
Методика включает 60 незаконченных предложений, условно разделенных на 15 групп, которые характеризуют Ваше отношение к:
Друзьям;
Представителям своего и противоположного пола;
Сексуальным отношениям;
Власти и подчинению;
Прошлому и будущему.
Некоторые группы предложений также затрагивают страхи и опасения, которые влияют на Вашу жизнь, указывают на непрожитую вину, а также проливают свет на жизненные цели.
Без обработки тестирование занимает от 20 минут и более.
Инструкция: На бланке теста необходимо закончить предложения одним или несколькими словами.
Бланк теста
1. Думаю, что мой отец редко…
2. Если все против меня, то…
3. Я всегда хотел/хотела…
4. Если бы я занимал руководящий пост…
5. Будущее кажется мне…
6. Мое начальство…
7. Знаю, что глупо, но боюсь…
8. Думаю, что настоящий друг…
9. Когда я был/была ребенком…
10. Идеалом женщины (мужчины) для меня является…
11. Когда я вижу женщину рядом с мужчиной…
12. По сравнению с большинством других семей моя семья…
13. Лучше всего мне работается с…
14. Моя мать и я…
15. Сделал/сделала бы все, чтобы забыть…
16. Если бы мой отец только захотел…
17. Думаю, что я достаточно способен/способна, чтобы…
18. Я мог/могла бы быть очень счастливым/счастливой, если бы…
19. Если кто-нибудь работает под моим руководством…
20. Надеюсь на…
21. В школе мои учителя…
22. Большинство моих друзей не знают, что я боюсь…
23. Не люблю людей, которые…
24. Когда-то…
25. Считаю, что большинство юношей (девушек)…
26. Супружеская жизнь кажется мне…
27. Моя семья обращается со мной, как с…
28. Люди, с которыми я работаю…
29. Моя мать…
30. Моей самой большой ошибкой было…
31. Я хотел/хотела бы, чтобы мой отец…
32. Моя наибольшая слабость заключается в том…
33. Моим скрытым желанием в жизни…
34. Мои подчиненные…
35. Наступит тот день, когда…
36. Когда ко мне приближается мой начальник…
37. Хотелось бы мне перестать бояться…
38. Больше всех люблю тех людей, которые…
39. Если бы я снова стал/стала молодым…
40. Считаю, что большинство женщин (мужчин)…
41. Если бы у меня была нормальная половая жизнь…
42. Большинство известных мне семей…
43. Люблю работать с людьми, которые…
44.Считаю, что большинство матерей…
45. Когда я был/была молодым/молодой, то чувствовал/чувствовала вину, если…
46. Думаю, что мой отец…
47. Когда мне не везет, я…
48. Больше всего в жизни я хотел/хотела бы…
49. Когда я даю другим поручение…
50. Когда буду старым/старой…
51. Люди, превосходство которых над собой я признаю…
52. Мои опасения не раз заставляли меня…
53. Когда меня нет, мои друзья…
54. Моим самым живым воспоминанием детства является…
55. Мне очень не нравится, когда женщины (мужчины)…
56. Моя половая жизнь…
57. Когда я был/была ребенком, моя семья…
58. Люди, которые работают со мной…
59. Я люблю свою мать, но…
60. Самое худшее, что мне случилось совершить, это…
Обработка и интерпретация результатов
Для каждой группы предложений выводится характеристика, определяющая данную систему отношений как положительную(1), отрицательную (2) или безразличную (0).
Например, Будущее кажется мне:
1) мрачным, плохим, странным (2)
2) интересным, интригующим (1)
3) неясным, неизвестным (0)
Такая количественная оценка облегчает выявление дисгармоничной системы отношений. Но более важно, конечно, качественное изучение завершенных предложений.
Ключ
1 группа
. Отношение к отцу 1, 16, 31, 46.
2 группа
. Отношение к себе 2, 17, 32, 47.
3 группа
. Нереализованные возможности 3, 18, 33, 48.
4 группа
. Отношение к подчиненным 4, 19, 34, 49.
5 группа
. Отношение к будущему 5, 20, 35, 50.
6 группа
. Отношение к вышестоящим лицам 6, 21, 36, 51.
7 группа
. Страхи и опасения 7, 22, 37, 52.
8 группа
. Отношение к друзьям 8, 23, 38, 53.
9 группа
. Отношение к своему прошлому 9, 24, 39, 54.
10 группа
. Отношение к лицам противоположного пола 10, 25, 40, 55.
11 группа
. Сексуальные отношение 11, 26, 41, 56.
12 группа
. Отношения к семье 12, 27, 42, 57.
13 группа
. Отношение к сотрудникам 13, 28, 43, 58.
14 группа.
Отношение к матери 14, 29, 44, 59.
15 группа.
Чувство вины 15, 30, 45, 60.
Методика «Неоконченных предложений» применяется в экспериментально-психологической практике давно. Однако, доступен он не только профессионалам. Этот тест можно использовать, как отправную точку в изучении себя и своего отношения к другим и миру в целом. Если результаты Вас расстроили, не спешите впадать в уныние: обсудите их с психологом или человеком, которому Вы доверяете. Так или иначе, каждая группа теста требует отдельного обсуждения и осознавания, а также дополнительного подтверждения другими методиками.
Читайте также:
|
Организация процесса тестирования. Разработка ПО в значительной степени есть процесс передачи информации о конечной программе и перевода этой информации из одной формы в другую. Кроме того, подавляющее число ошибок ПО вызвано дефектами организации работ, недостаточным взаимопониманием и искажениями в процессе передачи и перевода информации.
Путем повышения четкости самого процесса разработки можно избежать появления многих ошибок. Это приводит к тому, что в конце каждого этапа необходимо включение отдельного шага проверки, имеющего целью локализовать наибольшее число ошибок до перехода к следующему этапу. Например, спецификация проверяется путем ее сравнения с выходным результатом предыдущей стадии, а каждая обнаруженная ошибка возвращается для устранения в процесс разработки спецификаций.
Кроме того, конкретные процессы тестирования должны быть ориентированы на конкретные этапы разработки. Это сосредотачивает каждый процесс тестирования на каком-либо шаге перевода, в результате чего фиксируется определенный класс ошибок.
Соотношение между процессами разработки и тестирования.
Собственно процесс тестирования начинается с проверки исходного кода. Для этого применяются методы статического тестирования.
Далее следует тестирование модулей, ориентированное на проверку соответствия спецификациям интерфейса модулей, а также тестирование сопряжения и результатов сборки модульной структуры, ориентированное на проверку соответствия проекту системы и (или) проекту структуры отдельной программы.
После этого появляется тестирование функций, которое заключается в поиске различий между программой и ее внешней спецификацией. При тестировании функций обычно применяются методы функционального тестирования. При этом предполагается, что на более раннем этапе тестирования модулей требуемый критерий покрытия логики, свойственный методам структурного тестирования, удовлетворяется.
Для сопоставления результатов разработки с исходными целями появляется процесс комплексного тестирования или, как его еще называют, тестирование системы, в котором проверяется все ПС как единое целое. При рассмотрении различий между полученными результатами и исходными целями разработки ПО наибольшее внимание уделяется выявлению ошибок перевода, возникающих в процессе разработки внешней спецификации. Это делает комплексное тестирование жизненно важным, так как именно на этом этапе обнаруживается больше всего серьезных ошибок.
Процесс тестирования завершают испытания ПО. Испытания позволяют проверить полноту решения функциональных задач, их качество и соответствие ПО технической документации.
Тестирование системы. В отличие от тестирования функций, внешнюю спецификацию нельзя использовать как базис для получения тестов системы, поскольку это противоречит цели проведения такого тестирования. С другой стороны, документ, отражающий цели системы как таковой (в нашем случае - это техническое задание), нельзя использовать для формирования ее тестов, так как он по определению не содержит точных описаний.
Проблема разрешается применением эксплуатационной пользовательской документации. Тесты системы проектируются на основе анализа ее целей по результатам изучения пользовательской документации. Такая практика позволяет сравнить не только программы с исходным документом, но и результаты ее функционирования с пользовательской документацией, а также пользовательскую документацию с исходным документом.
Существует несколько категорий тестов, каждая из которых направлена на проверку определенных целей. К ним относятся тестирование полноты реализации, тестирование на предельных объемах, тестирование на предельных нагрузках, тестирование удобства эксплуатации, тестирование защиты, тестирование конфигурации оборудования, тестирование совместимости, тестирование надежности, тестирование восстановления, тестирование удобства обслуживания, тестирование удобства установки и тестирование документации.
Тестирование полноты реализации является наиболее очевидным видом тестирования системы, который заключается в проверке выполнения каждого пункта исходного документа. Процедура проверки состоит в последовательном просмотре исходного документа - предложение за предложением. Если предложение содержит конкретную задачу, то определяют, выполняет ли программа эту задачу.
Тестирование на предельных объемах заключается в выполнении программы на больших объемах данных, желательно превышающих предлагаемый эксплуатационный объем. Например, на вход компилятора в качестве теста подают большую исходную программу, на вход редактора связей -программу, содержащую тысячу модулей, а на вход программы моделирования электронных схем - схему, содержащую тысячи компонентов. Цель тестирования на предельных объемах - показать, что программа не может управлять объемом данных, специфицированным в исходных целях.
Тестирование на предельных нагрузках обусловлено тем, что потребность в ресурсах памяти и быстродействии в процессе решения задачи на ЭВМ значительно изменяется в зависимости от состава объема исходных данных. При высокой интенсивности ввода исходных данных может нарушаться временной баланс между длительностью решения совокупности задач ПО в реальном времени и реальной производительностью ЭВМ при решении этих задач. Цель тестирования на предельных нагрузках показать, что ПО не удовлетворяет целям в области эффективности.
Тестирование удобства эксплуатации заключается в выявлении психологических (пользовательских) проблем, возникающих при эксплуатации. При этом тестировании следует установить, как минимум, следующее.
- Можно ли приспособить разработанный интерфейс для информирования и обучения конечного пользователя, а также для обеспечения его работы в реальных условиях?
- Значимы ли, внятны ли, не оскорбительны ли выходные сообщения программы?
- Понятна ли диагностика ошибок?
- Проявляет ли все множество пользовательских интерфейсов постоянство и единообразие синтаксиса, соглашений, семантик, формата, стиля и сокращений?
- Содержит ли система опции, число которых чрезмерно или использование которых маловероятно?
- Выдает ли система какие-либо подтверждения на все входные сообщения?
- Легко ли и приятно ли использовать ПО?
Тестирование защиты заключается в проверке обеспечения защиты информации от несанкционированного доступа. Для тестирования защиты важно построить тесты, которые нарушают программные средства защиты. Одним из путей разработки подобных тестов является изучение известных проблем защиты в подобных существующих системах и построении тестов, которые позволяют проверить, как решаются аналогичные проблемы в тестируемой системе.
Тестирование конфигурации оборудования обусловлено тем, что операционные системы, СУБД и коммуникационные системы должны поддерживать множество конфигураций оборудования (например, различные типы и число устройств ввода-вывода и линий связи, различные объемы памяти и т.п.). Часто число возможных конфигураций слишком велико, чтобы проверить ПО на каждой из них. Однако программу следует тестировать по крайней мере с каждым типом оборудования при минимальной и максимальной конфигурациях. Если можно изменять конфигурацию самого ПО, то необходимо тестировать все возможные его конфигурации.
Тестирование совместимости вызвано тем, что большинство разрабатываемого ПО не является полностью новым. Часто оно заменяет несовершенные, устаревшие системы обработки информации или неавтоматизированные процессы. Поэтому при разработке ПО необходимо обеспечить совместимость со средой, в которой работали заменяемые системы, и если необходимо, создать процедуры конверсии, обеспечивающие переход от одного метода обработки данных к другой. В этом случае, как и при других формах тестирования, тесты должны быть ориентированы на проверку обеспечения совместимости и работы процедуры конверсии.
Назначение всех видов тестирования - повысить надежность ПО, но если в исходном документе, отражающем цели проекта, есть особые указания, например, обеспечить определенное время наработки на отказ или задано допустимое число ошибок, то необходимо провести исследование тестируемого ПО на удовлетворение этих требований. Для этого служит тестирование надежности. Дня проведения этого вида тестирования существует ряд математических моделей надежности. Далее, в разделе, посвященном критериям завершения тестирования, будут рассмотрены две модели надежности: так называемая модель Милса и простая интуитивная модель.
Для операционной системы, СУБД и средств телекоммуникации часто определяется, как система должна восстанавливать свою работоспособность после программных ошибок, неисправностей аппаратуры и ошибок в данных. При тестировании системы требуется показать, что эти функции не выполняются. Для этого служит тестирование восстановления. Для этого можно намеренно ввести в систему программные ошибки, чтобы проверить, восстановится ли она после их устранения. Неисправности аппаратуры можно промоделировать. Ошибки в данных (помехи в линиях связи или неправильные значения указателей в базе данных) можно намеренно создать или промоделировать.
В исходном документе иногда формируются специальные цели удобства обслуживания или сопровождения ПО. Они могут определять средства обслуживания, которыми должно снабжаться ПО (например, программы выдачи дампов памяти, программы диагностики и т.п.), среднее время нахождения ошибки, процедуры, связанные с сопровождением, и качество до кум стации о внутренней логике программы. Естественно, все эти цели должны быть протестированы. Для этого применяется тестирование удобств обслуживания.
Цель тестирования удобства установки - показать, что не удовлетворяются цели по части настройки ПО на конкретные условия эксплуатации.
В проверку системы входит и проверка точности пользовательской документации. Большая часть этой проверки происходит при определении правильности представления предшествующих тестов системы. Кроме этого, пользовательская документация должна быть подвергнута инспекции на предмет ее точности и ясности, аналогично инспекциям исходного текста. Любые примеры, приведенные в документации, должны быть оформлены как тест и проверены на ПО.
Критерии завершения тестирования. При проведении тестирования встает вопрос о том, когда следует закончить тестирование программы, поскольку не представляется возможным определить, является ли выявленная ошибка последней.
В основном на практике придерживаются следующих двух критериев: когда время, отведенное по графику работ на тестирование, истекло; когда все тесты оказались неудачными, то есть были выполнены без выявления ошибок.
Оба эти критерия недостаточно точны и логичны, так как первый критерий не содержит оценки качества тестирования и ему можно удовлетворить, ничего не делая, второй же не зависит от качества тестовых наборов данных.
Однако второй критерий можно улучшить, если ориентироваться на определенные методологии проектирования тестов. Например, можно определить условие завершения тестирования модуля с помощью тестов, получаемых двумя путями: удовлетворением комбинаторному покрытию условий и методу анализа граничных значений по спецификации интерфейса модуля. Все получающиеся тесты в конце концов должны стать неудачными.
Завершение тестирования функций можно определить при выполнении следующих условий: тесты, получаемые методами функциональных диаграмм; эквивалентного разбиения и анализа граничных значений должны стать неудачными.
Однако эти критерии, во-первых, бесполезны на той фазе тестирования, когда определенные методы становятся непригодными, например, на фазе тестирования системы; во-вторых, такое измерение субъективно, т.к. нет гарантии, что данный специалист использовал нужную методологию правильно и точно; в-третьих, чтобы поставить цель и дать возможность выбора наиболее подходящего пути ее достижения, рассмотренные критерии предписывают использование конкретных методов, но не ставят цели.
Иногда используют критерий, основанный в значительной степени на здравом смысле и информации о количестве ошибок, полученных в процессе тестирования. Для этого строят графики зависимости количества ошибок и времени их появления. По форме полученной кривой и определяют, стоит ли продолжать тестирование или нет. На рисунке приведены примеры графиков зависимости количества ошибок от продолжительности тестирования.
Зависимость количества ошибок от продолжительности тестирования.
Из примера видно, что если время тестирования велико и с увеличением времени тестирования число ошибок растет, то, естественно, тестирование следует продолжить. Если в процессе тестирования в определенный момент наступило снижение числа выявления ошибок, если число выявленных ошибок постепенно стремится к нулю или достигло нуля, то понятно, что процесс тестирования можно завершить.
Однако этот критерий тоже недостаточно эффективен, поскольку нет никакой уверенности в том, что в последнем случае в дальнейшем не последует увеличения числа обнаруживаемых ошибок.
Возможен еще один подход к определению критерия завершения тестирования. Поскольку цель тестирования - поиск ошибок, то в качестве критерия можно выбрать некоторое заранее установленное число ошибок, соответствующее некоторой части от предполагаемого общего числа ошибок. Однако с применением этого критерия связан ряд проблем. Во-первых, необходимо оценить общее число ошибок в программе. Во-вторых, требуется выяснить, какой процент этих ошибок можно определить тестированием. И, наконец, нужно определить, какая именно часть ошибок возникла в процессе проектирования и во время каких фаз тестирования целесообразно их выявлять.
Для оценки общего числа ошибок и выявления возможного процента ошибок, который можно обнаружить тестированием, можно воспользоваться методами, применяемыми при определении показателей надежности (модели надежности), например, с помощью модели Миллса или простой интуитивной модели, которые мы рассмотрим немного позже.
Другой способ получения такой оценки основан на статических средних величинах, широко применяемых в промышленности. Например, число ошибок, которое существует в типичных программах, по времени завершения кодирования (до проведения сквозного просмотра или инспекции) составляет примерно 4 - 8 на 100 операторов программы.
Модель Миллса основывается на внесении в программу ошибок с целью оценки в ходе тестирования числа остаточных ошибок, реально содержащихся в программе. Проверяя программу в течение некоторого времени и отсортировывая внесенные ошибки от собственно находящихся в программе, можно оценить число первоначально содержащихся в программе ошибок и число ошибок, оставшихся к моменту оценки.
Если в программу внесено случайным образом S ошибок, при проверке обнаружено n+V ошибок (n – число найденных собственных ошибок; V – число найденных внесенных ошибок), то предполагаемое число первоначально находящихся в программе собственных ошибок может быть рассчитано по формуле: .
Например, при обнаружении 20 собственных и 10 привнесенных ошибок, при общем числе первоначально внесенных ошибок, равном 25, значение N=25*20/10 = 50; т.е. на данном этапе предполагается, что в программе имелось 50 собственных ошибок и тестирование должно быть продолжено.
Оценку числа N можно проводить после каждого нового обнаружения ошибок.
Программа должна отлаживаться до тех пор, пока не будут обнаружены все внесенные ошибки. В момент обнаружения внесенных ошибок можно определить уровень доверия C, указывающий вероятность того, что оценка правильна:
где k - предполагаемое число собственных ошибок, S - число внесенных ошибок, n - число обнаруженных собственных ошибок.
Например, если утверждать, что в программе нет ошибок (k=0), и при внесении в программу 6 ошибок все они были обнаружены, а собственные ошибки обнаружены не были, то C=6/(6 + 0 + 1)=0,86. С другой стороны, чтобы достичь уровня доверия в 0,98 в программу необходимо ввести 39 ошибок: C=39/(39 + 0 + 1)=0,98.
Модель Миллса не лишена ряда недостатков, самые существенные из которых - это необходимость внесения искусственных ошибок (этот процесс плохо формализуем) и достаточно вольное допущение величины k (число собственных ошибок), которое основывается исключительно на интуиции человека, проводящего оценку, т.е. допускает большое влияние субъективного фактора.
Простая интуитивная модель предполагает проведение тестирования двумя группами программистов независимо друг от друга, использующими независимые тестовые наборы.
В процессе тестирования каждая из групп фиксирует все найденные ею ошибки. При оценке числа оставшихся в программе ошибок результаты тестирования обеих групп собираются и сравниваются.
Получается, что первая группа обнаружила N 1 ошибок, вторая – N 2 ошибок, а N 12 - это ошибки, обнаруженные обеими группами.
Если обозначить через N неизвестное количество ошибок, присутствующих в программе до начала тестирования, то можно эффективность тестирования каждой из групп определить как
Предполагая, что возможность обнаружения всех ошибок одинакова для обеих групп, можно допустить, что, если первая группа обнаружила определенное количество всех ошибок, она могла бы определить то же количество любого случайным образом выбранного подмножества.
В частности, можно допустить, что
Значение N 12 известно, а E 1 и Е 2 можно определить как N 12 /N 1 и N 12 /N 2 . Таким образом, неизвестное количество ошибок в про1рамме можно определить по формуле:
Развивая эту модель и опираясь на предположения, что обе группы, проводящие тестирование, имеют равную вероятность обнаружения "общих" ошибок, ее можно рассчитать по следующей формуле:
где P(N12i) - вероятность обнаружения N 12 "общих" ошибок тестирования программы двумя независимыми группами.
Определение ошибок, возникающих в процессе проектирования, использует данные, свидетельствующие о том, что в большом ПО примерно 40% всех ошибок составляют ошибки проектирования логики и кодирования, а остальные сделаны на более ранних этапах проектирования.
Исходя из этого, рассмотрим пример. Допустим, что тестируется программа размером 1000 операторов; число ошибок, остающихся после инспекции исходного текста, оценивается в 5 на 100 операторов. Цель тестирования - обнаружить 98% ошибок кодирования и логики и 95% ошибок проектирования.
Общее число ошибок составляет 500. Предполагается, что 200 из них составляют ошибки кодирования и логики, а 300 - ошибки проектирования. Следовательно, требуется найти 196 ошибок кодирования и логики и 285 ошибок проектирования.
Из соображений здравого смысла логично так распределить процентное отношение найденных ошибок по этапам тестирования, как показано в таблице.
Процентное отношение найденных ошибок по этапам тестирования.
Исходя из этих чисел, можно определить следующие критерии.
- На этапе тестирования модулей необходимо найти и исправить 130 ошибок (65% от оцененных 200 ошибок кодирования и логики).
- На этапе тестирования системы необходимо найти и исправить 6 ошибок и 105 (3% от 200 и 35% от 300).
Другая очевидная проблема для этого вида критериев - это проблема переоценки. Что если в приведенном примере к моменту начала проверки функций остается менее 240 ошибок? Основываясь на данном критерии, завершить фазу проверки функций не удается никогда. Во избежание такой ситуации критерий числа ошибок следует дополнить промежутком времени, в течение которого они должны быть обнаружены. В этом случае, если ошибки найдены быстро, то тестирование на определенном этапе следует продолжать до завершения заданного интервала времени. Если же возникает переоценка, т.е. время прошло, а заданное количество ошибок не обнаружено, то следует пригласить незаинтересованного эксперта, который выскажет свое мнение о причинах возникновения проблемы: либо тесты не эффективны, либо тесты удачны, но в программе действительно мало ошибок.
Наилучшим критерием завершения тестирования является комбинация всех трех рассмотренных подходов. Для тестирования модулей оптимальным будет первый рассмотренный критерий, потому что в большинстве проектов на этой фазе не следят за числом обнаруженных ошибок, здесь важно, чтобы использовался определенный набор методов проектирования тестов. На фазах тестирования функций и системы критерием завершения может служить останов по достижении заданного числа обнаруженных ошибок или достижение момента, определенного графиком работ, при условии, что анализ зависимости числа ошибок от времени тестирования покажет снижение продуктивности.
Когда нужно остановить тестирование и нужно ли его останавливать? Полный ли объем информации проработан и все ли учтено? И вообще – ? Эти вопросы актуальны для каждого тестировщика. Так давайте остановимся на минуту и подумаем: в какой момент нужно и можно прервать стремящийся к бесконечности процесс тестирования?
Причина для остановки: «Сроки поджимают! Время – деньги!»
Часто на проекте есть четко определенные сроки, которые заказчик не всегда готов передвинуть. В этом случае команда «заканчиваем тестирование!» зависит именно от установленных сроков, и это важный критерий. Да, такой сценарий нельзя назвать лучшим (так как времени всегда катастрофически не хватает для полной проверки, и часто страдает качество), но он тоже возможен.
Пример из практики. Вспоминается ситуация, когда из-за жестких сроков пострадало качество продукта. Тестировался интернет-магазин хозтоваров, и вместе с новой акционной скидкой только для зарегистрированных клиентов был внедрен баг: невозможность активировать несколько действующих на тот момент акций. Таким образом, релиз превратился в «релиз плюс еще пару напряженных дней баг-фикса». Наверное, гораздо лучше было подвинуть жесткие рамки на день-два и дать возможность дотестировать новый функционал… но в жизни встречаются разные ситуации.
Вывод. Главной задачей тестировщика в условиях ограниченного времени является охват максимально возможного количества критически важных тест-кейсов (тест-кейсы приоритета high и medium), запись всех найденных дефектов (во избежание их потери из-за времени и текучести задач) и формирование сообщения о реальном объеме проделанных работ. В итоге от тестировщика должна поступить полная картина проверенного и список того, что проверить еще не успели (чтобы в дальнейшем определить фронт работ).
Причина для остановки: «Это не конечная, а промежуточная»
Бывает, что в ходе тестирования нужно сделать вынужденную остановку, так как «что-то» критично блокирует оптимальную оценку тестируемого объекта, и из-за этого в дальнейшем может «протухнуть» вся система проверки. В таком случае лучше остановиться и дождаться решения проблемы.
Пример из практики.
Тестировалось довольно крупное медицинское программное обеспечение. На тестовом стенде не было возможности проверить в полном объеме новый функционал (отправку писем клиентам при заполнении формы и данных личного кабинета клиента). Задача была довольно обширной и затрагивала многие аспекты: активацию отдельных разделов при полной загрузке документов, ограничения в доступе к разделам при определенной степени заполнения профиля и другие. На вопрос перед релизом «все ли проверено и можно ли заканчивать тестирование?» однозначный ответ дать было просто невозможно: проверка частично блокировалась из-за невозможности проверить факт получения части писем на тестовой среде. В итоге при релизе на стороне клиента вылезли критические ошибки. Клиенту не поступали нужные уведомительные письма, а потому он не мог получить и полный доступ к своему профилю. Во избежание появления подобных ситуаций было найдено следующее решение: после доработки стали доступны опции отправки и получения писем на тестовом стенде, что позволило в дальнейшем проверять эту часть достаточно важного функционала. Включение этих проверок во все последующие прохождения регресса дало возможность более оптимально оценивать готовность продукта перед выпуском на клиентскую часть.
Вывод. Анализ ошибок позволил сделать верные выводы и устранить все блокирующие моменты. И все-таки, в подобной ситуации работа над оптимизацией средств и инструментов тестирования по итогу уже выявленных ошибок вряд ли может считаться хорошим вариантом. Несомненно, гораздо более уместной и правильной была бы остановка процесса тестирования и доработка изначально неполного функционала тестовой среды для предотвращения появления критических моментов уже на клиентской части.
Причина для остановки: «Стоять нельзя двигаться дальше». Где поставить запятую, и почему возникает неразбериха?»
Правильно ли исправлять баги прямо по ходу проверки, которая при этом не прерывается? Логика подсказывает, что процесс нужно остановить и начать с самого начала после внесения корректировки, так как любое исправление ошибки может повлечь за собой появление еще десятка новых.
Пример из практики. Сразу приходит на память довольно распространенный и известный любому тестировщику случай, когда по ходу тестирования обнаруживаются критические баги, а половина тест-кейсов уже проверена, и результаты по ним проставлены. Иногда разработчики стараются настолько быстро исправить ошибку, что «забывают» известить об этом старательного тестировщика, который вовсю спешит пройти все запланированные тест-кейсы с регресса. В итоге тестирование продолжается после исправления (bug-fix) вместо того, чтобы остановить проверку и начать ее заново; часть ошибок уже не будет обнаружена.
Вывод. В таких ситуациях разработчику важно своевременно сообщить о своих исправлениях тестировщику для того, чтобы тот остановил тестирование и повторно прошел тест-кейсы – все или только самые критичные и высокого приоритета (если времени остается не так уж и много). Это поможет избежать в дальнейшем неразберихи в вопросе: а откуда взялись новые дефекты в продукте, и кто за них отвечает?
Причина для остановки: «Поступил приказ отступать!»
Случается, что заказчик буквально на последнем этапе приостанавливает проверку. На это может быть масса причин: появление более важной задачи или функционала, который требует дальнейшего уточнения, переоценка приоритетов релиза, пересмотр плана на текущий момент. Наша задача при этом – приостановить процесс, но ничего не забыть!
Пример из практики. Случалось, что практически полностью протестированный релиз откладывался. Казалось бы, все готово – тщательно протестированы все блоки, сделаны все задачи, – и можно отдавать готовый продукт на радость пользователю, но заказчик вдруг решает, что лучше все сделать совершенно по-другому, а практически уже готовый релиз временно нужно остановить. Минусом такой ситуации является потраченное время тестировщика, плюсом – написанные тест-кейсы, которые могут быть использованы для проверки функционала другого ПО.
Вывод. Для тестировщика в таком случае важно написать качественные тест-кейсы, с которыми можно будет работать в дальнейшем либо на аналогичных задачах, либо (в случае возобновления работы) по отмененному/отложенному релизу.
Причина для остановки: «Все, устал, хватит!»
Остановка может произойти и просто из-за того, что напряжение достигло своего пика. Желание сделать как можно больше за максимально возможное время иногда негативно сказывается на результатах работы.
Пример из практики. На одном из наших проектов «случился» довольно затяжной релиз; мы тестировали его напряженно и активно. Тестирование в моей голове не прекращалось даже во время сна. И в тот момент, когда ошибка оказалась буквально перед моими глазами, явно «сигнализируя» мне в логах, – я ее просто не увидела. В такие моменты нужно уметь сказать себе: «Стой, передохни, а иначе допустишь ошибку, пропустишь баг, внимательность будет на нуле!» А внимательность – это основное качество тестировщика. Конечно, сам процесс нельзя просто взять и остановить, но выделить личное время на отдых – необходимо!
Вывод. В подобных случаях остановка в тестировании – это обязательный и важный момент для тестировщика. Заканчивая работу, нужно обязательно отдохнуть и отвлечься (заняться другим делом, например), дабы избежать «замыливания глаз».
Причина для остановки: «Есть сомнения? Остановись!»
Перед выходом каждого релиза тестировщик, оценивая проделанную работу и пройденный набор тест-кейсов, подводит итог: а все ли протестировано? Конечно, естественным состоянием будет желание продолжить процесс проверки, которое не всегда соответствует фактору времени. И все-таки обоснованные сомнения нужно по крайней мере озвучить. Даже если баг был «пойман» на последнем этапе, и его исправление задержит весь процесс релиза, – ни в коем случае нельзя оставлять ошибку без внимания, лучше остановить запущенный механизм и дать время на корректировку.
Пример из практики. В моем опыте были ситуация, когда ошибка обнаружилась уже на последних шагах (можно даже сказать, на последних минутах) регрессионного тестирования. Был ли это недочет тестировщика (то есть, мой)? Да, и это стало хорошим «пинком» для дальнейшей работы над своими ошибками. Но баг нужно было искоренять. Задачу «выкинули» из релиза для доработки, сам релиз состоялся довольно успешно. Не забывайте: заказчик скорее оценит качество проверки, чем соблюдения сроков без сохранения качества.
Вывод. Каждый этап процесса тестирования важен. Неверная проработка материала или неполное покрытие задачи тест-кейсами может стать причиной того, что тестировщик упустит важный и критический баг. На каком бы этапе тестирования это не обнаружилось – важно понимать, что в таких случаях необходимо остановиться, оценить ситуацию и принять решение о дальнейшем плане работ!
Причина для остановки: «По моему хотению – остановитесь!»
В тестировании важную роль играет понимание специалистом важности выпускаемого продукта. Плохо, если в человеке присутствует безразличие к итоговому продукту. В таком случае тестирование может остановиться просто потому, что сам процесс надоел тестировщику («и так сойдет!»).
По этому поводу вспоминается старый анекдот:
«Мужчина сшил в ателье костюм. Пришел домой, надел. Жена в ужасе:
– Ты что сшил? Посмотри: один рукав длиннее, другой – короче. Полы у пиджака разные, штанины. Неси все назад!
Муж пошел назад:
– Что вы мне сшили? Посмотрите! Брюки разной длины!
– А вы одну ногу согните в колене, ведь вы не ходите на прямых ногах. И все будет хорошо.
– Смотрите, рукава разной длины!
– Ну и что? Вы же не по швам руки держите. Согните их в локтях. Вот! Прекрасно!
– А полы? Что с ними делать?
– А вы немного набок наклонитесь. Все отлично!
Мужчина вышел в новом костюме. Люди на остановке:
– Смотри, какой урод! А как костюм хорошо сидит!»
Для тестировщика халатное отношение к процессу просто недопустимо. Все недочеты в итоге становятся явными, что в конечном итоге приводит к плачевным результатам.
Пример из практики. У меня и моих коллег, к счастью, таких ситуаций никогда не возникало: мы любим свою работу и с уважением относимся к конечным пользователям (ведь наши ошибки влияют на их опыт взаимодействия с продуктом). Надеюсь, подобного никогда и не случится. Главное – не забывать, что такое возможно, и избегать подобных случаев.
Вывод. Останавливать тестирование лишь по желанию тестировщика нельзя, каждая остановка должна быть обоснована. Решение об остановке процесса будет закономерным лишь в том случае, если оптимально и позитивно пройденным и тщательно проработанным оказывается целый набор параметров: написан полный объем тест-кейсов по задаче, правильно расставлены приоритеты для оценки времени в случае срочных или быстрых проверок, все задачи полностью проанализированы и сверены с техническими требованиями еще на начальных этапах ознакомления, все учтено на этапе планирования релиза.
И наконец… Барабанная дробь… Последняя, но самая желанная причина для остановки: «Готово, можно забирать!»
При начале планирования нового релиза закладывается определенный план тестирования, приоритеты и объемы. Правильное планирование ведет к положительным и качественным результатам. Когда все результаты тестирования полностью удовлетворяют критериям качества, можно смело сказать себе: «Стоп, здесь мы сделали все, что могли!» Но для этого нужно, чтобы все найденные ошибки были исправлены, все запланированные тест-кейсы пройдены (и не обнаружено ни одного бага выше минорного), все необходимые правки выполнены, а результат приемочного тестирования оказался полностью положительным. И так бывает на самом деле! Заказчик в таком случае доволен, а тестировщик может смело выписывать себе «медаль» за хорошую работу. А уж как это настраивает на дальнейшие «подвиги»!
Пример из практики. К примеру, некоторое время назад тестировали обновление сайта бытовой техники. Сайт пользовался и продолжает пользоваться довольно большой популярностью, ответственность за выпускаемый продукт была достаточно высокой. Итогом проведенного релиза стала положительная динамика и улучшение статистики по количеству пользователей, оформивших заказ через интернет. Это, конечно, огромный плюс для заказчика. Главный же показатель удачного релиза для тестировщиков – это продукт, максимально адаптированный под клиента и содержащий минимальное количество ошибок (а может, их там вообще не осталось?!!!). Остановка тестирования в таком случае вполне закономерна, так как заложена в четко установленных сроках с учетом всех необходимых критериев.
Вывод. Для получения хорошего результата важно учитывать в работе все факторы. Оценка и анализ задачи, написание тест-кейсов для ее покрытия, расчет времени и максимальная внимательность гарантируют положительные результаты в работе.
Финал
Подводя итоги, можно сказать, что последний сценарий – это идеальный вариант остановки тестирования: в нем сочетаются верное планирование, детальное тестирование и итоговая положительная приемочная часть. В остальных случаях остановки происходят из-за ошибок тестировщика, по желанию заказчика, недостаточно продуманного плана тестирования, неверного расчета времени или просто из-за лени (кстати, недопустимого в нашей профессии качества).
Поэтому и остановки в таких случаях не влекут за собой того конечного положительного результата, которого всегда хочется добиться. В данной ситуации важно сделать правильные выводы и вычленить причину основной ошибки. Как правило, это неверное планирование времени, боязнь спросить разработчика о готовности исправлений (то есть, плохо налаженное общение между разработчиком и тестировщиком) и халатное написание тест-кейсов из-за неполного ознакомления со спецификациями и требованиями. Выявив слабые места на проекте или в личных качествах, можно приступить к проработке плана дальнейшей более результативной работы.
Для этого всегда необходимо учитывать : условия и пожелания заказчика, установленные временные рамки и степень покрытия тест-кейсами требований, указанных и описанных в задаче. Каждый пункт должен быть четко проработан и обговорен как с заказчиком, так и с разработчиком. Тестировщик должен представлять объем работ: какое тестирование можно успеть осуществить в обозначенные сроки, сколько тест-кейсов потребуется, до какого момента допускаются баг-фиксы, когда начинается код фриз и допускает ли найденное количество багов сам выпуск продукта.
Конечно, каждый проект имеет свои особенности. Невозможно найти единый правильный эталонный метод решения. И все-таки учет указанных выше основных критериев приведет к тому, что выпускаемый продукт будет максимально соответствовать поставленным требованиям, а процесс и остановка тестирования будут понятны и закономерны.