Mar

17

Posted by : sanders | On : March 17, 2013

Decision table

Decision Tables – Тестване на бизнес логиката на продукта.

Научи повече по темата и как да прилагаш техниката в реален проект посещавайки курс по тестване в Прагматик ИТ Център http://pragmatic.bg

Mar

17

Posted by : sanders | On : March 17, 2013

ODCКласификация на дефекти чрез обогатяванe на набора от атрибути при репортване.

Научи повече по темата и как да прилагаш техниката в реален проект посещавайки курс по тестване в Прагматик ИТ Център http://pragmatic.bg

Mar

15

Posted by : sanders | On : March 15, 2013

Ако имате желание да се развивате в областта на софтуерното тестване и QA можете да стартирате с курс при нас http://pragmatic.bg

Темите, които съм добавил в курса са ключови, както за всекидневната Ви работа като QA-Test Engineer, така и за успешното преминаване на сертификационни изпити.

Предишните курсове, които проведохме доказаха своята ефективност като показателно е това, че 80% от кадрите успяха да се реализират в рамките на месец след края на курса. Още по-важно е да се отбележи, че Прагматик IT център няма практика да прави предварителна филтрация на курсистите, което от своя страна е още по-показателно за качеството на преподаване.

Nov

13

Posted by : sanders | On : November 13, 2012

Календара отново показва 13 Ноември само дето годината е различна. Мамка му, вече съм една година по-стар!

28 години върша глупости на този свят. Не мисля и да спирам, защото смятам, че се справям добре!

Правете това, в което сте най-добри!

Винаги съм смятал, че с годините ще ставам все по-гадно копеле заради кофти средата, в която живеем – Не се случи!

Не намалих алкохола, нито нивото на холестерола :D

Доста неща се промениха за последната една година. Прекалено много бих казал.

Много неща се и прецакаха, но като цяло общата равносметка е добра. В крайна сметка важното е плюса да е повече :)

Числото 28 е много приятно на вид, надявам се да носи и такъв късмет.

Пожелавам си неща, които да ме правят щастлив дори и да не ме правят успешен!

Защото, когато аз съм щастлив правя така, че и всички около мен да са щастливи и обратното ;) .

Така, че стискайте палци на гадният родопчанин!

Nov

06

Posted by : sanders | On : November 6, 2012

Не бях изненадан да го видя, но определено е супер смешно и парадоксално. Първо си помислих, че го ползват за лятото, но като влезнах вътре и видях, че няма радиатори определено останах смаян.

Една позната ме попита след като видя снимката: “Странно, защо не се отопляват на парно?”.

“Сигурно, защото е скъпо!” и отговорих.

Добър пример за BUG от реалния свят. За това темата ще остане в категория testing.

Jul

24

Posted by : sanders | On : July 24, 2012

I will allow myself to post this great article taken form JW’s book(Exploratory Testing).  I hope he doesn’t mind me posting it. I am doing it for the good of the whole testing community. I hope at least one manager will get the idea from it.

“So here’s my advice: don’t count bugs, their severity, test cases, lines of
automation, number of regressed suites, or anything concrete. It won’t give
you the right answer except through coincidence or dumb luck. Throw
away your bug finding leader boards (or at least don’t use them to assign
bonuses), and don’t ask the other testers in the group to rate each other.
They have skin in this game, too.
Instead, measure how much better a tester has made the developers on
your team. This is the true job of a tester, we don’t ensure better software,
we enable developers to build better software. It isn’t about finding bugs
because the improvement caused is temporal. The true measure of a great
tester is that they find bugs, analyze them thoroughly, report them skillfully,
and end up creating a development team that understands the gaps in
their skill and knowledge. The end result will be developer improvement,
and that will reduce the number of bugs and increase their productivity in
ways that far exceeds simple bug removal.”

Jul

24

Posted by : sanders | On : July 24, 2012

Like everything else in IT sphere, testing also evolves. What will happen in the near future? Are we ready to test new generation of software?

Jul

12

Posted by : sanders | On : July 12, 2012

The Net Negative
Producing Programmer

Introduction
We’ve known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
The Net Negative
Producing Programmer
G. Gordon Schulmeyer, CDP
Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]

The ratio of programmer performance that repeatedly appeared in the studies investigated by Bill Curtis in the July/August 1990 issue of American Programmer was 22 to 1. This was both for source lines of code produced and for debugging times – which includes both defect detection rate and defect removal efficiency. [5, pp. 4 - 6] The NNPP also produces a higher instance of defects in the work product. Figure 1 shows the consequences of the NNPPs.
This negative production does not merely apply to extreme cases. In a team of ten, expect as many as three people to have a defect rate high enough to make them NNPPs. With a normal distribution of skills, the probability that there is not even one NNPP out of ten is virtually nil. If you are unfortunate enough to work on a high-defect project (density of from thirty to sixty defects per thousand lines of executable code), then fully half of your team may be NNPPs. [6, p. 208]
John Gardner, in No Easy Victories, said, “An excellent plumber is infinitely more admirable than an incompetent philosopher.” He went on to observe that if society scorns excellence in plumbing because it is a humble activity and accepts shoddiness in philosophy because it is exalted, “neither its pipes nor its theories will hold water.” [14, p. 13] In the context under discussion, substitute “programmer” for “philosopher” and draw the conclusion that either the computer program will not run or that the NNPP will be so slow as to thwart project success.

Recognizing NNPPs
In Table 1 it is pointed out that there are significant differences between manufacturing and software development. It is a consequence of these differences that sets the programmer apart and provides difficulties in the recognition of the NNPP.

