Как в Excel вернуть комментарии на место

У меня довольно часто «съезжают» комментарии к ячейкам в Excel, что очень неприятно, когда их много. Оказывается, есть простой способ вернуть их на место. Для этого добавляем в книгу такой макрос:

Sub ResetComments()
    Dim cmt As Comment
    For Each cmt In ActiveSheet.Comments
        cmt.Shape.Top = cmt.Parent.Top + 5
        cmt.Shape.Left = cmt.Parent.Offset(0,1).Left + 5
    Next
End Sub

Запускаем и вуаля – все комментарии около своих ячеек ;)

Кучу подобных полезностей можно найти тут.

Хорошие программы

Хорошие программы – это продукт хорошего образования, удачного проектирования, адекватного тестирования и т.д., а не наличия в языке средств, которые предположительно должны использоваться только «правильно».

Бьерн Страуструп.  The Design and Evolution of C++.

Взято тут.

Разработка сценариев тестирования

Решил поделиться схемой разработки testcase’ов, которой пользуюсь сам. Не претендую на полноту и уникальность, сейчас меня такой подход полностью устраивает. Возможно, кто-нибудь сможет извлечь из него что-то полезное и для себя. Собственно, процесс разработки сценариев тестирования состоит из четырех этапов:

  1. Определение требований к ПО
  2. Группировка требований по приоритету
  3. Определение use-case’ов
  4. Разработка сценариев тестирования на основе определенных use-case’ов Прочтите эту запись до конца »

Непрерывная регрессия

Захотелось поговорить о регрессионном тестировании. Как к этому делу подходить. Вначале о том, что же с моей точки зрения представляет собой регрессионное тестирование (РТ). РТ – это тестирование, направленное на проверку того, что объект тестирования со временем не регрессирует по какому-то показателю качества. Т.е. в общем случае к РТ может относиться любой вид тестирования (функциональное, производительности, юзабилити и пр.). Но чаще всего речь идет о регрессионном функциональном тестировании, т.к. функциональность – наиболее важный показатель. Как следует из определения РТ, это некий набор тестов, который выполняется с некоторой периодичностью. И тут возникают следующие вопросы:

  1. Как часто надо выполнять данные тесты?
  2. Какие именно тесты необходимо включить в набор РТ?

Собственно, на эти вопросы я и постараюсь ответить. Прочтите эту запись до конца »

Реальность — это убийство прекрасной теории бандой мерзких фактов.

Роберт Гласс. Факты и заблуждения профессионального программирования.

Дефект – это диагноз, или зачем тестировщику владеть инструментами администратора.

О дефектах в тестировании сказано много. Существуют различные определения дефекта. Я бы хотел предложить взглянуть на предмет несколько с иной стороны.

Работу опытного тестировщика можно сравнить с работой диагноста. В идеале, описание дефекта – это диагноз, а не список симптомов. В особенности это касается функциональных дефектов. Некоторые начинающие тестировщики, на мой взгляд, иногда упускают этот момент.

Тестировщик может понятия не иметь КАК лечить, но рассказать ЧТО лечить – это его работа. Идя к врачу, Вы ведь надеетесь не на то, что он Вам расскажет как у Вас что-то болит, а на то, что он поставит верный диагноз. Но для того чтобы поставить верный «диагноз», необходимо обладать солидным багажом знаний, и владеть соответствующими инструментами. Развивая аналогию с врачом, можно сказать что нормальный человек не пойдет к хирургу, который не разбирается в анатомии, терапевту, который не знает как измерить температуру и т.д. Другими словами, на тестирование поступает «больной», и общая задача команды – вылечить его. Тестировщикам нужно поставить диагноз, разработчикам – вылечить «заболевание».

