Week 4 – Criteria For Picking An IDE

Although this blog is very loosely associated with testing, I still think it is important enough to warrant my attention. In his blog, Erik Dietrich outlines a list of criteria for “what is reasonable to expect from your IDE.”

  1. BUILDING THE SOFTWARE – His first criteria is that the IDE should be able to easily build your software. Additionally, the IDE should alert you of any problems and make it easy for you to locate those problems.  Ideally, the IDE would even suggest solutions to those problems.
  2. INTEGRATED DEBUGGER – Another essential aspect for an IDE is an integrated debugger.  The debugger should allow you to go through your code line by line and see the behavior of your code at runtime.
  3. PLUGINS AND CUSTOMIZATION – Any effective IDE or text editor relies on plugins.  Plugins and customization make you more productive and enhance the the coding experience.
  4. AUTOMATED REFACTORING – Here is the aspect that relates this blog to software testing.  Dietrich explains that he is a huge proponent of TDD.  A major factor in TDD is refactoring, and he suggests that an IDE that automates refactoring removes much more human error from the TDD process.  Not only does it remove error, but it is also much more efficient.
  5. INTELLISENSE/NAVIGATION – The last criteria is pretty self-explanatory.  An IDE should make navigating your code easy, and offer type-ahead support.

Week 3 – When To Stop Testing


Before you start. KIDDING. Alright so for this week’s blog I’m mixing it up and recapping a blog I read on softwaretestinghelp.com written by Renuka K.  This blog can be found here.

Well Renuka paints the picture of the typical tester.  Enthusiastic at the start and losing fervor with every run through the code.  Which makes sense, the more times a tester looks through the same code, the less interested that tester is going to be in that code. Especially because, if the testing is done correctly, the tester will find less defects with every run.  So then the question is, when is it okay for the tester to stop?

In the first scenario, for discontinuing testing, Renuka broaches the idea that a tester can stop testing when all of the defects have been found.  Unfortunately, there is no way to prove that software is free of bugs.

In the next scenario, Renuka suggests exit criteria, including, time, budget, and extent of testing.  Unfortunately, as Renuka points out, the quality of the testing process is compromised when these constraints are applied.  Before testing begins, conditions to be fulfilled should be established in order to conclude testing.

Below is  a useful yes or no list Renuka provided to help you decide if it is time to stop testing:

  • Are all test cases executed at least once?
  • Is the Test Case Pass rate as defined?
  • Is complete test coverage achieved?
  • Are all functional / Business flows executed at least once?
  • Is the decided defect count reached?
  • Are all Major High Priority Defects fixed and closed?
  • Have all Defects been Retested and closed?
  • Has Regression been done for all open defects?
  • Have you exhausted the testing budget?
  • Has the Testing end time reached?
  • Are all Test Deliverables reviewed and published?


Week 2 – An Inside Look At Testing

Yes, I know, Brendan Connolly again.  Out of the ten blogs I have gone through so far, his are the only ones that I have continued to read until the end.  His blogs are straight to the point and that keeps my attention.  Anyway, onto the blog.

First of all, let’s take a broad look at the purpose of testing.  In a very general sense, we test to reveal problems. Then those problems are reported so that they can be resolved. In his blog, Connolly asserts that, “A tester needs a clear understanding of what a problem is in their context in order to effectively relay their findings to stakeholders.” He relates the his model to the Scientific Method, so even if you don’t know much about testing, you can get a grasp on the idea behind it.

Connolly suggests a good way to grasp testing is to have groups of two working together, with one person as the tester, and the other as an observer.  The key for this to work is verbalization.  The tester needs to relay to the observer the actions he is taking and the thought behind his actions.  The observer is not silent, he must be paying attention, adding his or her input, and watching for bugs.  The important factors the tester and observer must agreed upon are the coverage of the project and the tempo at which the individuals work.

Week 1 – A Mnemonic Worth REACTing To


  • Reproduce
  • Explore
  • Analyze
  • Communicate
  • Triage

Every tester has to deal with bugs, but how should we deal with them? Brendan Connolly suggests that we REACT.  Connolly says that the first step in resolving a bug is to REPRODUCE the bug by tracking down the steps that caused it.  The next Step is to EXPLORE the nature of the bug.  Connolly warns that acting too hastily can create more problems than the bug does.  The next step is to ANALYZE the severity of the bug.  Steps one and two have given you an idea of how big the bug is and where it is, step three is where you must decide which action you should take based on the impact of the bug.  Now it is time to COMMUNICATE.  The next step is to report the bug, either to a bug tracking system, your team, etc.  Finally, the last step is TRIAGE.  After the bug is reported, the process isn’t over.  You must continue to clarify the issue as best you can.