A model of programmer behavior would help us to recognize NNPPs. Such models of programmer behavior must be able to account for at least these basic programmer tasks:
∗ composition: writing a program
∗ comprehension: understanding a given problem
∗ debugging: finding errors in a given program
∗ modification: altering a given program to fit a new task
∗ learning: acquiring new programming skills and knowledge
In addition, the model must be able to describe these tasks in terms of: the cognitive structure that the programmer possesses or comes to possess in memory, and the cognitive processes involved in using this knowledge or in adding to it. [21, p. 46] Certainly, the programmer tasks of composition, debugging, modification, and learning may be measured (more about this below) fairly easily to determine programmer differences. The cognitive structure (comprehension) is not measurable as such, but manifests itself in the cognitive processes (composition, debugging, modification, and learning).
Metrics
Perhaps surprisingly, the people orientation of companies has a tough side. In Search of Excellence tells us that the excellent companies are measurement-happy and performance-oriented, but this toughness is borne of mutually high expectations and peer reviews. [17, p. 240]
Most functions associated with software development can undertake a measurement program. However, we find that little measurement has been done by the programming community. For whatever reason, programmers and their managers seem not to want to record information concerning software defects. Two possible reasons that come to mind are lack of time and a disinclination to ponder the less attractive aspects of what to do about NNPPs. [8, p. 355]
Edit

Jul

12

Posted by : sanders | On : July 12, 2012

The ISTQB Advanced Syllabus makes it clear that the ISTQB expects certificate-holders to adhere to the following code of ethics.
PUBLIC—Certified software testers shall act consistently with the public interest. For example, if you are working on a safety-critical system and are asked to quietly cancel some defect reports, that’s an ethical problem.
CLIENT AND EMPLOYER—Certified software testers shall act in a manner that is in the best interests of their client and employer and consistent with the public interest. For example, if you know that your employer’s major project is in trouble and you short-sell the stock and then leak information about the project problems to the Internet, that’s a real ethical lapse—and probably a criminal one, too.
PRODUCT—Certified software testers shall ensure that the deliverables they provide (on the products and systems they test) meet the highest professional standards possible. For example, if you are working as a consultant and you leave out important details from a test plan so that the client has to hire you on the next project, that’s an ethical lapse.
JUDGMENT—Certified software testers shall maintain integrity and independence in their professional judgment. For example, if a project manager asks you not to report defects in certain areas due to potential business sponsor reactions, that’s a blow to your independence and an ethical failure on your part if you comply.
MANAGEMENT—Certified software test managers and leaders shall subscribe to and promote an ethical approach to the management of software testing. For example, favoring one tester over another because you would like to establish a romantic relationship with the favored tester’s sister is a serious lapse of managerial ethics.
PROFESSION—Certified software testers shall advance the integrity and reputation of the profession consistent with the public interest. For example, if you have a chance to explain to your child’s classmates or your spouse’s colleagues what you do, be proud of it and explain the ways software testing benefits society.
COLLEAGUES—Certified software testers shall be fair to and supportive of their colleagues and promote cooperation with software developers. For example, it is unethical to manipulate test results to arrange the firing of a programmer who you detest.
SELF—Certified software testers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. For example, attending courses, reading books, and speaking at conferences about what you do help to advance you—and the profession. This is called doing well while doing good, and fortunately, it is very ethical!

The ISTQB Advanced Syllabus makes it clear that the ISTQB expects certificate-holders to adhere to the following code of ethics.
PUBLIC—Certified software testers shall act consistently with the public interest. For example, if you are working on a safety-critical system and are asked to quietly cancel some defect reports, that’s an ethical problem.
CLIENT AND EMPLOYER—Certified software testers shall act in a manner that is in the best interests of their client and employer and consistent with the public interest. For example, if you know that your employer’s major project is in trouble and you short-sell the stock and then leak information about the project problems to the Internet, that’s a real ethical lapse—and probably a criminal one, too.
PRODUCT—Certified software testers shall ensure that the deliverables they provide (on the products and systems they test) meet the highest professional standards possible. For example, if you are working as a consultant and you leave out important details from a test plan so that the client has to hire you on the next project, that’s an ethical lapse.
JUDGMENT—Certified software testers shall maintain integrity and independence in their professional judgment. For example, if a project manager asks you not to report defects in certain areas due to potential business sponsor reactions, that’s a blow to your independence and an ethical failure on your part if you comply.
MANAGEMENT—Certified software test managers and leaders shall subscribe to and promote an ethical approach to the management of software testing. For example, favoring one tester over another because you would like to establish a romantic relationship with the favored tester’s sister is a serious lapse of managerial ethics.
PROFESSION—Certified software testers shall advance the integrity and reputation of the profession consistent with the public interest. For example, if you have a chance to explain to your child’s classmates or your spouse’s colleagues what you do, be proud of it and explain the ways software testing benefits society.
COLLEAGUES—Certified software testers shall be fair to and supportive of their colleagues and promote cooperation with software developers. For example, it is unethical to manipulate test results to arrange the firing of a programmer who you detest.
SELF—Certified software testers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. For example, attending courses, reading books, and speaking at conferences about what you do help to advance you—and the profession. This is called doing well while doing good, and fortunately, it is very ethical!

Apr

20

Posted by : sanders | On : April 20, 2012

Is it even possible to calculate software cost using Man-months?  How far is that from the truth? Why software production is different than any other kind of production?  What is the impact of team size and milestones over schedule?