Перейти к содержимому

kitsune

Регистрация: 02 сен 2011
Offline Активность: 28 сен 2017 15:52
-----

#144681 Проект Ситечко закрылся?

Написано kitsune 30 сентября 2015 - 10:08

Спасибо, через http все отработало.


  • 1


#117191 Поставте мне правильно голову!

Написано kitsune 17 апреля 2013 - 09:22

Вопрос второй: как быть? :)


Попробуйте сформулировать для себя, для чего Вам нужны тест кейсы.

Примеры формулировок:
* Чтобы не забыть выполнить все тесты
* Чтобы новым тестерам было легче работать с приложением
* Чтобы знать, сколько еще тестов нужно написать / выполнить / автоматизировать
* Чтобы произвести впечатление на руководство
* ...

После этого можно адаптировать тест кейсы, чтобы они помогали добиваться целей.
Может получиться так, что тест кейсы Вам на самом деле не нужны.
  • 1


#116981 Определить книгу по рисунку

Написано kitsune 11 апреля 2013 - 12:34

Недавно в интернете случайно наткнулся на вырезанный фрагмент из этих тестов. (См. прилагаемый рисунок)



Ммм, а по каким признакам Вы решили, что это копия из книги?

Описанный стиль скетчей - это Balsamiq. См. http://www.balsamiq.com
  • 1


#116860 Языки программирования: На каком остановить выбор?

Написано kitsune 10 апреля 2013 - 08:53

Например?
Я работаю как мануальщик, то есть в рабочем процессе у меня такой задачи пока нет.
Да и в любом случае для начала нужно иметь хоть какой-то теоретический бэкграунд


Вы можете автоматизировать совсем маленькие кусочки своей работы. Посмотрите в сторону тестовых данных.

Пример из жизни.
Мы тестировали загрузку и обработку картинок.
Папка с тестовыми данными была набита разными файлами.

Мне нужно было про каждый файл знать формат, размер в МБ, размер в пикселях.
Я написала скрипт, который читал эту информацию из файла и переименовывал файл по шаблону FORMAT_Kb_xxx-xxxpx_increasing_number - типа BMP_1240Kb_600-240px.bmp

Никакой экономии времени я на этом, конечно, не получила:) Но использовать такие красивые, поименованные файлы было очень приятно.
  • 1


#116500 Языки программирования: На каком остановить выбор?

Написано kitsune 03 апреля 2013 - 08:18

Хотелось бы услышать советы от людей, имеющий подобный опыт - какой язык лучше выбрать для изучения?


Берите тот язык, на котором пишет Ваш хороший знакомый - человек, который сможет и захочет с ним помочь.
  • 1


#116160 Кто тестировал банковские приложения? Нужен совет!

Написано kitsune 22 марта 2013 - 08:27

Впервые тестирую подобное приложение (толстый клиент).
И, как сказано было работодателем, я нашла не все баги.


Работодатель уточнил, какие баги были не найдены?
Там может быть что угодно.
Попробуйте запросить список багов. При анализе такого списка можно найти слабые места.
  • 1


#116028 Как справится с хаосом в команде?

Написано kitsune 20 марта 2013 - 10:27

Он старается давать четкие задания, но зачастую не получается. Одно задание через короткий промежуток нарастает новыми подзаданиями, а иногда и вообще принимается решение о том, что "все это фигня, давай по-другому". Контроля над этим человеком нет, т.к. он считается главным в фирме. Плюс в том, что он понимает свою неординарность в действиях в связи с тем, что он не подходит не под понятия "руководитель / менеджер", "аналитик" и т.п. У него нет навыков и задатков к этому, но для нашего стартапа это особо и не нужно. Его знаний, идей и видений вполне хватает для того, чтобы двигаться дальше.


Один из признаков налаженного процесса: все участники следуют существующему процессу.
Все участники - включая руководство.
Если процессу следует босс, то остальные подтягиваются (обратное тоже работает, босс вносит хаос - все вносят хаос).
Следовать процессу в некоторых случаях (и для некоторых людей) сложнее, чем принимать решения с нуля.

Если всё же рискнёте связаться, то вот пример подхода к оптимизации процессов.
Бессмысленно придумывать весь процесс, а потом его вводить его одним огромным куском.
1. Вводите маленькие кусочки процесса.
Кусочек процесса - это взаимодействие между двумя участниками. Участниками могут быть роли "программист, тестер, аналитик" или люди "Вася, Петя, Саша".