Имея в своем арсенале набор утилит (те же Sysinternals, различные мониторы и т.д.) и знания рабочего окружения, можно намного эффективнее находить причины возникновения дефектов. А это, в свою очередь, экономит время при исправлении дефектов. И потом это просто интересно – докопаться до сути! Это вносит разнообразие в работу, тестировщик превращается в своего рода исследователя. Тут важно соблюсти «золотую середину», не углубляться в малоперспективные и сомнительные «исследования», особенно если время ограничено. Но если помнить об этом, то тестирование может стать более увлекательным и эффективным занятием. Думаю, от этого только все выиграют.

Итого:

  1. Дефект – это диагноз. «Симптомы» только помогают понять его.

  2. Чтобы поставить верный «диагноз», нужны инструменты и знания.

  3. Не стоит слишком увлекаться исследованиями.

Как организовать скрытый ввод пароля в vbscript

Следующий код запрашивает у пользователя ввод пароля. Вводимые символы при этом не отображаются. После ввода пароля скрипт выводить его на экран.

Set objPwd = WScript.CreateObject(«ScriptPW.Password»)
strUserPassword = objPwd.GetPassword()
WScript.Echo strUserPassword

Примечание: Данный код работает только при запуске через cscript.exe.

Опубликовано в vbscript. 1 комментарий »

Как сгенерировать GUID в vbscript

Следущий код генерирует и выводит GUID:

Set TypeLib = CreateObject(«Scriptlet.TypeLib»)
Wscript.Echo TypeLib.Guid

Быстрая сортировка на vbscript

Option Explicit
Dim
i, arrSample (9)

arrSample (0) = 9.9
arrSample (1) = 8.7
arrSample (2) = 7
arrSample (3) = 6
arrSample (4) = 5.8946456
arrSample (5) = 4
arrSample (6) = 3
arrSample (7) = 2.4
arrSample (8) = 1

qsort arrSample, 0, 8

For i = 0 To 8
WScript.Echo arrSample(i)
Next

Sub qsort (arr, l, r)
Dim i, j, x, y
    i = l
    j = r
    x = arr((l + r) \ 2)
Do
        While arr(i) < x
            i = i + 1
Wend
        While x < arr(j)
            j = j - 1
Wend
        If i <= j Then
            If arr(i) <> arr(j) Then
                y = arr(i)
                arr(i) = arr(j)
                arr(j) = y
End If
            i = i + 1
            j = j - 1
End If
    Loop Until i > j
If l < j Then qsort arr, l, j
If i < r Then qsort arr, i, r
End Sub

Опубликовано в vbscript. Комментарии (2) »

Синтаксис описания дефектов

Наткнулся в документе Administering & Using StarTeam 2008 (Borland) на интересное предложение по описанию дефектов. Предлагается использовать такой набор сокращений:

Shorthand Description
1, 2, 3,… Номер шага.
LClick Левый клик мышкой.
RClick Правый клик мышкой.
DClick Двойной клик мышкой.
[ ] Кнопка клавиатуры.
For example: [F1] for Help or [F5] for Refresh.
< > Кнопка диалогового окна.
For example: Press <OK> or <Cancel>.
> Разделитель пунктов меню.
For example: Select File > Open or Topic > Tools > Reports.
// Комментарий, не являющийся шагом выполнения сценария.
For example:
3) LClick the field.
// At this point my machine started to smoke.
EXP Ожидаемый результат.
For example:
EXP: The focus moves to the next field.
ACT Полученный результат.
For example:
ACT: The application crashes.

Описанный с помощью этих сокращений дефект, может выглядеть примерно так (пример взят из того же документа):

1. RClick the column headers in the upper pane.
2. Select Show Fields.
3. LClick Show Advanced Fields check box.
// The check box is activated.
4. LClick Show Advanced Fields check box.
// The check box is deactivated.
5. EXP: The standard fields appear in the Available Fields list box. 6. ACT: No fields appear in the Available Fields list box.

Такое описание легко читается и вызывает меньше возможных вопросов. По-моему очень удобный и простой синтаксис.