Week 1:

The introductory week consisted of the set up for the rest of the semester; mainly being building our teams. We built our SCRUM team: ZOLINQ. The sprints will begin shortly but for now we are seeking information on our project which entails coding new features for the AMPATH section of OpenMRS. My team is actively communicating on slack to share information about these organizations.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Testers often find themselves being questioned at some point as to how a problem was tested. There’s a tendency to minimize recorded information when testing especially while running detailed instructional test cases, therefore when the question comes up, we can’t recall what we did or when.

Test cases a helpful, but they are just a model. They represent how tests can be done, but should not be relied solely on. The most important set of artifacts are the records kept during testing. Here are tips to keep in mind when testing..

The records should provide enough evidence to dismay any disbelief that the said tester did not complete accurate testing. Pair up with another individual to have a second pair of eyes and someone to back up your word. Record everything, make a note of everything performed in order to show the complete process.

https://www.stickyminds.com/article/how-was-tested-providing-evidence-your-testing?page=0%2C1

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Exit Criteria, Software Quality, and Gut Feelings

Imagine a situation, within the last two weeks the company has had eight new builds to combat every bug that had been found. Release day is tomorrow, currently there are no critical bugs due to not having a chance to retest, but technically this passes the exit criteria…..A simple gut feeling will say that it is a terrible idea to go live, but it is not your choice. How do we avoid such situations?

Create Comprehensive Exit Criteria

The exit criteria can’t be a simple bug count; it has to be sophisticated. It has to take into account the number of critical bugs discovered over the last test cycle, check that the count of new bugs has a lowering rate of appearance at x bugs/week, y days since last critical bug, etc. Looking at the overall development timeline can help better estimate if you are going to meet your exit criteria and allow your team to be more proactive.

https://www.stickyminds.com/article/exit-criteria- software-quality- and-gut- feelings

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Agile testing demands more from its testers, therefore places a higher value upon them. Here are several factors that come into play in the comparison.

Continuous Involvement

In traditional projects, it is mostly solo working with little to no interaction between developers and teams. But in agile, the test team is integrated with the Scrum team in order to be continuously involved. This includes discussions, meeting, constant interactions, etc.

Essential Tools

Agile requires more tool support than the traditional method because of the increased pace in development along with the continuous iterations. Each iteration carries over previous iterations that have to be automated quickly.

Multidimensional Skills

Traditional projects have set expectations that never really change. It’s bland. An agile tester’s viewpoint has to not only include the functional aspects of testing but advise on design discussions, usability efficiency, and reviewing installation guide steps.

Effective Communication

Agile requires greater communication skills than traditional because of the key role of effective communication among team members at all times. Testers act as the binding force of the team when they work in pairs with developers through sharing their test cases and ideas.

Quick Feedback from Testing

Agile timeframes are shorter than on a traditional project, and testing already requires feedback on a regular basis. Agile requires daily stand-up meetings, design discussion or review meetings.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

The most common situation testers find themselves in is producing a bug report. So what’s the process? You REACT accordingly.

R eproduce

The first step to prove that it is truly a bug and not a mistake is to recreate the steps to reproduce the bug. People don’t believe hearsay; they want to witness the problem.

E xplore

Take a second before reporting and look around to see if this bug is part of a larger problem. In the end, fewer reported problems are better.

A nalyze

Determine the severity of the bug and who it will affect the most. Testers are advocates for both users and quality.

C ommunicate

Report the bug, and give an informed representation of the issue and its impact. Most likely this includes sharing information at a meeting, or speaking with developers separately.

T riage

Testers continue to assist in helping others duplicate the issue, clarifying questions and any other knowledge of said issue.

http://www.brendanconnolly.net/react-to-bugs/

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Scrum is the idea of working in shorter increments; the idea of planning, attempting to execute that plan, and repeat. With short cycles, teams are relying heavily on automation but what if the test automation sucks?

There are three options in this case,

• Make it not suck

Make the automation not suck. Put effort into it and make it worthwhile. You’ll spend more time fixing than progressing if a lot of it sucks.

• Freeze like crazy

The common process is slowing down development to make time for testing then you test, fix, repeat. Since new problems arise from testing, the original problems get frozen in time only to cause more stress down the road upon return. Freezing is essentially gatekeeping as described by Maaret.

• Do continuous releases with exploratory testing

Begin to think of testing as a manual task just like programing. Test before merging changes into the mainline. More or less: stop doing scrum.

http://visible-quality.blogspot.com/2016/10/the-three-ways-to-solve-our-test.html

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

What differentiates good software testers from great?

Priority; the understanding of urgency and ranking of importance. Testers have to evaluate all tasks and adjust accordingly on the daily.

Prioritization can be categorized into three levels being the people level, the process level, and the activity level. At a people level, the tester has more interaction points than potentially anyone on the design team. They have to meet with the business team, the developers, the clients, executives, etc. With a limited amount of time, choosing who to meet with for best interest of the software can be tough. At a process level, consistent testing strategies are good but with more and more end-user expectations there is a need to adapt on the go. For example functional issues are more dependent on the OS rather than screen size. At the activity level, functional testing tends to outweigh non-functional. Testers have to maximize core testing activity.

https://www.stickyminds.com/article/setting-priorities-differentiates-great-testers-rest

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Can you develop a formula to determine how long it will take you to write your project or test that entire project that your boss is waiting for?

That’d be quite the challenge, but estimating hours that will be spent working on specific tasks is required in any positions regarding Software. “Management tends to think of Software Development as an investment”, (Lee Copeland). I’m sure most have heard the saying time is money, which is why management wants to know ahead of time how long a project will take and what the cost will be before it has begun.

Companies will make set dates for big releases; such as going live with a new Software. To do this, they will have to plan accordingly regarding how long it will take to finish current bugs/problems, test the entire system, then take care of more bugs that will surely arise as they always do. At this point, as a developer or tester, you have a date that you HAVE to meet. All of the bugs have to be fixed and tested by said time. Can you account for problems that can be caused from fixing one item? Can you account for discovering new problems while testing?

There will always be an amount of uncertainly in giving a estimate on how long, but take your guess, multiply it by at-least three and you should be all set.

https://www.stickyminds.com/article/why-estimating-software-testing-time-so-difficult

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Software is invading our lives whether you know it or not. I highly doubt you can go a day without using/interacting with some form of software, don’t believe me?

Sure, you might be able to fight the will to look at your phone for twenty-four hours, but can you avoid driving your car? Watching TV? Eating at a restaurant?

Vehicles have computers that are tuned for maximum efficiency, there are vehicles that can DRIVE THEMSELVES, TV’s are TV’s, and restaurants use software to keep the order system in track.

We can’t avoid it anymore, and it is too late to turn back.

Software is love, software is life.

http://blog.coverity.com

https://www.stickyminds.com/rss-cmcrossroads

http://curioustester.blogspot.com/

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Hi everyone!

My names Kyle Polewaczyk. I am an intern for Small Business Service Bureau, a small business insurance company, where I practice CRM Developing/SQL Developing. Outside of work my hobbies include skateboarding, video games, and Crossfit.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.