2. Вводите кусочки там, где это действительно нужно.
Как вычислить, где сейчас не хватает процесса: смотрите за вопросами внутри команды. Обычные вопросы тестеров и программистов: "я сделал это, что мне делать дальше?". "Я пофисил баг, что мне делать дальше?". "Я проверил фичу, на первую часть нашел баг, вторая работает, что мне делать дальше?".
Эти вопросы как-то решаются естественным образом, но если процесса нет, подобные вопросы будут возникать снова и снова.

3. Обсуждайте и записывайте кусочки процесса
Заведите вики-страничку, что-нибудь вроде "Правила проекта".
Обсудите решение с теми, кого вопрос может затрагивать - "Как ты думаешь, если мы пофикшеные баги всегда будем переводить на Васю в день релиза, нормально будет?"
Решение запишите на страничку простыми словами: "Каждый пофикшенный баг переводится на Васю в день релиза (следующий релиз 25 апреля)."
Разошлите ссылку на страничку всем.

4. Напоминайте о принятых кусочках
В следующий раз, когда возникнет подобный вопрос (а он возникнет не раз, несмотря на всё, что Вы до этого сделали:)) - отвечайте не пересказом процесса, а ссылкой "Договорились делать так, как тут написано".
В день релиза пришлите ссылку еще раз - "Кстати, ребята, все пофикшенные баги переводим на Васю"

5. Изменяйте принятые кусочки, если нужно
В случае споров придется обсуждать "Тебе неудобно переводить баг на Васю, а как бы тебе было удобно? На Петю?". Обойти всех остальных "Есть предложение баги переводить на Петю. Как думаете?" и повторять весь цикл.

6. Проверяйте, что правила соблюдаются
В день релиза посмотрите список пофикшенных багов. Если что-то висит не на Васе - попросите перевести на Васю отдельно. Может выясниться, что здесь это правило не работает, тогда см. пункт 5.


Необходимо лишь каким-то образом грамотно выстроить процессы.


!! Работы тут очень много и она довольно адская) потому что люди не будут следовать процессу, будут спорить (несмотря на то, что согласились раньше), итд.
Нужно понимать, что выстроенные процессы - это не "всего лишь выстроенные процессы", это медленная, кропотливая работа, не всегда добавляющая популярности в коллективе.

И, повторюсь, это не сработает, если начальник будет принятые процессы динамить.
  • 1


#112577 Грамматическое тестирование веб-сайтов

Написано kitsune 04 декабря 2012 - 12:25

Подскажите плз тулу которая найдет грамматические ошибки на сайте. Пользовался приложением Xenu, которое ищет все битые ссылки и подумал - а не уж то нету приложения, которое ище грамматические ошибке в тексте заданного Web ресурса. Спасибо.
Извините, если немного не в тему...


http://webmaster.yan.../spellcheck.xml

Правда, ошибки типа написания частицы "неужто" (пишется слитно) она не отловит :crazy:
  • 1


#112553 Можно ли в Jira создать тип запроса: подзадача подзадачи, т.е.

Написано kitsune 04 декабря 2012 - 08:15

Официальный ответ в джире джиры.
https://jira.atlassi...browse/JRA-4446
Sub-issues should be able to contain their own sub-issues
  • 1


#112457 Нету полей Steps и Expected results

Написано kitsune 30 ноября 2012 - 07:50

TestLink 1.9.4. При создании TestCase в теле создаваемого тесткейса нету полей Steps и Expected results. Как это побороть? :help:/>


После создания теста появится кнопочка Create Step.
  • 1


#111657 Как донести информацию о покрытии тестами

Написано kitsune 06 ноября 2012 - 07:56

В JIRA только такси и баги. Таска = часть требования. Или два требования. Или две части требования. Мне надо было уточнить.

Это без разницы, называйте элемент из списка тестируемых элементов как угодно.
В данном случае "требование" - некая сущность НА КОТОРУЮ пишутся тесты. Каждый тест проверяет "требование" или часть "требования". Требования внутри себя могут делиться на какие угодно типы, для рисования матрицы покрытия это не оч. интересно.


Нужно:
* В любой момент получать статистику для скольких элементов из списков 1 и 2 есть элементы в списке 3


Вот! Это максимум того, что мы придумали.

Но например требование описывает удаление чвототам. Мы видим, что на это есть 6 тестов.
Мы видим даже заголовки тестов, условно считаем, что они есть и они понятные.


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

