Meeleetester

Most blogs on test automation are about how to add more and more tests to your automation suite, but rarely does anyone mention that you also should consider removing automated tests, especially those that do not provide any value. If you are on a new and relatively fresh project, you probably focus most on adding automated tests across different layers, focusing on automating regression testing certain parts of your service that you create. As your service mature, you probably have built up a good chunk of automated tests and you keep on adding more and more automated tests as new parts are added. Now instead of 10-15 minutes, your test suite perhaps need 20-30 minutes to run, and it becomes heavier and heavier to regression test new code. (This can probably be solved by other means of course, but consider this an example, there could be more reasons why you have a test-heavy delivery pipeline) Seldom does one consider the possibility of removing tests, not only in order to reduce...

So where to shift now that testers are part of reviewing the business cases, participate in creation of user stories and backlog grooming, have the ability to use monitoring in different environments, and everything in between, meaning participate in different parts of the software development and delivery life cycle? Well, I think that we could benefit a lot from trying to look at where we generate mistakes. If we sum up the development life cycle, regardless of how often you release, or whether you follow a  waterfall, agile, or devops approach, it all starts with some ideas, business cases, requirements on a higher level, before going into the process of refining the requirements, developing, testing and releasing the changes to the end-users. We previously shifted left and right trying to mitigate and correct issues that occur along the way in the process, without looking into where these mistakes originated. All of the ideas or requirements start in someones mind, with all...

2010 - a full year in, "if testers are not involved early, we do not want to be involved later" After being employed full-time for a year or so, we finally completed a full circle of releases, both the major releases involving a full scaled up beta/pilot program, and some minor releases, as this was taking place on a yearly basis. After each ended project, a small group of people from different teams formed a retrospective team, to go over what was done good and what could be done better next time, for all projects individually but also as a whole. This was before any agile methodologies were introduced. During the retrospective, or post-mortem analysis I think it was called at the time, we from the test team argued that we were not involved early enough and that we ended testing specifications that were well out of date due to our late involvement. This was taken into consideration and that from next phase we were to be included in all start up meetings, and walkthroughs...

Today it is almost unthinkable, with the teams that I work with every day (read - in my context), that some team members inside a software delivery team are not involved in almost every phase of the software development life cycle. Looking back some years ago it was certainly not like that, specially for testers. In this, and the coming posts I will share some of my experiences and thoughts on this subject as well as what I believe where we should shift in the future;  left, right, or even more left, and right... 2007 - The first experiences, part-time tester, waterfall I started to work with software testing in 2007, as many of us in the field, by chance as a part time tester. At this point the company that I worked for did not have any full time dedicated testers, only a team of part time testers who rotated, and worked at least 2 days a week. The team consisted of students studying economics or computer science at master level, who could work at any time of the day/night, ...