Отсутствие силы воли у наших людей породило огромное количество тренингов. Людям нужен толчок, чтобы отказаться от надоедливой работы, нелюбимого человека и серых будней. Однако запала надолго не хватает. В конце концов они вернутся за новой порцией мотивации. Относишь ли ты к ним или можешь оставаться счастливым самостоятельно? Сейчас проверим!
Добро – это то, чего не хватает современному обществу. Убедиться в этом можно пролистав ленту новостей. Позитивного и доброго там мало. Мы поддерживаем мнение, что начинать всегда надо с себя. Пусть этот тест будет твоим первым шагом.
Интуиция - это то, что мы привыкли называть "совпадением" и "случайностью". На самом деле именно шестое чувство приводит нас к тому самому совпадению, которое способно поменять ход событий. Старая, как мир, игра "Орел или Решка" - прекрасный способ проверить свою интуицию. Казалось бы, нет ничего сложного угадать, ведь шанс предельно высок - 50%! Как бы не так. Мы сделаем 8 бросков, попробуй дать столько же правильных ответов.
Союза нерушимых республик свободных уже давно нет, но это не означает, что можно забыть историю великой державы, которая оставила такой яркий след в истории. Сегодня мы подготовили тест, состоящий из вопросов, с которыми справится лишь выпускник советской школы, так как они требуют глубокие знания. Если ты считаешь, что справишься, то скорее приступай!
Биологический возраст - это далеко не самый важный показатель в жизни. Существуют куда более весомые цифры. Например, сколько лет вашей душе или мозгу. Наш поток мыслей - это невероятно сложная система, она развивается и растет вместе с нами. С точки зрения психологии, каждому возрасту соответствуют определенные мысли и выбор. Давайте разберемся, вы преуспеваете или отстаете в своем развитии.
Магистр клуба "Что? Где? Когда?" скандально отстранен от участия в программе. Теперь у него больше нет права своими знаниями и логикой зарабатывать деньги, популярность и уважение. Но, как говорится, на корабле всегда должен быть капитан, предлагаем тебе попробовать занять его место. Используй свой жизненный опыт, логику и смекалку!
Работа – твой второй дом, и весь мир крутится вокруг неё? Или же, работа – способ выжить и приобрести желаемое? Как хорошо ты работаешь и выполняешь свои обязанности, по достоинству ли тебе платят за неё, а может быть, ты заслуживаешь повышения? Пройди наш тест и узнай, какой зарплаты ты, действительно, заслуживаешь. И не забудь показать результат своему начальнику!
Классический набор блюд в России - это пельмени, яичница, жареная картошка, борщ и макароны по-флотски. Это меню закрепилось за нами ещё с советских лет, когда выбор продуктов был скудным. Но так продолжаться больше не может, поэтому предлагаем тебе пройти наш просветительный тест.
Нет проблемы в том, чтобы узнать на фото Альберта Эйнштейна или Михаэля Шумахера. Но мало кто знает, что во всех сферах жизни есть женщины, заслужившие не меньшего внимания. Восстанавливаем справедливость и знакомим тебя с ними.
Сегодня мы подготовили необычайно интересный тест! Он уникален тем, что тут собраны психологические задачи, для решения которых потребуется не ум и логика, а фантазия и внимательность. Если ты считаешь, что справишься, то скорее приступай! Безусловно, твои знания тебе тоже очень помогут!
Знаменитая игра «Кто хочет стать миллионером?» годами собирает целые семьи перед телевизором. Волнение и азарт, которые испытывают участники игры, жаждущие выиграть заветные миллионы, передаются и телезрителям. И не расстраивайся, если по ту сторону экрана ты еще не оказался, ведь сегодня у тебя есть отличная возможность потренироваться! Проверь свои знания!
Любовь – это очень непростое чувство. Некоторым для выражения своих чувств достаточно нескольких дней знакомства, другие же не осмеливаются о них сказать годами, боясь всё испортить. Возможно, наш тест подскажет вам того, кто уже давно не спит по ночам, ломая голову над тем, как вам понравится. И, кто знает, может это перевернёт вашу жизнь!
Самые сумасшедшие и неадекватные люди всегда оказывались примерными семьянинами и работниками. Окружающие могут не замечать, но агрессия внутри переполняет их сердца. Если не проверяться у специалиста, то рано или поздно это выйдет наружу. Наш тест как раз должен помочь разобраться. Точного диагноза не поставим, но о проблеме намекнем.
Когда-то тест Джозефа Сакса впечатлил меня способностью структурировать мои хаотичные представления об окружающем мире, о себе и других.
Методика включает 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.
Методика «Неоконченных предложений» применяется в экспериментально-психологической практике давно. Однако, доступен он не только профессионалам. Этот тест можно использовать, как отправную точку в изучении себя и своего отношения к другим и миру в целом. Если результаты Вас расстроили, не спешите впадать в уныние: обсудите их с психологом или человеком, которому Вы доверяете. Так или иначе, каждая группа теста требует отдельного обсуждения и осознавания, а также дополнительного подтверждения другими методиками.
Начало - половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.
Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).
Но в дальнейшем нередко возникают сложности. По завершении первого раунда тестирования, тестировщики обычно находят кучу багов, а затем подходят ко второму этапу несколько расслабленными. Имеет место т.н. человеческий фактор и общечеловеческая тенденция, когда становится скучно выполнять повторные операции.
В подобных ситуациях у многих возникает ощущение того, что они делают монотонную работу, и, как следствие, теряется интерес к продолжению тестирования уже знакомого ПО. И во время третьего, примерно, раунда над тестировщиком неумолимо нависает вопрос: «Когда же все-таки нужно прекращать тестирование?»
Каждый тестировщик хотя бы раз задавался таким вопросом, расширенная версия которого выглядела бы так:
Многие тестировщики полагают, что не существует каких-то особых условий, указывающих на то, что тестирование следует завершить. Но чтобы ответить на этот вопрос, придется проанализировать тестовую активность от начала до конца.
Допустим, стоит задача протестировать новый проект.
Начальные действия:
- Команда тестировщиков получает требования.
- Затем следует планирование и разработка.
- Подготавливается и проверяется документация по тестированию.
Тестирование, раунд #1)
Команда тестировщиков приступает к тестированию, как только ей передают только что созданный программный продукт.
На этапе тестирования тестировщики выполняют различные сценарии, пытаясь взломать ПО и обнаружить дефекты. (Поскольку приложение новое и проходит оценку впервые, показатель обнаруженных дефектов будет сравнительно высоким).
Разработчики устраняют дефекты и возвращают разработку тестировщикам для повторного теста.
Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к .
Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.
Тестирование, раунд #2)
Тестировщики начинает второй раунд тестирования и повторяют то, что выполнялось во время первого раунда.
Во время этого процесса, как правило, обнаруживаются еще некоторые дефекты.
Дефекты устраняются разработчиками и приложение вновь отправляется на проверку.
Тестировщики проводят повторные тесты и регрессионное тестирование тех частей разработки, которые не претерпели изменения.
Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.
Но представляется ли теоретически возможным найти абсолютно все дефекты? Это вопрос на миллион долларов, но попробуем на него ответить.
Большинство приложений устроены сложно, оттого фронт их тестирования достаточно большой. Не то чтобы обнаружить абсолютно все дефекты совсем невозможно, но для этого понадобится вечность.
Даже после того, как большинство багов в ПО найдены, никто не сможет с уверенностью заявить, что приложение стало безупречным.
Более того, такая задача не стоит. Цель тестирование ПО - убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.
У приложений может быть бесконечное множество дефектов, и проводить до полного их устранения непрактично. Никогда не знаешь, какой из багов окажется последним.
А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?
Попытаемся разобраться, какие факторы следует считать наиболее важными?
Решение о прекращении тестирования обычно зависит от времени (которое есть в распоряжении), бюджета и необходимой продолжительности тестирования.
Чаще всего решение завершить тестирование принимается, когда закончилось время/бюджет, или же когда все тестовые сценарии выполнены. Но это компромиссное решение, которое может быть в ущерб качеству.
Пример
Сценарий тестирования:
Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.
Сценарий #1)
Первая неделя : Вы добились успеха - в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.
Неделя 2 : Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.
Неделя 3 : К началу третьей недели все дефекты с высоким приоритетом устранены, но теперь к выполнению текущих сценариев добавляется еще и перепроверка ранее обнаруженных багов. За третью неделю вы охватили 120 сценариев, и нашли еще несколько багов. Теперь остается искать только дефекты третьего порядка.
Неделя 4 : К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.
Данные о проведенном тестировании помещаются в таблицу:
| Недели #1-4 |
Работа | |
| Неделя #1 |
|
|
| Неделя #2 |
|
|
| Неделя #3 |
|
|
| Неделя #4 |
|
|
Может этого уже достаточно?
Время, отведенное на тестирование, истекло. Вы нашли и устранили ряд дефектов первого уровня. Если на этом остановиться, можно ли будет считать разработанное ПО надежным? Не совсем, в силу некоторых причин:
- Сценарии проверены не все.
- Несколько потенциально опасных дефектов не тестировались ни разу.
- Все проверенные сценарии тестировались только раз.
- У ПО все еще есть дефекты.
Сценарий #2)
Неделя 1 : Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.
Результаты первой недели аналогичны примеру #1.
Неделя 2 : За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача - охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.
Неделя 3 : К началу третьей недели все приоритетные дефекты устранены, и теперь, помимо текущих сценариев, необходимо перепроверить ранее обнаруженные дефекты. За третью неделю вы охватили 200 сценариев, и нашли еще ряд багов.
Теперь вы может сообщить только о дефектах второго и третьего уровня.
Данные о проведенном тестировании:
| Недели #1-3 | Работа | Результаты по истечении недели |
| Неделя #1 |
|
|
| Неделя #2 |
|
|
| Неделя #3 |
|
|
Этого достаточно?
Вы охватили полностью все сценарии тестирования, нашли еще несколько дефектов. Если на этом остановиться, можно ли будет считать ПО надежным?
Не совсем:
- Все сценарии проверялись лишь по разу.
- У ПО все еще есть дефекты.
- Регрессионное тестирование не проводилось.
Как можно видеть, оба сценария не гарантируют качества. Лучше всего в такой ситуации попытаться найти золотую середину, использовать такой подход, который бы учитывал все лучшие особенности из первого и второго сценариев. Для этого понадобится определить ряд критериев.
Критерии завершения или выхода
Критерий выхода позволяет установить, какой объем тестирования следует считать достаточным. Определяется он по завершении цикла тестирования и включается в план. Это набор условий или активностей, которые должны быть выполнены, чтобы тестирование можно было назвать законченным.
Что включает в себя критерий выхода?
В идеале это комбинация нескольких факторов, уникальных для всех проектов. Все зависит от требований конкретного проекта. Поэтому во время планирования целесообразнее подсчитать как можно больше параметров.
Ниже приведены некоторые нюансы, которые стоит учитывать во время или . Вы можете составить определенную комбинацию или же использовать все эти факторы, чтобы определить, когда именно следует завершить тестирование.
Тестирование может быть завершено когда:
- Все 100% требований учтены.
- Дефекты установлены/ожидаемое число дефектов обнаружено.
- Все дефекты, относящиеся к классу Show Stopper или Blocker, устранены, ни у одного из критических дефектов нет статуса «открытый».
- Все дефекты с высоким приоритетом идентифицированы и исправлены.
- Defect Rate (скорость дефектообразования) ниже установленного допустимого уровня.
- Очень небольшое число дефектов среднего уровня критичности «открыты», их разбор проведен.
- Число «открытых» дефектов среднего уровня, которые не влияют на пользование системой, очень небольшое.
- Все дефекты с высоким уровнем приоритета закрыты и соответствующие регрессивные сценарии успешно проведены.
Охват теста:
- Охват теста должен быть на уровне 95%.
- Pass Rate текст-кейса также должен быть 95%. Для расчета этого процентного соотношения применяется формула:
(Общее число успешных текст-кейсов / общее число тест-кейсов) * 100.
- Все критически важные тест-кейсы оказались успешными
- 5% тест-кейсов могут быть провалены, но это относится к низкоприоритетным кейсам.
- Достигнуто полное покрытие функционала.
- Все крупные функциональные дефекты успешно устранены.
Сроки:
Срок, отведенный на тестирование, истек.
Документация по тестированию:
Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.
Бюджет:
- Бюджет, выделенный на тестирование, полностью израсходован.
- Совещания в формате «Go / No Go» проведены, решение о релизе продукта принято.
И в заключение, пожалуйста, ответьте на несколько вопросов
Если большинство ответов окажутся утвердительными, это будет означать, что вы можете завершить тестирование. Если большинство ответов будут отрицательными, тогда придется искать, что было упущено.
- Были ли все тест-кейсы проверены по меньшей мере один раз?
- Установлен ли показатель успешности тест-кейса (Test Case Pass)?
- Достигнут ли полный охват тестирования?
- Все функциональные/бизнес «потоки» проверены как минимум раз?
- Найдено ли установленное число дефектов?
- Устранены и «закрыты» ли все дефекты с высоким приоритетом?
- Все ли дефекты прошли повторную проверку и считаются «закрытыми»?
- Регрессивное тестирование проведено для всех «открытых» дефектов?
- Закончился ли выделенный на тестирование бюджет?
- Истекли ли сроки проведения тестирования?
- Вся ли документация по тестированию проверена и опубликована?
Когда нужно остановить тестирование и нужно ли его останавливать? Полный ли объем информации проработан и все ли учтено? И вообще – ? Эти вопросы актуальны для каждого тестировщика. Так давайте остановимся на минуту и подумаем: в какой момент нужно и можно прервать стремящийся к бесконечности процесс тестирования?
Причина для остановки: «Сроки поджимают! Время – деньги!»
Часто на проекте есть четко определенные сроки, которые заказчик не всегда готов передвинуть. В этом случае команда «заканчиваем тестирование!» зависит именно от установленных сроков, и это важный критерий. Да, такой сценарий нельзя назвать лучшим (так как времени всегда катастрофически не хватает для полной проверки, и часто страдает качество), но он тоже возможен.
Пример из практики. Вспоминается ситуация, когда из-за жестких сроков пострадало качество продукта. Тестировался интернет-магазин хозтоваров, и вместе с новой акционной скидкой только для зарегистрированных клиентов был внедрен баг: невозможность активировать несколько действующих на тот момент акций. Таким образом, релиз превратился в «релиз плюс еще пару напряженных дней баг-фикса». Наверное, гораздо лучше было подвинуть жесткие рамки на день-два и дать возможность дотестировать новый функционал… но в жизни встречаются разные ситуации.
Вывод. Главной задачей тестировщика в условиях ограниченного времени является охват максимально возможного количества критически важных тест-кейсов (тест-кейсы приоритета high и medium), запись всех найденных дефектов (во избежание их потери из-за времени и текучести задач) и формирование сообщения о реальном объеме проделанных работ. В итоге от тестировщика должна поступить полная картина проверенного и список того, что проверить еще не успели (чтобы в дальнейшем определить фронт работ).
Причина для остановки: «Это не конечная, а промежуточная»
Бывает, что в ходе тестирования нужно сделать вынужденную остановку, так как «что-то» критично блокирует оптимальную оценку тестируемого объекта, и из-за этого в дальнейшем может «протухнуть» вся система проверки. В таком случае лучше остановиться и дождаться решения проблемы.
Пример из практики.
Тестировалось довольно крупное медицинское программное обеспечение. На тестовом стенде не было возможности проверить в полном объеме новый функционал (отправку писем клиентам при заполнении формы и данных личного кабинета клиента). Задача была довольно обширной и затрагивала многие аспекты: активацию отдельных разделов при полной загрузке документов, ограничения в доступе к разделам при определенной степени заполнения профиля и другие. На вопрос перед релизом «все ли проверено и можно ли заканчивать тестирование?» однозначный ответ дать было просто невозможно: проверка частично блокировалась из-за невозможности проверить факт получения части писем на тестовой среде. В итоге при релизе на стороне клиента вылезли критические ошибки. Клиенту не поступали нужные уведомительные письма, а потому он не мог получить и полный доступ к своему профилю. Во избежание появления подобных ситуаций было найдено следующее решение: после доработки стали доступны опции отправки и получения писем на тестовом стенде, что позволило в дальнейшем проверять эту часть достаточно важного функционала. Включение этих проверок во все последующие прохождения регресса дало возможность более оптимально оценивать готовность продукта перед выпуском на клиентскую часть.
Вывод. Анализ ошибок позволил сделать верные выводы и устранить все блокирующие моменты. И все-таки, в подобной ситуации работа над оптимизацией средств и инструментов тестирования по итогу уже выявленных ошибок вряд ли может считаться хорошим вариантом. Несомненно, гораздо более уместной и правильной была бы остановка процесса тестирования и доработка изначально неполного функционала тестовой среды для предотвращения появления критических моментов уже на клиентской части.
Причина для остановки: «Стоять нельзя двигаться дальше». Где поставить запятую, и почему возникает неразбериха?»
Правильно ли исправлять баги прямо по ходу проверки, которая при этом не прерывается? Логика подсказывает, что процесс нужно остановить и начать с самого начала после внесения корректировки, так как любое исправление ошибки может повлечь за собой появление еще десятка новых.
Пример из практики. Сразу приходит на память довольно распространенный и известный любому тестировщику случай, когда по ходу тестирования обнаруживаются критические баги, а половина тест-кейсов уже проверена, и результаты по ним проставлены. Иногда разработчики стараются настолько быстро исправить ошибку, что «забывают» известить об этом старательного тестировщика, который вовсю спешит пройти все запланированные тест-кейсы с регресса. В итоге тестирование продолжается после исправления (bug-fix) вместо того, чтобы остановить проверку и начать ее заново; часть ошибок уже не будет обнаружена.
Вывод. В таких ситуациях разработчику важно своевременно сообщить о своих исправлениях тестировщику для того, чтобы тот остановил тестирование и повторно прошел тест-кейсы – все или только самые критичные и высокого приоритета (если времени остается не так уж и много). Это поможет избежать в дальнейшем неразберихи в вопросе: а откуда взялись новые дефекты в продукте, и кто за них отвечает?
Причина для остановки: «Поступил приказ отступать!»
Случается, что заказчик буквально на последнем этапе приостанавливает проверку. На это может быть масса причин: появление более важной задачи или функционала, который требует дальнейшего уточнения, переоценка приоритетов релиза, пересмотр плана на текущий момент. Наша задача при этом – приостановить процесс, но ничего не забыть!
Пример из практики. Случалось, что практически полностью протестированный релиз откладывался. Казалось бы, все готово – тщательно протестированы все блоки, сделаны все задачи, – и можно отдавать готовый продукт на радость пользователю, но заказчик вдруг решает, что лучше все сделать совершенно по-другому, а практически уже готовый релиз временно нужно остановить. Минусом такой ситуации является потраченное время тестировщика, плюсом – написанные тест-кейсы, которые могут быть использованы для проверки функционала другого ПО.
Вывод. Для тестировщика в таком случае важно написать качественные тест-кейсы, с которыми можно будет работать в дальнейшем либо на аналогичных задачах, либо (в случае возобновления работы) по отмененному/отложенному релизу.
Причина для остановки: «Все, устал, хватит!»
Остановка может произойти и просто из-за того, что напряжение достигло своего пика. Желание сделать как можно больше за максимально возможное время иногда негативно сказывается на результатах работы.
Пример из практики. На одном из наших проектов «случился» довольно затяжной релиз; мы тестировали его напряженно и активно. Тестирование в моей голове не прекращалось даже во время сна. И в тот момент, когда ошибка оказалась буквально перед моими глазами, явно «сигнализируя» мне в логах, – я ее просто не увидела. В такие моменты нужно уметь сказать себе: «Стой, передохни, а иначе допустишь ошибку, пропустишь баг, внимательность будет на нуле!» А внимательность – это основное качество тестировщика. Конечно, сам процесс нельзя просто взять и остановить, но выделить личное время на отдых – необходимо!
Вывод. В подобных случаях остановка в тестировании – это обязательный и важный момент для тестировщика. Заканчивая работу, нужно обязательно отдохнуть и отвлечься (заняться другим делом, например), дабы избежать «замыливания глаз».
Причина для остановки: «Есть сомнения? Остановись!»
Перед выходом каждого релиза тестировщик, оценивая проделанную работу и пройденный набор тест-кейсов, подводит итог: а все ли протестировано? Конечно, естественным состоянием будет желание продолжить процесс проверки, которое не всегда соответствует фактору времени. И все-таки обоснованные сомнения нужно по крайней мере озвучить. Даже если баг был «пойман» на последнем этапе, и его исправление задержит весь процесс релиза, – ни в коем случае нельзя оставлять ошибку без внимания, лучше остановить запущенный механизм и дать время на корректировку.
Пример из практики. В моем опыте были ситуация, когда ошибка обнаружилась уже на последних шагах (можно даже сказать, на последних минутах) регрессионного тестирования. Был ли это недочет тестировщика (то есть, мой)? Да, и это стало хорошим «пинком» для дальнейшей работы над своими ошибками. Но баг нужно было искоренять. Задачу «выкинули» из релиза для доработки, сам релиз состоялся довольно успешно. Не забывайте: заказчик скорее оценит качество проверки, чем соблюдения сроков без сохранения качества.
Вывод. Каждый этап процесса тестирования важен. Неверная проработка материала или неполное покрытие задачи тест-кейсами может стать причиной того, что тестировщик упустит важный и критический баг. На каком бы этапе тестирования это не обнаружилось – важно понимать, что в таких случаях необходимо остановиться, оценить ситуацию и принять решение о дальнейшем плане работ!
Причина для остановки: «По моему хотению – остановитесь!»
В тестировании важную роль играет понимание специалистом важности выпускаемого продукта. Плохо, если в человеке присутствует безразличие к итоговому продукту. В таком случае тестирование может остановиться просто потому, что сам процесс надоел тестировщику («и так сойдет!»).
По этому поводу вспоминается старый анекдот:
«Мужчина сшил в ателье костюм. Пришел домой, надел. Жена в ужасе:
– Ты что сшил? Посмотри: один рукав длиннее, другой – короче. Полы у пиджака разные, штанины. Неси все назад!
Муж пошел назад:
– Что вы мне сшили? Посмотрите! Брюки разной длины!
– А вы одну ногу согните в колене, ведь вы не ходите на прямых ногах. И все будет хорошо.
– Смотрите, рукава разной длины!
– Ну и что? Вы же не по швам руки держите. Согните их в локтях. Вот! Прекрасно!
– А полы? Что с ними делать?
– А вы немного набок наклонитесь. Все отлично!
Мужчина вышел в новом костюме. Люди на остановке:
– Смотри, какой урод! А как костюм хорошо сидит!»
Для тестировщика халатное отношение к процессу просто недопустимо. Все недочеты в итоге становятся явными, что в конечном итоге приводит к плачевным результатам.
Пример из практики. У меня и моих коллег, к счастью, таких ситуаций никогда не возникало: мы любим свою работу и с уважением относимся к конечным пользователям (ведь наши ошибки влияют на их опыт взаимодействия с продуктом). Надеюсь, подобного никогда и не случится. Главное – не забывать, что такое возможно, и избегать подобных случаев.
Вывод. Останавливать тестирование лишь по желанию тестировщика нельзя, каждая остановка должна быть обоснована. Решение об остановке процесса будет закономерным лишь в том случае, если оптимально и позитивно пройденным и тщательно проработанным оказывается целый набор параметров: написан полный объем тест-кейсов по задаче, правильно расставлены приоритеты для оценки времени в случае срочных или быстрых проверок, все задачи полностью проанализированы и сверены с техническими требованиями еще на начальных этапах ознакомления, все учтено на этапе планирования релиза.
И наконец… Барабанная дробь… Последняя, но самая желанная причина для остановки: «Готово, можно забирать!»
При начале планирования нового релиза закладывается определенный план тестирования, приоритеты и объемы. Правильное планирование ведет к положительным и качественным результатам. Когда все результаты тестирования полностью удовлетворяют критериям качества, можно смело сказать себе: «Стоп, здесь мы сделали все, что могли!» Но для этого нужно, чтобы все найденные ошибки были исправлены, все запланированные тест-кейсы пройдены (и не обнаружено ни одного бага выше минорного), все необходимые правки выполнены, а результат приемочного тестирования оказался полностью положительным. И так бывает на самом деле! Заказчик в таком случае доволен, а тестировщик может смело выписывать себе «медаль» за хорошую работу. А уж как это настраивает на дальнейшие «подвиги»!
Пример из практики. К примеру, некоторое время назад тестировали обновление сайта бытовой техники. Сайт пользовался и продолжает пользоваться довольно большой популярностью, ответственность за выпускаемый продукт была достаточно высокой. Итогом проведенного релиза стала положительная динамика и улучшение статистики по количеству пользователей, оформивших заказ через интернет. Это, конечно, огромный плюс для заказчика. Главный же показатель удачного релиза для тестировщиков – это продукт, максимально адаптированный под клиента и содержащий минимальное количество ошибок (а может, их там вообще не осталось?!!!). Остановка тестирования в таком случае вполне закономерна, так как заложена в четко установленных сроках с учетом всех необходимых критериев.
Вывод. Для получения хорошего результата важно учитывать в работе все факторы. Оценка и анализ задачи, написание тест-кейсов для ее покрытия, расчет времени и максимальная внимательность гарантируют положительные результаты в работе.
Финал
Подводя итоги, можно сказать, что последний сценарий – это идеальный вариант остановки тестирования: в нем сочетаются верное планирование, детальное тестирование и итоговая положительная приемочная часть. В остальных случаях остановки происходят из-за ошибок тестировщика, по желанию заказчика, недостаточно продуманного плана тестирования, неверного расчета времени или просто из-за лени (кстати, недопустимого в нашей профессии качества).
Поэтому и остановки в таких случаях не влекут за собой того конечного положительного результата, которого всегда хочется добиться. В данной ситуации важно сделать правильные выводы и вычленить причину основной ошибки. Как правило, это неверное планирование времени, боязнь спросить разработчика о готовности исправлений (то есть, плохо налаженное общение между разработчиком и тестировщиком) и халатное написание тест-кейсов из-за неполного ознакомления со спецификациями и требованиями. Выявив слабые места на проекте или в личных качествах, можно приступить к проработке плана дальнейшей более результативной работы.
Для этого всегда необходимо учитывать : условия и пожелания заказчика, установленные временные рамки и степень покрытия тест-кейсами требований, указанных и описанных в задаче. Каждый пункт должен быть четко проработан и обговорен как с заказчиком, так и с разработчиком. Тестировщик должен представлять объем работ: какое тестирование можно успеть осуществить в обозначенные сроки, сколько тест-кейсов потребуется, до какого момента допускаются баг-фиксы, когда начинается код фриз и допускает ли найденное количество багов сам выпуск продукта.
Конечно, каждый проект имеет свои особенности. Невозможно найти единый правильный эталонный метод решения. И все-таки учет указанных выше основных критериев приведет к тому, что выпускаемый продукт будет максимально соответствовать поставленным требованиям, а процесс и остановка тестирования будут понятны и закономерны.
Читайте также:
|
Организация процесса тестирования. Разработка ПО в значительной степени есть процесс передачи информации о конечной программе и перевода этой информации из одной формы в другую. Кроме того, подавляющее число ошибок ПО вызвано дефектами организации работ, недостаточным взаимопониманием и искажениями в процессе передачи и перевода информации.
Путем повышения четкости самого процесса разработки можно избежать появления многих ошибок. Это приводит к тому, что в конце каждого этапа необходимо включение отдельного шага проверки, имеющего целью локализовать наибольшее число ошибок до перехода к следующему этапу. Например, спецификация проверяется путем ее сравнения с выходным результатом предыдущей стадии, а каждая обнаруженная ошибка возвращается для устранения в процесс разработки спецификаций.
Кроме того, конкретные процессы тестирования должны быть ориентированы на конкретные этапы разработки. Это сосредотачивает каждый процесс тестирования на каком-либо шаге перевода, в результате чего фиксируется определенный класс ошибок.
Соотношение между процессами разработки и тестирования.
Собственно процесс тестирования начинается с проверки исходного кода. Для этого применяются методы статического тестирования.
Далее следует тестирование модулей, ориентированное на проверку соответствия спецификациям интерфейса модулей, а также тестирование сопряжения и результатов сборки модульной структуры, ориентированное на проверку соответствия проекту системы и (или) проекту структуры отдельной программы.
После этого появляется тестирование функций, которое заключается в поиске различий между программой и ее внешней спецификацией. При тестировании функций обычно применяются методы функционального тестирования. При этом предполагается, что на более раннем этапе тестирования модулей требуемый критерий покрытия логики, свойственный методам структурного тестирования, удовлетворяется.
Для сопоставления результатов разработки с исходными целями появляется процесс комплексного тестирования или, как его еще называют, тестирование системы, в котором проверяется все ПС как единое целое. При рассмотрении различий между полученными результатами и исходными целями разработки ПО наибольшее внимание уделяется выявлению ошибок перевода, возникающих в процессе разработки внешней спецификации. Это делает комплексное тестирование жизненно важным, так как именно на этом этапе обнаруживается больше всего серьезных ошибок.
Процесс тестирования завершают испытания ПО. Испытания позволяют проверить полноту решения функциональных задач, их качество и соответствие ПО технической документации.
Тестирование системы. В отличие от тестирования функций, внешнюю спецификацию нельзя использовать как базис для получения тестов системы, поскольку это противоречит цели проведения такого тестирования. С другой стороны, документ, отражающий цели системы как таковой (в нашем случае - это техническое задание), нельзя использовать для формирования ее тестов, так как он по определению не содержит точных описаний.
Проблема разрешается применением эксплуатационной пользовательской документации. Тесты системы проектируются на основе анализа ее целей по результатам изучения пользовательской документации. Такая практика позволяет сравнить не только программы с исходным документом, но и результаты ее функционирования с пользовательской документацией, а также пользовательскую документацию с исходным документом.
Существует несколько категорий тестов, каждая из которых направлена на проверку определенных целей. К ним относятся тестирование полноты реализации, тестирование на предельных объемах, тестирование на предельных нагрузках, тестирование удобства эксплуатации, тестирование защиты, тестирование конфигурации оборудования, тестирование совместимости, тестирование надежности, тестирование восстановления, тестирование удобства обслуживания, тестирование удобства установки и тестирование документации.
Тестирование полноты реализации является наиболее очевидным видом тестирования системы, который заключается в проверке выполнения каждого пункта исходного документа. Процедура проверки состоит в последовательном просмотре исходного документа - предложение за предложением. Если предложение содержит конкретную задачу, то определяют, выполняет ли программа эту задачу.
Тестирование на предельных объемах заключается в выполнении программы на больших объемах данных, желательно превышающих предлагаемый эксплуатационный объем. Например, на вход компилятора в качестве теста подают большую исходную программу, на вход редактора связей -программу, содержащую тысячу модулей, а на вход программы моделирования электронных схем - схему, содержащую тысячи компонентов. Цель тестирования на предельных объемах - показать, что программа не может управлять объемом данных, специфицированным в исходных целях.
Тестирование на предельных нагрузках обусловлено тем, что потребность в ресурсах памяти и быстродействии в процессе решения задачи на ЭВМ значительно изменяется в зависимости от состава объема исходных данных. При высокой интенсивности ввода исходных данных может нарушаться временной баланс между длительностью решения совокупности задач ПО в реальном времени и реальной производительностью ЭВМ при решении этих задач. Цель тестирования на предельных нагрузках показать, что ПО не удовлетворяет целям в области эффективности.
Тестирование удобства эксплуатации заключается в выявлении психологических (пользовательских) проблем, возникающих при эксплуатации. При этом тестировании следует установить, как минимум, следующее.
- Можно ли приспособить разработанный интерфейс для информирования и обучения конечного пользователя, а также для обеспечения его работы в реальных условиях?
- Значимы ли, внятны ли, не оскорбительны ли выходные сообщения программы?
- Понятна ли диагностика ошибок?
- Проявляет ли все множество пользовательских интерфейсов постоянство и единообразие синтаксиса, соглашений, семантик, формата, стиля и сокращений?
- Содержит ли система опции, число которых чрезмерно или использование которых маловероятно?
- Выдает ли система какие-либо подтверждения на все входные сообщения?
- Легко ли и приятно ли использовать ПО?
Тестирование защиты заключается в проверке обеспечения защиты информации от несанкционированного доступа. Для тестирования защиты важно построить тесты, которые нарушают программные средства защиты. Одним из путей разработки подобных тестов является изучение известных проблем защиты в подобных существующих системах и построении тестов, которые позволяют проверить, как решаются аналогичные проблемы в тестируемой системе.
Тестирование конфигурации оборудования обусловлено тем, что операционные системы, СУБД и коммуникационные системы должны поддерживать множество конфигураций оборудования (например, различные типы и число устройств ввода-вывода и линий связи, различные объемы памяти и т.п.). Часто число возможных конфигураций слишком велико, чтобы проверить ПО на каждой из них. Однако программу следует тестировать по крайней мере с каждым типом оборудования при минимальной и максимальной конфигурациях. Если можно изменять конфигурацию самого ПО, то необходимо тестировать все возможные его конфигурации.
Тестирование совместимости вызвано тем, что большинство разрабатываемого ПО не является полностью новым. Часто оно заменяет несовершенные, устаревшие системы обработки информации или неавтоматизированные процессы. Поэтому при разработке ПО необходимо обеспечить совместимость со средой, в которой работали заменяемые системы, и если необходимо, создать процедуры конверсии, обеспечивающие переход от одного метода обработки данных к другой. В этом случае, как и при других формах тестирования, тесты должны быть ориентированы на проверку обеспечения совместимости и работы процедуры конверсии.
Назначение всех видов тестирования - повысить надежность ПО, но если в исходном документе, отражающем цели проекта, есть особые указания, например, обеспечить определенное время наработки на отказ или задано допустимое число ошибок, то необходимо провести исследование тестируемого ПО на удовлетворение этих требований. Для этого служит тестирование надежности. Дня проведения этого вида тестирования существует ряд математических моделей надежности. Далее, в разделе, посвященном критериям завершения тестирования, будут рассмотрены две модели надежности: так называемая модель Милса и простая интуитивная модель.
Для операционной системы, СУБД и средств телекоммуникации часто определяется, как система должна восстанавливать свою работоспособность после программных ошибок, неисправностей аппаратуры и ошибок в данных. При тестировании системы требуется показать, что эти функции не выполняются. Для этого служит тестирование восстановления. Для этого можно намеренно ввести в систему программные ошибки, чтобы проверить, восстановится ли она после их устранения. Неисправности аппаратуры можно промоделировать. Ошибки в данных (помехи в линиях связи или неправильные значения указателей в базе данных) можно намеренно создать или промоделировать.
В исходном документе иногда формируются специальные цели удобства обслуживания или сопровождения ПО. Они могут определять средства обслуживания, которыми должно снабжаться ПО (например, программы выдачи дампов памяти, программы диагностики и т.п.), среднее время нахождения ошибки, процедуры, связанные с сопровождением, и качество до кум стации о внутренней логике программы. Естественно, все эти цели должны быть протестированы. Для этого применяется тестирование удобств обслуживания.
Цель тестирования удобства установки - показать, что не удовлетворяются цели по части настройки ПО на конкретные условия эксплуатации.
В проверку системы входит и проверка точности пользовательской документации. Большая часть этой проверки происходит при определении правильности представления предшествующих тестов системы. Кроме этого, пользовательская документация должна быть подвергнута инспекции на предмет ее точности и ясности, аналогично инспекциям исходного текста. Любые примеры, приведенные в документации, должны быть оформлены как тест и проверены на ПО.
Критерии завершения тестирования. При проведении тестирования встает вопрос о том, когда следует закончить тестирование программы, поскольку не представляется возможным определить, является ли выявленная ошибка последней.
В основном на практике придерживаются следующих двух критериев: когда время, отведенное по графику работ на тестирование, истекло; когда все тесты оказались неудачными, то есть были выполнены без выявления ошибок.
Оба эти критерия недостаточно точны и логичны, так как первый критерий не содержит оценки качества тестирования и ему можно удовлетворить, ничего не делая, второй же не зависит от качества тестовых наборов данных.
Однако второй критерий можно улучшить, если ориентироваться на определенные методологии проектирования тестов. Например, можно определить условие завершения тестирования модуля с помощью тестов, получаемых двумя путями: удовлетворением комбинаторному покрытию условий и методу анализа граничных значений по спецификации интерфейса модуля. Все получающиеся тесты в конце концов должны стать неудачными.
Завершение тестирования функций можно определить при выполнении следующих условий: тесты, получаемые методами функциональных диаграмм; эквивалентного разбиения и анализа граничных значений должны стать неудачными.
Однако эти критерии, во-первых, бесполезны на той фазе тестирования, когда определенные методы становятся непригодными, например, на фазе тестирования системы; во-вторых, такое измерение субъективно, т.к. нет гарантии, что данный специалист использовал нужную методологию правильно и точно; в-третьих, чтобы поставить цель и дать возможность выбора наиболее подходящего пути ее достижения, рассмотренные критерии предписывают использование конкретных методов, но не ставят цели.
Иногда используют критерий, основанный в значительной степени на здравом смысле и информации о количестве ошибок, полученных в процессе тестирования. Для этого строят графики зависимости количества ошибок и времени их появления. По форме полученной кривой и определяют, стоит ли продолжать тестирование или нет. На рисунке приведены примеры графиков зависимости количества ошибок от продолжительности тестирования.
Зависимость количества ошибок от продолжительности тестирования.
Из примера видно, что если время тестирования велико и с увеличением времени тестирования число ошибок растет, то, естественно, тестирование следует продолжить. Если в процессе тестирования в определенный момент наступило снижение числа выявления ошибок, если число выявленных ошибок постепенно стремится к нулю или достигло нуля, то понятно, что процесс тестирования можно завершить.
Однако этот критерий тоже недостаточно эффективен, поскольку нет никакой уверенности в том, что в последнем случае в дальнейшем не последует увеличения числа обнаруживаемых ошибок.
Возможен еще один подход к определению критерия завершения тестирования. Поскольку цель тестирования - поиск ошибок, то в качестве критерия можно выбрать некоторое заранее установленное число ошибок, соответствующее некоторой части от предполагаемого общего числа ошибок. Однако с применением этого критерия связан ряд проблем. Во-первых, необходимо оценить общее число ошибок в программе. Во-вторых, требуется выяснить, какой процент этих ошибок можно определить тестированием. И, наконец, нужно определить, какая именно часть ошибок возникла в процессе проектирования и во время каких фаз тестирования целесообразно их выявлять.
Для оценки общего числа ошибок и выявления возможного процента ошибок, который можно обнаружить тестированием, можно воспользоваться методами, применяемыми при определении показателей надежности (модели надежности), например, с помощью модели Миллса или простой интуитивной модели, которые мы рассмотрим немного позже.
Другой способ получения такой оценки основан на статических средних величинах, широко применяемых в промышленности. Например, число ошибок, которое существует в типичных программах, по времени завершения кодирования (до проведения сквозного просмотра или инспекции) составляет примерно 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 ошибок? Основываясь на данном критерии, завершить фазу проверки функций не удается никогда. Во избежание такой ситуации критерий числа ошибок следует дополнить промежутком времени, в течение которого они должны быть обнаружены. В этом случае, если ошибки найдены быстро, то тестирование на определенном этапе следует продолжать до завершения заданного интервала времени. Если же возникает переоценка, т.е. время прошло, а заданное количество ошибок не обнаружено, то следует пригласить незаинтересованного эксперта, который выскажет свое мнение о причинах возникновения проблемы: либо тесты не эффективны, либо тесты удачны, но в программе действительно мало ошибок.
Наилучшим критерием завершения тестирования является комбинация всех трех рассмотренных подходов. Для тестирования модулей оптимальным будет первый рассмотренный критерий, потому что в большинстве проектов на этой фазе не следят за числом обнаруженных ошибок, здесь важно, чтобы использовался определенный набор методов проектирования тестов. На фазах тестирования функций и системы критерием завершения может служить останов по достижении заданного числа обнаруженных ошибок или достижение момента, определенного графиком работ, при условии, что анализ зависимости числа ошибок от времени тестирования покажет снижение продуктивности.