Тогда нужный Вам анализ смогут делать люди, не вникая в список полностью.

Вообще, я бы хотела матрицу такого формата (в экселе, конечно же).

ID + cабжект "требования" | Дата последнего обновления "требования" | ID + сабжект теста | Дата последнего обновления теста

+ две кратких инструкции - как по ID локализовать любой из элементов матрицы (буквально, на какой url пойти и что искать).

Если при этом список "требований" содержит еще и непокрытые - всё оч шоколадно.
У Вас естественным образом появляется три списка:
  • непокрытые требования
  • требования, требующие обновления (дата последнего обновления больше чем у тестов)
  • требования, требующие анализа качества покрытия (вот тут как раз - достаточно ли сюда 6 тестов, не много ли это - 6 тестов)

Три списка обрабатываются в порядке приоритета и/или наличия свободных сил.
Требования, покрытые и проанализированные получают какую-нибудь галочку "проверено, мин нет", далее в этой же матрице галочка отображается.

Т.е. да, индивидуальной работы нужно много, но перед тем как ее начинать, продумайте, как просматривать ее результаты.
  • 1


#110552 Помогите, пожалуйста! Тестовое задание.

Написано kitsune 02 октября 2012 - 12:51

нет :blush:


Э-эх..

По сути ответов.
В задании про медали явно перевернуты значения М (Миссий) - эксперт круче железнодорожника.
Ошибка.

Про ввод данных в поля - а где разнообразные некорректные значения?
  • 1


#110541 Помогите, пожалуйста! Тестовое задание.

Написано kitsune 02 октября 2012 - 11:17

Мой ответ на вопрос:

[i]Ответ:
Вообще сама документация написана «сухим», абсолютно непонятным языком. Явно существуют лексические ошибки, но на них я не буду акцентировать внимание.


Вот эту фразу из ответа вычеркнуть полностью:)
А пару явных лексических ошибок напишите сюда, оч интересно.
  • 2


#108589 Тест кейс на юзабилити интерфейса

Написано kitsune 13 августа 2012 - 12:36

Ну, например, в серии вебинаров Михаила Портнова второй урок называется "Тестирование графического интерфейса", даже на слайдах к уроку значится GUI testing. А разговор весь урок идёт скорее о юзабилити, чем о ГУИ (начиная от различия заглавных и строчных букв в Unix и неразличия их в Windows и заканчивая ссылками на гайдлайны на Usability.gov). Мнение достаточно авторитетное, ИМХО.


Я прослушала все 44 минуты!
Про непосредственно тестирование GUI начинается с 27й минуты (и дальше, в общем, по делу).
Перед этим довольно много несистемных рассуждений, среди которых упоминается и usability.gov.

Вот смотрите, что про юзабилити пишет вики (ссылка была выше).

Goals of usability testing
Usability testing generally involves measuring how well test subjects respond in four areas: efficiency, accuracy, recall, and emotional response. The results of the first test can be treated as a baseline or control measurement; all subsequent tests can then be compared to the baseline to indicate improvement.

* Efficiency -- How much time, and how many steps, are required for people to complete basic tasks? (For example, find something to buy, create a new account, and order the item.)
* Accuracy -- How many mistakes did people make? (And were they fatal or recoverable with the right information?)
* Recall -- How much does the person remember afterwards or after periods of non-use?
* Emotional response -- How does the person feel about the tasks completed? Is the person confident, stressed? Would the user recommend this system to a friend?


Если пересказывать своими словами - берут пользователей, опытных, неопытных - сажают их работать с программой и смотрят, какими словами и как долго пользователи ругаются :crazy:
Люди, которые с программой работают и люди, которые оценивают на их примере удобство использования - должны быть разные люди.
  • 1


#108516 Тест кейс на юзабилити интерфейса

Написано kitsune 10 августа 2012 - 11:25

Нам на лекции, когда рассказывали типы тестирования, сказали : "GUI - это бзабилити интерфейса"


Что такое GUI.

Что такое usability.

Упрощая, одно - внешний вид программы, а второе - взаимодействие пользователя с программой.

Еще упрощая.
Пользовательский интерфейс может быть корректно сделан программистами.
Пользовательский интерфейс может быть более или менее удобным в использовании.

И то, и другое можно протестировать. Для тестирования одного пункта, тестирование второго совершенно не обязательно.

Вопрос: что именно Вы хотите протестировать?:)
  • 1