Test Management Tools Forum
Jun 03 2021
I'm working for a company with 1000+ employees and I'm exploring two products: Panaya and Tricentis.
How good is Panaya Test Dynamix in comparison with Tricentis?
How is adhoc testing used in software testing?
PraveenMishra What is Adhoc Testing When a software testing performed without proper planning and documentation, it is said to be Adhoc Testing. Adhoc methods are the least formal type of testing as it is NOT a structured approach. Ad hoc Testing does not follow any structured way of testing and it is randomly done on any part of the application. AD HOC TESTING, also known as Random Testing or Monkey Testing 2. Why Adhoc Testing used? Adhoc testing can be performed when there is limited time to do exhaustive testing. Adhoc testing can be done at any point in time whether it’s beginning, middle, or end of the project testing. This testing can also be done when the time is very limited and detailed testing is required. However, this testing can be done only when the testers are having complete knowledge of the product. 3. Advantages:- It is able to identify any errors that would usually go unnoticed during formal testing methods. This saves time sometimes. Testers get to explore the application freely, according to their own knowledge and understanding of the application. This helps in identifying more defects that go unnoticed in Test Cases. Ad-hoc testing can find holes in your test strategy. If testing occurs very late in the development cycle, this will be the only kind of testing that can be performed. 4. Disadvantages:- In Adhoc Testing actual testing process is not documented since it does not follow a particular test case. So, sometimes it gets difficult to reproduce the scenarios. Ad hoc testing also does not guarantee that all errors will be found. The success of ad hoc testing relies on the skill and knowledge of the tester. It can only be done by experienced resources with proper knowledge of requirement. The amount of time, effort and resources that go into these tests remains unspecified. Finding one error could take anything from a few minutes to a few hours or longer. Conclusion Ad hoc testing does not require elaborate planning, documentation, and test-case designs. Instead, it saves time due to its ad hoc nature, and by selecting testers who are creative and have prior knowledge of the application’s functionality. This testing can help find more defects than planned testing.
There seem to be 2 different approaches in test management - BDD and TDD. What are the differences between these approaches, and what are the relative pros and cons of each?
Julio De LimaBDD is not about testing. It is about to have common sense about the application behavior and use this to develop a piece of software. As I mentioned, "to develop" software. Testing comes before and after it, not in it. Testers are part of the definition, he/she collaborates with the Developer and the Product Owner by defining the scenarios or examples that will be used by the developers during the coding. A big part of the companies misunderstood it and I believe I know why. Test Automation is something that works perfectly when developers and testers work together creating and maintaining the test scripts, but since the first time I heard about test automation, the tester was put as the exclusive owner. Also, the first time I heard about Cucumber, it happened again, testers being the owner of it. But, look, testers are not developing software in the companies that adopted Cucumber. So, where are the second "D" in the mnemonic "BDD"? If testers are not developing software, it is anything different than Behavior Driven Development. Summary of all, BDD is a development method used by "coders" (it includes the tester if he/she are programming the software the client will use in the future) where they look at the same behavior that he/she defined together with the tester and the Product Owner, and start to code focusing in to develop a software that is obeying that scenarios. It is not about testing. Let's see an example: Moment 1*: tester, developer, and PO meet and discuss a brand new feature Moment 2*: they define some examples to describe better how this feature will be used by the user Moment 3: they decide to write the examples in Gherkin, cause it is a common way to describe things Moment 4: Three scenarios are written, it is not related to API or UI, it is written in a descriptive way instead of an imperative way (it is not an IEEE-829-1998 test case) Moment 5A*: The API developer use the Gherkin feature files to create snippets to defined previously the way the API will be used after it became done Moment 5B*: The UI developer does the same Moment 6: Once the three scenarios were achieved, they are done with the task Moment 7: the tester will take the software that already obeys the scenarios defined collectively in the Moment 3 and start to run the tests planned based on the features described in the Moment 1 and 2; Moment 8: Tests passed, feature done. (*) The tester is using the information get here to help to define him/her test strategy or even helping the team to understand better how to produce a better software Pros: - Favor the collective understanding of the software; - Brings the developer to think in the user; - Backend, Frontend, and Testing guys know exactly what will be delivered. - Produces a lot of documentation Cons: - It takes time to do it right - Produces a lot of documentation - It is difficult to find documentation about the right way to do it TDD is also aiming to focus the software creation on something different than tables, classes, interfaces, and repositories. The developer thinks about the feature to be created, then he/she defines what are the tests that will prove the piece of code that will be developed works as expected. These tests are written and run, it breaks in the first moment. The developer produces software code to achieve the test passing. After that he/she refactor the code to improve it since now they are confident that the test will validate that the code is working under that combination and state. Again, who produces the tests in the TDD approach are the coder (tester or developer who is going to implement a feature). Let's see an example: Moment 1:* The developer already know what should be developed and what kind of tests can prove it is working properly; Moment 2*: He/she write eight test methods (in the project they are using to produce the software) exercising the conditions they believe that proves the software are working properly; Moment 3: Now, the developer starts to code the software in order to make the eight tests pass; Moment 4: It is good, let's mark it as done. Moment 5: The tester will take the version to test with my 8 million test design techniques or my abilities to explore the software (*) The tester can be consulted by the developer to teach some testing techniques that help the developer to assure what he/she is going to produce are working. Pros: - Favor the software architecture - Brings coders to the point where they need to think about testing in the very first moment - Better code Cons: - Does not works if you have a coupled legacy code - A low number of developers doing this
NancyMcClanahanTest-Driven Development (TDD) is an "inside out" focused process. To understand the process, one needs to know that the writer of the test cases is written at the same time as the code or Build. So it is the developer that writes the tests. To answer, "Who reads the tests?" It is the Developers and the Testers. It's unlikely that anyone else will read them. Then it is essential to provide speciﬁcity. When testing a new department with a unique workflow, and the test fails - a defect is created, and the failure analyzed. It is known that the build of the area is where the fault is located. The Developer or Builder does a Unit Test on the component/module, which is in isolation—making a mockup may be required, but is (potentially slow) and has external dependencies. As a result, Unit Tests are super-quick to run. The higher the level of code or build coverage, the better the developer, Quality Assurance, and Project Manager will sleep at night. But 100% code coverage is rare/difﬁcult to achieve where Unit Test is concerned, which leaves gaps in risk management that need to be discovered and tested. Also, any change to the functionality of the system will require a modification to one or more Unit Tests. (Remember: the tests change ﬁrst!) Unit Tests are highly speciﬁc to the code that they cover; they are intertwined with interfaces and other models. Unit Tests are not transferable and will require version control. Behavior Driven Development (BDD) is an "Outside-in" focused process. To maintain comparison consistency, we need to answer, "Who writes the tests?" The plain English format means that the tests can be written by the person that understands the customer the best: the Product Owner or Operations owner. Then to answer, "Who reads the tests?" Almost anyone: Developers, Testers, Stakeholders, Business Owner, Product Owner. The speciﬁcity is based on the coding of the module build. When there is a defect, we know something is wrong, but we have to investigate to find out what is wrong. Behavioral Tests are tests of the system as a whole. At Parkview Health, we consider this integration testing. The system must be "put into a known state," which is all builds for each module that has to be in the testing environment before every test cycle. Not particularly difﬁcult to do, but not quick either. When defects show up, they have to be fixed in the build, but the test case stays the same. Code or build coverage percentages for Behavioral Tests tend to be high. 100% code coverage is not uncommon. Not all functional changes impact the external behavior; the high-level nature of Behavioral Tests means that they change infrequently. Behavioral Tests are not coupled to code. Without changing a single test, the Test Coordinator can: • Rewrite the module or application in a different programming language; • Refactor or influence the massive application into a set of Test cases by the workflow. • Fix a defect and start a new cycle In summary, the first step of the project is to discuss the behavior of the software or feature to be built. BDD is a methodology for developing software through continuous example-based communication between developers and business. This communication happens in a form that both the business and developers can clearly understand. The business owners talk in requirements to the developers, and developers talk in examples. The value of BDD is as follows: • A better understanding of the business operations • Better ideas • Developers can improve the systems • Developers can help the business reach their requirements TDD focuses on the developer's opinion on how parts of the software should work, and BDD focuses on the user's view on how they want the application to behave. When using BDD, it is all about functional testing and specifying the behavior. The story BDD helps ensure that the development team understands the business on the same level that the client does, adding value to the released software or build of the software.
Waqar.tufailIn TDD (Test Driven Development), the test is written to check the implementation of functionality, but as the code evolves, tests can give false results. BDD (Behavior Driven Development) is also a test-first approach, but differs by testing the actual behavior of the system from the end users perspective You can consider as a example TDD do not have specific file to write the test Case in Grammar language which describe the Behavior of application as a End User BDD have the feature file where you can write simple language test case which simply describe that what is the scenario and what steps are going to execute Example: Scenario: Validate the Login Module Test-1 User open the Application Enter the credentials and Click on Login He should be redirected to Dashboard All the code will be bind with these steps and report will have only above lines with the status