The most used defects classification is severity and priority.
So, What severity and priority:
I will explore this topic in a future post 😉
The software test plan in project development using agile is different to the plan used in traditional development methodologies (example: WaterFall).
The tester usually reads the requirements and defines the test plan but the ideology of agile project is creating more functionality instead of documentation. Therefore, the existing documentation may not be enough and the tester needs to communicate with the developer. An objective of the agile development is greater communication between people involved in the project.
Another problem is the timeline; the development is executed by sprint. The sprint is usually done in a short time and it is necessary to plan, develop and test the functionality. The functionality is only considered implemented when tested. In an ideal system the development of the test should be the same as the testing time, but when the development is delayed, the time test is compressed.
In agile development, it is possible for the test not to be executed by an independent team but by any developer who is given the role of tester of certain functionality. The only restriction is that the developer has no involvement in that functionality of the test. The approach of not having an independent team for the execution of the test has the advantage that the developer becomes more sensitive to the testability of the code. In other words, when the developer produces code, he remembers details necessary to allow the application to be tested.
The agile testers have ten principles; they are represented in the image below.
I recommend the book Agile Testing: A Practical Guide for Testers and Agile Teams.
Web testing is an interesting challenge because Web interfaces are very dynamic.
Web Testing represents a big challenge to the developer too, which include:
When a company decides to have automation test they need to have some ideas in mind:
The reason the keep this post in mind is that automated tests only have benefits when executed many times.
The advantages of using this strategy is:
In automated testing there is an initial higher cost (effort) compared to the manual test, but as time progresses, the cost of an automated test is much lower than in manual testing.
 
For me, it is unbelievable when I hear people saying that manual testing is obsolete and they want all tests to be automated. The paradox of this type of thinking is that when we are always testing the same thing, we end up testing nothing and in fact we are regressing by not using other methods of testing. We cannot forget that the testing tools are blind even if there is another defect on the side, they will not be able to identify it. I believe in automation testing of course but always with a small part of manual testing.
Hi guys,
Today I’m going to talk about a bug’s life cycle.
No QA likes to have defects in the code but unfortunately they do appear :(.
The life cycle of a bug is the journey of this little creature from its discovery to its elimination. The Life Cycle has some variations from organization to organization and it is generally influenced by the defect-tracking tool used.
Typically the bug life cycle has the following four phases: New, Open, Resolved and close.
New:
When the tester or a stakeholder finds a defect, a new bug is created on tool. It means that the bug has not yet been approved.
Assigned
Most companies don’t consider this phase as it is incorporated in the Open phase. In this phase the development leader confirms the veracity of the defect only.
Open: In this phase, verifying the veracity of the defect if necessary (refer Assigned phase). The developer reads the bug description and debug software to identify the bug that is causing the failure.
Resolved: The main objective of this phase is identifying that defects have been resolved and they can be retested.
Closed: After the bug is successfully retested, the bug is closed.
During the bug life cycle is important understand the following terms:
The most common approach in Software testing is the black-box and white-box as they are very easy to distinguish.
White-box
Other known names
Objective:
Orientation:
QA Access level:
Black-box
Other known names
Objective:
Orientation:
QA Access level:
I have explained using bullets, so that it can be easier to read. I hope I haven’t forgotten anything.
Ok, now we know the difference between both techniques but what type of bugs can only be discovered in white-box?  The answer is easy, bugs like un-used variables.
Grey-box
Grey-box (gray-box) testing isn’t easy to define because there isn’t an official definition. Some people defend that you have access of the code but you cannot read the entire code, only some parts are known. For me, this is cheating, how can you know that the parts you read are the important ones?, and what is the benefit of reading only part of the code?
Others defends that you have access to the technical manual and algorithms, which is true, but in agile development sometimes there isn’t enough documentation or the documentation is not up to date.
Ok, now you are wondering what definition I agree with, well, I believe in two different definitions:
If you use the grey-box approach you can sometimes reduce the number of tests. But you can hang in there for more details when I will cover that in a future post about testing techniques.
